Hiring the First Engineering Manager Nobody Reports To Yet

The signal is usually a missed handoff, not a bad hire

A founder running a cybersecurity engineering team of eight or nine people tends to notice the problem sideways. A customer-reported vulnerability sits in triage for two extra days because the founder was in back-to-back sales calls. A junior engineer ships a change to the detection pipeline without the context of why a similar change was rolled back six months earlier, because the person who remembered that history was out of the loop. None of these are individually alarming. Together, they describe a team that has outgrown the informal coordination a single technical leader can hold in their head.

In most early software companies, this happens gradually enough that founders adapt without noticing. In security-focused companies, it tends to happen faster, because the stakes of a missed handoff are higher. A delayed patch, an unreviewed access control change, or a compliance artifact nobody owns can turn into a customer-facing incident rather than a minor bug. The ISC2 Cybersecurity Workforce Study documents a persistent shortage of experienced security talent industry-wide, which means small security engineering orgs often carry senior-level responsibility on a team that is still structurally flat. That mismatch between what the team is trusted to do and how it's organized is usually the real trigger for the first management hire, not headcount alone.

What bottleneck actually looks like

Founders who are still doing all of the engineering management tend to describe their week as busy rather than broken, which is part of why the transition gets delayed. The more useful diagnostic is to separate two kinds of bottleneck that get lumped together.

The first is a technical decision bottleneck: architecture calls, security review sign-offs, and prioritization calls all still route through one person. This is often tolerable longer than people assume, especially if the founder is the strongest technical judgment on the team.

The second is a people bottleneck: performance conversations, career growth, conflict between engineers, and day-to-day check-ins are also routing through that same person. This one degrades faster, because people issues don't wait for a founder's calendar to open up. A security engineer who is frustrated about scope, unclear about their growth path, or in conflict with a teammate will quietly disengage long before it becomes a conversation the founder is available to have.

The useful test is whether the founder can name, without checking notes, what each engineer is currently working on, what's blocking them, and how they're doing personally. Once that list takes real effort to reconstruct, the founder has become the bottleneck for both kinds of decisions at once, and management is being done in the gaps between other work rather than as its own function. First Round Review's account of recognizing the need for a first dedicated functional leader describes the same pattern in product management: the founder isn't failing at the job, the job has quietly split into two jobs.

Define the role before you define the candidate

The mistake most founders make at this point is writing a job posting before writing a role description. A first engineering manager in a cybersecurity company needs clarity on a handful of specific questions before recruiting starts:

• Does this person own security review sign-off, or does the founder retain that authority while the manager owns people and process?
• Do they inherit on-call ownership, incident command, or postmortem facilitation, or does that stay with senior engineers directly?
• Are they expected to still write code, and if so, how much?
• Do they own hiring decisions for their team, or make recommendations the founder approves?

There's no universal right answer to any of these. What matters is that the founder decides before the search starts, rather than negotiating scope during onboarding with whoever gets hired. A role defined loosely tends to default back toward the founder anyway, because ambiguity favors whoever already holds informal authority. Research on early team sequencing, including Lenny's Newsletter's data on which functional hires companies bring on first, suggests companies that define scope narrowly and specifically for a first management hire retain that person longer than companies that hire for a vague "help me manage the team" mandate.

Promote internally or hire from outside

The choice between promoting a senior engineer already on the team and hiring an experienced manager externally is one of the more consequential calls in this process, and it deserves more scrutiny than it usually gets. An internal promotion preserves technical credibility and institutional knowledge, but it also means the newly promoted manager now has authority over people who were peers a week earlier, which changes every existing relationship on the team whether anyone acknowledges it or not. An external hire brings management experience the team may genuinely lack, but arrives with none of the trust engineers have built with each other, and in a security context, none of the domain-specific judgment that took the existing team months or years to develop.

The mechanics of that tradeoff, including how to handle the awkward first weeks either way, are worth working through in more depth, and this publication has covered the internal-versus-external decision directly in a piece on promoting a tech lead instead of hiring one from outside. The short version for a cybersecurity team specifically: if the role requires making judgment calls on security severity and customer risk from day one, domain knowledge tends to matter more than management pedigree, which tips the calculus toward internal promotion more often than in a typical SaaS team.

Handling the engineers who now report to someone else

Engineers who joined the company reporting directly to the founder will notice, immediately, that they no longer do. Some will read it as a demotion of access rather than a structural change, particularly if the founder has been generous with informal one-on-one time. The founder's job in this transition isn't to reassure people that nothing is changing, because something is changing and pretending otherwise erodes trust faster than the change itself. It's to be specific about what moves and what doesn't: performance conversations and day-to-day priority calls move to the new manager, while the founder remains reachable for security judgment calls that the manager isn't yet equipped to make alone. That last part matters particularly in compliance-heavy environments, where sign-off authority and psychological safety around raising concerns are already under pressure, a dynamic examined in a companion piece on compliance sign-offs and psychological safety.

What authority actually needs to exist on day one

A new manager without real authority becomes a message-passing layer, which engineers detect within weeks and resent almost as quickly. At minimum, the role needs authority over performance feedback, day-to-day prioritization within the team's mandate, and a seat in whatever forum makes security and architecture decisions, even if the founder retains final sign-off there for a defined transition period. What shouldn't happen is a founder publicly overriding the manager's calls in front of the team during the first quarter. Every override, however well-intentioned, teaches engineers that the real decision-maker hasn't actually changed, and the next attempt at this hire will be harder because of it.

The founders who get this right tend to treat it less like filling a vacancy and more like designing a role that didn't exist yet, then finding or growing someone into it deliberately, the same discipline that made the shift from a single engineer to a second one work the first time the team's structure had to change to match its size.