There's a specific inflection point in engineering leadership that nobody warns you about.
It happens somewhere between managing 5 engineers and managing 15+. The techniques that made you a great individual contributor — deep technical expertise, hands-on problem solving, personal relationships with everyone on the team — suddenly stop scaling.
I crossed that threshold managing a 19-member engineering organization at eZhire. Here's what I learned.
The Span-of-Control Problem
19 engineers. 3 team leads. 4 QA engineers. 2 database engineers. 1 DevOps engineer.
If you try to manage all of these relationships directly, you'll fail. You simply don't have the bandwidth. You'll be spread so thin that nobody gets enough attention, context will be lost between meetings, and the most critical work won't get the oversight it needs.
The solution is obvious in theory: build team leads who can operate independently.
The execution is harder than it sounds.
What team leads actually need:
- Clear scope of ownership (which systems, which decisions)
- Decision-making authority within that scope
- A clear escalation path for decisions outside their scope
- Feedback loops that tell them if they're operating well
What most engineering managers actually give their team leads:
- Vague ownership
- Decision-making authority in theory, overridden in practice
- No clear escalation criteria
- Feedback only when something goes wrong
I made all of these mistakes. Fixing them took about a year.
Architecture Governance at Scale
When you're managing 5 engineers, you can be in every technical discussion. You can review every pull request. You can catch architectural drift before it becomes technical debt.
At 19 engineers, that's not possible. By the time you're in every discussion, you've become a bottleneck. And by the time you're reviewing every PR, you're doing your team leads' job for them.
The answer is architectural governance — a set of standards, patterns, and review processes that don't require your personal involvement to enforce.
What we built:
- Architecture Decision Records (ADRs) — every significant architectural decision is documented with context, alternatives considered, and rationale
- A design review process — any new service, integration, or significant feature goes through a lightweight design review before implementation begins
- Code standards — enforced by linters and code review checklists, not by my personal taste
- Database review process — every schema change is reviewed by our database engineers before it goes to production
None of this is novel. But establishing it requires saying "we don't merge this until the review happens" in the moments when you're under delivery pressure. That's the hard part.
Performance Management Is a System, Not a Conversation
The biggest mistake I made early in my leadership career was treating performance management as something that happened in quarterly reviews.
It doesn't work. By the time you're in a quarterly review, the feedback should be ancient history — something that's already been discussed and mostly resolved.
What actually works is a system:
- Weekly 1:1s with direct reports (team leads, senior engineers)
- Bi-weekly skip-levels with individual contributors on a rotating basis
- Documented expectations — every engineer knows what success looks like in their role
- Continuous feedback — positive and corrective feedback delivered immediately, not stored for the review cycle
The quarterly or semi-annual review then becomes a summary, not a surprise.
Hiring Is the Most Leveraged Activity
Nothing you do as an engineering manager has more leverage than hiring.
A great hire multiplies the team's capability. A bad hire consumes enormous energy — yours, the team leads', the other engineers'. And removing someone from a team is one of the hardest, most emotionally taxing things you'll do.
My hiring principles after 5+ years:
Technical bar must be held. It's tempting to lower the bar when you're under pressure to fill a role. Resist it. A gap in the team is better than a permanent drag on team velocity.
Culture fit is real, but be specific. "Culture fit" can be a cover for bias. Instead, articulate what you actually mean: Do they collaborate well? Do they receive feedback graciously? Do they take ownership or look for someone to blame?
Referrals have signal, but aren't free passes. Some of the best engineers I've hired came through referrals. Some of the worst did too. Run the same process regardless.
Trial projects reveal what interviews don't. A paid trial project (with a clear scope and timebox) tells you things about how someone works that no interview question can.
The Things That Actually Drain You
Nobody talks about the emotional weight of engineering leadership.
The engineer who's been here for 3 years, is technically solid, but simply isn't growing into a senior role — and you have to have that conversation.
The team lead who has the technical chops but struggles with interpersonal conflict — and you have to coach them through it while also managing the fallout with the team.
The delivery pressure from executives that you have to translate into a realistic engineering plan — without burning out the team or under-committing to the business.
These aren't technical problems. They're human problems. And they're the majority of what engineering leadership at scale actually is.
What I'd Tell Someone Starting This Journey
Invest in your team leads before you need them. By the time you're overwhelmed, it's too late to develop your leads. Start early.
Write things down. At 19 engineers, organizational memory is fragile. Decisions that you think are obvious need to be documented, or they'll be relitigated in 6 months when the people who made them have moved on.
Protect your own thinking time. The calendar fills up fast. Block time for strategic thinking, architecture review, and writing. If it's not on the calendar, it doesn't happen.
The technical work is the easy part. The relationship, feedback, and communication work is where you'll either succeed or struggle. Get comfortable with it early.
19 engineers is a fascinating number. Large enough that organizational structure matters. Small enough that you still know everyone personally. It's a privilege to lead a team at this scale, and I'm still learning.
Find me on LinkedIn if you're navigating similar challenges — I'm always happy to compare notes.