THE STORY
One of the most impressive feats of the second half of the 19th century was the completion of the US transcontinental railroad. This railroad line linked Omaha, Nebraska to Sacramento, California. Construction of the railway began in 1863 (during the US Civil War) and ended in 1869. During these 6 years, approximately 1,777 miles (2,859 km) of track were laid down, much of it across treacherous, snowy mountains. Not only did the workers have to battle the terrain, but they had to battle attacks by Indians.
This was an extremely important development, as it connected the entire United States—from coast to coast—with efficient travel. Prior to this rail line, a cross-country trip could take as long as six months. Now, the coast to coast trip could be completed in just one week.
The task to build the line was divided between two companies. The Central Pacific company was to start in Sacramento and build eastward. The Union Pacific company was to start in Omaha and build westward. Each worked independently and devised its own process for building its railway. The US government paid each company independently based on how many miles of track they laid down (at preset amounts based on the difficulty of the terrain).
Although the companies worked independently, the US government, however, needed to intervene in the decision of where the two tracks would connect. Both companies were trying to direct the connection point closer to where they controlled land (so as to maximize their profits). In doing so, the two firms could not come to an agreement. To settle the differences, the US government determined that the connection point would be Promontory Summit in Utah. On May 10, 1869, the golden spike which connected the railways was driven into the ground at Promontory Summit.
THE ANALOGY
The building of the transcontinental railway was a complex and extremely difficult feat. Many strategic business plans today call for their own version of a complex and extremely difficult feat.
In today’s world, when large complex projects are undertaken, there is usually a lot of talk about “collaboration.” The thinking is that complex projects in a “knowledge-based” economy are more efficient if there is continual collaboration and dialogue amongst those with various pieces of the relevant knowledge.
To foster collaboration, companies tend to add quite a bit of complexity to the business. Intricate matrix organizations are built, with multiple reporting relationships (and lots of dotted lines on the org chart). Expensive data/knowledge warehouses are built, with the capability for real-time sharing and interaction across the entire organization.
The transcontinental railroad didn’t worry much about collaboration. Other than collaborating on the initial design and the ending connection point, there was hardly any “working together” between the Union Pacific and the Central Pacific. To the contrary, rather than collaborating, they were encouraged to compete against each other to see who could lay the most track. Without collaboration, they very quickly completed a very difficult task.
This blog will try to show that modern businesses may be over-emphasizing the need to collaborate. As a result, they are building an unnecessarily complex infrastructure which may be choking efficiency rather than helping. It may be more productive to move to a structure more like that used to build the transcontinental railroad.
THE PRINCIPLE
The principle here is that there is a big difference between collaboration and communication. The dictionary defines collaboration as various parties working together on a project. By contrast, communication is just a sharing of information. Communication tends to move in one direction (from the person with the information to the person without). This is typically not a group of people who need to work together side by side to get the project done. It is just a data dump.
If we consider all communication to be “collaboration,” then we significantly overestimate how much true collaboration is going on. These inflated estimates then cause us to create elaborate collaboration solutions which may not be justified. Worse yet, all of that forced collaboration may create a bureaucratic nightmare that makes it harder for people to independently just go out and get the work done.
We can see this by looking at the typical life cycle for a major project.
Usually, a new strategic initiative starts with data gathering. Great strategies are not created in a vacuum, but within a context—an answer to a real need in the marketplace. One must understand the context in order to create the proper strategic solution. Therefore, data is needed to answer questions like:
1) What are My Capabilities?
2) What are the Key Issues/Concerns of my Customer?
3) What is the Competitive Landscape?
Getting the answers to these questions does not require collaboration. Instead, what is needed is a good data dumping process. In the fall 2008 issue of the MIT Sloan Management Review, there is an article about IBM’s attempt to create innovation through a massive collaborative process. Over 150,000 IBM employees were asked to participate in a multi-day on-line collaboration concerning ideas for innovation. IBM came up with a sophisticated process for such collaboration via computer software on the internet.
What was the result? Although lots of people wrote in and submitted ideas (available for all to see), there was virtually no dialogue which built upon any ideas. There was no real collaboration...no connections between submissions. It was just a data dump. All of those ideas could have just as easily have been mailed in on post cards. The ability to collaborate was not necessary.
Next comes the visioning—the choosing of the right course. My experience is that great visions come from great visionaries—not committees. Collaborating committees tend to compromise and dilute the vision into something bland and average. It doesn’t offend, but then again, it doesn’t inspire or excite the emotions. Radical, groundbreaking visions, typically result in love/hate reactions—something that would typically not escape a collaboration until watered down. In the case of the transcontinental railroad, Abraham Lincoln was the visionary who chose the path and made it happen, not a collaborative team.
Yes, visions need to be communicated and accepted around the organization. But this is more about persuasion than it is about collaboration. It is about disseminating information and inspiring folks. Sure, there is room to accept feedback and modify things a bit, but the overall vision, if properly chosen, should remain in tact.
Now comes the implementation phase. Collaboration is important here, particularly at those points where people’s work intersects with each other. Choosing the point at which the Union Pacific and the Central Pacific were to meet was one such intersection. To me, the key here is to:
1) Identify points of intersection early.
2) Come to a rough agreement of how you will mesh at the point of intersection (collaborate).
3) Go off and do your thing somewhat independently (not collaborate).
4) Check in periodically to see if you are still on a path to mesh, or if new information/knowledge requires readdressing the earlier decision (collaborate).
For example, if you are designing a new car, it is important that the people designing the chassis and the people designing the engine have a general agreement about engine dimensions, so that the engine fits into the spot where it is to be located in the chassis. That is collaboration. However, you do not need the chassis people to collaborate on building the engine. They are not trained in that skill. Nor do you need the engine people designing the chassis. As long as the intersection point (putting the engine in the chassis) is worked out well in advance, you have most of the collaboration you need.
The exception would be if the engine designers discover that they cannot design a proper engine to meet the earlier specs. They you may need to reconvene and collaborate on a new revised conclusion.
Having everyone fully collaborating together as one unit all the time can be counter-productive. Most great advances in business are driven by the forces of competition. If you eliminate internal competition, you can become as inefficient as the old communist regimes. Internal competition between Union Pacific and Central Pacific caused the train track to be built more quickly than if they had worked together. In my time at Best Buy, I saw how internal competition can bring out the best and drive great improvement.
A similar thing happens with best-in-class benchmarking. I have often seen people speak of moving best-in-class processes throughout a firm as “collaboration.” This is not collaboration—this is teaching and learning. And if you force everyone, all the time, to act in the same exact way, you have frozen productivity and innovation. You can never get better, because doing anything different from the current standard is not allowed. To make advances, you need renegades—people who do not collaborate and go off on their own to experiment and find the next improvement.
By the time you add internal competition and renegades into the mix, even the implementation stage is not as much about collaboration as one might at first think.
SUMMARY
Collaboration is not the same as communication. Communication seems to be more critical than collaboration. If we focus on building organizations that are unencumbered with bureaucracy, but communicate well, we are probably better off than if we had focused on building complex collaborative structures.
FINAL THOUGHTS
There’s an old saying that “too many cooks spoil the broth.” In other words, if you bring together a lot of chefs to collaborate on a cooking project, it will fail because the combination of all of their conflicting ideas will create a disaster. Better to find one great chef and let him or her create their masterpiece with a single, working recipe.
No comments:
Post a Comment