Growing Wheat in Siberia
Once upon a time, the late and unlamented Soviet Union decided to grow wheat in Siberia. Their logic was simple: by growing wheat in the inhospitable conditions of Siberia, the wheat would become stronger. The wheat, however, was indifferent to Soviet philosophy. Despite speeches, threats, and promises from the government, the wheat stubbornly refused to grow.
A belief about how the world should work was trumped by the way the world does work.
To bring this a little closer to home, I worked with one high technology company that decided to create a set of coding standards for its software development team. While not an unusual occurrence in software companies, in this case, the manager in charge wrote up a fifty (that’s right, 50) page standards document. Naturally, everyone was overjoyed and memorized everything; at least, that’s what the manager thought. In fact, no one read more than a page or two and most of the engineers ignored even that.
Another company was trying to manage information: design decisions, notes from discussions, and so forth. They had the very good idea that they could manage all their accumulated wisdom as a Wiki. Unfortunately, the Wiki swiftly ballooned into an unmanageable morass of data in which no one could actually find anything useful. The problem wasn’t so much getting people to remember to update the Wiki; it was organizing the information in a manner useful to everyone who needed to use it, and in convincing people to take the time to keep it organized.
In both of these cases, beliefs about how people should do their work were trumped by the way people actually do work. Like Soviet wheat, it can be remarkably difficult to motivate or threaten people into doing something that they really do not want to do. Unlike wheat, people can be forced. It’s merely a question of how much time and energy you want to spend: pushing people takes a great deal of effort and tends to result in significant amounts of anger and frustration for all parties involved. Not, in other words, a conducive atmosphere for creating a strong, collaborative team.
Of course, sometimes it is necessary to have people do things they don’t want to do. Code does need to be commented, information needs to be documented, and so forth. Fortunately, unlike wheat, people can be convinced. Instead of pushing them, the key is to get them to pull. How do you do that? Here are some tips:
- Involve those who will be affected by the outcome in the process of solving the problem. Nothing gets buy-in like giving people the opportunity to develop the solution.
- Identify the actual problem. The company with the 50 page style guide needed code that could be maintained over time and easily read by someone other than the writer, and they needed the process to not interfere with actually getting work done. That can be accomplished with a one page style guide. Instead, they were trying to win the World’s Most Beautiful Code Contest. That may be prestigious in certain obscure circles, but it doesn’t sell product.
- Ask yourself how you’ll know when you have a workable solution. This may seem counter-intuitive since you don’t have a solution yet, but it helps to figure out what success looks like. That way, you’ll know it when you get there.
- Brainstorm possible solutions.
- Do not evaluate any solution until the end of the brainstorming process. Off-the-wall ideas frequently trigger creative solutions.
- For each solution, ask yourself if it will actually get you to the outcome you want. Focus on the idea, not the person who came up with it.
- Take the time to honestly assess what might go wrong.
- Recognize that “oh, we’ll figure that out later,” is often a warning of trouble ahead. Make sure there is a way past potential roadblocks.
- Test your solution before you commit to it, or at least look for examples of similar solutions being successfully implemented.
- If more than one solution has survived to this point, pick one and implement it. Be willing to abandon it and pick another if it becomes obvious that it won’t work. You can’t foresee everything that can go wrong.
- Be willing to reformulate the problem if the solution doesn’t work.
- Give people as much autonomy as possible in implementing the solution. When possible, allow them to develop their own implementations. The company with the Wiki could have used email and encouraged each person to maintain their own records in whatever form was most individually useful. Instead of trying to figure out how to maintain a central repository, perhaps what they should have done was to present different ways of organizing the information and allow each person to pick the one most useful to them.
This may seem like a lot of steps, and there certainly is effort involved. The Soviet Union decided it was easier to yell at the wheat. Given the amount of wheat they imported, it’s clear which method is cheaper in the long run.
Good luck!
Published at FreudTV.com
