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."
Isn't this why you get paid?
I mean come on! If you're not competent enough to do your job, why should anyone here tell you?
Oh, and by the way, FP beeyatch.
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.
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.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.
Read the EFF's Fair Use FAQ
Choice of technology has no bearing on this question. Or did you know that and just decided to troll?
-- @rjamestaylor on Ello
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:
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.
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:
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:
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.
Andrew Wiles
a**n + b**n != c**n for n > 2
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.
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.
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.
.001 rev of some plugin or why we woudln't run machines with no security, hand out root passwords, etc.
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
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.
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
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:
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.
My Greasemonkey scripts for Digg &
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,
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
Scott Stevenson
Tree House Ideas