I see companies that keep hiring directors, VPs, and more C-level executives, but do not hire the people who will take action.
On the other hand, I see companies that keep hiring engineers with almost no management.
I want to discuss the second group.
Your engineering team is growing. Delivery is still slow. Is another developer actually the missing piece?
Before opening another position, I would look at what the work is waiting for.
Follow the Feature Beyond the Code
Imagine a feature whose code is ready.
Infrastructure wants a different deployment approach. Product has changed priorities. A vendor controls a dependency, and nobody knows when it will be available.
The engineer moves to another ticket. The feature stays where it is.
Each team may have a reasonable concern. Infrastructure may see a production risk. Product may have a more urgent customer commitment. The vendor may need information that nobody has provided.
But who is responsible for getting those concerns resolved?
Someone needs to understand the deployment tradeoff, agree with product on whether the feature should still ship, and decide what to do about the dependency.
Another developer can implement another feature. These decisions will still be waiting.
Build a System That Helps the Team Deliver
As a team grows, more decisions cross team boundaries. An engineer may understand a deployment risk without having the authority to change infrastructure priorities.
I think this is where companies underestimate technical leadership.
You need someone who can zoom out and build a system that helps the team build and deliver software. That includes the architecture, the path to production, and how people make decisions across teams.
Look beyond the feature that is stuck today. Why did deployment concerns appear only after implementation? When should vendor dependencies become visible? Who decides when priorities conflict?
That person needs the technical understanding and authority to resolve these questions, change how the work moves, and follow through to see whether delivery improves.
The business result still matters. Is the delay blocking a customer launch? Would reducing scope get something useful into production sooner?
I discussed this in What Type of CTO Does Your Startup Really Need?: understand the capability your company needs before choosing the title.
Sometimes you need to hire someone. Sometimes a person already on the team needs clearer authority and time to do this work. Adding responsibility to an engineer who is already fully occupied does not create that time.
I made a related point in Burning More Tokens Does Not Make Your Team More Productive: look at what AI usage accomplishes across the team.
Suppose AI helps the team finish implementation sooner. That is useful. But if completed changes still wait for deployment decisions, priorities, or external dependencies, releases can remain just as slow.
You may simply accumulate more unfinished work after coding.
Trace One Real Change
Before deciding whom to hire, I would take one recent change and follow it from the business request to production.
Use the actual tickets, pull requests, and conversations. Ask the people involved what happened.
For each point where the work stopped, write down:
- What was it waiting for, and for how long?
- Who could make the decision or remove the obstacle?
- Why did that not happen?
- What would have allowed the work to continue?
Follow a few more changes and see whether the same delays repeat.
Maybe the requirements are clear, decisions happen promptly, and the team simply has more implementation work than it can handle. Hiring more engineers makes sense.
If the same obstacles keep returning, someone needs to change how the work moves.
Before adding capacity, understand what the work is waiting for.