It turns out, far more often than you might expect.

Complicated tasks that require both creativity and rigorous thought are often performed more effectively by two people than by a single person. This is especially true for upstream tasks with downstream quality consequences.

Example: Pair Programming
Pair programming is an agile software engineering practice where one person codes while the other performs real-time review and test planning.
Programming pairs perform work faster and with significantly fewer defects than individual programmers. Also, architecture is improved, since each decision is reviewed by the programming partner.

Of course, more effort (i.e. man-hours) is required by pair programming. About 85% more. However, this is where quality takes over. Coding represents only about 25% of a software project. Downstream there is testing, acceptance, roll-out, documentation, training and support. The quality of the original architecture and code has a large impact upon these downstream activities, and can save large amounts of effort and money.

Additionally, consideration must be given to maintenance where original architecture and code quality impact snowballs.

Real-Time Peer Review
Real-time peer review can improve the quality of almost any task.

Think of a person pouring over a problem and getting the same incorrect result, over and over. Another person comes along, peeks over the first person’s shoulder, and bingo! “There’s your problem.”

As infuriating as this can be, it is an example of how effective peer review is.
When tasks are shared, the creative effort and real-time review often bat back-and-forth, as the workers iterate through the problem. This uncovers important subtleties very quickly.

Conversation as Problem-Solving
Conversation and story-telling are critical components of problem solving. A Problem that seems impossible to an individual is often overcome by discussion with others.
Consider the example of a team of Xerox repairmen. Well intentioned managers created a book for troubleshooting copiers; if this indicator is on, change out this board, etc. The book was not helpful. Problems that were simple enough to encode in a manual were already solved quickly by the repair team.

Tougher problems were discussed by the team at breakfast and lunch, which they spent together each day. The worst problems involved two repairmen visiting the site together. The pair would observe the problem, discuss, review stories of similar problems, and iterate. The comments from one would unearth ideas from the other, and back again. This is how really tough problems got solved; worked through in pairs through conversational problem-solving, story-telling and experimentation.

Many problems yield to two minds when one cannot find the way. Two heads are better than one.

Knowledge Transfer & Creation
Another advantage of working in pairs is knowledge transfer. When two people work together, they share knowledge almost invisibly. Furthermore, conversational problem solving, as in described above, can create knowledge. This type of knowledge creation is characteristic of learning organizations.
Conclusion
Many of the best moments of my professional life involved partnership. Working with another person increases the quality of work and the creativity of the solution. Whether it is design of user interface, writing a white paper, or solving an engineering problem, every aspect of work seems to improve with a partner.

Next time you have a tough problem that requires creativity, intellectual rigor and a quality solution, consider whether two heads are better than one, even if using two resources breaks with tradition.
Questions
Have you observed pair-teams like the ones discussed, above?

What are your thoughts regarding this kind of partnership?

Think of the three most productive people you know; the people that managers and coworkers would pay good money to clone. These are the folks whose loss spells organizational crisis. Now, take a moment and write down their names.

Here is the key question: Are any of the people on your list there because of the technology that they use?

Odds are that these folks use technology well. However, technology is likely a secondary aspect of their success. For most people, dedication, knowledge and the ability to create a working process lead to their success. Not the technology they use. So, what is the point? Just this: Technology is important, but the team and their work flow trump technology. If you don’t improve your people and your process, technology benefits will be limited, or even negative.

That is why the US military uses the term “force multiplier” to describe technology. A force multiplier can amplify the effectiveness of a well-trained team that is already executing well-honed processes. Conversely, if you have a team that is muddled and processes in chaos, technology can also amplify that!

Let’s look at a case from outside the utility industry that demonstrates this.

GM & Toyota
In the early 1980s, GM was having great difficulty keeping up with the Japanese auto makers. So, GM partnered with Toyota in an attempt to learn their technology secrets. The two companies formed a joint venture and re-opened a plant in Freemont California that GM had closed two years earlier.

Toyota managed the plant and brought it back up to speed. Productivity was 50% higher than at other GM plants.  However, when GM management visited the plant, they did not find any high-tech secrets.

Toyota removed much of the new technology that GM had in the plant. However Toyota also involved all the employees in efforts to improve. The company improved their people through training and engagement, and the people improved the process. Huge differences in work flow resulted.

For example, at Toyota, if assembly workers spotted a defect, they were expected to stop the line so the defect could be fixed as early in the process as possible. At GM, if a worker stopped the assembly line, someone’s arm had better be stuck in the machinery, or that worker was getting fired. Defects were fed downstream, where fixes involved much greater re-work and expense.

There is a great NPR story on what GM learned and didn’t learn from this venture with Toyota. Click here to hear it.

Isn’t SNS a Technology Company?
Some readers may wonder why SNS would take the position that technology is not top of the list of factors for effective performance improvement. Isn’t SNS a technology company? I would answer with a follow up question: Who would you rather have implementing your automation: a team of technophiles who believe their tool is the center of the universe, to which your team and processes must bend, or the folks who wrote this article and understand that people and process should drive technology decisions?

A Couple Questions
What does it take to change an organization so that people and process get more attention, and start driving technology decisions?

Do you have an example of smart people and process trumping technology?

Thanks for reading. If you found this article interesting, please, join the conversation by subscribing and leaving a comment.