Fire Fast or Coach Long? A Decision Framework for Engineering Performance

The Engineer You've Been "Waiting on" for 9 Months

You have an engineer on your team. Let's call them Alex.

Alex has been "almost there" for 9 months:

• PRs take 2x longer than expected
• Code reviews require heavy back-and-forth
• Estimates are consistently off by 3x
• Work quality is... acceptable, but not great

You keep telling yourself:

• "They're still ramping up" (it's been 9 months)
• "Maybe the next project will click" (it hasn't)
• "I need to give them more time" (how much more?)

Meanwhile:

• The team is quietly frustrated. Other engineers are picking up slack, redoing work, or avoiding pairing with Alex.
• Your velocity is dragging. That 3-quarter roadmap? Now a 5-quarter roadmap.
• Your credibility is eroding. The team sees you tolerating mediocrity. They wonder: "Does performance actually matter here?"

The hard truth: Every month you wait to make a decision is a month the rest of your team suffers.

This isn't about being heartless. It's about being honest. Let me show you a framework to make these decisions with clarity, speed, and respect.

Separate Performance Problems from Environment Problems

Before you label someone a "performance issue," ask: Is this a people problem or a systems problem?

Common Environment Problems That Look Like Performance Issues

1. Unclear expectations

Looks like: Engineer ships work that misses the mark, makes poor technical decisions, or doesn't prioritize correctly.

Actually is: No one told them what "good" looks like, what the priorities are, or what success criteria exist.

Fix: Write clear expectations, define done, establish decision-making frameworks.

2. Broken onboarding or context

Looks like: New engineer (3–6 months in) is slow, asks basic questions, struggles with architecture.

Actually is: Onboarding was "read the wiki and ask questions." No one explained the system, the patterns, or the trade-offs.

Fix: Structured onboarding, pair programming, explicit knowledge transfer.

3. Role mismatch

Looks like: Senior engineer struggling with ambiguity, missing deadlines, needing hand-holding.

Actually is: You hired a "senior" engineer who's actually mid-level with an inflated title from their last company.

Fix: Adjust role, scope, or level. Don't force-fit someone into a box they don't fit.

4. Impossible workload or scope

Looks like: Engineer is overwhelmed, missing deadlines, stressed.

Actually is: You assigned them 3 projects, expect them to be on-call, and attend 15 hours of meetings per week.

Fix: Reduce scope, delegate differently, protect their time.

The Rule: Fix the System First

Before you blame the person, check:

• Have I given them clear, written expectations?
• Do they have the tools, access, and support they need?
• Is their workload reasonable?
• Have I given specific, actionable feedback?
• Is there a mismatch between their role and their actual skills?

If you haven't fixed these, you haven't given them a fair shot.

Once the environment is clean, then you can evaluate: Is this a performance issue?

A Simple 2×2 Framework: Willing vs Able

Not all performance issues are the same. Use this framework to decide your approach.

The Four Quadrants

         HIGH WILLING
              │
    ──────────┼──────────
    Coachable │  Stars
              │
    ──────────┼──────────
    Problem   │  Misfit
              │
         LOW WILLING

    LOW ← ABLE → HIGH

Quadrant 1: High Willing, High Able – Stars

Characteristics:

• Consistently delivers high-quality work
• Proactively seeks feedback and improvement
• Helps others, strong cultural contributor
• Adapts quickly to new challenges

Your action: Invest, promote, retain. These are your multipliers.

Quadrant 2: High Willing, Low Able – Coachable

Characteristics:

• Tries hard, asks for help, implements feedback
• Misses the mark but learns from mistakes
• Strong culture fit, team players
• Skill gaps in specific areas (e.g., system design, testing, communication)

Examples:

• Junior engineer who's eager but inexperienced
• Senior engineer promoted to staff who's struggling with new scope
• Strong IC struggling with first tech lead responsibilities

Your action: Coach, mentor, provide structure. Invest 3–6 months. Most will improve.

Coaching investment: High. Worth it.

Quadrant 3: Low Willing, High Able – Culture/Behavior Problem

Characteristics:

• Technically strong but poor team fit
• Resists feedback, blames others, defensive
• "Brilliant jerk" patterns: smart but toxic
• Does minimum viable work, no initiative

Examples:

• Senior engineer who refuses to document, review others' code, or mentor
• Staff engineer who undermines decisions in public
• IC who's technically solid but demoralizes the team

Your action: Clear, direct feedback. If no change in 4–8 weeks, exit. Don't let talent excuse bad behavior.

Coaching investment: Low. Rarely improves without major self-awareness shift.

Quadrant 4: Low Willing, Low Able – Exit Fast

Characteristics:

• Underperforms and doesn't care
• Misses commitments, makes excuses, no improvement
• Drains team energy
• Resistant to feedback and support

Your action: Exit quickly. These situations rarely improve and damage team morale.

Coaching investment: None. You're not helping anyone by delaying.

Designing a Performance Improvement Plan That Isn't Theater

If you decide to coach (Quadrant 2 or early Quadrant 3), set up a real plan, not a paper trail for HR.

The Structure

1. Identify 1–3 specific behaviors or outcomes to improve

Bad (vague):

• "Improve code quality"
• "Be more proactive"
• "Communicate better"

Good (specific):

• "PRs are reviewed and merged within 3 days of opening, with no more than 2 rounds of major revisions"
• "Proactively update the team in standup when you're blocked or behind schedule"
• "Write design docs for changes affecting > 2 services, reviewed before coding starts"

2. Define success criteria

How will you know if they've improved?

Example:

• "In the next 4 weeks, complete 3 features with high-quality PRs (< 2 revision rounds)"
• "Deliver project X on time with clear communication at milestones"
• "Pass technical design review for service Y with minimal revisions"

3. Set a timeline

4–8 weeks for most situations.

• Shorter (4 weeks) for critical role clarity issues or behavior problems
• Longer (8 weeks) for skill-building (e.g., learning new tech, system design practice)

4. Establish weekly check-ins

30 minutes, every week:

• Review progress against specific goals
• Provide feedback (what's working, what's not)
• Adjust support if needed

No surprises. By week 4, both of you should know if this is working.

5. Provide real support

Not just "try harder." Give:

• Mentoring: Pair them with a strong engineer 2–4 hours/week
• Training: Send them to a course, share resources, book study groups
• Scope adjustment: Reduce project complexity temporarily so they can focus on quality
• Explicit feedback: Code review comments that teach, not just criticize

What a Real PIP Looks Like

Week 1 conversation:

"I want to be direct: your current performance isn't meeting expectations. Specifically, PRs are taking 2–3 weeks to merge due to quality issues, and you're not proactively communicating when you're blocked.

Here's the plan: Over the next 6 weeks, I want to see you deliver 3 features with high-quality PRs (< 2 revision rounds) and proactive standup updates. I'm pairing you with Sarah for mentoring, and we'll meet weekly to review progress.

This is fixable. I'm here to support you. But I need to see clear improvement."

Week 3 check-in:

"Good progress. Your last 2 PRs were much cleaner, and your communication has improved. Keep this up. Let's focus this week on design thinking—before coding, sketch out your approach and get feedback."

Week 6 decision:

If improved: "You've hit the goals. Great work. Let's keep this momentum. Next focus: [new challenge]."

If not improved: "We set clear expectations 6 weeks ago, and I haven't seen the progress we need. I don't think this role is the right fit. Let's discuss next steps."

When to Lean into Coaching (and for How Long)

Good candidates for coaching investment:

1. High Effort, Wrong Direction

Situation: They're trying hard, but missing the mark due to lack of experience or clarity.

Example: Junior engineer writing overly complex solutions because no one taught them "boring is better."

Coaching approach: Pair programming, code review teaching moments, share patterns and anti-patterns.

Timeline: 3–6 months. Should see steady improvement.

2. New Level Adjustment

Situation: Strong IC promoted to senior or staff, struggling with increased scope or ambiguity.

Example: Senior engineer promoted to staff who's great at execution but struggles with strategy and influence.

Coaching approach: Explicit expectations for new level, mentorship from another staff+, scoped projects to build new muscles.

Timeline: 6–9 months. Level transitions take time.

3. Skill Gap in Specific Area

Situation: Strong overall performer with a clear weakness.

Example: Backend engineer who's solid on APIs but weak on system design and architecture.

Coaching approach: Targeted learning (books, courses, design review participation), practice with real projects.

Timeline: 3–6 months with measurable milestones.

How Long Is Fair?

Rule of thumb:

• Skill issues: 3–6 months of active coaching
• Behavior issues: 4–8 weeks of clear feedback

Red flag that coaching isn't working:

• No improvement after 2 months of clear support
• Improvement only when you're micromanaging
• Temporary improvement followed by regression

If you're asking "How much longer should I give them?" you've probably already waited too long.

When to Make the Hard Call to Exit

Sometimes, the right answer is to let someone go. Here are the clear signals.

Signal 1: Repeated Missed Commitments After Clarity

Pattern:

• Clear expectations set
• Adequate support provided
• Still consistently missing targets

Example: Engineer commits to delivering feature by Friday. Friday comes, it's 40% done. This happens 4 sprints in a row.

Action: If this continues after a clear PIP, it's time to exit.

Signal 2: Behavior That Damages Team Trust or Safety

Examples:

• Publicly undermining decisions or leaders
• Dismissive or disrespectful to teammates
• Creating a hostile environment (even if technically strong)
• Refusing to collaborate, review code, or help others

Action: Give one clear, direct conversation. If behavior doesn't change in 2–4 weeks, exit.

Why fast? These behaviors spread. The longer you tolerate them, the more you signal "this is acceptable here."

Signal 3: Success Only with Heavy Micromanagement

Pattern:

• They deliver when you're closely managing every step
• The moment you step back, quality drops or deadlines slip
• You're spending 30%+ of your time managing one person

Reality check: Your job isn't to be their personal project manager. If they can't operate independently at their level, they're in the wrong role.

Action: After 2–3 months of coaching, if they still need constant oversight, exit or significantly adjust role/level.

Signal 4: The Team Is Quietly Suffering

Symptoms:

• Other engineers avoid working with them
• People redo their work rather than review it
• Team velocity is tanking
• Your top performers are frustrated

The hard truth: By protecting one person, you're punishing the rest of the team.

Action: Move quickly. The team is watching. Your credibility depends on accountability.

The Cost of Waiting Too Long

What happens when you delay:

• Top performers leave. They don't want to carry dead weight.
• Standards drop. The team sees that mediocrity is tolerated.
• Your credibility erodes. "Why would I trust their judgment on anything if they won't deal with this?"

The kindest thing you can do—for everyone, including the underperformer—is make a clear decision quickly.

Communicating Decisions with Respect

How you handle these conversations matters.

Script 1: Performance Feedback (Early Warning)

Situation: First sign of performance concern. Not yet a PIP, but needs to be addressed.

Your message:

"I want to talk about something I've noticed. Over the last month, [specific examples of the issue]. This isn't meeting expectations for [your level/role].

Here's what I need to see: [1–2 specific improvements].

Let's meet weekly to check in on progress. I'm here to support you—what do you need from me to succeed?"

Tone: Direct, clear, supportive. No sugarcoating, but not punitive.

Script 2: Setting Up a PIP

Situation: Performance hasn't improved. You're putting a formal structure in place.

Your message:

"We've talked about [issue] a few times, and I haven't seen the improvement I need. I want to be very clear: this is serious. We're going to set up a structured plan.

Over the next [6 weeks], here's what success looks like: [specific goals]. I'll provide [support/mentorship], and we'll meet weekly.

I believe you can turn this around, but I need to see clear progress. If we don't see improvement by the end of this period, we'll need to revisit your role here."

Tone: Serious, clear, fair. No room for ambiguity.

Script 3: The Exit Conversation

Situation: PIP didn't work, or behavior issue isn't improving. Time to part ways.

Your message:

"We've had several conversations about [performance/behavior], and despite the support and time we've given, I'm not seeing the progress we need.

I've decided this role isn't the right fit. [HR details about offboarding, timeline, etc.]

I respect the effort you put in, but this isn't working out. I want to make this transition as smooth as possible."

Tone: Calm, firm, respectful. Don't over-explain or apologize for the decision.

Script 4: Talking to the Team Post-Exit

Situation: Someone has left the team. The team knows there were performance issues.

Your message:

"[Name] is no longer with the team. I'm not going to get into details out of respect for them, but I want to acknowledge that I know this wasn't a surprise.

I take accountability seriously, and I don't make these decisions lightly. If you have concerns about expectations or your own performance, let's talk—I'd rather address things early.

Let's focus on moving forward. [Plans for redistributing work, hiring, etc.]"

Tone: Professional, brief, no gossip. Acknowledge reality without airing details.

Performance Systems, Not Personal Heroics

Here's the reframe: Performance problems are usually systems problems.

Most "underperformers" aren't lazy or incompetent. They're:

• In the wrong role
• Missing clarity
• Lacking support
• Struggling with broken processes
• Not getting honest feedback until it's too late

Your job as a leader:

1. Set clear expectations. What does "good" look like? Document it.
2. Give continuous feedback. Don't save it for reviews. Weekly, informal check-ins.
3. Provide support. Mentorship, training, pairing—not just "try harder."
4. Make timely decisions. Coach when it makes sense. Exit when it doesn't.

The goal isn't to be "nice" or "tough." It's to be clear, fair, and decisive.

Your Decision Checklist

Before making a final call on performance, run through this:

✅ Environment Check

• Have I given clear, written expectations for their role/level?
• Have they received specific, actionable feedback (not vague)?
• Do they have the tools, access, and support they need?
• Is their workload reasonable?
• Have I checked if this is a role/level mismatch?

If any of these are "no," fix them first.

✅ Quadrant Assessment

• Are they willing (trying, receptive to feedback, culture fit)?
• Are they able (skills match role requirements)?

High Willing + Low Able: Coach (3–6 months)
Low Willing + High Able: Behavior feedback (4–8 weeks)
Low Willing + Low Able: Exit fast

✅ PIP Execution (if coaching)

• Set 1–3 specific, measurable goals
• Define success criteria
• Establish 4–8 week timeline
• Weekly check-ins scheduled
• Real support provided (mentorship, training, scope adjustment)

✅ Exit Decision

• Clear expectations were set and support was given
• Adequate time to improve (3–6 months for skills, 4–8 weeks for behavior)
• No meaningful improvement observed
• Team is suffering / velocity is impacted
• You've consulted with HR/leadership

If all true, make the call.

The Hardest Part of Leadership

Letting someone go is hard. It should be.

But harder than making the decision is not making the decision:

• Your top performers leave
• Your team loses trust in you
• Standards erode
• Everyone suffers

The most compassionate thing you can do—for the team, for yourself, and even for the underperformer—is make a clear, timely decision.

Coach when it makes sense. Exit when it doesn't. But don't waffle for 9 months.

Your team is watching. They're counting on you to be clear, fair, and decisive.

Don't let them down.