Wrong beliefs could cost you a lot. Here is the reality: all the people are unique. The software developers are different, as well as the tasks and projects that they face. Distinct problems have various dimensions of complexity, and different people have various mental capacities.
A software development increment may involve several abstractions that a developer must keep in the head while designing a solution and implementing the source code. The specific task abstractions are usually represented by one or several independent program branches. Thus the scale of complexity number is well approximated by cyclomatic complexity (https://en.wikipedia.org/wiki/Cyclomatic_complexity). Different developers naturally have various cyclomatic capacities: an ability to deal with and consider multiple edge cases and data flows simultaneously.
I have two bad news here. First: the cyclomatic mental capacity is tough to develop, and it takes many years. Second: contrary to the effort, the cyclomatic power of the team does not add up. While ten developers can write ten times more lines of code than one developer for a given period, the team's cyclomatic capacity is the best capacity of its individual.
To perform unique or even more challenging assignments, the team often has to have a qualitative improvement. It is not always possible to increase the team performance just by increasing its size. It is worse. Every manager knows this inflection point of their team: after reaching this particular head size, the actual team performance decreases.
In agile practices, it is common to split stories into components on the estimation phase. The typical elements are effort, doubt, complexity. Many readers have noticed that in this article we are distinguishing effort and complexity.
Here is a real example from my practice. As a result of the assessment of individuals, we replaced a multidiscipline team of seven senior developers with a 70% lesser team for one startup in 2017.
The first team was developing the project for two years and kept failing to complete the delivery because the code was not scalable and was falling apart. The team tried to restart the project a few times, but with no success. The team reached its mental capacity. The developers could produce an incredible amount of code that would, theoretically, cover every possible case, and the management invested a lot of money in QA. Still, the task's cyclomatic complexity was merely higher than every team member's best cyclomatic capacity.
As the new team stepped in, they completely rebuilt the project from scratch and released it in just three months with none to zero bugs and perfect scalability.
Every developer in the first team was roughly $120k per annum, which was the $860k of the wasted money per year (you should add other resources as the time, desk costs, management costs, interests, etc.). The second team members' salaries were considerably higher: in the range of $180-220k per year, but the team consisted of just three people, so its total cost was only $600k per year. What is more important, the second team delivered the project in 3 months, so the development costs were just $150k.
Again: the first team burnt almost 20(!) times more money with zero results while the second team was cheaper and more performant.
The whole article, as the fact that a project may be too complex for a team, is, in fact, banal and still often being ignored. The leaders try to introduce monetary incentives, overtimes, build the team culture and still face failures.
Suppose you are a project manager and your team consistently fails to deliver one particular type of project while nailing slightly simpler others. In that case, it may be a good idea to question the team's cyclomatic capacity and compare it to the problem requirements. As an experiment, may I suggest temporary borrowing one more expensive bright contributor from a parallel team and observing the results?