The repair loop

You have just finished diagnosing an engineer's underperformance. The conclusion is skill-fixable, or it is confidence rather than ceiling, and the answer was not "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 common operational mistake is to default to the PIP because HR asked for a paper trail, before the engineer has had a genuine attempt at recovery. A PIP adds pressure, and pressure helps in a few narrow cases and 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. The third option is the repair loop: a structured, time-bound attempt at recovery, run as two cycles in order. The loop is also how you keep diagnosing, because what looked like a craft gap from a distance has a way of turning out to be something else once you are working at close range. I will come back to that, since it is the part I got wrong myself.

Confirm intent, diagnosis, and your own state

Run three checks before you open anything.

• Diagnosis depth. The diagnosis has been worked through, and the conclusion is skill-fixable or a confidence case rather than a silent ceiling, loud intent, or a team-level dip. If that work has not happened, do it before you open.
• Engineer-side preconditions. A dip you read as performance is often burnout or role mismatch, and sometimes something happening outside work entirely. You find that out by talking, in the normal 1:1, before launching anything formal. A repair loop launched on a burned-out engineer deepens the hole, and so does one launched on someone whose role no longer fits the team they are in. Rule these out first, because what those people need is a different intervention altogether.
• Leader-side check. Managers launch repair out of guilt or HR pressure as often as out of real signal, so read your own state first. 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, and both pressure and guilt produce theatre rather than a real attempt.

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 and plain language about where the engineer is performing and where the role needs them, with concrete examples from recent work: "at this level, the team expects X. The work I have seen has been Y. Here is the gap."

Leave the conversation with one specific outcome: mutual agreement that there is a gap worth working on. Without that agreement, the plan you write next will not function, because 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, and the path forward branches. Either you are missing something they can see, in which case go back and re-diagnose, or repair is the wrong tool and you are looking at parting.

Write a shared, plain-language plan

Both sides now agree the gap exists, so write the plan together, in a shared document the engineer opens too: a running doc both sides edit as the cycle progresses, written in plain sentences a working engineer can read and act on, with none of the SMART-goals jargon. 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 whatever any single conversation stirs up. Both sides can re-read it on a hard day, and that matters, because the engineer's confidence will swing during the cycle and the document does not swing with it.

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, owned by the EM, with no HR involvement, no formal documentation system, and no written consequences. It stays informal on purpose, so the engineer gets a real shot at recovery before the pressure of a PIP changes the dynamic.

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

The structure fails in two common ways.

The first is collapsing both cycles into one drifting loop: monthly updates, no real end date, and six months later a confused separation. Drift is stable because of how the costs fall week to week. Extending the loop costs you nothing on any given Monday, ending it costs you a hard conversation, so the loop extends, month after month, while the engineer waits for a verdict that is not coming. A loop that drifts is also telling you the original diagnosis was wrong, which is the next section.

The second is skipping the repair cycle entirely and going straight to the PIP because HR asked for documentation. That shortcut is tempting because its costs are split unevenly: the paper trail protects the company and costs HR nothing, and the added pressure lands on the engineer. Pressure helps when the diagnosis is "the engineer is coasting" and almost nothing else; for confidence problems, role mismatch, or context issues, it makes the situation worse, fast. The repair cycle exists so the EM and the engineer can fix the thing before the HR machinery starts measuring it.

Tighten cadence, candor, and shared ownership

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

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

The candor sharpens: every touch point names progress and gap honestly, paired with what you are seeing them do well, hiding nothing and delivering all of it 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 becomes shared. The engineer brings ideas to each touch point and owns 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. When only you are contributing, the loop has quietly turned back into performance management, and an engineer who stays passive is itself a signal, either that the diagnosis was wrong or that the intent was never real on one side or the other. You still own the verdict at the end, 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 in, look hard at the signals. If they are not moving, the reflex under pressure is to push harder on what you started, with more reviews and tighter standards, and the useful move is to resist that long enough to ask whether the diagnosis was right. You named the gap on the signals you had two weeks ago, and after two weeks of high-cadence work together you have more data than you did when you named it.

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, the cycle benchmarked against the ladder on exactly that, and the plan I wrote included tighter pairing, scoped work, and more reviews up front.

Two weeks in, the signals were not improving; the reviews were producing more comments rather than fewer, and the engineer was visibly slowing down, second-guessing every line of code. When I paused and re-diagnosed, the real problem was confidence. Sustained negative feedback from the previous manager had left the engineer so conscious of every code change that they were doubting themselves into mistakes, and my plan, with its extra reviews and tighter standards, had been prescribing a larger dose of the exact thing that caused the injury.

So the plan changed completely. I removed the goal of fewer PR comments and stopped being critical at all, and 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.

Underperformance has a way of looking like one thing on the surface and being another underneath, and the high-cadence weeks of the cycle are where you find that out, if you are still asking.

Exit cleanly, either way

A repair cycle ends with a verdict, and the verdict is one of three things.

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

The soft ending is the one to guard against, where the cycle quietly winds down without the engineer ever hearing whether they passed. It happens for the same reason loops drift: silence is free this week and the verdict costs a conversation, and the ambiguity corrodes both the engineer and the team that has been watching the silence. Whatever you decide, deliver it to the person it is about.

When not to run it

There are 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, and 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. They need a different intervention: time off, a smaller scope, sometimes a role change. A cycle that asks them to perform their way back deepens 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 more often a role change or parting than a six-week cycle aimed at a probation-grade gap.
• No clock at all. The opposite failure: coaching without a time bound turns into the drifting loop from earlier, where the team watches the silence and the engineer's confidence never recovers because the verdict never arrives. Of the four, this one feels the kindest while it is happening, and it is the one that ends in the six-month confused separation.