"We've got a lot of features on the roadmap, so just hire 3 more engineers."
I witnessed a COO make this statement in a meeting once. On the surface, it sounds like logical resource allocation. In reality, it was blind ignorance. There was no evidence of capacity issues, the roadmap hadn't actually been discussed with engineering, and the existing teams were already sized too large to work efficiently.
This is the Fallacy of the "Engineering Volume Knob." It is the mistaken belief that engineering output is directly proportional to headcount, and that you can simply dial the team size up when you need speed and dial it down to save costs.
This mindset is a sure-fire way to ruin your primary value delivery system and create organizational chaos.
Why Adding People Can Slow You Down
In software engineering, people are not interchangeable assembly line workers. Engineering is a system of communication and decision-making. When you add people to that system without preparation, you introduce massive amounts of friction.
- The Communication Explosion: As you add people, the number of communication lines grows exponentially, not linearly. Teams that are already too large get bogged down in meetings, handoffs, and overlapping work. Adding more bodies to a bloated team just grinds the gears to a halt.
- The Onboarding Tax: Without established onboarding procedures, new hires become a drain on your most productive senior engineers. Instead of building that critical roadmap feature, your best people are stuck teaching the new hires the basics of a system that isn't documented.
- The Roadmap Void: Hiring before you have a scoped and planned roadmap is just an expensive guessing game. You end up with expensive talent sitting idle or building the wrong things because the business hasn't decided what actually matters.
The Prerequisites for Hiring
Hiring is not a shortcut to speed; it is an investment in capacity. And like any investment, it requires due diligence. Before you sign a single offer letter, you must have the core fundamentals in place:
- Validated Roadmap: Do you know exactly what these new people will work on for the next six months?
- Evidence of Constraint: Do you have metrics showing that capacity is the bottleneck, rather than inefficient processes or unclear requirements?
- Team Topology: Are your current teams sized correctly (think the "Two Pizza Rule")? Would adding people require splitting a team to keep it efficient?
- Onboarding Process: Can you bring a new engineer up to speed without halting current development?
If you treat engineering as a cost center that can be added to when speed is needed and removed from when slower, you will never build a high-performing organization. Fix the system first. Then, and only then, scale the team.