Organizing Your Web Services Division?

Anml4ixoye asks: "I currently work for a county government as their senior webmaster. Before that, I oversaw the internet development for a large credit union. In both places I ran into the same issues. What should compose a web services team, and where does it belong within an organization? I notice that larger companies such as IBM have separate departments for their web sites (VP of Web Site Operations). So my question is, should the team that handles the organization's web site be its own entity, being solely responsible for the hardware, programming and implementation of the web site, or can those tasks be effectively split between several sections and still work? Can anyone give some insight into how it works within your organization?"

"For example, at the credit union, the position I was hired into was brand new. They wanted to bring their web site in house. Their solution was to hire a Manager of Internet Development (me) who was responsible for determining the needs of the credit union, setting up the servers, doing the development and programming, and maintaining the site. No staff, and they wanted the site up as quickly as possible. I spent most of my time reporting back and forth between the VP of marketing and the Director of IT. When they finally figured that wasn't going to work and tried to have me report to one department, they couldn't figure out which one it should be so they eliminated the position and outsourced the web site again.

I am running into the same thing at the county. I came on about a year ago to a web site in shambles. The previous 'web team' consisted of an Internet Administrator, a team leader, a webmaster, a web data specialist, and a web temp. The team leader wanted them to be their own section, but unfortunately, he did it by power-playing and burning bridges. The Director of IT came through and broke the team apart, firing the team leader and the web data specialist, releasing the temp, and splitting the remaining team between the Distributed Processing Management (DPM) and the Network Administration sections. The other webmaster left about two months after I came on, leaving me as the sole webmaster for 3 sites of around 80-100 thousand webpages. We are finally back up to staff (another webmaster and a web-data specialist). The challenge we are running into is that in order for items to get on the site, they are designed by the departments, approved through our communications department, then passed on to us to integrate into the site. If we have a server problem, we have to contact Network Administration, even if it is something like having a Data Source Name set up.

To further challenge matters, the manager we report to has 28 people who directly report to him, including us.

With the size of the sites being what they are, it wouldn't take much for the whole thing to fall apart, and I am trying desperately to prevent that from happening. I envision an Information Architecture being put into place which would allow us to work on content management, instead of building these pages by hand. But I seem to run into obstacles every where I turn."

Comments

Here at CESDIS...

[Walter Bell]

We have found that having a small web services team that is directly accountable to a high level manager is important. In fact, our web site is currently down because of a reorganization in that area.

We had similar problems in the past few years. In fact, our web services used to be run by the IS department, who used our web site to try out "new and cool" technologies. That is one reason why we were, until recently, running web servers on HURD, BeOS, and AtheOS platforms, with little coordination amongst them. We also had trouble keeping up to date on patches, and nobody seemed to want to learn enough about the novelty OSs to support them properly. In effect, our web site became a toy for bored administrators to tweak. Not a good idea when we've got millions of dollars in funding riding on the public and the Congress being able to measure our progress as an organization.

So, in a business, it would probably make sense to have a dedicated VP who oversees the web site, along with several senior technical people who approve changes. Although everybody hates red tape, it's simply not a good idea to trust a couple of recent CS grads not to mess up the company's image by goofing up the web site. Changes should all require approval, and unapproved changes should be grounds for dismissal. That is how we are doing it, so stay tuned to see how well it works when the site comes back up...

~wally

Separate design, coding, and administration

[revscat]

The best models I have seen have different groups responsible for the design, the coding, and the hardware. The design people are usually the freaky Mac types, the administrative people are the moles who are really into that kind of thing, and the software people are the attractive psychologically balanced ones who do the actual work.

Ahem. Excuse me.

Seriously, the separation of labor between these three camps works out best because it allows each group to maximize their specialty. If you have some designers with good HTML skills, then your coders can, for example, just drop in, custom JSP tags where appropriate without having to mess with the web server or design principles. A group consisting of people who have a lot of knowledge in one of these areas and a little knowledge in each of the other two tend to perform best. I hate to use the word "synergy" but it really is appropriate here.

Depending on your resources there are other areas to consider as well. Q&A is extremely important and can help the developers to more efficiently debug. Content writers and proofreaders are important as well; someone who can tell the difference between "your" and "you're" can be a real boon to your professionalism.

But the basic web team, IMHO, should minimally consist of the three core elements I listed above. The most successful projects I have worked on have been variotions on this theme.

- Rev.

Tips From the Big Guys:

[corky6921]

I work for a large company doing web development for the external site. There are several problems with our website. Since our group (Internet Engineering) is in charge of future development for the site, we've charted out the problems and their solutions. Here is a short synopsis:

• Content management system. It's crucial when doing a large website. Ours is horribly outdated. Keys to a good content management system: it should be web-based, and it should be a standard, out-of-the-box solution with as little customization as possible. It should allow for maximum flexibility. (We've run into problems with ours not supporting custom META tags, for instance.)
• Don't let IT run your website unless you know all of IT personally. In a large company, unless you have a dedicated (and by that I mean reporting to the same VP as your core web team) IT department, you're asking for it. If I told you what IT refuses to do to our website, you'd be shocked. For instance, we only support {ancient scripting language}. We were supposed to have other scripting languages supported this year, but that hasn't happened. Our department is slowly absorbing IT's functions so we can crank things out faster. Meanwhile, we continue to get last priority with IT, and we don't have the root passwords to our own servers. (In recent months, they have given us tools to check log files, but that was two years in the making.)
• Follow IBM's rule. You mentioned IBM's web services division. In fact, IBM is the standard by which most other e-commerce sites should be judged as far as organizational hierarchy. IBM did a presentation earlier this year about their web site; basically a "tell-all". Several other high-profile companies attended. Someone asked an IBM person why they did the informational session; the reply was "We're so far ahead of everyone else; we don't think anyone can catch up." Key point to IBM's success: totally separating nearly EVERYONE who develops for the web site under the same department. If you have someone in each department doing the website, you're going to get a website that defines subsections by the organization's departments, some of which may be mumbo-jumbo to outsiders. For instance, "Information Services". What is that? Separating products into categories like "Software" and "Desktop Systems" is much more meaningful, but this can only happen if you have one group in charge of the web site. Otherwise, the tendency is to title subsections by the department name, which results in some weird naming conventions.

Where I work is not important; what's important is what you can learn from our mistakes. Every major company has organizational problems with their web site. Your company must take these issues and deal with them now as opposed to later. A content management system is an invaluable tool in helping with these issues. Most feature workflow routing so you can have one manager signing off on several people's projects before they get published. You can then also hire graphic designers without having to hire a complementary Dreamweaver jockey; good systems create HTML and correct menus for you in a lot of cases. Most take the Developers / Graphic Designers / Managers / Administrators approach, where they place you in one group and you get different tasks according to what group you're in. This may or may not work for you; the good thing is that in a good content management system, you can customize it to fit your needs.

It's great that you've asked this question when your group is still small. It shows a lot of forethought that the older, larger companies didn't have time for. In a lot of respects, you're lucky: you can design an ideal system. Just make sure it will scale and that you can easily upgrade if some new time-saving feature comes out in a year or two.

Ideal Web Team

[Andrew Wiles]

Yeah, it makes sense to have a single group in charge of the company Web site. This eliminates duplication of effort and -- more importantly -- makes sure your whole site has uniform navigation and graphics so that users don't give up in disgust. Stuff like a single sign-on is also important for huge sites.

For a medium-sized site, the team should consist of:

• One person who can spel
• One person who can coordinate colors
• One person who knows how to reboot NT (or edit an .htaccess file), install patches, and who handles stress by kicking ass
• One attractive, well-adjusted coder
• One trained (web)monkey who can take copy and pictures from 3 million incompatible sources (i.e. your marketing and sales departments) and turn it into web pages

It doesn't have to be exactly 5 people, but some number of people who combine to cover all these skills.

Oh, yeah, I forgot a really important one:

• One person with good tech vision who can make sure the other guys don't make things too hard for themselves. This is the person who makes sure the system everyone uses for plugging the content in doesn't get too complicated, that the programmer doesn't spend 80 hours trying to implement those dumb Javascript menus desired by Marketing, etc. This person is also the hard-nosed schedule Nazi who is responsible for Getting Things Done. He or she has to have a tech background, and must be able to communicate with the suits.

This last person isn't necessarily more important than the others, but he/she is harder to find. Lots of projects fail for lack of this guy, the one who tells the other suits "That would be too expensive," and "That would take too long," who sets expectations so that when you (the programmer) have done a damn fine job, the rest of the company knows it.

If you haven't been in industry yet, you have no idea how important that is.

Well THIS is a fun question!

[Anthony Boyd]

First off, let me say that of all the responses, you need to be listening to corky's response the most. Having worked on some huge sites myself, I can confirm that he appears to actually speak from experience. As for my experience, I've worked at 4 companies since I got into the Web in 1994. Here's the breakdown:

• At Borland in 95-98, the Web stuff was part of "Electronic Marketing" which was an offshoot of the Marketing group. IT ran the Unix servers, but I and 2 others built most of the apps as part of the Marketing team. IT eventually tried to deploy StoryServer for content management, but it was terribly inflexible at the time. Since I had been building highly creative, DHTML games and presentations to hype product launches, I couldn't resign myself to a future of paint-by-numbers page building. I bailed.
• At Actuate in 98-00, I was the sole Web person for most of the time. I was in Marketing. It was flat-out miserable trying to convince the VP we should be using Oracle instead of Access or MS SQL Server. I was forced to use technology based upon who we partnered with rather than upon what was superior. When I left, the CEO offered to move my "team" into its own department, reporting directly to him. I should have listened to him. He was right.
• Arzoo was a Web company, so I was part of the design team. There was no IT or Marketing, not in any substantial sense. There were a few product marketing people, and they mostly used my team to create content.
• At SST, I am currently part of the IT department, and I run a small team called "Web Technology". This seems to be the best balance for me now. I have a lot of Marketing under my belt, so being in IT has allowed me to build a technically competent team but I focus them on the company's image, helping Sales, and so on.

In my experience, the best solution is autonomy. Being in Marketing, you are going to butt up against people who are driving technology decisions but have no clue what they're talking about. Marketing people should not be managing developers. In IT, the Web will either be too rigidly controlled, or will be a hodge-podge of all the various new technologies the geeks wanted to play with.

At SST, the saving grace has been the content management system, which we've built entirely ourselves. It's simply a few Web forms that dump data into a database. And then other Web pages use that data for display. But what is sooooo important is that each form has an owner, and that person is responsible for filling it out when needed. Each time we deploy a form, we free IT from the manual labor of building and rebuilding pages upon request. We are also able to tie in automated signoffs -- some content goes to a manager for approval, some content is published immediately. Whatever the case, you need a content management system. A small, nimble one.