How to write a PIP the engineer can actually pass

It happens more often than you’d think: an engineer skips their manager and comes straight to me. The message is almost always the same: my manager is being unfair with me, I don’t know what they expect, and they say I’m underperforming just because they don’t like me.

Very often, there’s a performance improvement plan (PIP) behind it.

The story usually goes like this. The team complains about a colleague. He needs too much handholding, or his code keeps coming back from review and others have to redo it. The manager sees the same thing: work isn’t landing on time. So the manager puts him on a two-month PIP with two goals:

• You need to be more independent.

• The quality of your code needs to meet the team’s standards.

The engineer reads them and has no idea what to do differently. The manager still isn’t happy, the conflict grows, and it ends up on my desk.

The problem isn’t that the manager is wrong about the performance. The problem is that nobody can tell what passing looks like.

The question I ask about every goal

When this happens, I first ask the engineer if they’re OK with me getting involved. Then I sit with the manager and ask them to walk me through the PIP. For every line, I ask one question:

Me: How will you know this is fixed? And by when?

Many managers can’t answer. A common reply is:

Manager: I’ll collect feedback from the team.

Me: OK. What do you expect that feedback to say, objectively, for the PIP to pass?

If the manager can’t answer that, the engineer has no chance. They’re chasing a target that only exists in someone else’s head.

Turn each goal into a row

I write PIPs in a simple sheet. Each goal is a row, and each row has the same columns:

• Current state: what’s happening today, as objectively as possible.

• Target state: what good looks like, with a metric and a target.

• Support: what we’ll do to help. If the root cause is a knowledge gap, say Kotlin, then a mentor, a course, or other learning material.

• Deadline: when we expect the target to be reached.

Here’s how the two goals from the story look once you do this.

Code quality

“Meet the team’s standards” becomes something you can count. For example:

• How often your PRs need rework after review.

• How many bugs from your changes reach production.

For the target, a number like under 5% of PRs needing rework is a reasonable example, but the right number depends on your team. Look at what your other engineers achieve today and set the bar there. With AI writing more of the code, review and rework patterns are changing, so your own team’s baseline is a better reference than any number from a blog post.

Independence

This one is harder, and it’s easy to get wrong.

The obvious metric is how often the person asks for help. Don’t use it. It’s hard to count honestly, and it rewards the wrong behaviour: the easiest way to hit “twice a day” is to stop asking and get stuck in silence. That’s the last thing you want from someone who’s already struggling, and you don’t want a team where people are afraid to ask each other questions.

What you really care about is this: can the person deliver their share of the team’s work, on time, without someone else carrying it for them?

So I set the target around that:

• The person takes a fair share of the sprint’s committed work, sized and assigned by the team the way it normally is, at the level expected of their role.

• They deliver it on time.

• Their teammates’ own commitments still land on time too.

The last point matters. When one engineer is held by the hand, another engineer misses their own goals to support them, and their engagement drops. If the struggling engineer hits their targets because a colleague quietly did half the work, nothing is fixed.

The teammates’ input matters here too, since their complaints are often what started the PIP. But I don’t ask them “how is it going with him?” That’s how a PIP slides back into “my manager doesn’t like me.” I ask the same concrete question every week: did you have to put your own work aside to help this sprint, and roughly for how long? That gives me a number I can follow over time.

Pair speed with quality

Notice that the two goals protect each other. If you only measure delivery, the person can ship faster by cutting corners. If you only measure quality, they can slow down until nothing comes back from review.

Whatever you measure, people will optimise for it. So whenever a PIP has a speed target, I add a quality target next to it, and the other way around.

Eight weeks, eight data points

My PIPs usually last two months. That gives me eight weekly data points, which is enough to see a pattern.

I don’t expect the person to be green from week one. Sometimes the PIP is a wake-up call and things change immediately. Other times, like the Kotlin case, the person needs to learn, and progress is gradual. If the first weeks are below target but the last weeks fully meet it, that’s a pass.

What I don’t accept is “almost there.” I’ve heard many managers say it at the end of a PIP: he improved a lot, he’s putting in the effort, the rest is coachable. And the PIP is marked as passed.

I’ve seen many of those people relapse a few weeks later. Then the manager has the same problem again, and a much harder conversation with HR, who don’t want to go through a second process for the same issue. Passing someone who’s almost there is often a way of avoiding a hard decision. If the target was clear from the start, the end has to be clear too.

What doesn’t belong in a PIP

Not everything fits this model. For me, a PIP is for skill gaps: not independent enough, code quality below the bar, ideas that don’t get across. Those can be learned, supported, and measured.

Toxic behaviour is different. If someone is disrespectful to colleagues, I don’t give them two months and a sheet. That’s a conduct issue, and it goes through a different route.

Be careful with the line, though. A dismissive code reviewer is sometimes someone who never learned how to give feedback. That’s a skill gap, and it can go in a PIP. A person who chooses to treat people badly is not.

How the escalation ends

After the conversation with me, the manager rewrites the PIP and restarts it. The manager presents it to the engineer, and then I check in with the engineer myself: is it clear now what’s expected, and does it feel fair? If not, we clarify it together.

Some of those engineers pass, some don’t. In my experience, by the time a PIP has escalated, trust between the engineer and the manager is already badly damaged, and a rewritten plan doesn’t always fix that. It also tells me something about the manager: they need support in how to manage performance.

That’s why it’s worth getting the PIP right the first time.

The takeaway

Before you give someone a PIP, read every goal and ask yourself: how will I know this is fixed, and by when? If you can’t answer with a metric, a target, and a date, neither can the engineer. Write down the current state and the target state, pair speed with quality, give the support they need, and when the time is up, judge the result against what you wrote, not against how you feel.