When to Fire Your First Engineering Hire

According to research on startup scaling, engineers in growth-stage startups spend 42% of their time on legacy code and workarounds. The engineer who built your MVP is often the same one blocking your next phase of growth. It's a pattern I've seen repeatedly: the brilliant first hire who was perfect for a two-person team becomes an obstacle at twenty.

This isn't about performance. It's about context. The skills that make someone invaluable at the earliest stage are often the opposite of what a scaling company needs. Scrappiness, generalist thinking, building with duct tape and determination. The person who wrote all your legacy code frequently becomes its fiercest defender. Even when that code is holding you back.

The Perfect Early Hire Problem

Your first engineer was probably exactly right for the moment you hired them. They shipped fast. They wore multiple hats. They made architectural decisions with incomplete information and kept the company alive. That's what early-stage engineering demands.

The problem is that early-stage engineering decisions compound. Every "good enough" choice becomes foundational. Every shortcut becomes load-bearing. According to research on startup scaling, engineers spend 33% of their week fixing bad code and workarounds. In growth-stage startups, that jumps to 42%. Your first engineer often built the code that's now consuming nearly half your engineering capacity.

That's not their fault. It was the right approach at the time. But it creates an uncomfortable situation. The person who understands the legacy system best may also be the least motivated to replace it.

Signs Your First Engineer Isn't Scaling

The transition from startup hero to scaling blocker happens gradually. Here's what I've observed:

Defensiveness about early decisions. When new engineers question architectural choices, your first hire responds with "you don't understand why we did it that way" rather than "you're right, that was a tradeoff we made for speed."

Resistance to new hires. Finding flaws in every candidate. "They wouldn't survive here." "They're too corporate." The standards somehow become difficult to meet. Conveniently, no one else can understand the codebase.

Knowledge hoarding. Critical systems exist only in their head. Documentation is "on the roadmap." Questions get answered with demonstrations. Explanations that could be repeated without them never materialize.

Fighting cultural evolution. As Elad Gil describes in the High Growth Handbook, some early employees fight the changes. They resist hiring a sales team, professionalizing staff, or sunsetting irrelevant products. They cling to the chaos that made them valuable.

Lost hunger. Early equity grants sometimes mean your first engineer got rich on paper. The drive that characterized their early contributions has faded. They're still collecting a salary but not delivering the intensity the role requires.

Why This Is So Hard to Address

Firing your first engineer is harder than firing almost anyone else, for reasons that are entirely human.

They have history with you. They believed when belief was unreasonable. They worked nights and weekends when the company was a spreadsheet and a dream. That creates loyalty difficult to override with performance concerns.

They know where the bodies are buried. Literally and figuratively. Every production incident that got papered over. Every customer promise that was technically impossible but somehow delivered. Every corner cut. Losing them means losing institutional memory. Some things can't be documented.

The team is watching. How you treat your first hire signals how you'll treat everyone. Handle it badly and you damage trust across the organization. This connects to why founder ego kills startups. Making this decision requires setting aside emotional attachment. Do what's right for the company.

And there's guilt. You asked them to sacrifice, and they did. Now you're telling them it wasn't enough. That feels like betrayal even when it's the right business decision.

The Technical Debt Trap

The most dangerous dynamic is when your first engineer becomes the guardian of the technical debt they created. They know every hack and shortcut. Every "temporary" solution that's been running in production for three years. That knowledge is power.

A startup that scaled from MVP to growth stage will inevitably carry technical debt - which is really rot, not debt. The question is whether that rot is being actively managed or actively protected.

Your first engineer's relationship with the legacy code matters. Are they leading efforts to pay it down? Or are they explaining why it can't be changed? Do they welcome new perspectives? Or gatekeep with "you don't understand the history"?

When the person who built the system becomes the reason it can't evolve, you've got a problem. It won't solve itself. This is similar to how architecture decisions kill startups. Except the architecture is human.

The Transition Conversation

If you've identified the problem, you have options short of termination. But they require honesty that many founders avoid.

The role change: "The company needs a different kind of engineering leadership now. Here's what we're looking for. Do you want to grow into that, or would you prefer to focus on individual contribution?"

Some first engineers thrive when relieved of leadership expectations. They never wanted to manage people or set architecture direction. They wanted to code. Letting them do that can preserve institutional knowledge. Make appropriate title and compensation adjustments. Open space for new leadership.

The timeline: "We're hiring a VP of Engineering. Here's how I see your role evolving over the next six months. Let's check in monthly to see if this is working for you."

This gives them an opportunity to adapt. Some will. According to First Round Review's research on scaling engineering teams, early employees who can grow with the company are "invaluable." They channel the mindset of founders. They have the trust of the executive team. They deeply understand company operations and culture.

The exit: "I don't think this is working anymore. Let's figure out a transition that honors your contributions."

Sometimes there's no role that makes sense. The honest conversation is kinder than gradual marginalization.

When to Pull the Trigger

There's no universal timeline, but there are inflection points where the decision becomes unavoidable:

Around 50 employees. Research on organizational thresholds suggests this is when startups fundamentally shift. Founders can no longer be involved in every decision. If your first engineer still operates like it's a five-person company, the gap becomes visible.

When other engineers leave citing them. Exit interviews are data. If multiple departing engineers mention the same person as a reason, you're paying twice. Losing good people and keeping the problem.

When velocity has clearly stalled. Engineering output correlates with many factors. But if delivery speed has declined even as headcount increased, that's a signal worth investigating.

When you're managing around them. If you find yourself routing decisions, projects, or people to avoid your first engineer, you've already made the decision. You're just not executing it.

The Emotional Reality

I want to be direct: this will feel terrible. You're ending a relationship with someone who helped build something meaningful. The guilt is real. The sense of disloyalty is real.

But consider the alternative. A first engineer who blocks scaling doesn't just slow the company. They make it a worse place for everyone else. Other engineers leave. New hires fail to integrate. Technical progress stalls. The company's ceiling gets defined by one person's limitations.

Keeping someone because of what they did, rather than what they can do, isn't loyalty. It's choosing one person over the entire organization.

The founders I most respect handle these transitions with generosity. Extended timelines. Generous severance. Public acknowledgment of contributions. They still make the hard decision. Kindness and clarity aren't mutually exclusive.

What Comes After

When handled well, the departure often benefits both parties. First engineers who leave frequently find new opportunities. Their skills - broad experience, scrappiness, ability to ship with nothing - are exactly what early-stage companies need. They were a bad fit for the company you've become, not a bad engineer.

The organization, meanwhile, often accelerates dramatically. Not because the person was bad. Because their departure created space for changes that had been waiting. New architecture. New processes. New people who weren't navigating around someone else's territory.

And sometimes the relationship recovers. More often than you'd expect. Years later, the first engineer understands why the decision was right. They've seen it from the other side. What felt like betrayal becomes, with distance, just a hard thing that had to happen.

Blocker vs. Builder Audit

Assess whether your first engineer is scaling with the company. Check all that apply:

First Engineer Decision Matrix

"Keeping someone because of what they did, rather than what they can do, isn't loyalty. It's choosing one person over the entire organization."