More collaboration – and better collaboration – is seen by many as a key requirement for business success. Open a recent leadership book or an issue of Harvard Business Review, and you will see that this topic is very much in vogue right now. Not without reason. We do need more and better collaboration to achieve coordinated action and to ensure that we harness the collective intelligence of people at all levels of an organization.
At times, though, we overshoot. We collaborate just for the sake of it (we secretly love meetings, some say). We forget why we were supposed to collaborate. We overlook the cost of unnecessary collaboration. We fail to consider whether an individual could have done the job better than the team.
I came across an interesting study that provides some quantitative evidence relevant to this problem. It is authored by two Microsoft employees together with a researcher from the University of Maryland*. The study looks at how one best can predict the quality of software systems (in this case, Windows Vista). The key quality factor they measure is defects or “failure proneness”, i.e., the probability that the software system will fail when in use.
Traditionally, one has used metrics related to either the software itself or the development process to predict defects. For example, it has been shown that large and complex software systems will be more likely to fail than smaller and less complex systems. One has also looked at the edits being made to the code during development and been able to predict defects by measuring “code churn” (large changes to code made just before a release).
The Microsoft authors ask, however, what the effect of the organizational structure might be. They note that previous authors have speculated that product quality is strongly affected by organizational structure. They formulate several hypotheses, including the following:
- The more people who touch the code, the lower the quality
- The lower level [in the organization] the ownership of a software module [is placed], the higher the quality
- The more cohesive the contributors are [i.e., the lower the number of different organizational units that participate] the higher is the quality
They test these hypotheses with data representing more than 50 million lines of code. They find that organizational structure predicts defects with very high precision (86%) and also conclude that this measure is a better predictor of defects than traditional process and software related metrics.
Too many Programmers spoil the Code, the authors say.
Too many Cooks spoil the Broth, Balthazar Gerbier said, in 1662.
When you hear this saying you inevitably think about a kitchen – but the origin of the saying is actually a different – and more fitting – setting.
Gerbier was writing about how to design a new royal palace for the king of England. He explains how the building can be designed according to the principles of Solidity, Conveniency, and Ornament. But he also talks about the planning and construction process.
Here’s a bit from the text so you see the context:
As I said before, no building is begun before a mature resolve on a completely finished model of the entire design: the builder having made choice of his surveyor, and committed to him all the care and guidance of the work (…)
(…) It has been observed among the French (…) that when the charge of an undertaking has been committed to many, it caused but confusion, and therefore it is a saying among them, Trop de Cuisineirs gattent le pottage, ‘Too many Cooks spoil the Broth’.
Another way to put it: The purpose of organization design is not to maximize collaboration, but to ensure that we have the right amount of collaboration for the task.
We have known this for a few hundred years – but the Microsoft study shows that these are concepts that we can now measure and use to improve the design of organizations.
*Nagappan, N., Murphy, B. & Basili, V. R., (2008). The influence of organizational structure on software quality: An empirical case study. Proceedings of the 30th international conference on Software engineering.