If only it were so simple. The book Software Assessments, Benchmarks, and Best Practices, by Capers Jones, does a deep dive into the factors that make software projects succeed or fail, with a particular focus on large software projects - the kind that fail more often than they succeed, eating a budget that could fund 100 startup launches. Jones observes that “Excellence in project management is associated with 100% of successful projects for projects larger than 1000 function points.” So, you can’t possibly live without ’em. On the other hand, the book also offers a tantalizing glimpse of a world where hackers might roam free, unencumbered by the distraction and inefficiencies of project managers. Sometimes, you shouldn’t live with ’em – or very many of ‘em. Jones observes that “productivity levels for software projects tend to decline as the number of managers goes up, rather than as the number of technical staff members goes up.”

Even without Jones’ statistics, it’s obvious that bigger projects have a lower productivity than smaller projects – much lower. So, if you have a big project, you need to do everything possible to keep productivity from declining as you add staff. Many of you might be thinking “Project managers waste a lot of time in meetings and so on, and they often don’t understand the key technical or design decisions, and they bug me. Is Jones giving us the green light to jettison the project managers?”

I will quote from page 222 of this timeless work of literature:

“…good managers are a fairly scarce commodity. If a company has a low span of control, then it will have a large management population. Because bad management is a common reason for project failure, it can be seen that having fewer but better managers may lead to overall improvements in both performance and productivity. In general, software productivity levels decline as the number of workers increases. Here, too, this is a general finding from many industries, and not just a finding for software projects. However, there is a curious phenomenon within the software domain that was first noted in the 1970’s. Productivity levels for software projects tend to decline as the number of managers goes up, rather than as the number of technical team members goes up. The implications of this finding are that for large applications (>10,000 function points), small teams with four to eight workers are not as productive as larger departments with 10 to 12 employees. As the management count goes up, coordination and cooperation between departments becomes difficult due to normal corporate politics.”

In other words, you should have the largest span of control – the ratio of developers to managers - that you can get away with. A really great manager can work with a lot of developers, which improves efficiency.

The best example that I can think of is the way open source projects are organized. I have written before about how open source projects seem to avoid many of the scaling problems that have seemed intractable since the publication of The Mythical Man Month 35 years ago. One reason is that developers don’t absolutely have to wait for fixes from someone else, which is what developers on large projects spend a lot of time doing. Every developer has all of the code, so if the problem is important enough, the developer experiencing the problem can fix it. But, another important scaling factor is a very large span of control.

A recommended span of control in a business is 8 – one manager with eight staff members. Open source projects have maintainers, who are hands-on contributors rather than managers. So, one would think that they can handle fewer contributors than a full time manager. However, Andrew Morton, top maintainer of the linux kernel with Linus Torvalds, notes that “We have probably 50 or more subsystems, each with an identifiable top-level maintainer.” All of these maintainers feed code to Morton and Torvalds. So, the span of control in linux development is closer to 20.

I continue to learn from open source projects. They work and they continue to provide management insights.