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."

Committees

[fishebulb]

Avoid committees's like the plague. No matter the organization, too much dependance on a seperate group making the decisions will only foster a failure. Its not as much a problem with splitting the group into sections, but rather the people that oversee those groups. can you make descions together between sections, or will you be needing to go to the higher up, which then calls the dreaded meeting.

Re:Committees

[j-jahnke]

Apparently you have never worked for gubbiment at any level, committees are how things are done, consensus. Isn't the always the best way to get things done, but remember the person who you must please most got his/her job in an election. As such they MUST have some input. Universities work this way as well, but becuase faculty contribute to departments via outside funding.

So having said that, when I was tangentially involved in a similar fiasco, the reporting went like thus. The actual nuts and bolts of the operation went via IT. The programmars and machine administration was done via IT content specialists were in Marketing (actually they were departmental admins, but liked it when we told them they were Marketers.)

We had a template all departments were supposed to conform to, none of them liked it, but the template had it's own process which was a big ass committee and was updated on average every 9 months. This way if there were complaints about how the template looked there was a committee to redress it, and we had a stable spec from which to operate. It also effectively lets you turn away requests to do one offs, which are time wasters, you can just point to the spec and point out that what user XYZ wants can't currently be done and to bring it up at the next template meeting.

The IT guys were responsible for maintaining the template, keeping it consistant with what the template committee wanted (if you wanna hear boring some of those meetings were real dooozies, arguments bout font size and exactly how things should be named, as well as what EXACT colors should be used for what banners.) Anyway becuase we used a templated approach the content folks just opened up the editor which was online and inserted the data they needed. When the template was changed they did not have to reenter data it was just plugged into the template.

By doing this we put a clear line of seperation between what was content and what was IT and no one ever got too bent out of shape about it. But like I said what helped the most is that what things looked like was defined from the start and it was then our responsibility as IT to provide both the tools and server support for the content people, they could do it if they wanted but 9 times out of 10 they just came down with drawings and floppy discs and let one of our own interns plug it all in.
IT was happy becuase my programmers had a well defined set of tasks to work on, not an ever growing long list of one offs that had to be done for X, Y or Z. We did have a lot of push back when we moved from departments doing their own thing and moving into the template so we used a carrot and stick approach. We told them we would take their current system and convert it to the template form. We would then tell them once converted we would no longer support their old web infrastructure. If it was on our machines we turned it off, if it was on their we never came to fix the problems.

The deparments liked it becuase they could participate in what the template looked like and we did most of the work. They had a set of tools which let them modify the data whenever they wanted.

In all I have been gone a few years the process is still in place no one loves it but it has not devolved into pure chaos again either.

Jer,

Re:Committees

[TinWeasle]

A Camel is nothing but a horse built by Committee.

Process & boundaries are key

[Hoonis]

If you are working at a startup, you can do it all
yourself (hardware, design, code, maintenance, etc).

The age-old conflict is the IT people want it
maintainable, always up, and conservatively
designed, marketing wants to do things on the
seat of their pants without advance notice..

I separate the server maintenance from the updates. I manage a colo, server, backups, and the cgi parts of the server, the contractor of the week does the design & updates. The tools I have built are all designed to have no ongoing maintenance from me (IT reporting).

If you can make that clear from the outset,
you can co-exist well with a marketing department
or a PR branch etc that needs an effective
publishing platform. These boundaries sometimes
result in conflict:

Do it quick
Do it stable/well

but rarely does it become catastrophic if you
work with good people.

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

This Guy Is Full of Bullshit!!!!

[Anonymous Coward]

Honestly, the moderators are just completely clueless. Do they mod up posts that only sound good?

I honestly doubt that "Walter Bell", a systems engineer at NASA would have time to post so much on slashdot.

I work for a government contractor, and have seen government systems, the idea that they would tinker on niche OSs is completely laughable. They are usually the LAST people to move to the latest platforms. The computer technology used by gov't is hardly cutting edge.

So while this guy might have a web server with HURD running, it definitely is not commmon to see.

Well you're wrong

[Walter Bell]

Unfortunately, it seems as though your contract job hasn't given you the experience it takes to realize that different agencies in the government actually have different setups, needs, and "corporate" cultures.

Your post is tantamount to saying that because the Navy standardized on WinNT, it's obvious that nobody at NASA runs Linux.

Please check your arrogance at the door before you post again.

~wally

Re:Well you're wrong

[jmarpet]

Whether Wally is or is not a NASA senior/junior/nobody/somebody, at this point doesn't matter. There are many ways to get an idea across, even a vehement idea, without resorting to the ridiculous amount of cursing and plain old nastiness that you have spewed here.

NASA is one of the most autonomous government agencies there are, answerable to the government for only funding and results. Does this mean they don't follow the rules? No. Does this mean they can feel free to test things, such as Niche OS'. Perhaps. I am not going to rule it out, and your posts lose much credibility with your attitude.

feel free to reply to me offline.
[e-mail]

Joshua
cc'ed to Wally offline

Re:This Guy Is Full of Bullshit!!!!

[ameoba]

Of course he's full of bullshit. I can't think of many places where somebody could get away with setting up a production webserver on the hurd, or AtheOS (I can't even get it to format a partion w/o crashing) and keep their job...

...and BeOS should at least result in beating.

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.

Re:Separate design, coding, and administration

[mrjohnson]

-The best models I have seen have different groups responsible for the design, the coding, and the hardware.-

I definitely agree with you, but his boss and the other department heads are going to be worried about another power play. So he's going to be perpetually under staffed.

If this guy wants to get the job done under these circumstances and still have time to occasionally sleep, he's going to have to work on streamlining everything. My suggestion: start small. Get together the smartest people that you can get your hands on. Make them design something *simple*, something that will grow into a full-fledged site later on.

Most importantly with such a large site, it should take no longer than five minutes to add a new page. Period. Insist on it.

By emphasizing planning early on, you'll be able to make the changes you know they're going to request down the road. You won't get the resources you need right away (or maybe ever), so focus on being a *really* nice guy, and make some friends. Have a good time, but be forceful when you need to be.

Re:Separate design, coding, and administration

[antdude]

revkat: Shouldn't Q&A be QA (Quality Assurance)?

Re:Separate design, coding, and administration

[cornflux]

The best models I have seen have different groups responsible for the design, the coding, and the hardware.

I agree that this model is probably best. That's pretty much how we're set up at where I work. Well, except we call them different things: (technical) production, (software) engineering, and (web) operations, respectively.

If you set it up this way, you'll also be able to set up some good project "standards and practices." For example, a producer should create some sort of spec that the engineer codes against; the producer and engineer should do a sanity check with the operations person; etc.

Re:Separate design, coding, and administration

[dragonfly_blue]

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.

I think you mean "boon to you're professionalism.

(ok that was probably funnier-sounding in my head.)

email integration

[Technodummy]

I noticed you have an email form [hillsboroughcounty.org] on your website. It reminded me about something almost no webmasters seem to take responsibility for. Email customer service.

MAKE SURE SOMEONE IS READING AND RESPONDING TO EMAIL.

You wouldn't (well, you shouldn't) have incoming mail or phonecalls that no one checks and responds to, so don't do it with email. If someone goes on leave, either monitor their inbox, or set up an autoresponder (always check they are actually working, and keep checking it).

If you have a large volume of email correspondance, have a seperate email response group, don't allocate it as something to be done in spare time.

Have a procedure about how all this is to be done, and how long it should take for email to be responded to.

There will be people who are supposed to follow this, who have no idea how email really works.

Email is not an optional extra if it's used for public or client contact.

If I rang a store or office and left a message, and got a return call 2 weeks later, I wouldn't be impressed. Same goes for email.

Think this isn't the responsibility of a webmaster? who knows the mail links are available to the public?

Unless there is a notice near all email links that it is not a priority for replies, or to expect a delay, most people will assume a quick response.

Now while the monitoring etc may not be what the webmaster is doing, someone needs to make sure the rest of the organisation is using the website properly.

Letting the web group know when email addresses become defunct, or staff leave/arrive.

Letting the web group know when staff are going on leave, or are away for the day (if one day makes a difference in your work).

A website is like a virtual office in a lot of ways, and it all needs to function properly.

Don't be a weak link in the chain.

Re:email integration

[Anml4ixoye]

Actually, this is one of the best parts of the site. We use a Citizens Action Center that handles ALL incoming email, and forwards it to the appropriate department. That form you saw is used in every departments section as a way for them to contact us. That way if someone leaves it still goes to the right person.

We also use an autoreponder that is immediately sent out, and they will be contacted by phone or email. And if it is destined for one of the commissioners, we have a Correspondence Tracking system that assigns it a number and is tracked throughout the organization.

you're way ahead of most

[Technodummy]

keep it up :o)

Make it part of IT - needs to be a core team

[ZPO]

Spend some time building a plan and make damn sure you have a single reporting line. The dotted-line/solid-line/dual-reporting scenarios are just a great way to get yourself used as a pawn in a power game.

How independent the team is all depends on how integrated the web site will be with county operations. Is it generally just a static window on the county or can folks actually lookup info, search jobs, read government reports, etc, etc, etc?

I'd say the web team should be an independent entity of the IT department. The web team would be responsible for the servers, security, processes, and base content. They would also be responsible for the style-guide (and the gloriously fun task of getting it fully approved).

Each county department/division gets their own standard 5-page setup (mission, history, news, blah, blah). Additional content is reviewed and billed back to the request department to keep from overextending the IT/web group with the demands of each department. Since each department typically has their own budget lines (and cost centers) this might work well for you.

Re:Make it part of IT - needs to be a core team

[Anml4ixoye]

We have quite a bit of integration into the systems. We allow citizens to search for permits online, sign up for updates, customize portions of the site (thought that *needs* a redesign), and quite a bit else.

And we actually bill the departments for the work that we do. If it is under 8 hours, we set it up as a help desk case (IT staffs a help desk off-site of 6-8 people who handle all tech support calls), otherwise it becomes a project. If it is really big, then it becomes part of the Strategic Automation plan, which are things like (for example) creating a system to tie into our 911 dispatching system that would automatically map out the route the ambulance or firetruck would go and beam it to a Palm 7x wirelessly so they would have it there.

Thanks a lot for the input!

Largest Site

[Vardamir]

Speaking of which, who has the largest amount of data on a web site? Could it be IBM, or C-Net, or e-bay....?

Re:Largest Site

[hearingaid]

I doubt it's any of those three, although C-Net is probably up there.

This [ic.gc.ca] is the biggest site I know of. However, it's also one of the most poorly organized, with probably terabytes of lost documents.

Re:this IS the largest site

[Boxcarwilli]

Oh ya, you pinned that one down. Archive.org by a freakin longshot. Too Cool.

Web Site is three things...

[jackb_guppy]

Hence three different departments.

First the content... Pure Sales / Marketing

Second the machines... Operations

Third the Software... IT

The webmaster should NEVER be the operator. But could be the a coder - but not the best use of their time.

You want the:

Webmaster to be artful, help place a "good face" on the company.

Operator make it run day in an day, plan for backup and outages, fall overs and upgrades.

Software to build it on the machine and make it look like the webmaster wants. Coding in the main frames, the sql servers and the web hosts.

You need to think of web development as program development. GUI=Webmaster, Business Rules=Software, Data Storage=Operator. With that model work gets done, by the right people for the greatest impact.

Re:Hillsborough

[Anml4ixoye]

Actually, that page is maintained by the Hillsborough Sherriff's Office IT staff - not us. We get a lot of that confusion though, so I understand completely! :)

public websites

[thedeacon]

If you have access to a few boxes, I would suggest setting up a *BSD or GNU/Linux server and showing your higher ups that there are ways to manage content and that you and your crew can competently maintain and control it. Maybe, if they are reasonable, they will loosen your reins and you can get some of the things you want to do done. Nothing quite like having everything in-house if you can swing it. Don't forget to mention that getting the OS and associated software (Apache, PHP, Jakarta, MySQL, PostgreSQL, and the like) are free!

Good luck to you and your dealings with the red tape of public employment. I have been there.

Re:public websites

[rjamestaylor]

Choice of technology has no bearing on this question. Or did you know that and just decided to troll?

How about Fagan Inspections?

[imrdkl]

Web people need more B&D, imho. Nothing like good Fagan Inspection [stickyminds.com] to keep things sane and controlled.

Re:How about Fagan Inspections?

[RennieScum]

Web people need more B&D, imho.

What does the maintaining a website have to do with bondage and discipline?!?

Oh, wait...

Make content owneers work for you

[Infonaut]

The government agency I used to work at hired me as their first official webmaster. I was placed in the Public Affairs office, but I also reported directly to the Chief of Staff. Of course, in order to effectively manage content, I had to take information from several different departments, all with their own agendas. Prioritizing whose content would go up where and when became a nightmare.

So I decided to change things around. I formed a committee (yes, an evil committee, but bear with me). The members were mid-level people from each of the dozen or so internal constituencies. We met twice a month to review the direction of the site. They would inform me if something I was doing bothered them, or if they wanted something new added.

I would also meet individually with these members, and we'd prioritize the content for their department. I'd then collect all of the content "wish lists" together into one master list. The committee members could then see the entire list, and see where their items were on the list. I'd have the Chief of Staff review the list as well, and since they knew he'd signed of on it, they couldn't hassle me when a priority of theirs wasn't high on the list.

The best thing was that these mid-level people were the sole content managers within their departments. All content for that section of the site had to go through them, and then on to me. If they slacked off on the job, or didn't help me out enough, I could talk to their supervisor about it. If they did a good job, they got kudos from the boss, if they screwed up, everyone in that department knew why their part of the site was lagging.

It wasn't a perfect solution, and it can't be applied in every organization, but it helped me maintain my sanity as the sole person developing and maintaining a 1,200+ page site. Even though I left three years ago, the structure I put in place is still being used, and the site has more than doubled in size.

The key to it all is that you have to try and understand human nature. Everyone wants to sharpshoot you if you fail, but by setting up a system that puts other people in the loop while still giving you primary control over development, you can keep your sanity, and more importantly, build a system that will work for everyone.

Best of luck - I feel your pain.

My company

[JediTrainer]

I don't know what the optimal is, but this is how it works (more or less) at my company. I will not give out any individual names nor the company I work for to protect the guilty:

Marketing owns the content on our web site (the www.com address). They can access and update the docs themselves.

A separate entity, E-Business, owns a separate site which runs our app. The people in this org manage the application and content on this server.

The IT department ties everything together by managing all of the server hardware, os and network configuration.

Basically, this structure helps our company by keeping the people who know a certain area best working in just that area. The coders do the coding, the designers do the content, and the IT guys manage the hardware aspects. Most of the time this works out ok.

The frustrations come in mostly when Marketing or E-Business run into network problems, and have to turn to the IT department. Unfortunately this particular IT department isn't a very reliable one, often ignoring or conveniently 'forgetting' about a problem until you have to pester them to look at it. Problems that take 15-20 minutes to fix are left broken for days until you come back to bring it up again. And again. And no, they are not overworked. They also have a habit of changing things around (IP addresses, router configuration, firewall 'upgrades') without notifying the other departments who run dependant services. If these guys worked for me, they would have been fired long ago for their work ethic and lack of organization. Since they don't work for me, and they're not even in the same branch in our org hierarchy, I can't do that. You have to make sure you've got a decent IT manager who can control this sort of thing. Too bad this particular one can't (his employees reflect his own behaviour).

Same song

[bckspc]

I experience a similar phenomenon at the non-profit [hrw.org] I work at. There is no Web department. Nor even a real Web budget. Our 'Web Master' is in the Communications Department. I'm the 'Web Advocate' in our Advocacy Department. Our Publications Director does his own coding. Our IT Director has a consultant that tweaks our server box - which is now in-house since our previous host [interland.com] merged and lost what little brain power they had left. There is no central managing authority or oversight and instead we have an 'IT Committee' that meets every other week to try and do the job of a Web Director. The budget is all ad-hoc and barely gets us through. We also manage content in six languages, relying mainly on volunteers and interns. I argue for a Web Department and a budget, but org. management just doesn't want to hear it. Needless to say there is nothing resembling a strategy or plan. It's a constant battle just to get through the week.

And what is your point?

[/dev/trash]

That's life in the real world. Get used to it.

Re:And what is your point?

[Anml4ixoye]

That's life in the real world. Get used to it.

Sorry. Some of us see the web as a useful tool, and want to make it something that works and is enjoyed by everyone. Is it an uphill battle? Sure. But each and every positive (and not-so-positive) comment I have gotten has not only shown better ways to do it, but made it worth it.

Sorry for making you roll out of bed to comment.

Re:And what is your point?

[/dev/trash]

That's funny. The web as a useful tool.
Anyway I was commenting on your fruitless battle to get departments to work together cohesively. It won't ever happen.

Re:And what is your point?

[Anml4ixoye]

Ahh, I see. Many apologies, for you are most correct on that.

Almost any structure CAN work...

[JudasBlue]

I have worked on large web sites where my teams were almost all cross-functional, dual-reports with other departments and on teams where I had direct control of all my assets. Both can work, but the problems are a little different on each side.

When working on cross functional teams, the key is politics and bridge building. Find someone in each key department who is going to be fully reponsible for your contact and work within that department. This sounds self-evident, but I have been places where random PR people seem to take whatever parts of various web projects that interest them. This doesn't work.

Once you have a single point of contact, constantly keep that person's manager in the loop on projects and goals for web efforts. Give them some mindshare in your projects. Get them vested in what you are accomplishing for them. Also carve out very defined work boundaries and proceedures for the duties of your contact person.

Next, when something works, make sure you slather praise though the organization that hits the managers of your cross-reports. You team will get its due because the stuff is obviously up on the web site. Make all your praise to the people you need to keep happy to keep getting work from your cross-departmental memebers.

I have found this to work in organizations with the right culture. The thing is that with cross-departmental teams, the majority of your job becomes consensus building and coordination. I have had this eat up almost all the time I would rather be using on real work. But it is the nature of the buisness.

In a perfect world, I want my own team, broken into servers, content production and coding support. In my experience this produces more consistency and quality in my team's projects and tends to ensure more uptime.

But the problem here is that a smaller number of managers have a vested interest in the success of the web team. This can hurt in budget fights. And the budget fights WILL come.

The other problem here is on the content side. Coming from a content background to start out, I always want direct control of my content folk. But a couple of dedicated content people, while frequently better and more professional content producers, aren't as close to some of the things going on in a large organization and things that could or should be in the content pipeline can get overlooked that way.

I know this is unfortnately just a post dealing with the edges of the ugly politics, but in larger organizations, most of the reality of leading web dev teams seems to come down to dealing with the political issues that are instrumental to being able to get the work done. A sad thing. Maybe I have just had bad luck selecting jobs.

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.

IT vs Web team deathmatch

[swb]

Heh, I've seen (participated in?) the IT vs. Web development wars and it's not a good idea to have Web as a client of IT because IT is usually pissed/jealous/scared/disgusted at/of/at the Web group for many of the same reasons that the Web group can't stand IT.

I was on the IT side, and we had a shitpile of varied systems and thousands of end user computers to keep running *securely* and in whatever harmony the software would allow, within our budget, and within the complex politics that is most corporations. A complicated job by itself.

The web people I worked with were usually nice, I even respected some of them. But they didn't get the big picture of the total environment as well as we (tried to) do, and they were always at the bleeding edge of everything and were pissed because we wouldn't do massive client-side upgrades every time there was a .001 rev of some plugin or why we woudln't run machines with no security, hand out root passwords, etc.

I'd agree with you that they need to be seperate, in fact I'd vote for totally seperate -- like in another building across town. I think better web sites (better interop, better functionality, etc) comes from not even dreaming about having any influence or control over the desktop environment.

Re:IT morons understand little beyond windows

[swb]

Remember that there were those of us doing real work on Cisco and SunOS that paid the bills, including all the money that the web group squandered, back when internet meant the home office LAN and all the field offices linked together, not some dot-bomb fairyland.

I don't doubt that there are real pikers in many IT departments, but in the one I work in, there are very few. We were, however, subjected to a rotating collection of child "web designers" who knew fuckall outside of VB script and could have cared less about anything that they couldn't put into their Palm Pilots in under 30 seconds.

As for security, about half their sites (hosted externally) were owned in a week long period. Even after that they wondered why wouldn't let 'em run NT boxes open to the world.

Re:Tips From the Big Guys:

[chris_7d0h]

Good post.
A small comment. Having a separate web department handling everything related to the web effort might be viable for a large company.In the case of the company I work for, we have employees counting close to the same as a small country and creating departments for the tiniest detail is often not a problem. However, I see possible problems for companies not being of big blue's size or who are focusing on markets other than computers / IT (not having enough skills/resources in this area). Sometimes (personally I'd say often) it's better to leave information creation out of the IT related orgs. and let the IT people focus on the technical, functional aspects.
When it comes to conformity of the site and it's image, that can favourably be done by a function having this specific assignment.

I have not yet taken a look at what the company is doing for it's own site, perhaps it's worth a look though, as judging from the seminar you attended they seem to be doing this fairly well.
(My defence for ignorance: it's a large company and I don't have time to keep track of even 5% of what we're doing).

Re:Tips From the Big Guys:

[marxmarv]

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.)

"Content management system" is a glorified name for "source control software" with prettier buttons and a heftier price tag. Whatever you do, do NOT spend more than $20k on your content management system. If you do, you could have just as well paid a monkey to hack CVS for a month and come out the other side with something much nicer, cleaner, and more customizable. Web interfaces are not essential; a GUI client is very nice to have for the content producers. Customization is not evil when offset by documentation; make sure the latter gets done, all the time, every time.

If I told you what IT refuses to do to our website, you'd be shocked.

It's easy to shock Linux fetishists with supposed wrongs when you've never administered a production site for yourself. If I told you what development at a recent job has done to our systems, you'd be embarrassed. Let's see... NFS was used for all inter-machine communication because apparently none of them could be bothered to write socket code. A single machine served NFS requests for "site_status" because eng couldn't be bothered to write socket code; the ramifications to the stability of the site were Not Their Problem. Developers controlled the configuration files; adding a machine to the web farm involved haggling with them. Worse still, they hardcoded web farm machine names into the code to make exceptions rather than use proper configuration files or documentation. They controlled portions of the health and monitoring system, which became a messy accretion of sad, broken, unreliable tools. These were all people with over ten years of experience in software engineering, supposedly.

Meanwhile, we continue to get last priority with IT, and we don't have the root passwords to our own servers.

Damned right you don't. Developers don't get access to production, ever. If a developer needs access to production, then they are fixing a problem irreproducible in the test environment. At no other time does a developer need to even touch production -- that's what test harnesses and environments are for. If you haven't even got a separate pre-production test environment, then pretty much nothing you have to say is of any value at all.

Applications should never run as root. If you think you need root access to listen on port 80, what you really need is to run your web server on high ports and make the load balancer or other firewall translate the request. If you think you need root access to modify certain system files, you really need to not use that part of the system. If it takes two years to get access to logs, then maybe your operations people are trying to tell you to stop shitting on them.

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.

Which is why you have an editor or relatively small editing committee that makes final decisions about every color, every menu, every word, every URL that gets 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.

When you give powerful tools to people who have no idea what the consequences of using them are, you get a web site that impresses only managers. So your content management system creates menus and HTML for you? Is it compatible HTML? Does it work on all browsers? With or without Javascript enabled? (It's hard enough for Dreamweaver jockeys to get that last one right.) If your copy people can't hand-code HTML when necessary and understand every single detail of any HTML that's automatically generated, they're not qualified for the job, especially in this market.

the good thing is that in a good content management system, you can customize it to fit your needs.

What happened to "as little customization as possible"? Heh.

Why don't you identify your success story of a site? The Keynote numbers can tell us whether your lessons make for a better, more reliable site, or whether you just talk a good game.

-jhp

Re:Tips From the Big Guys:

[CaptainSuperBoy]

It's thinking like yours that keeps people "inside the box." Developers, you say, should shrug off problems in the production environment because they don't have the password, nobody wants them mucking around there anyway. Thinking like yours is what PRODUCES developers who just don't give a shit about the nuts and bolts anymore. Developers get sick of justifying every idea to IT, and they get sick of submitting to unreasonable demands and restrictions. Developers stick with what they know, software engineering, and when it comes to a technical issue they don't know what to do after a while because they don't care any more.

"If you haven't even got a separate pre-production test environment, then pretty much nothing you have to say is of any value at all."

Spoken like a true BOFH. In my experience those who say 'nothing', 'never', 'shouldn't ever' as much as you, really don't have much of value to say either.

Re:Tips From the Big Guys:

[marxmarv]

It's thinking like yours that keeps people "inside the box."

In case you haven't noticed, a system administrator's job is not to suffer through streams of alerts every night so that the development crew can sleep eight hours and achieve self-actualization. A system administrator's job is to keep the damned site up. If the organization's primary face is the site, then keeping the site up is not open to compromise.

Developers, you say, should shrug off problems in the production environment because they don't have the password, nobody wants them mucking around there anyway.

Exactly. If there's a problem in the production environment, and not in the pre-production testing environment, then 99 times out of 100 the problem is either with the production environment itself or with the data in the production environment.

What is so foreign about the concept of keeping application code in its own managed, gated little world? In my experience it has almost always produces better, more reliable code. Giving engineering staff free rein on production has almost always resulted in poorer, less reliable code.

Thinking like yours is what PRODUCES developers who just don't give a shit about the nuts and bolts anymore.

Good. They're employed to write business logic and HTML. If you want to give a shit about the nuts and bolts, microcontroller trainers and Linux boxes are embarrassingly cheap and available. Again, the system administrator's job is not to assist in the self-actualization of the application developer.

There are plenty of folks around who can see big-picture technical systems issues well, can code a bit, and can arbitrate well between operations and engineers. These people are valuable assets to a development organization and are useful for writing whatever glue is necessary to support the business logic and HTML/graphic content.

Developers get sick of justifying every idea to IT, and they get sick of submitting to unreasonable demands and restrictions.

What exactly is unreasonable about "production is not a toy"? If they want to test things they have machines set aside for the purpose. If they don't, then there is a serious problem of not only QA but development process, and that needs to be fixed. As far as justifying every idea to IT, what sort of justification do we ask for? We ask that you've tested the hell out of it, that it is well-behaved, that it requires minimal maintenance beyond code pushes or perhaps the occasional automated restart, and that it run with privileges appropriate to application software. As a sysadmin, it needs to not increase my workload, because in most cases my manager is all too keen to do that anyway, and preferably needs to decrease it. Is that too much to ask?

Spoken like a true BOFH.

Why, thank you.

In my experience those who say 'nothing', 'never', 'shouldn't ever' as much as you, really don't have much of value to say either.

I have my ideals. I've seen something very close to them in action at one installation, and things worked well there. The site had excellent uptime, the apps scaled well, and Things Just Worked. I've seen places that meet my ideals less than well, and they too work less than well.

-jhp

Keep your team in focus

[russg]

At my company we have a large online content services group. They are responsible for the development of the content as well as publishing it. The leader of the content group is at the same level as other IT groups. The content group however has no control over the servers themselves. The servers are controled by the systems administrators as they should be. Just as the content group maintains the content and makes the rules up for how things will look and flow, the sys-admins control the systems updates and change controls used on the servers. This works well for us, because our teams work together to make things happen. Content publishing is a part of IT. If you can't get results by having your teams work together, you have other political problems that won't go away very easy. I used to work for a local goverment and I would bet the later of here is true. Sorry but there isn't any way around those dang politics.

Integration

[incast]

Integration in an organization is key. Depending on how "modern" the management in the company is, an idea you might want to try is a participatory, cross-functional team.

Try having people from different areas (Finance, Marketing, Human Resources, Operations, etc.) with different levels of authority coming together to work as a part of the team. This will give your department the decision-making power it needs in the organization, while maintaining a broad perspective in terms of everything you will need to successfully set up and run the site.

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.

Organization

[Anonymous Coward]

After taking my licks in this industry for a decade, I think I've learned some hard lessons about management:

1. You need a person who makes the decisions. PERIOD. Anyone who tries to bring issues above his/her head should be slapped down by his/her seniors.

2. This figure needs to diligently listen to the needs of his organization. However, this figure also needs to resolve conflicts quickly and decisively. If this means hurting someone's feelings, hurt them (and maybe sweet talk them later). If this means firing someone's sorry ass, fire them.

3. Experience and "the right way" takes priority over personal feelings and political correctness. Encourage controlled conflict. Stir things up at designated meetings. And if any level of yelling or bad feeling arises, there should be a mandatory drink-beer-and-talk-shit after work.

This is how things get done.

In our shop...

[pixel_bc]

In our office the main web administration is handled by IT. IT is in turn considered part of Operations. Operations consists of HR, Facilities, Food Services, Library Services, and IT. Basically all non-financial, non-engineering, and non-marketing.

First thing to do...

[Chibi]

Is to not do something silly like Slashdotting your own sites. You said you were the senior webmaster, and yet you put out URLs to be Slashdotted?! Either you like pain, or you just want to be called in on a Saturday (which is another way to describe pain, I guess).

;-)

Web Services Organization

[nickjennings]

Well, At my previous job we had the best web team I've ever seen as far as efficient website management. Let me break it down for you.

The company had about 200 total employees, our web team was about 5 people, and then there was the Database team & the content team, both which we worked closely with. It was extremely important that each of the 5 people knew a little of everything and was an expert in one important skill.

1). Team leader - very good with security, and FreeBSD (or server OS of choice). And general server setup & maintnence.

2). Network guy - had a nack for network setup & design. Worked with the foundry routers and junipers, as well as helped with server maintnence and shell scripting little things.

3). Perl Scripter - wrote many scripts to help automate and monitor servers. Helped with server administration and setup etc.

4). Jack of all trades - proficient in most areas and able to help out where things were needed. Excellent to have.

5). Jr. Sysadmin - the lackey you get to make patch cables and drill in the rack. train him on
server setup & maintnence etc.

Our team was responsible for the setup/maintnence & overall design of the website. We setup load balancers, content management (not the actuall content), like seting up jserv, monitoring the servers, setting up the Sun boxen for the database etc.

The database team just focused on the data organization etc. and they worked with the Java (content) team to produce the dynamic pages. We did the build process and installed everything into our network layout, they didnt have to worry about anything but whether their content was correct (and looked cool).

I think this design is very efficient, because it allows each team to have a very specific focus and to not be distracted with understanding some other areas that are close, but not related.

Our main problem (which you really want to avoid) was that there was a big gap between US and our Manager (Director of Engineering). Basically we just didnt have enough communication and there was alot of distance between the teams and him. Basically fell apart at that point.

My five cents on this topic.

[chris_7d0h]

My experience tells me that separating information and function is essential and should be the first thing to do.

One of the more elegant approaches I've used here is having near 100% of the data on the site stored in a database (or databases).
(Performance is gained by good use of caching components in the application code)

Since you didn't describe what kind of functionality the "company" requires it's a bit more tricky to give a proposal on the technical side. However, going with a MVC (Model-View-Control) architecture will be fine regardless.

Application logic is run from and AS (Application Server) which is based upon templates for presentation. The templates could for be for ex. JSP pages using custom tags for creating the design of the pages. The data provided to the pages would be retrieved from the database by business objects and delivered (wrapped in data structure beans) to the JSP templates.

That way, you could have the designers focusing on creating templates, the programmers taking care of the business logic (and creating custom tags) and the database people making sure that the database is running at an optimal.

When it comes to updating information, I'd suggest spending some time creating a content mgmt. tool (not very hard), or let an outside company do it.
With this CMT "ordinary" employees could change the data without having to involve the IT department.

As for the organization structure regarding the web aspect, I'd suggest having each organization within the company appoint one responsible person, who is the one channelling and deciding what information will be allowed to be published on the site. This person can of couse appoint some other people whom have this authorization as well, but that is not for your IT group to decide or even bother with.
The focal points within each org. can send you an official request for people who should have the ability publish info and all you do is add these people as authorized users in the CMT application.
This way your group can focus on what you are good at while the other orgs. can do what they do best.
When a decision making person in an org. decide that some information is to be allowed to be published onto the site, they can enter the date and time for when the information goes live and press the "approve" button. The rest will be handled automatically.

As you see, this requires no specific restructuring of the company. Instead you can probably continue using a structure which the company has probably been using for years (and which is hopefully already working well).

I think it's important to realize that by utilizing the Web, companies do not have to radically change their way of working when it comes to publishing information. What was earlier published in press, ads, brochures etc. can be done much in the same way. The only difference is that a CMT tool is used instead of sending the info to the print house.

If you do not think your company will be able to create this kind of solution (provided this makes sense to you), I could probably get you in contact with one which have. In that case just drop me a line at: [e-mail]
(Note remove the [.antijunk] spam protection from the address)

Don't ask, Don't tell my friend

[thecrusher]

If you have a VP who is so stupid he/she can't figure out this stuff for you then you are going to have an impossible challenge. The problem is that if you take some of the advice I have seen on this thread (create your own well thought out plan and present it blah blah) which are great ideas you run the serious risk of becoming the enemy of the VP who realizing they are failing horribly will start to attack people below them. Its human nature. So screw trying to teach this idiot what they should already know and would either only take credit for or sabotage. If the CEO/president of your company is so lame they can't hire the right people which really is about the most important part of their job then I say colelct your checks, keep quite, and leave ASAP. And of course warn the rest of us who these idiots are so we can avoid working for them or demand outragous salaries for taking on the stress of leading from the bottom. All that talking will do (if upper management doesn't see the problem already) is get you into trouble. -m

Re:Don't ask, Don't tell my friend

[Anml4ixoye]

We don't have a VP. We don't have a CIO, CTO, yadda yadda. We have four seperate managers spread across two different (highly political) departments. I am trying to make a case that having a CIO (or something similar) of web operations is the way to go.

I woked for a dot-com for about three months, and what you mentioned above is what I saw. They wanted to build a site with DHTML out the wazoo, completely cross-compatible, with no databases allowed, or any other technology then Javascript. I walked into a development envornment that had three 7,000 line Javascript include files being passed with each page, which of course did not work as soon as N6 came out.

If you'll notice - I work somewhere else now. :)

My 2 cents on this one...

[MadCat]

The first step is to try to get it into one department - working together with others is fine, but you do need the final authority on the website and anything you need for the site(s).

Seeing as how that's problematic, your best bet is to nudge it in the direction you want it to go in small steps, and not in one big shove.

Make sure you have the people you need. At the least one server wiz, one perl wiz, one graphics/content wiz and someone who can make them work as a team.

The place I now work at (a whopping 2 employees, yes yes, startup) already has this on paper - except that I'm doing all 4 of those things right now. In the future (read: when we make money) there will be people hired to focus on specific needs - thankfully I managed to get a sensible structure going from the get-go.

What I've seen work

[BillTheKatt]

This is a touchy subject for most companies, everyone wants to play politics since websites are high-visibility.

I've seen it at companies where the web team was part of IT, a separate group, and once where they reported to marketing. There are pros and cons to each of them, it really depends on what kind of company you're with and how strong the group leaders are.

IMHO things work really well if the IT group is *competent* and has a good director/manager and you're part of that group. You get fast response for your needs on the IT side, and protection from marketing's wild ideas (let's go with an all flash website!). It will work best though if you have a good, strong IT manager who will listen to you, stand up for your team, and make sure you get the support you need. This is good for a corporation because marketing can dicatate the content, you can manage the web technology and IT can support you and the systems.

The separate group can work, but really only if you're in a small company or if you have a high-level boss. You're going to be stuck between IT not wanting you to change things, and marketing's wild ideas. Usually marketing has a high-level VP close to the CEO, unless you have someone big enough to fight for you you'll be at their mercy.

Which is just as bad as being under marketing IMHO. Marketing usually doesn't have a clue about technology, and they come up with wild ideas about how fast things can be done or random toying with tech just "because".

Again, it really depends on your corporate structure and the people involved. Personally I think you can forget about crap like VP of Web Services. I can't believe companies waste their time with this crap. You know how much $$$ I've seen on VP of Janitorial Engineering, VP of Food Services, Chief Privacy Officer, etc. etc. Most companies need less time-wasting VP's and Chief's and more Indians getting things done.

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.

Re:from the 'Everything is relative department'

[hoggoth]

HAHAHA! Please mod'em up!

Re:from the 'Everything is relative department'

[Anml4ixoye]

Haha

Thanks for the laugh. Yes, unfortunately being involved with a lot of the tech organizations, I know how many people would love to have a job where they complain.

So I figure if I can come up with a grandeur enough vision, I'll be able to employ everyone!

The Wrong Way

[TheInternet]

A company that has its web team reporting to marketing just screams "we don't under the internet." Marketing executives simply don't tend to have sufficient experience with engineering and administration issues to understand the goals, challenges and advantages of having a web site.

A lot of companies see their web site primarily as a marketing tool. That may be, but running a web site is completely different than laying out a catalogue or brochure.

- Scott

Re:The Wrong Way

[TheInternet]

we don't under the internet

Make that "we don't underSTAND the internet."

- Scott

Re:The Wrong Way

[bcaulf]

Sadly, any company that doesn't understand the internet, will also not understand TheInternet.

It is not so hard...

[pvera]

The first thing you have to ask yourself is what is the main function of the website.

If the site is used for brochureware then it is a marketing function. Marketing should have somebody to oversee the website, with both technical and content people working on the site.

If the site provides a service, then it falls under operations because it is part of the day-to-day business of the organization.

I have a half-half situation in my organization. I have a brochureware corporate site and a very complex intranet application that is web-based. The solution:

1. The outside website is run by marketing and sales (it comes out of their budget, so it is theirs). Whenever they need programmers to work in it they buy our time with their own budget.

2. The intranet is run by operations. We assign internal resources to deal with it.

3. The outside website has some automated components that are being fed from the intranet. These dynamic components are maintained by operations. Any and all content issues are solved by Marketing and Sales.

Final recommendation: Keep the team as small as you can afford. Avoid yourself heartbreak later. I already see you will need a project manager, a good programmer and somebody to deal with content. The graphic artist you do not need full time (unless you are one of those lucky bastards that has a good programmer that also has decent graphic skills!).

Sounds like very familiar problem

[wiebke]

Hi. A coworker of mine sent this to me and I was thrilled to see discussion of this problem, since I've been stuck in this same sort of place (which is where????) for over four years. My first experience as a web designer was as a contractor for a large state agency. I was there for about three years and over time the situation as far as our autonomy / ability to get stuff done got better AND worse. On the one hand, we managed to evolve into a fairly autonomous team where each member had a job. There were three web designers / programmers, one content reviewer / agency liaison, a group supervisor (who also did lots of liaison and content work), and then there was a boss, somewhere out there, who only got consulted when we had problems or something major. We did a lot of work with individual departments within the agency as well as people in the state counties/regions. The worst problems we faced were that 1) we had no one "upstairs" who really had a clue how to fully utilize us, which was bad in terms of getting priority in budget, 2) we had hardly any connection to IT, so it would take MONTHS to get simple stuff done, and 3) the site ended up being really high maintenance because we had so much material coming in from the departments we'd buttered up to work with us. These three problems came together in a pretty nasty way right around the time I managed to get a new job. Basically the boss got an idea that we should go to a content management system so we could handle all the maintenance and content that was coming in. This is not a good thing to attempt when you don't have a lot of $$$, when you have very limited staffing as far as people who *directly* support you. Our agency had IT people for the whole agency, but we didn't really have our own IT people or if we did it changed like every week and they were forever playing catch up. In the end, the contract on the content management system got bogged down in red tape (complicated grants, funding, etc.), the administration sort of forgot about us, and finally most of us jumped ship becuase we were all sick of it. I landed with another gov't group, an IT department within a technical research division at a large university that's basically all technology, engineering, etc. Our group works a lot better than the one at the state ever did, but for the web site, they're still not ready. Basically they have me (working in the IT group which mostly does Java programming, plus our intranet) doing the whole web site myself, working with someone in another dept., the head of communications. We in turn work with various department/laboratory heads. She has her boss, I have mine. It's been good and bad but lately bad because the other woman, my partner, has had to go to half-time and it leaves me in the lurch, since she routes all content. The other bad thing is that 90% of our web site being eliminated due to 9/11 security concerns. I think I just sant the heck out of gov't jobs, steady as they are, but then I think there are nasty problems and dumb work set-ups everywhere. Wiebke

Re:Sounds like very familiar problem

[Anml4ixoye]

It's a shame that you don't have any contact information for you. Can you email me sometime? I'd be interested in hearing your comments or some of the issues you talked about.