Your First Engineering Manager 
When to Hire One and What They Should Own 

Somewhere between eight and twelve engineers, the founding CTO notices they have become the bottleneck for everything: every one-to-one, every hiring decision, every architecture question, every priority call, and every incident. Their own technical output has dropped to nothing, one-to-ones are the first meetings to be cancelled, and two engineers have privately mentioned that they do not know how they are doing. The obvious response is to hire an engineering manager. The decisions inside that — when exactly, promote or hire, what the manager owns, and what the CTO keeps — determine whether it relieves the pressure or adds a layer that makes everything slower.

The signals that it is time

• The CTO has more than about eight direct reports, and one-to-ones are routinely the first thing cut.
• Hiring has stalled because nobody has the time to run a structured interview loop properly.
• New engineers ramp slowly because onboarding is nobody's job.
• Delivery commitments are missed without anyone having seen it coming.
• A performance problem has been visible to the team for months and has not been addressed.
• Strong engineers are leaving for reasons of feedback and growth, the pattern described in why senior engineers leave.

Decide what the CTO keeps before writing the job description

The role is defined by the split, so make the split first. The most common version has the CTO keep technical direction, architecture, the external technical face of the company — customers, the board, due diligence — and the bar for senior technical hires, while the engineering manager owns people (one-to-ones, feedback, performance, career development), delivery process and predictability, execution of the hiring process, and team health. The alternative split, where the founder becomes the people leader and hires a strong principal engineer or architect instead, is the right answer for some CTOs. Choose based on an honest view of what the CTO is good at and wants to spend the next three years doing. The failure mode is hiring a manager without deciding at all, so the CTO keeps doing both jobs and the new manager has responsibility without authority.

Promote from within or hire externally

An internal promotion keeps context and trust and shows the team there is a path upward. Its risks are real: the strongest engineer is often not the strongest manager, the company loses their technical output, former peers become reports, and there is no management experience to draw on when things get hard. If you promote, frame it as a trial with an explicit, stigma-free route back to a senior individual-contributor role — that option is what makes the experiment safe for everyone. An external hire brings practice from a company one or two stages ahead, at the risk of a culture mismatch, big-company process imported wholesale, and three to six months before they are trusted. For a first manager, someone who has grown a team through the stage you are about to enter beats someone who ran a large, stable team at a mature company. Either way, the first manager should be technical enough to judge work and hold their own in a design review, but should not be the primary developer on critical-path features; a manager who is also the main feature developer does neither job well.

What the first six months should produce

• Reliable one-to-ones with every report within the first month, and a written picture of each person's goals and concerns.
• A lightweight, visible delivery cadence — planning, and a single place where commitments and status live — rather than a heavyweight process import.
• Clear expectations for each level, even if the first career framework is a single page, so performance conversations have something to stand on.
• A running hiring pipeline with a structured loop and consistent evaluation.
• At least one long-standing team problem resolved: the unaddressed performance issue, or the on-call rotation everyone quietly dreads.
• A baseline of delivery measures such as the DORA metrics, used to find bottlenecks rather than to grade individuals.

The mistakes that make the first manager fail

The most common is the CTO going around the manager to give direction straight to their reports, which tells the team where authority really sits within a week. Close behind is importing process from a five-hundred-person company — cascading objectives, estimation rituals, and approval layers designed for a scale the team has not reached. Another is hiring a manager to fix what is really a strategy or prioritisation problem owned by the founders; no manager can make a team deliver against priorities that change every fortnight. The new manager also needs managing: regular one-to-ones with the CTO, honest feedback, and support in hard conversations. And the span needs to be sane from the start — a manager handed fourteen reports on day one is the CTO's problem relocated rather than solved, where five to eight is a workable range.

How Infiniti Tech Partners fits in

We are not a recruiter, and we do not place engineering managers. Where we fit is the gap. The pressure that makes a CTO hire a manager quickly is usually the same pressure that makes them hire the wrong one, and a fractional engineering team with its own senior tech lead can take delivery ownership for part of the roadmap — running planning, estimates, and reporting — while the CTO hires properly rather than urgently. We also help design the interview loop for management candidates and plan a clean handover once the right person is in the seat. We keep a deliberately small number of concurrent engagements and plan the calendar about a quarter out. If you are the CTO who has become the bottleneck for everything, that is worth a conversation before it becomes a delivery problem.