"When should you put an engineer on a PIP or let them go"

"Use a PIP when the engineer has the skills but something changed — new responsibilities, burnout, unclear expectations, or a fixable skill gap. Skip the PIP and move to separation when there's a fundamental values or integrity mismatch, when the engineer has already had multiple clear conversations about the same issues with no improvement, or when their behavior is actively damaging the team. A good PIP has 3-5 specific, measurable goals with a 30-60 day timeline. If you can't articulate what 'success' looks like in concrete terms, you're not ready to PIP someone."

When to Put an Engineer on a PIP vs. When to Let Them Go

Nobody becomes an engineering leader because they love firing people. But every engineering leader eventually faces this decision, and how you handle it defines your team’s culture more than any values statement on the wall.

I’ve managed this process dozens of times — for my own teams and alongside clients who’ve never had to let someone go before. Here’s the framework I use.

When a PIP Makes Sense

A Performance Improvement Plan is appropriate when you believe the engineer can succeed and something specific is preventing it. That distinction matters. A PIP is not a formality you go through before firing someone. If you’ve already decided to let them go, putting them through a 60-day PIP is cruel — to them and to the team watching.

They have the skills but something changed. An engineer who was performing well six months ago and is now struggling has probably hit a specific obstacle: burnout, personal issues, a role change that doesn’t fit, or new responsibilities they weren’t prepared for. A PIP with the right support can address this.

The expectations were unclear. If you’ve never explicitly told someone that their code quality isn’t meeting the bar, you owe them the chance to improve with clear expectations. This is more common than leaders admit. “Everyone knows the standard” is not the same as “I’ve told this person specifically what they need to do differently.”

There’s a fixable skill gap. A mid-level engineer promoted to senior who’s struggling with system design isn’t a bad engineer — they’re an engineer who needs development. A PIP with specific mentoring, paired with architectural work, and clear milestones can close this gap.

What a Good PIP Looks Like

A PIP that works has three components:

Specific, measurable goals. Not “improve code quality.” Instead: “All PRs must pass code review without more than one round of significant revisions. Unit test coverage for new code must be above 80%. No critical bugs attributable to your code in the next 30 days.” If you can’t write specific goals, you’re not ready to PIP someone.

A realistic timeline. 30 days for behavioral changes (showing up to meetings prepared, responding to code reviews within 4 hours, communicating blockers proactively). 60 days for skill-based improvements (system design quality, debugging approach, technical communication). Anything longer than 60 days and you’re just delaying the inevitable.

Genuine support. Assign a mentor or pair programming partner. Remove distractions so they can focus on the improvement areas. Check in weekly — not to monitor, but to help. If you’re putting someone on a PIP and then leaving them alone to sink or swim, you’re going through the motions.

When to Skip the PIP

Integrity issues. An engineer who lied about their work being done, falsified test results, or covered up a production incident they caused doesn’t need a PIP. That’s a trust violation, and trust isn’t something you can put in a 30-day improvement plan.

You’ve already had the conversation multiple times. If you’ve explicitly told someone three times that their behavior needs to change and documented those conversations, a formal PIP is just HR paperwork. You’ve already given them the feedback. They’ve already demonstrated they can’t or won’t change.

They’re poisoning the team. An engineer who’s technically competent but actively undermines team culture — constant negativity, refusing to collaborate, making other engineers dread working with them — is doing more damage every day they stay. The rest of the team is watching to see if you’ll act. Every week you don’t is a signal that you tolerate the behavior.

The role has fundamentally changed. Sometimes the company outgrows an engineer’s capabilities, and the gap isn’t closable in 60 days. A founding engineer who built the MVP but can’t operate in a team with code review, testing requirements, and production SLAs isn’t a bad engineer — they’re a bad fit for what the company now needs. A PIP won’t change that.

The Conversation

However you get there — PIP completion without improvement or direct termination — the conversation needs to be direct, respectful, and brief.

State the decision. Reference the specific issues and previous conversations. Don’t negotiate, don’t relitigate, and don’t apologize for the decision (you can express genuine empathy without apologizing for doing the right thing). Have HR involved. Have the logistics handled — last day, severance, equipment return, access revocation.

The biggest mistake I see: managers who try to make the person feel better by softening the message until it’s incomprehensible. “We’re going in a different direction” is not clear. “Your performance hasn’t improved to the level we need despite the support we’ve provided, and we’re ending your employment” is clear. Clarity is kindness, even when it doesn’t feel like it.

What the Team Sees

Your team knows who isn’t performing. They’ve been picking up the slack, reviewing the subpar PRs, and working around the gaps. When you finally act, the most common reaction isn’t “that’s harsh” — it’s “what took so long?”

The way you handle underperformance tells your high performers everything they need to know about whether excellence matters at your company. Tolerate low performance long enough and your best people leave — not the underperformer.