Sometimes it's more! You have nine projects you want to do. A, B, C, D, E, F, G, H. You have 2 developers. You hire 3 more. One of the new hires has more familiarity with what projects E and G needs than anyone on the existing team had. One of them is slower than the average of the existing devs. One of them is MUCH faster. The five of them complete those nine projects in three months (15 total people months, with boosts from one of the new dev's skills and the other's increased speed) when it may have taken 9 otherwise (18 total people months).
But I've seen a lot of companies not be quite that smart in their hiring...
(The faster scenario I've outlined above also potentially bites you in the butt if you don't have enough more valuable projects lined up behind that first set...)
There is a sweet spot for how many people should be on a team. That number depends entirely on a nature of tasks. I would even go as far as to say - in a good environment up to that sweet spot, productivity gain is linear.
And yes, managers do expect close to linear productivity gain past that spot. Managers, that are a little smarter, start thinking about how spotify did squad (without actually knowing anything about it).
The term "Two pizza team" comes from Amazon and describes a team size such that it is the number of people that can be fed by two pizzas. The reality is that the term is not only a reference to team size but, rather, underscores the concept of "Accountability".
What I was talking about is something like this: SRE team has 1 member and productivity of 1, that person is overworked and if vacation is taken productivity goes to 0.
Hire second person, after onboarding productivity goes to about 2 (i.e. linear scale). Hire third person, productivity will probably be a little under 3 because now they need to spend time to be on the same page. Vacation is still shaky because with such small team, knowledge will be 100% siloed due to outside performance expectations ("hey you worked on X last time, I'm going to assign this ticket to you" repeated many times).
Eventually team grow to a point where they can handle all work load, share knowledge between each other and take vacations without fear (btw if you fear taking vacations - don't, it's not your fault if team can't handle without you).
You can think of "work load + process" as a data structure. If work load is bog and process requires a lot of synchronizations (every meeting is essentially a Mutex for the entire team) - you won't get linear productivity increase, instead you will increase lock contention.
Sometimes it's more! You have nine projects you want to do. A, B, C, D, E, F, G, H. You have 2 developers. You hire 3 more. One of the new hires has more familiarity with what projects E and G needs than anyone on the existing team had. One of them is slower than the average of the existing devs. One of them is MUCH faster. The five of them complete those nine projects in three months (15 total people months, with boosts from one of the new dev's skills and the other's increased speed) when it may have taken 9 otherwise (18 total people months).
But I've seen a lot of companies not be quite that smart in their hiring...
(The faster scenario I've outlined above also potentially bites you in the butt if you don't have enough more valuable projects lined up behind that first set...)