The CTO's Guide to Firing an Engineer (Without Wrecking the Team)

This is the conversation I dread most when I step into a fractional CTO role: the founder who asks, quietly, "How do I fire someone on my team?"

It's never casual. It's usually someone they hired. Someone they believed in. Someone who was excellent once but isn't anymore, or who never was and the hiring decision is being revisited.

I've fired exactly three people in my career. Each one was necessary. Each one taught me something. And I still don't love it.

But here's what I know: not firing the right person at the right time is more damaging to a team than the firing itself.

When you keep an underperformer, you signal to high performers that excellence doesn't matter. You burn out the people carrying extra weight. You teach junior engineers that standards are negotiable. You make your best people's job harder, and you make them question your judgment.

So you have to do it. You just have to do it right.

The Stakes: What Happens When You Wait Too Long

Let me paint a picture I've seen three times:

You hire a backend engineer. Smart. Good credentials. First three months are rough, but you assume the ramp. Month four, they're still producing code that requires senior review for everything. Month six, you're hoping they'll find their footing. Month nine, your most senior engineer asks to talk to you, and she says, "I can't spend another hour reviewing their PRs. I'm not learning anything. I'm just cleaning up."

Now you have two problems: the engineer who isn't working out, and the retention risk of the senior engineer who's about to quit because the standards aren't being upheld.

Waiting is a tax on your best people.

The cost of this is:

Culture degradation: Other engineers see consequences don't happen. Why rush code review if Carlos has been here eight months and still ships rough code?
Talent flight: Strong engineers go to companies with high bars. If they watch you tolerate low performance, they leave.
Compounding impact: The longer they stay, the more institutional knowledge they have to hand off. The harder it is to extract them. The more systems they've touched and potentially left fragile.
Founder avoidance: You spend so much emotional energy managing around the problem that you can't focus on strategy.

The math is simple: fix it now, or pay for it later.

The Framework: How to Actually Do This

I break this into four stages: detection, documentation, conversation, execution.

Stage 1: Detection (Before You Decide)

This is where most founders fail. They make a firing decision based on gut feeling or frustration, not data.

Before you fire anyone, you need to be honest: Is this about performance or personality?

Some questions:

Can I point to specific work outcomes that aren't meeting expectations?
Have I clearly communicated what good looks like and what they need to change?
Is this a mismatch between the role and the person, or is the person not performing at the level the role requires?
Would I make this decision if this person had a different personality (introvert vs. extrovert, less chatty, different style)?

If you can't answer the first two with specific examples, you're not ready.

Once you are:

Document recent work: PRs that aren't meeting standards, projects that shipped late, code that required major refactoring, decisions that didn't align with company direction.
Identify the gap: "We need someone who ships production-grade code on their own. This person still requires senior review on every feature."
Assess teachability: Have you actually given them the feedback? Do they understand what needs to change? Are they improving?

Stage 2: Documentation (Create a Clear Record)

Here's the unglamorous part: you need a paper trail.

I'm not suggesting you be petty or document every misstep. I'm suggesting you're clear in writing about what the job requires and what you're seeing:

Send an email: "Following up on our conversation, here's what I'm looking for. [Specific, measurable expectations]. Let's check in on progress in two weeks."
Document the feedback conversation: Send a note afterwards. "We discussed: the code review feedback I'm giving is about bringing the quality of X up to our standard. Here's what improvement looks like by [date]."
Keep notes on work quality: If you're assigning them work, track it. "Shipped feature late without alerting team. Required major refactoring from senior engineer."

This isn't punishment documentation. It's clarity documentation. It says: "Here's what's expected. Here's what I'm seeing. Here's how we measure improvement."

If they improve, great. If they don't, you have a record that says you tried.

Stage 3: The PIP (Performance Improvement Plan) or Final Conversation

Some companies use formal PIPs. Honestly? At a small company, they can feel performative.

But you do need a final, explicit conversation:

"We've talked about the code quality bar. I've given you feedback on the last three features you've shipped, and the pattern is the same. Senior engineers are still doing major refactoring. That's not what this role requires. So here's what I need: by [specific date, usually 4-6 weeks], I need to see you shipping features that meet our standard without major rework. I'm going to support you with [pair programming, training, whatever]. If we're not there by the date, I'll need to make a change. This is serious."

That conversation should be:

One-on-one, early in the day: Not ambushed. Not in front of others.
Clear about consequences: "If this doesn't improve, we'll be letting you go."
Specific about expectations: What does "improvement" actually look like?
Supportive: "I want to help you succeed. Here's what I can offer."
Documented: Send a follow-up note. "Here's what we discussed..."

If they improve, you've kept a good engineer and you've helped them grow. If they don't, they've had clear notice.

Stage 4: Execution

Let's assume the improvement didn't happen (or improvement wasn't possible). You've decided to let them go.

Timing:

Early in the week (Monday-Wednesday). Not Friday. You don't want to leave them job-hunting on a weekend.
Early in the day. They'll need time to process, make calls, plan.

The conversation:

Keep it brief. "This isn't working out. We're letting you go effective immediately. [HR person] has details on severance and final paycheck timing."
Don't debate. Don't explain all the reasons. You've had that conversation. This is not a trial.
Have an HR person or co-founder present (if you have them). Not for you—for them, so there's a witness.
Hand them severance terms and final paycheck timing in writing.

What comes next:

Secure their access immediately. Laptop, keys, code credentials.
They'll be escorted out (or you'll be fine with them collecting their things; depends on the situation and relationship).
You'll handle communicating to the team.

The team communication: This is the part that actually matters. Do this in person, same day:

"We've made a staffing change. [Person] is no longer with the company. I know some of you worked closely with them. I'm happy to answer questions, but I'm going to be respectful of their privacy. Here's what changes for you: [assign their work, clarify responsibilities]. We'll get through this. Let's talk in small groups if you want more detail."

Don't trash-talk. Don't over-explain. Don't make it a referendum on whether the decision was right. You made it. You're moving forward.

Concrete Example: The Data Engineer Who Couldn't Ship

I was advising a Series A company that hired a really experienced data engineer. Great resume. Interview loop strong. First two months seemed fine, but then the pattern emerged: nothing shipped.

Design docs went nowhere. The code was over-engineered. When the CTO started pair programming to unblock, she realized: the person kept rewriting the same thing, never felt ready to merge, had perfectionism that became paralysis.

The CTO gave clear feedback: "I need you to ship something to production. Start small. Here's what done looks like."

Month later: nothing. Different excuses each time.

PIP conversation: "Here's the bar. Ship a small feature by April. Show me you can be on the team."

Next week: they put in their resignation. Realized on their own it wasn't working.

Best case. But if they hadn't?

Plan would have been: clear record, dismissal, focus on distributing the work to people who could execute.

The lesson: sometimes people know before you fire them. Sometimes clarity helps them leave on their own, which is cleaner for everyone.

The Counterpoint: When You Fire the Wrong Person

I've seen this too. A founder fires someone because they clashed with them personally, not because of performance. Or because they hired wrong and rather than help someone grow into a new role, they're impatient.

The costs are real:

Legal exposure (wrongful termination)
Team morale hit (if people see you firing for personality mismatch)
Opportunity cost (losing someone who could have been great with support)

This is why the detection phase matters. Before you fire, ask yourself hard questions:

Am I firing because of performance or because I don't like them?
Have I actually given them real feedback and support?
Are they in the right role, or did I hire wrong?

If the answer is "I hired wrong but they could work here," consider a role change before firing. If the answer is "I clashed with them but they're solid," that's a reason to improve your relationship, not their severance.

Where I Come In

The decision to let someone go rarely gets easier. But I help CTOs and founders make sure it's the right decision, done cleanly, and that the team comes out intact. If you're questioning whether someone needs to go, or if you need help managing the conversation and the aftermath, let's talk. I'll help you think through the decision clearly and handle the execution well.

Action Checklist

Before deciding: Can you point to specific performance gaps? Have you given feedback?
Document: Collect recent examples of unmet expectations (PRs, projects, outcomes).
Draft a clear email: Here's what we need. Here's the timeline for improvement. Here's the support you'll get.
Schedule a conversation: Make it early in the day, one-on-one.
If dismissing: Have severance terms in writing. Secure their access. Time it early in the week.
Same-day team communication: Brief, respectful, forward-looking. No drama.
Follow-up with impacted direct reports: 1:1 conversations to process and clarify their role.