The repair loop

You've just finished diagnosing an engineer's underperformance. The conclusion is skill-fixable, or it's confidence rather than ceiling, and the answer wasn't "let them go." Now you are looking at what to do next.

Two default options sit in front of you. The first is the Performance Improvement Plan (PIP), optimized for HR documentation and legal defensibility. The second is open-ended coaching with no clock, well-intentioned and prone to drifting for months. The most common operational mistake is to default to PIP because HR asked for a paper trail, before the engineer has had a genuine attempt at recovery. PIP adds pressure, which helps in narrow cases but makes most situations worse.

Hire and fire fast applies before someone clears probation. Past probation, you are responsible for the engineer's career, and separation is rarely the answer to a real gap. This essay describes the third option: the repair loop, a structured, time-bound attempt run as two cycles in order. The cycle is also how you keep diagnosing. What looks like a craft gap often turns out to be something else. Better to pause and ask what you missed than push harder on what you first tried.

Confirm intent, diagnosis, and your own state

Three checks before you open anything.

• Diagnosis depth. Diagnosis has actually been worked through, and the conclusion is skill-fixable or a confidence case rather than silent-ceiling, loud intent, or a team-level dip. If the work hasn't happened, do it before you open.
• Engineer-side preconditions. A dip you read as performance is often burnout or role mismatch, sometimes something happening outside work. You find that out by talking, in the normal 1:1, before launching anything formal. Launching a repair loop on a burned-out engineer deepens the hole. So does launching one on someone whose role no longer fits the team they are in. Rule these out first; what they need is different.
• Leader-side check. Managers launch repair from guilt or HR pressure as often as from real signal. Read your own state. If you are starting this because you are tired of carrying the gap, or because someone above you is pushing for documentation, that is pressure. Both produce theatre.

When all three pass, you can open.

Open in the 1:1, benchmarked against the ladder

Open inside the normal 1:1 cadence. The formal HR tone belongs to parting. This conversation is a benchmark.

Use the written ladder. Plain language about where the engineer is performing and where the role needs them. "At this level, the team expects X. The work I have seen has been Y. Here is the gap." Concrete examples from recent work.

Leave the conversation with one specific outcome: mutual agreement that there is a gap worth working on. Without that, the plan you write next will not function. The engineer will treat it as something happening to them rather than something they are in.

If the engineer rejects the diagnosis outright after a real attempt, that is itself an early signal. The path forward branches: either you are missing something they see, in which case re-diagnose, or repair is the wrong tool and parting is the path.

Write a shared, plain-language plan

Both sides agree the gap exists. Now write the plan together, in a shared document the engineer opens too. A running doc both sides edit as the cycle progresses. No SMART-goals jargon. Plain sentences a working engineer can read and act on.

Four headings get you most of the way:

• The gap. Named against the ladder, in concrete language. "You are operating at L4 on technical scope; the team needs L5 on this surface."
• The support. What you are providing. Paired reviews, scoped work that lets them rebuild signal, mentorship from a strong peer, obstacles removed.
• The cadence. When you will meet, what gets reviewed, what each touch point produces.
• The time bound. When the cycle ends and what the exit conditions are.

The doc is the artifact that survives the emotional weather of any single conversation. Both sides can re-read it on a hard day. The engineer's confidence will swing during the cycle; the plan will not.

Two cycles, in order: repair first, PIP second

The structure is two time-bound cycles: the repair cycle, then the PIP.

The repair cycle runs about six weeks. EM-owned. No HR involvement, no formal documentation system, no written consequences. Give the engineer a real shot at recovery before the pressure of the PIP changes the dynamic.

The PIP runs four to six weeks. Formal, HR-involved, with consequences written down. It opens only if the repair cycle does not land.

Two failure modes here, both common.

The first is collapsing both into one drifting loop. Monthly updates, no real end date. The cycle runs for six months and ends in confused separation. Drift is usually a signal the original diagnosis was wrong; that is the next section.

The second is skipping the repair cycle entirely and going straight to PIP because HR asked for documentation. PIP adds pressure. Pressure helps when the diagnosis is "the engineer is coasting" and almost nothing else. For confidence problems, role mismatch, or context issues, pressure makes the situation worse, fast. The repair cycle exists so the EM and engineer can fix the thing before HR machinery starts measuring it.

Tighten cadence, candor, and shared ownership

Once the cycle starts running, three things change at once.

Cadence tightens. The monthly 1:1 becomes weekly, sometimes twice a week. Discovering at the end of the repair cycle that it did not land is the wrong way to find out.

Candor sharpens. Every touch point names progress and gap honestly, paired with what you are seeing them do well. Hide nothing; deliver in a form they can act on. The shape is candor without crushing: concrete observations grounded in specific work. "This PR shipped without a regression test and the rollout broke prod for twenty minutes" is candor. "You are not careful enough" is crushing.

And the cycle is shared. The engineer brings ideas to each touch point. They own pieces of the plan: which obstacle they want removed first, what scoped work would help them rebuild, where they need pairing, where they need space. A loop where only you contribute is performance management dressed as repair. The engineer being passive is itself a signal that diagnosis was wrong, or that intent was not real on either side.

Shared responsibility is partnership in execution. You still own the verdict at the end of the cycle, but the work inside the cycle is two people working on the same thing.

Re-diagnose mid-loop when signals do not move

Two or three weeks into the cycle, look hard at the signals. If they are not moving, the reflex under pressure is to push harder on what you started: more reviews, tighter standards. Resist that. Pause and ask whether the diagnosis was right.

The cycle is not just a plan to execute. It's also how you keep diagnosing. You named the gap based on the signals you had two weeks ago, and after two weeks of high-cadence work together, you have more data.

A real example. I once opened a repair cycle on an engineer whose code quality had been visibly poor: multiple rounds of PR comments on every change, regressions slipping through. The surface read was a craft gap, and the cycle benchmarked against the ladder on exactly that. The plan included tighter pairing, scoped work, more reviews up front.

Two weeks in, the signals were not improving. The reviews were producing more comments rather than fewer. The engineer was visibly slowing down, second-guessing every line of code. I paused and re-diagnosed. The real problem was confidence rather than craft. Sustained negative feedback from the previous manager had left the engineer so conscious of every code change that they were doubting themselves into mistakes.

The plan changed completely: I removed the goal of fewer PR comments and stopped being critical at all. The new support was space. Work where they could fail safely, encouragement to express themselves on their own terms, and fewer reviews rather than more.

The engineer recovered. The craft caught up once the confidence did.

Most underperformance looks like one thing on the surface and turns out to be another. The cycle is the data that lets you see that. Treat it as just an execution plan and you miss half of what it's for.

Exit cleanly, either way

A repair cycle ends with a verdict. One of three things.

• Recovery. The signals are real and durable. Close the cycle, name the recovery to the engineer directly, return to normal cadence. Make sure they know they passed. Confidence does not actually rebuild if the verdict is never delivered.
• The PIP opens. The repair cycle did not land. Open it with the same transparency, the same shared plan structure, and a clean reset on the time bound.
• Parting begins. Either after the repair cycle with enough signal that the PIP would be theatre, or after the PIP does not land. The handoff to separation is clean. The mechanics belong to parting well.

The failure mode here is the soft ending. The cycle quietly winds down without the engineer knowing whether they passed. Ambiguity at the end of a cycle corrodes the engineer and the team that has been watching the silence. Whatever you decide, deliver it.

When not to run it

Four cases where the repair loop is the wrong tool.

• No genuine intent. You have already decided this person is leaving, and the cycle is there to make that decision look fair. The engineer can tell. The team can tell. The loop becomes a slower, more painful version of the thing you were going to do anyway. If you have decided, part directly.
• The engineer is burned out or in crisis. Different intervention. Time off or a smaller scope, sometimes a role change. A cycle asking them to perform back would deepen the hole.
• Probation should have caught it. The gap is so deep that the fix belongs to the hiring system. Past probation, you still owe the engineer a real attempt, but the answer is usually a role change or parting rather than a six-week cycle on a probation-grade gap.
• No clock at all. The opposite failure. Coaching without a time bound becomes drift. The team watches the silence. The engineer's confidence does not recover because the verdict is never delivered. A loop without exit conditions is not a loop.