Slashdot Mirror
Organizing Your Web Services Division?
"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."
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.
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
-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.
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.
7. What we cannot speak about we must pass over in silence.
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 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: chris_7d0h.antijunk@yahoo.com
(Note remove the [.antijunk] spam protection from the address)
In a society that believes in nothing, fear becomes the only agenda ~ Bill Durodié