What is the optimum size for a tech team?

September 8, 2023

Price’s law (competence is linear, incompetence is exponential) pertains to the relationship between the literature on a subject and the number of authors in the subject area, stating that half of the publications come from the square root of all contributors.

If 100 papers are written by 25 authors, five authors will have contributed 50 papers.

Transfer this interpretation into the most effective development team size and it’s our conclusion, that you will get diminishing returns with any team size greater than 10.

Derek de Solla Price observed that on any particular subject, half of the publications come from the square root of all contributors.

This became known as Price’s Law [the use of the word Law here is a scientific term that is based on observations, but it does not explain why or how it exists].

The generic interpretation of Price’s Law has since been extended to 50% of work is performed by the square root of the population on the work.

My experience of mentioning this to business colleagues and in particular to fellow CTOs, is that they generally dismiss the concept as interesting, but not true of their experience of teams and organisation.

Then, after about two minutes of cogitating and unpacking the theory in more detail, they start to appreciate that perhaps it could and has been a truth in their management of teams.

Price’s Law is Logarithmic 

It is common for Price’s Law to be compared with the 80/20 principle (Pareto Principle).

The key difference is that Price’s Law is logarithmic and applies to only 50% of the work (so 50% is still done by the rest of the group).

To understand what Price’s Law mean, the graph below visualises the difference between more productive (star) and regular workers.

Tech Team SIze for High Performance

Reading the graph for a team of 8 means that regular workers are about 50% as productive as the star workers whereas, with a team of 100, the regular worker is only 10% as productive.

For the sake of this article, we assume that efficiency and productivity are interchangeable whilst understanding that there is a difference in a wider context, subject for another article.

  • Only a small number of individuals affect change in a tech team and drive progress, due to position and personality.
  • Once a team goes above ten, informal communication drops off which affects productivity as well as allowing frustrations to build between individuals.
  • It is easier to hide in a larger team. When one inherits a team or needs to do a shakeup, it’s this deadwood that gets targeted.
  • Some team members have more experience and will thus, be more productive.
  • Some tasks may not appear to help towards productivity but be just as important i.e. testing.New team members take time to get up to speed and often take up time of another team member (The Mythical Man Month)

Of course, it’s rarely possible to grow a team to 10 and then stop!

How does it affect team building? 

Look at splitting a team once it gets to 12. How you split it will depend on the product, company and skills of the developers.

You might split by functional areas, so with an e-commerce type web application, that means splitting the team into admin functionality and user functionality, with each taking backend and frontend developers. Alternatively, you could split by type of work such as splitting the team into a frontend team and a backend team.

To prevent silos, you then make sure that each team talks freely with each other, as well as move members around occasionally to develop their skills and career.

Without necessarily being aware of Price’s Law at the time, my experience was that an optimum size for a development team should be 8-10. Any more and the productivity dips, your time is chipped and the team becomes less productive. I’ve therefore always split a larger number into separate teams, with a nominated team leader (i.e. scrum master).

Does it apply only to development teams? 

Canvassing around elsewhere there is evidence that this theory may be applicable more generally. As an example, most team sports have less than 12 players on the field at any one time.

The subject of optimum team size has been the source of much pub debate with some of my colleagues but I’d say the general consensus (from our team at least) is that Price’s Law is a useful yardstick when designing teams for development.

Here’s an interesting article on the topic, Price’s Law Is Going To Kill Your Company

Download Our Free eBook!

90 Things You Need To Know To Become an Effective CTO

CTO Academy Ebook - CTO Academy

Latest posts

Tech Strategy Discussion Panel Summary - blog post featured image

Aligning Tech Strategy with Business Goals – Discussion Panel Summary

An important part of each module in our Digital MBA for Technology Leaders is a discussion panel where a group of experienced tech leaders dive […]
Tech Leadership in So Many Words - #25 - Collaborative

Tech Leadership In So Many Words…#25: Collaborative

The essence of collaboration in tech leadership revolves around creating a culture where a common mission, openness, complementary strengths, and collective problem-solving are the pillars. […]
Responsibilities Strategy and Skills of Technical Leader

Responsibilities, Strategies and Necessary Skills of an Effective Technical Leader

A technical leader bridges the gap between technical teams and business objectives. Unlike general managers, they possess strong technical expertise and can therefore guide engineers and developers. […]

Transform Your Career & Income

Our mission is simple.
To arm you with the leadership skills required to achieve the career and lifestyle you want.
Save Your Cart
Share Your Cart