Law & Order: Content Owners and Developers

By Paul Chin

Originally published in Intranet Journal (15-Aug-2003)

back back to portfolio

In the corporate intranet world, users are represented by two separate yet equally important groups: the development team who builds the intranet and the content owners who populate the site. These are their stories.

It's difficult enough to get consensus from a large group of like-minded individuals, much less a group of disparate members of a multi-disciplinary intranet team. Everyone has their own set of priorities, points of view, and personal interests at hand. To make matters worse, they all have their own idiosyncratic verbiage. And nowhere is this distinction more apparent than the one that exists between the "non-techies" and the "techies" of an intranet project—the content owners and the developers.

There has always been an unfortunate "us versus them" attitude between the two groups. And as much as we like to pretend it's not there, this division has existed since the dawn of information systems. Techies think their users don't know what they really want and users believe techies think they always know what's best for them.

Content owners and developers have very different roles to play but work toward a common goal: to make information readily available to those who need it. Ideally, the two halves would function in perfect tandem in a Utopia-like world where phone calls and e-mail are answered in a timely manner and always begin with "How are you today" instead of "What the-?" And of course, all of this would be animated and shown as part of the Saturday morning cartoon line-up.

This division usually exists not because of some fundamental flaw in interpersonal relationship skills (although this may play a part) but rather because of misconceptions. Once you learn a little something about the other groups, perhaps you won't be so quick to jump to false conclusions.

Law: The Role of the Content Owners

Content owners should rarely, if ever, have to deal with technology issues at a practical level. Whether an intranet is database driven, based on XML, or housed on a Linux, Unix, or NT backbone is irrelevant. For all they're concerned, there could be a hundred monkeys on tiny bicycles inside those large server rack cabinets.

A content owner's job is to take care of the heart of an intranet—its content (see "Intranet Content: Long Live the King" for more on this subject). And while it may be a good idea for content owners to be familiar with the technology that manages their information, it should never linger in their minds so long as to take their focus away from their main duties:

Order: The Role of the Developers

The development team, whether in the form of internal IT personnel or outsourced developers (see my four-part series "Making a Home for Your Intranet" for more on this subject), is responsible for putting an intranet framework into place for content owners to populate with information.

Unfortunately, to this day, many still view intranets as a technology-driven system, and content owners are often tempted to delegate content management tasks to the technical staff rather than take ownership of their information. This takes a considerable amount of time and effort away from the developers, time that can be better spent on more technical matters such as:

Tips for a Happy Co-existence

As someone who has worked very closely on both sides of the fence, I was sometimes put into the awkward position of having to act as a mediator between the content owners and the developers. The reason? Both sides claimed, "Those guys have no idea what we're talking about."

In many cases, however, each group's negative preconceptions prevented them from hearing and understanding what the other had to say. But in reality, they were a lot closer to being on the same page than either gave the other credit for.

Here are some useful tips to building a successful working relationship between content owners and developers:

Tips for Content Owners

  1. Present detailed requirements: Be prepared with a detailed set of business requirements to explain exactly what you want. This will prevent the development team from having to make assumptions as to what they thought you meant.
  2. Create a "Big Picture": Let the development team know your entire vision of the project even if later phases are months down the road. By doing so, they will base current technological decisions on the final product rather than just the phase they're currently working on. This enables them to build an intranet flexible enough to accommodate future additions.
  3. Avoid verbal on-the-fly changes: If there's a need to correct or add something that will not break original project specifications, send them to your developers in the form of a memo or e-mail rather than mentioning it casually. This leaves a request trail that can be referred to in the future.
  4. Don't hover: You shouldn't feel as though you need to constantly look over your development team's shoulders—they won't appreciate that. They are trained and highly specialized. They know their job so give them space to do their work and trust enough in their abilities to make the right call.
  5. Never dump content management tasks on developers: Developers hate it when you ask them to update your content. It's not their job to do so and they have no vested interest in seeing that your content is updated—that's your job.

Tips for Developers

  1. Always offer alternative solutions: Content owners and users don't like to hear you bring up a list of things you can't do. When you hit a snag, don't just bring up the problem; approach content owners with the problem as well as alternative solutions.
  2. Stick to project deliverables: The schedule of a large project is like a domino maze, if one piece falls, there may be a chain reaction. If you're unable to meet a deadline, always let content owners know ahead of time rather than dropping it on them one day before so that they can adjust to the change in schedule.
  3. Avoid tech talk as much as possible: Try not to bring up overly technical issues during meetings with content owners. Technical issues fall under your area of expertise and should be discussed among other developers.
  4. Always listen: Understand that your job is to help content owners realize their needs, not to compel them to accept something you believe they should need.
  5. Post-production commitment: Content owners and users require a certain amount of training and support to familiarize themselves with the new system. Don't disappear after the system is put into production.

Tips for Both Groups

  1. Meet regularly: E-mail and telephone calls are fine, but there should be regular, in-person meetings to measure progress, review spec changes, and discuss future enhancements.
  2. Base the project on formal specs: In order to avoid confusion and misunderstandings, both teams must work off of the same set of formal project specifications rather than an assortment of casual requests brought up in meetings, phone conversations, or e-mail.
  3. Avoid scope creep: Stick to the original project specifications as it was agreed upon by everyone in the intranet team. If there does happen to be a real need for an additional feature, make sure that there's general agreement to the amendments.
  4. Maintain a steady stream of communication: Neither group likes to think that the other has disappeared on them. Keep the lines of communication open—even if it's just a quick status report on where things are heading.
  5. Be flexible: Each team must be willing to compromise between what they would like to do and what they are actually able to do. Don't be so set in your ways as to stunt the other team's progress.

Final Verdict

There's no magic formula to a healthy working relationship between content owners and developers. And if there is, it's probably as well-guarded as the entrance to Shangri-la or the secret of how they get the caramel in a Caramilk bar.

But there's really no need unleash your inner Indiana Jones and parachute into the jungle to seek out this elusive answer—it's a lot closer to home than you think.

Copyright © 2003 Paul Chin. All rights reserved.
Reproduction of this article in whole or part in any form without prior written permission of Paul Chin is prohibited.