Saturday, April 14, 2007

How Should a Web Team Work?

Try as I might I've found little research on how a corporate Web team should be structured. Should developers work directly with front-end designers? Should content producers be involved in architecture? Should anyone other than IT know what's going on with the servers? I work in an environment where each element of the Web site is handled by different departments:
  • Server maintenance
  • Hard-core development (applications, eCommerce, etc)
  • Database maintenance and development
  • Front-end design and architecture
  • Content development
  • E-mail marketing
  • Enterprise applications

These separate departments don't necessarily play well together and are rarely looped in on each others' plans or projects, operating largely in their own silos. Is this how it should be or should they all be under one, centrally-managed group?

How are other "Web Teams" structured? Bear in mind I'm not talking about agency Web teams, I mean Web teams internal to a corporation or association. These teams work together over the long haul and may evolve over time. They're not the streamlined, project-focused teams you'd find in agency and members may wear several hats and manage several different Web sites like intranets, extranets, external sites, enterprise applications, etc. They may be called on to handle the minutiae and whims of departments throughout the enterprise.

I've yet to see an optimal model for this kind of team, but I will keep looking.

1 comment:

Fumbles said...

I too am amazed at how little information there is on web teams (especially in house web teams).

Don't know if you've seen Jesse James Garrett's nine pillars of successful web teams or not (it's a good place to start) but it doesn't tackle any of the more "infrastructure" type of issues that you've raised.

In a shmaless self promotion, I've just started a blog about managing web teams (I don't claim to be an expert, but I'm hoping we can kick more of discussion off).

I'm not so sure regarding the optimal interface with IT, but one thing I have found reaaly useful is being able to have someone from the design side who understands enough about boxes and wires to talk coherently to IT, and soemone from IT who understands enough about business to talk to the design team without disregarding them as "artsie". If you can get these guys together you really can get through a lot of hold ups.

One area that I think is being writen about more and more is how to combine Agile development and user centred design. For me this looks like the best option by far, but can't say I've actually been through the transition yet, so I can't guarantee that it's the solution you're after.

Lucy