Playbooks Managing an Underperforming Team Member

Managing an Underperforming Team Member

The Problem Statement

"An engineer on your team who was previously a solid contributor has experienced a sharp drop in productivity, missing commit windows, and disengaging from team collaboration."

Target Impact

40% recovery / 6-week turn

01/ The Tactical Resolution

The Case Study: The Slump of a Lead Contributor

The Problem

Alex was a senior mid-level backend engineer who, for the last year, was the team’s reliable "go-to" for API design. But over a six-week period, his velocity fell off a cliff. Pull requests that typically took two days lingered for ten. In standups, he was uncharacteristically brief, offering vague updates like "Still working on database migrations."

It wasn't just a velocity problem; his teammates were quietly picking up his slack, creating subtle resentment. In a high-velocity startup, ignoring this wasn't an option. The standard corporate response would be to HR-document the decline and prep a formal Performance Improvement Plan (PIP)—which almost always results in the employee checking out and resigning. We needed a different path: a diagnostic, human-first intervention that separated the person from the output.


The Playbook: The Performance Recovery Loop

This playbook avoids the legalistic PIP and focuses on identifying the bottleneck (Skill vs. Will vs. Friction) and co-creating a rapid feedback loop.

Step 1: The Diagnostic 1-on-1 (The SCARF Assessment)

Do not start the conversation with metrics. Start by mapping the behavior shift. Use the SCARF (Status, Certainty, Autonomy, Relatedness, Fairness) framework to pinpoint where the disconnect is.

  • The Script: "Alex, I’ve noticed a shift in your engagement and PR delivery over the past month. Usually, you’re leading the charge on our API updates, but lately, tasks are stalling. I’m not here to write a warning; I want to understand what’s blocking you. How are you feeling about the current workload and scope?"

In Alex’s case, the diagnostic revealed two hidden issues:

  1. Friction (Technical): The database migrations he was working on had undocumented circular dependencies that caused local containers to crash, making testing a nightmare. He felt embarrassed to ask for help on something he felt he "should" know.
  2. Will (Motivation): He had been passed over for a senior promotion last quarter, leading to a quiet "what's the point" mindset.

Step 2: The Co-Created 30-Day Recovery Sprint

Instead of dictating terms, co-create a document with exactly three clear, measurable objectives for the next 30 days.

| Target Area | Concrete Expectation | Weekly Review Criteria |
| :--- | :--- | :--- |
| **Friction Resolution** | Unblock the migration path and document local setup. | PR submitted for migrations by Friday of Week 1. |
| **Delivery Rhythm** | Break down tickets so no PR remains open > 3 days. | Daily updates on sub-tasks; request review within 48h. |
| **Communication** | Proactively flag technical blockers in Slack channel. | No blocker goes unflagged for more than 4 hours. |

Step 3: High-Frequency, Low-Stakes Syncs

Set up a twice-weekly, 15-minute check-in. This is not a status report; it’s a coaching session.

  • Tuesday: What is the immediate next step to get your current PR merged? Do you need a pair-programming partner for 30 minutes today?
  • Thursday: Are we on track for the Friday milestone? If not, what can we cut or who can we pull in to assist?

This removes the anxiety of a looming "end of month" judgment and replaces it with small, repeatable wins that rebuild confidence.


The Long-Term Impact

By treating the drop as a systemic or motivational problem rather than a capability failure, we saw:

  • The Turnaround: Alex unblocked the migrations in Week 1, and with the peer-pairing we set up, he resolved the local setup issues for the whole team.
  • The Output: By Week 3, his average PR cycle time dropped back down to 2.8 days.
  • The Cultural ROI: The team learned that temporary slumps are treated with curiosity and support, not immediate punitive action. Alex stayed with the company and was promoted the following year.

Liked this playbook?

Share this strategic blueprint with your network.

Frequently Asked Questions

When should I put an engineer on a performance improvement plan (PIP)?

A formal PIP should be a last resort. Use a 30-day collaborative performance recovery framework first to address root causes like burnout, personal issues, or lack of role clarity.

How do I diagnose why an engineer is underperforming?

Run a diagnostic 1-on-1 using the SCARF framework to assess if the issue is a gap in capability (skills, tools) or motivation (burnout, misalignment, or personal issues).

Related Domains

Scaling Engineering Teams Processing Constructive Feedback