Hiring ICs vs Engineering Managers: The Decision I Keep Revisiting

The right ratio of ICs to engineering managers is not a constant — it is a function of team size, product phase, and how much unresolved technical debt is actively blocking delivery. I have revised my hiring framework three times across companies ranging from 8 engineers to 140. The current version is a scorecard, not a headcount formula.

Answer first

Hire an IC when the bottleneck is implementation capacity on well-scoped work, and at least one senior IC can own technical direction for that scope.

Hire a manager when the bottleneck is coordination cost — too many dependencies, unclear priorities, or engineers spending >30% of time on status sync instead of code — and existing leads are already at their span-of-control limit (typically 6–8 direct reports for a hands-on EM, fewer if they are also tech-leading).

Do neither and fix the system when the bottleneck is process, unclear product strategy, or infrastructure that should be a platform investment.

That third case is where companies burn headcount.

The scorecard (updated March 2025)

I score five dimensions 1–3 before opening a req. Total ≤ 8 → IC. Total ≥ 11 → manager or senior EM. 9–10 → split req (senior IC + fractional EM from another team) or delay one quarter.

Dimension	1 (favor IC)	3 (favor EM)
Delivery predictability	Sprint commitments met 80%+	Misses blamed on "who owns what"
Technical debt velocity	Debt tracked; 20% capacity allocated	Debt blocks features every sprint
Cross-team dependencies	≤2 external teams per epic	≥4 teams on critical path
On-call health	Pages per engineer <4/month; runbooks current	Repeated pages with no owner
Career pipeline	Clear IC ladder; promotions on time	ICs doing manager work unpaid

We ran this on a 34-engineer org last year. Score was 12. We hired an EM for a 9-person product squad that had been "led" by a staff engineer who wanted to stay IC. Six months later, that staff engineer shipped the hardest technical project of the year because they were not in every standup.

Team size breakpoints that held up

These are not laws — they are where I have seen inflection points:

• ≤8 engineers, one product: No dedicated EM. Tech lead + PM + weekly prioritization ritual. Adding an EM here often creates a communication hop for no gain.
• 9–15 engineers: First EM or experienced EM-with-tech-cred. Span of 7–9. If you have two distinct sub-products, you probably need two leads before you need a director.
• 16–40: EM layer + staff/principal ICs owning domains. Manager's job is load-balancing and hiring, not design approval.
• 40+: Director layer; EMs should not also be the only architect for their group.

The failure mode at 12–18 engineers is hiring a "player-coach" EM who cannot let go of coding and manages 4 people while tech-leading — you get neither good management nor good architecture.

Product phase matters more than org chart templates

Phase 0–1 (finding fit): Bias IC-heavy, especially generalists who can tolerate ambiguity. A manager who "processes" exploration kills learning speed.

Phase 2 (scaling what works): Bias toward EMs and senior ICs who can systematize — observability, CI/CD, on-call rotation design. This is when on-call rotation design becomes a hiring signal: if nobody owns it, your next hire might be an SRE or an EM who has done it.

Phase 3 (margin and reliability): Bias platform ICs and EMs who can say no to feature work. Cost discipline — see cloud egress accounting — often exposes that you hired feature engineers into an infra-debt problem.

The IC-vs-manager interview mistake

We used to ask EM candidates to whiteboard system design. We stopped. EM interviews now center on:

• A real prioritization conflict story (what they cut, how they communicated it)
• A underperformer they managed (timeline, documentation, outcome)
• How they ran a post-incident review without blame

IC interviews still include design depth. Conflating the two pipelines is how you get managers who want to be staff engineers and staff engineers who are forced into people management to get promoted.

Compensation and title traps

At one company, the only path to $200K+ was people management. We lost two staff-quality ICs to management titles they did not want. Fixing the IC ladder changed hiring math: we could hire an EM at L6 knowing our L6 ICs would not leave for scope.

Dual-track is not optional once you have senior ICs. If your "senior manager" band starts above your "principal engineer" band, you will hire managers.

What I would do differently next time

I would instrument coordination tax directly: weekly survey, two questions, five-point scale — "I know what to work on" and "I had to wait on someone outside my team." Trend that for a quarter before opening any EM req. Anecdotes from frustrated engineers over-index on recent pain.

I would also require every EM req to name what IC work the EM will stop doing — explicitly, in the job description. Candidates deserve honesty; teams deserve not to hire a third project manager.

Decision memos for org changes should follow the same async discipline as technical RFCs — see writing RFCs that get read. Org changes implemented by surprise create the coordination debt you hired an EM to fix.