The Village Stew

In: Columns > The Carpenter’s Workbench

By Nathan Smith

Published on February 12, 2007

The politics involved in building a large corporate website always make for an interesting dynamic. Contrary to what one might assume regarding strength in numbers, typically, the more people involved in the process, the more diluted the final product. When I worked for a Fortune 500 company, our web team struggled to convey this message to the multiple layers of middle management, while we pushed for a more agile development strategy. Finally, a delicate way of describing the problem of design by committee dawned on me. I have come to refer to this group-think phenomenon as village stew.

What’s Cooking

Imagine, if you will, an experienced chef who is hired by the town council to be the chief expert to revitalize the town’s restaurant industry. His mission will be to pull together the disparate area vendors under one unified, standard process for cooking—one that is both intuitive and leads to delicious dishes, while still being flexible enough to handle multiple cuisines. He offers to cook a meal for the city’s residents to gain their confidence and trust as the new head chef. He decides to prepare his famous soup, one which numerous other townships have already enjoyed immensely. Since the weather is pleasant, he opts to cook outdoors so that everyone can enjoy the aroma.

People soon begin to gather in the town square, but to the chef’s surprise they are carrying with them all manner of foods and ingredients. Confused, the chef tries to reassure the populace that he will cook for them, and that they need not trouble themselves with bringing anything else. He quickly learns that the Mayor is second-guessing the decision to hire a chef, and wants to get additional feedback about how the meal should be cooked. He had issued a decree allowing everyone to bring their favorite food to be added to the cauldron. The carefully blended soup quickly turns into a concoction full of random ingredients: lobster, ice cream, macaroni, peanut butter, and pizza, to name a few. The Mayor stands behind his podium nearby, aloof and pleased that the democratic process was going so well. Surely this would be the best meal ever, with so many people’s favorite ingredients taken into consideration.

Despite the chef’s initial protests, the cooking continues. Not wanting to defy the will of the masses during his first major undertaking, he does as the Mayor and the city council have instructed. Before long, it is time to dole out the servings of soup, and everyone eagerly awaits their turn. Spoons ready, they all dig in simultaneously as the mayor proudly gives the order to begin eating. The looks of delight on the faces of the happy citizens quickly turn to disgust, and then to anger. They scowl at one another across the many dinner tables. Townsmen who hate the taste of peanut butter glare at those who supplied it, while those not fond of shellfish make comments about those who brought lobster.

The Mayor himself does not particularly enjoy the meal either, but realizing that he is responsible for allowing everyone an equal say in the process, he is quick to shift blame to the chef for not mixing the ingredients properly. Everyone agrees, and soon the chef is made a scapegoat for not filtering through all of their input and still producing an excellent meal. What kind of chef is he, anyway? Certainly not the type that could revitalize their restaurant industry. And so, after running him out of town, they continue on as they always did—without cooperation or any semblance of taste.

Dumb and Dumber

While the village stew scenario is a bit melodramatic, this type of thing happens every day at large organizations. In an ideal world, people would recognize the need to facilitate the best possible solution for the betterment of everyone involved. The last time I checked, though, such altruistic dreamlands existed only within the manufactured confines of overpriced theme parks. Being mindful of business-world politics will help you cut through the crufty layers of protocol in order to affect change and produce tangible results. I like to think of it this way: You cannot restructure the foundations of an institution without disturbing a few fossils in the process.

Andy Rutledge recently wrote an article about doing web development and design work in a smaller agency, but within the context of a larger business environment. His gave his article a somewhat abrasive title: The Dumbest Guys in the Room. Rutledge pointed out that, in general, there is an ongoing tension of distrust between executives and their subordinate middle managers. It seems almost paradoxical that the higher up in a company one climbs, the further one is removed from the realities of actual work, thus contributing to one’s own eventual irrelevance.

“There’s no getting around the fact that when company leadership distrusts mid-management (a common circumstance), and mid-management runs the design project, designers are to be second-guessed and their suggestions and solutions picked over and committeed into shape.”

Despite their unfamiliarity with design or code concepts, these people are inevitably the ones making crucial decisions that will affect both your job and the success of the task at hand. Rutledge suggests that as developers and designers, we need to not only understand the solutions we are building, but also work closely with the key stakeholders to ensure that they are included in the process and are making the most informed decisions possible.

“And by all means make every effort to know exactly who the ultimate decision maker is, and learn how best to connect with them and gain their confidence. Your success, and likely their fortunes, depend on this (whether they know it or not).”

Also be cognizant, when working with committees, that at least one person in the group could be described as a yes-man (or woman). The yes-man derives his name from an insatiable desire to be liked by everyone, and an inability to say “No” to any request or proposal, however outlandish. He is particularly dangerous because, while on the surface it may seem that he is cooperative and likable, the motive behind this amicability is the drive to further his own career. He will over-promise and under-deliver, all the while not having a full grasp on how the web design and development process really works.

The yes-man is a businessman, and having not been in the trenches of designing or writing code himself, will treat your skill-set as a commodity he barters as he tries to gain favor with his superiors. To ensure that things stay on track, be careful to keep the yes-man from adding too many bells and whistles, lest the process fall prey to scope creep and metamorphose into an unwieldily behemoth. If the project spirals out of control, it is often difficult to steer in the right direction. Stakeholders will find it difficult to justify major change even if it is for the better, because of the notion that there has already been too much invested to turn back. This is known as the sunk cost fallacy.

Delegation + Sunk Cost

In Walter C. Wright’s Relational Leadership, the author describes a team of experienced mountain climbers who endeavored to reach the summit of Mt. Everest. Because each one of them was considered an expert, they decided to defer to one another in a round-table method of governance, in which each person would be respected and have equal say in the route they took up the mountain. During their trip, however, the weather took a turn for the worse and they found themselves in the middle of a tough decision: scrap the trip and endure the embarrassment of having turned back despite their expert status, or press on and brave the elements in hopes that the storm would pass. Since each of them had equal say, and nobody wanted to be seen as trying to trump the others, they all continued the trek. This story did not have a happy ending. Several of them lost their lives, simply because they did not choose a leader to make the tough decisions. It is tragically ironic that even though any one of them could have filled that role, a leadership vacuum existed because of mutual respect.

The lesson to be learned here is that selecting a leader is not necessarily a bad thing. However, typically, it manifests itself in one of two ways. Either the most senior people are the only ones who get to make decisions because of their status and clout, or decisions fall to those with lower positions because the issues at hand are not seen as pertinent and worthwhile. The ideal environment is one where people all have something to bring to the table, but a group consensus is reached on who will take ownership of the team effort before a project even starts. This need not be re-negotiated every time, but the important thing is that people know who has governing authority, and that there are not overlapping agendas in the process. One could think of this in terms of professional sports teams. Michael Jordan might have had a superstar shoe deal, but he respected Phil Jackson as the one who was coaching the game. Contrast this with players such as Latrell Sprewell, who attacked his coach, P.J. Carlesimo.

So What?

What does any of this have to do with web development? Quite a bit, actually. The tale of the village stew reflects how big businesses get so tied up in their own IT bureaucracy that their processes become a hindrance instead of an effective governance model. As the ones building websites, we first need to understand the human factors involved before constructing solutions that might not address our problems. In her book Web ReDesign 2.0: Workflow that Works, Kelly Goto offers this advice:

“Clients usually have clear business objectives, but are notorious for not having clear site objectives. And why expect them to? They are neither designers nor web experts. By asking clients the right questions, you guide them into aligning their business objectives with the constantly changing, evolving, and demanding web.”

The mountain-climber tragedy illustrates how small agencies can be hindered by lack of structure. Somewhere in the middle is a solid team model, in which there is just enough of a framework in place to keep people communicating effectively, but not so much paperwork that it keeps anything from really happening. As a general rule, if your web team produces more Word documents than deliverables, then it may be time to re-strategize. On the flip side, if you are just designing and coding all day, but there is no clearly established scope or budget for a project, then you should define those parameters, pronto.

Here are a few pointers:

Do:

1. Choose a project leader who has final authority.
2. Establish scope and budget for the project.
3. Agree upon a timeline for deliverables.
4. Set specific, incremental milestones in the process.
5. Get to know the key stakeholders.
6. Keep the yes-man under control.

Don’t:

1. Be afraid to demand that someone take charge.
2. Give into scope creep unless the client is paying.
3. Shoot from the hip without any timeframe.
4. Start a project with no clear goals defined.
5. Be a loner or isolate yourself.
6. Let a yes-man run the show.

Summary

No matter the size your team, be it an agile design shop or large IT department, it is important to know when to defer to those who are well-versed in a particular area, and equally as imperative to step up and take the initiative for the betterment of the project as a whole. In either situation, check your own motives to make sure that ego or personal agenda is not clouding your judgment. In the business world, projects are unsuccessful not because a group of professionals working together lack anything by way of skill or intelligence, but, more often than not, they simply fail to work well together. In the future, we can hope for more culinary masterpieces and less village stew.

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Planning, Web Teams