A classic book by Tom DeMarco and Timothy Lister from 1987 which I'd summarize: Leaders of software developer teams should care more about sociology. It is hard to summarize however because it is a collection of essays meandering into different topics. I'll try to stay with its core message.
Sociological issues are dominant
The authors can reference years worth of data as they were running Coding War Games.
The game rules: A pair of developers from the same company registers. They compete with each other and implicitly all previous participants. They work in the normal working conditions. The get the same task to build a small program. They keep a journal to log the times to milestones. A standardize acceptance test rates the results.
From 1984 to 1986 more than 600 developers from 92 companies have participated in the games. This study seems to be the root of the "10x programmer" meme. The best participants were 10x as fast as the worst ones. However, they were only 2.5x as fast as the median one. The distribution is roughly the same for number of defects. The mix of both is what Peopleware means by "productivity".
With more than 600 data points, they could investigate the meta data. For example, what does not matter for productivity:
- The programming language does not matter except that assembly is worse.
- Years of experience does not matter if above six months.
- Number of defects and time are independent, so apparently speed and correctness is not a trade off.
- Salary does not matter much but there is a correlation: Above median developers earned 10% more on average (while being twice as productive).
Of course, this data is pretty old now. For example, the programming languages they write about are Fortran, Cobol, and C. It would be nice to see this study replicated.
Maybe you wondered about the "pair" constraint in the rules? This is behind one thing that does matter for productivity: The company. In other words, it matters more what is around your desk than what language you use and how many years of experience you have. Correlation is not causation of course. We don't know if the environment determines the productivity or if productive programmers end up in certain environments or if another factor attracts productive programmers and creates certain environments.
Does it matter though? If an organization can create productive environments it should either make the existing developers more productive or attract the productive developers. Both is worth it if you remember that you only pay 10% more salary for a developer twice as productive. Salary shadows any cost of the environment so it is a sweet deal.
This is the core argument of the book. This is where you have to decide if you consider this convincing. Personally, I think with 600 data points it is a solid argument. Its age weakens it a little though.
How to make teams jell?
The book uses the verb "jell" to describe productive teams. It seems to be similar to flow for individuals.
What is called for here is a concise chapter entitled "Making Teams Jell at Your Company". It should have a dozen simple prescription for good team formation. [...] Between plan and execution, there were a few distressing encounters with reality. The first was that we just couldn't come up with the six prescriptions needed. We got stuck at zero.
Then they explored anti-patterns instead. However, three chapters later...
A chemistry-building strategy for a healthy organization:
- make a cult of quality
- provide lots of satisfying closure
- build a sense of eliteness
- allow and encourage heterogeneity
- preserve and protect successful teams
- provide strategic but not tactical direction
There are more. We've cited only those elements that have a particular effect on team formation.
Unfortunately, the book does not try to rate the measures or even provide evidence that each of them is relevant.
Who should read it?
There are a lot more ideas in the book. It makes no sense to summarize them into a blog post. The book itself reads like a collection of blog posts. If you believe the argument above and you want to know more, get the book. It is a book I want to keep on my shelve anyways. Maybe in five or ten years, I want to read it again to get ideas.
I can recommend it to any manager of software developers (or probably knowledge workers in general). You should at least think about the idea that the environment can have a huge impact on your peoples productivity. However, I would recommend The Culture Code even more.
Software developers in large corporations should also read it. Maybe you don't even realize what makes you suffer. This book may give you concrete ideas what you could change.
If you try to change something, read Switch.
The Culture Code has a similar topic and is more recent.