Thread by @tottinge

"Ability To Do Work" is so ignored by many contemporaries. It's easier to assume that one person is pretty much the same as another, on average, and that work is done by individuals.
This way the math works out for linear gains from adding headcount.

"Capacity" has become a euphemism for headcount.
The "on average, a programmer is a programmer, a QA is just another QA" is not only wrong about individuals, it's dreadfully wrong about teams.

For people to be great soloists with equal capacity in solo work, each person has to have the same set of skills, habits, approaches, talents, knowledge as every other person. We know that isn't so. It will never be so.

But on a team? That's a whole different game. A proper team (not unteamed with solo assignments) is a tide that lifts all boats. You don't need the people to each have all the skills, you only need the skills to be in the ensemble.

All the work the team does is the work of an expert Java programmer and an expert JS programmer and a React expert, and an architect, and a testing professional, and a product specialist, and a SRE if those people are in the ensemble.

Adding a redundant set of hands to the ensemble is probably not going to make a lot of difference. Adding a needed talent is going to make a big difference.
Spreading better habits, knowledge, skills is going to make a big difference.
That's the tide that lifts all boats.

BTW: you don't get these benefits if your ensemble is "worker/watchers" or if the ensemble is doing work specifically carved out for one of the members.
It's only the work of those experts if those experts participate. That's why we self-organize, to get the right brains:task.

And instead of adding more hands, you might get a lot more benefit by removing wait states, queues, tedious repetition, style disagreements, and the (ever-present for solo programmers) muddling through when they don't know "the best way".

you might be surprised to see the improvement in quality and robustness when you improve "the ability to do work" instead of "the number of workers."

"But we need more people!"
Does that mean you need to get more work done? Or that you have a quota of people? Or that you need additional product lines?
What does "need more people" mean?

Is bigness the reason? Do you need more people so you can be bigger, because the big players have a lot of people? Is it an embarrassment to have a small staff? Or do you need more work done?

You can get more work done without hiring a lot more people or working overtime.

If you want to get more work done without becoming more skilled or efficient and without using a better process, then you're pretty much down to having more people working in more teams.
But maybe a bit of curiosity and imagination is cheaper, faster, better?