Hiring Your First Engineering Manager: A Founder's Guide

What you need to know

• Engineering managers are not senior engineers with management duties added on. They are a fundamentally different role whose output is team velocity, not individual code.
• The wrong time to hire an EM is when you are trying to fix a broken team. The right time is when a healthy team is too large for you to manage directly.
• Promoting the wrong person internally is often worse than hiring externally. A senior engineer who takes the EM role but misses writing code will underperform and usually leave.
• The best first EM hire has done this before at a similar stage. They know what a five-person engineering team looks like and what it needs to become ten.
• The founder who hires an EM expecting to stop thinking about engineering will be disappointed. The founder who hires one to scale what is already working will see results.

The core argument

The decision to hire an engineering manager is often framed as a headcount question. You have six engineers, you cannot run all the one-on-ones, therefore you need a manager. That framing is not wrong but it is incomplete. The real decision is whether your team is healthy enough for a manager to scale it, and whether you are ready to delegate the people function while keeping the product function. Founders who are not ready for that delegation hire an EM and then shadow every decision the manager makes. That is not delegation. It is paying a manager's salary for the privilege of creating confusion.

The profile of the first EM hire matters more than most founders realize. A strong individual contributor who moves into management at your company brings context but often lacks the management frameworks that come from doing it elsewhere. A manager from a larger company may know the frameworks but lack the scrappiness that a small team requires. In my experience, the ideal first EM has managed a team of five to ten engineers at a startup before. They know what messy looks like and they know how to build process without burying the team in it.

The first ninety days are the make-or-break period. A new EM who spends the first month reading documentation and attending every meeting will arrive at month three with no trust and no authority. The ones who succeed build a relationship with each engineer in the first two weeks, establish a consistent one-on-one cadence by week three, and ship one visible process improvement by day sixty. The founder's job in that period is to give the EM enough context to act and enough space to build credibility without the founder's shadow in every conversation.

Common mistakes

1. Hiring an EM to fix a team problem. A disorganized team, high attrition, or missing senior engineering culture are symptoms. An EM cannot cure symptoms when the underlying structure is broken. Fix the structure first.

1. Promoting the strongest technical engineer without asking if they want the role. Technical leadership and people management are different skills. Many excellent engineers actively dislike management. The conversation about what they want matters more than what you need.

1. Letting the EM own the roadmap immediately. Technical roadmap ownership requires trust and context that takes months to build. Give the EM the people function first. The technical function expands as they earn it.

1. Expecting the EM to hire on your behalf without training. The first EM needs to understand your hiring bar, your culture, and what a good candidate looks like for your specific team. That calibration is your job to provide.

1. Not setting success metrics for the first ninety days. What does a successful first quarter look like? If you cannot answer that before the hire starts, you will not know if they are succeeding until it is too late to course-correct.

Where to start

1. Write the EM job description around outcomes, not credentials. What do you need the team to look like in twelve months? Work backward from that to what the manager needs to do and be in their first year.

1. Talk to your engineers before you hire. They will work with this person daily. Understanding what they need from a manager tells you what to look for and signals that you take the culture seriously.

1. Run a structured reference check. Call the candidate's former direct reports, not just their former managers. Ask whether the team shipped consistently and whether people stayed. Those two data points predict more than any interview.

Related reading

• Hiring Mistakes That Founders Repeat Endlessly
• Senior vs Mid vs Junior Developer: When to Hire Which
• The Vetting Framework: How to Verify a Developer's Real Experience
• The First Five Hires for a Bootstrapped SaaS