When should you assign two people to do one person’s work?
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?
