Broken Systems Don't Need More Developers
If four developers aren’t delivering fast enough, why not make it eight?
Manager:
"We're behind schedule! We need more developers."
Senior developers don’t think:
"Great, we'll finish sooner."
Instead, it's more like:
“We’re about to spend the next month onboarding.”
Because they know what comes next…
Onboarding
Interruptions
Explaining codebase
More meetings
More PR reviews
More merge conflicts
The Rules Nobody Wrote Down
The system is a tangled mess of dependencies.
But after working on it for years, experienced developers have learned to navigate the mess.
They know:
“Don’t touch that class.”
“Only Mike understands billing.”
“Changing this always breaks reporting.”
“That test is flaky, just rerun it.”
They’ve built a mental map of the codebase.
A new developer hasn’t.
Every feature starts with: “Who knows this part of the system?”
They need someone to explain the codebase, the architecture, and all the hidden pitfalls nobody documented.
More detailed code reviews.
More meetings.
More Developers. Less Progress.
The bottleneck isn’t the number of developers.
It’s the architecture.
When the system is tightly coupled, every change collides with another change.
Adding more people doesn't remove the bottleneck.
It just makes it worse.
📅 Join me: Clean Architecture for Backend Developers on Wed 26th Aug, 5:00 - 6:30 PM (CEST)
"Only Mike understands billing" — that's not just a people problem. It's measurable.
When 80%+ of the commits to a module come from one person, that's a knowledge silo.
Git history records it commit by commit — long before Mike hands in his notice.
"Changing this always breaks reporting" is also in the log: billing and reporting co-changing in the same commits, across years, across teams.
Nobody documented it, but the codebase did.
The mental map experienced developers carry exists in the git log.
It just needs to be read.