The ideal web team (so they say)

Published on:

Peter-Paul Koch, on Digital Web Magazine, has the recipe for the ideal web team (part 1 and 2).

This article is targeted at web agencies which want to create web sites, and that is pretty much about it. This is not clear from the title and notably this recipe would prove less than ideal if applied as is to create a corporate web team.

Let's see what the main differences are. To do that, I need to highlight the three main steps in the life of a web site:

  1. Design. Going from a simple idea to a complete design.
  2. Build. Going from a design to a fully functional web site.
  3. Run. Managing the ongoing operations: hosting, content management, interaction with the audience, metrics, evolutions, etc.

A typical agency will focus on the design and build aspects and stay as far away as possible from the run side. A company may handle all or part of them but needs to focus in particular on the run aspect. If I need only one reason to explain why an agency web team is not ideal for a company, I will focus on this one.

The suggested team leader, for an agency, is a project manager. While a web site manager definitely needs project management skills, thinking of a web site as a "project" -- therefore giving it on the hands of a project manager, a project team, etc. -- is completely missing the point. A web site is a customer touch-point, and running your customer touch-points as projects can be a pretty bad idea. If you are serious about your web site, it is managed on an ongoing basis by someone who has your audience in mind at all times (this implies customer-facing skills and a good grasp of your communication and marketing objectives), the knowledge of the numerous aspects of this particular media (the techniques as opposed to the technologies), and more importantly the capability and power to decide what makes through the home page, the scarcest resource of a site, its most valuable real estate. This is my personal definition of a webmaster, but since I am an old-fashioned one(*), do not take my word for it and name your web site manager as you see fit.

You should see now why the "run" side of things takes precedence, for a company, over an agency (or a project team) "design/build" roles. There is a dichotomy here that, if underestimated, may create real problems for the company web team. This DW article, in an involuntary way but that is what makes it interesting, demonstrates the thinking gap of agencies regarding the run aspect:

Occasionally a Web site project will employ other supporting specialists, like system or server administrators. Their job is not to create the Web site but to make sure it can run on the system(s) meant for it.

Note how the hosting aspects are optional and disconnected from the design/build (creation) roles. But the real problem is here (emphasis is mine, where it hurts):

First of all, the team will have to select a server-side language. Will the applications be written in ASP, Perl, PHP, Java, ColdFusion, or another language? Although proponents of one language or another are quick to point out the advantages of their favorite and the disadvantages of other languages, in practice a server-side language is seldom selected because of these arguments.

Instead, the availability of competent programmers is the most important requirement. For instance, Java could be the best language for a certain job, but if your company only employs ASP programmers, choosing Java is not a good idea. Usually ASP can do the job, too, though it might be less efficient.

Without extending this judgment to the entire article, I think this is a very ill-conceived suggestion. While it may make sense for some agencies (if you have ASP-only competencies, do not sign for a Java project), it is one of the greatest mistakes of web development. Or, as a matter of fact, of IT development in general. Most developers do not have a clue of the "run" side of life, in the present case the hosting aspects. They will, as DW advises, pick back-end technologies according to their own agenda which can be far remote from the client's operational environment, leading to discrepancies such as an ASP/MS SQL site landing on a Linux/PHP/MySQL back-end. Here you can take my words for granted, I have seen this happening too many times for it to be a coincidence. "Good afternoon! I understand you are the webmaster, I have this brand new ASP site for you that needs to go live tomorrow morning, where do we FTP it?"

Agencies that are following this model, i.e. ignoring the run environment of their clients, are not serious. And a company that is not careful enough may be happy to get a brand new site for a cheap fee, only to discover that its hosting costs have increased and their site reliability decreased, on an ongoing basis.

I will not pretend I have the recipe for the ideal web team, a title that is making a promise difficult to match, and that some may find rather pretentious. Your mileage may vary but mine tells me that there is no such thing as a universal web team model, as each enterprise is different. There is a simple acid test every one can run: define what is a webmaster (or a web manager). You will get a lot of different answers, potentially one per enterprise.

But I hope that you will find this little advice valuable: your ideal web site manager needs to be strong on how to run a website to be better equipped on how to handle the design/build aspects. And if you help him/her to build a team that fits your and your clients' needs, here comes your ideal web team.

(*) Disclaimer: I wrote that article for my company e-zine about 2 1/2 years ago. It was edited to fit a different audience and the e-bubble had not yet bursted at the time of writing. Since then, about 17 web years have passed (the webmaster's life is a dog life, so I get 7 years for one) and more lessons have been taught. The apprentice hidden in the webmaster would like to rewrite this, but will relegate that task on maintenance mode unless there is significant interest out there.