We all know that small teams work better then big teams, and there is even a study.

But what are the limiting factors of big teams? why do they do so poorly compared to small teams?

a 32-person team on average would have used 178 person-months of effort ($2.1 million at $12,000 per person-month). The 4-person team would have used 24.5 person-months ($294,000 @ $12,000 per person-month).

How much schedule compression was achieved? Not much! The difference between the large team and the small team approaches for the average project of 100,000 source lines of code is approximately 1 calendar week.

In the study results, we can see that it took the big team (32 developers), 1 week less to complete the same project then the small team (4 developers), this 1 week difference seems to be too small for it to be luck, but it just seems too small.

We are talking about 8X developers working on a project for 9 months, and the only difference is 1 week.

So what is it that limits big teams from doing much better then small teams? I don't expected 50% less time if you hire twice the developers, but I do expect a much bigger difference then just 1 week (out of 9 months).

Is it management? Communication?

  • 8
    Do note that QSM (the company that did the study) is the vendor of a commercial planning platform and is not an independent/scientific study. They do not seem to provide any differentiation between the types of company/industry that had the greater teams or if that was accounted for in their analysis. Not saying I disagree with the premise of your question, but be critical of the study as it is presented to steer you towards planning more efficiently which they coincidentally can help you with by buying their product.
    – Jeroen
    Commented Mar 15, 2021 at 11:32
  • I totally get it, I used this study just as an example to make it clear what im asking, it is known that every team in any field have a cap to the number of employes they can hire where it starts to not be beneficial. I wonder what are the reasons for it.
    – Art3mix
    Commented Mar 15, 2021 at 11:43
  • 2
    It depends on the task. In my study, that I just made up, I assigned 100 individuals and a team of 100 people the task of creating a fizzbuzz procedure. Amazingly the team of 100 was no faster than the majority of the individuals! Coming from the other side it's unlikely a team of 6 will be almost as fast as however many people are working on the design of the next SpaceX design. Most tasks have a point at which throwing extra people at it is not efficient. For some tasks like designing a very simple program that point is 1 person, for others, like designing a rocket, it is 100s.
    – Eric Nolan
    Commented Mar 15, 2021 at 16:39

2 Answers 2


The key limiting factor is how many people can work on tasks which are independent of each other and are ready to be started. Usually there are a number of people from the business side to define what needs to be done. After a certain point, having a greater number of people doesn't help as they will be blocked—they will be waiting for someone else to complete work so that they can start ("finish to start dependency" in terms of project planning). Also, more people means more overhead, we need tech leads to ensure standards are followed, code is reviewed etc.

The next hit comes in integration—streams may develop independently but they need to integrate so that system works as a whole. Again this would need a smaller subset of developers and a bigger test team.

There is no perfect size of the team, it depends on how many parallel streams you can run.


There are two factors.

One is the issue of how many people can work on the same tasks independently. However this isn't really about team size. This is very dependent on the kind of work being done, and can't be fixed by dividing your workers into two teams. It's a limit on how many people can work in one area.

The main one is about communication. In general within a team everybody should have at least a rough idea of what everyone else is doing, precisely to avoid conflicts and duplication. The amount of communication grows faster than the number of people in the team (technically it grows as the square of the team size). In a two person team there are two people who each have to tell one other person what they are doing, giving 2 channels of communication. With a three person team there are three people each talking to two people, giving six channels. In a ten person team that number is 90, and in a 32 person team 992.

Incidentally you can fix the "how many people can work independently" problem by having people not working independently. By having everybody work in pairs where the pairs communicate very tightly you can double the limit.

  • There is a third factor - errors. A larger team writes more errors into the code. Often, the errors are the subtle ones such as design flaws for submodules. Thus, the QA portion of the process has to be longer and more formal.
    – David R
    Commented Mar 15, 2021 at 19:13
  • 1
    I don't think that's right. Why does a large team produce more errors than a small one, except in the sense that it produces more work than a large one with the same error proportion? But a large team also potentially fixes more errors and find more errors, because it's larger. Commented Mar 15, 2021 at 19:15
  • It is a result of the communication problem. Because there are so many more people involved, not everyone will understand the design when they are writing a module. A larger team often will have multiple designers and they don't all understand what each other are designing. Thus, they will write in bugs. The QSM study found that large teams generated five times the defect rate as a small team. Other places simply note that larger teams build more chaotic systems.
    – David R
    Commented Mar 15, 2021 at 19:53
  • OK. But in my mind that doesn't make it a third factor, it is just a byproduct of communication. Commented Mar 15, 2021 at 20:45
  • Really, we could just sum it up as "coordination". More people = more coordination to make sure the right hand is aware of what the left hand is doing, at the right time, and with the right resources. It's a more high-level version of what is being described. IMHO.
    – David
    Commented Mar 15, 2021 at 21:40

Not the answer you're looking for? Browse other questions tagged .