> The aphorism is a bit dated but rings true: you can’t add another developer and make the process …

If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you. I’m talking from personal experience of well over twenty years as both a developer, and for a while, a manager.

When people say code is the bottleneck, they don’t always mean the lack of code: it’s also the accumulation of code, which becomes like plaque clogging your arteries. When you have too many people pumping out too much code, it can be the death of your startup. Startups have failed from writing way too much code.

> new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team This is true of training someone new to do a routine job. You spend some time teaching them, and they learning, and then that overhead of teaching/learning slowing you both down disappears. But it's a little different with knowledge work, as the constant changes and creation of stuff means other team members have to constantly learn what you changed/created if they are to do anything with it. So you never reach this "well-oiled" state, unless you divy up the tasks so that the amount of information you need to deal amongst each other is minimal and unchanged. This principle even holds true in multithreaded programming as to performance, in that constant sharing and changing of data between threads can actually hurt performance in comparison to a single threaded process.