I Carried an Underperformer for 7 Months: the 7-Step Plan I Use Now

Seven months. That is how long I let a situation run before I did anything structured about it, and the cost was not mainly the output I did not get. It was that two strong engineers quietly started routing work around their colleague, a third asked me in a one to one whether standards applied to everyone, and when I finally sat down to write something down I discovered I had almost no usable evidence. Three conversations, all of them softened to the point of being unreadable, and nothing in writing. The method below is what I built afterwards. It is not gentler than what I did. It is faster, and it is fairer, mostly because it forces a decision onto a date.

Why the fixed date is the whole mechanism

Every failure mode I have seen in this work comes from the same source: the absence of a date by which something must be concluded. Without one, a manager who dislikes conflict will keep choosing the comfortable next step, which is always another informal chat. Meanwhile the team is running its own assessment, and it concludes faster than you do. By month three they are not asking whether their colleague is struggling. They are asking what you are going to do, and reading your inaction as the answer.

So the plan below is built around one commitment made at the start: on a named day, you will say one of three things. The gap is closed. The gap is not closed and here is the single documented extension. Or we are separating, handled properly. Everything before the date exists to make that statement defensible and, ideally, to make the first outcome the likely one.

Step 1: Rule out the system before you judge the person

This is the step people skip, and skipping it is expensive. Before concluding that an engineer is underperforming, establish whether the conditions for performance exist. Run through four questions and answer them with evidence rather than impression:

• Ownership. Does this person have a clear, bounded area they are accountable for, or are they the default assignee for whatever is left over? An engineer whose queue is other people’s leftovers will look slow at everything.
• Environment. Can they run, test and ship their work without asking someone? Count the days lost to a broken local setup or missing access over the last month. I have seen a 30 per cent output gap close entirely when someone finally got the credentials they had requested twice.
• Dependencies. How much of their calendar time is spent waiting on a decision, a review or another team? If review turnaround is four days, nobody on your team is fast.
• Requirements. Does work arrive as a written outcome, or as a verbal fragment that gets reinterpreted at review time? Engineers who repeatedly build the wrong thing are often the only ones honest enough to build what they were actually told.

The decisive test is a thought experiment I now apply before anything else: would a clearly strong engineer, dropped into exactly this role with exactly this context, visibly succeed? If the honest answer is that they would also struggle, you have a system problem wearing a person as a costume, and replacing the person leaves you with the same results plus the cost of a departure. If you have instrumented delivery at all, our method for measuring developer productivity with DORA metrics in Dubai gives you team-level baselines, which is what tells you whether one person is an outlier or simply the most visible part of a slow pipeline.

Step 2: Write the gap as observable behaviour

Take the complaint and convert it into facts a neutral third party could verify. “Not senior enough” is not a fact. “On three dated occasions in September, work was marked ready for review with no tests and failed in staging, and in each case the omission was pointed out in review rather than caught beforehand” is a fact. Specificity is not bureaucracy here, it serves two purposes: it tells the person precisely what to change, and it protects you from the much more common failure of describing a personality rather than a behaviour.

Apply one hard filter. If you cannot write the gap as something a reasonable observer would see, dated, you do not have a performance case yet. You have an impression, and impressions are where bias lives. Three dated examples is the minimum I will act on. One is an incident, two is a coincidence, three is a pattern.

Step 3: Check that the expectation was ever actually communicated

Now find the moment the standard was stated. Not implied, not assumed from seniority, stated. Look in the role scope, your one to one notes, written feedback, the team’s definition of done. This step is uncomfortable because of how often it fails. In my own seven-month case I could not find a single instance where I had told the engineer plainly that what he was producing was below the bar for his level. I had told his colleagues, by complaining to them, which is worse than useless.

If you cannot point to the moment, the first corrective action is yours. State the standard clearly, in writing, give a reasonable period to meet it now that it is known, and start the clock from there. This is not softness, it is the thing that makes the rest legitimate. A written engineering career ladder removes this failure mode permanently, because the expectations for each level exist before the disagreement does.

Step 4: Hold the unambiguous conversation before any plan

Before a formal plan exists, have one direct conversation whose only job is to remove ambiguity. Name the gap using the dated examples from step two. State the standard. Ask the question that matters most and then stop talking: what is making this hard?

A meaningful share of cases resolve at this step, and the reason is usually mundane rather than motivational. Someone was given an area they had never worked in and was too proud to say so. Someone has a caring situation at home they assumed would not be accommodated. Someone has been quietly blocked for a month by a dependency they did not feel senior enough to escalate. None of that survives a plan if you never ask.

Keep two rules. Do not soften the gap to protect the mood, because a conversation the person leaves feeling reassured has failed at its only task. And do not attach consequences yet. This conversation is for information and clarity. If it needs to become a plan, that is step five, and it should not be a surprise when it arrives.

Step 5: Write a 30-day plan with criteria a sceptic would accept

Now the document. Four components, and the fourth is the one most plans omit:

1. Two or three outcomes, no more. Each stated as something that will be true by the end date, not as an activity. “Every change I submit includes tests covering the paths I touched, with no review comments about missing tests” works. “Improve code quality” does not.
2. Evidence that would satisfy a sceptic. For each outcome, name what you will look at: the pull requests from these four weeks, the staging failure count, the review comments. Decide this in advance, because evidence chosen after the fact is always chosen to confirm the conclusion you already reached.
3. Named support. What you are changing to make success possible. A weekly pairing session with a named engineer, a reduced scope for the month, access that was missing, a specific piece of training. A plan that asks for change while providing nothing is a notice period with extra steps, and your team will read it that way.
4. What happens either way, in writing. State plainly that meeting the criteria ends the plan, and what follows if they are not met. Ambiguity here is not kindness. It is the thing that makes the end of the plan feel like an ambush.

Review the document with whoever owns people processes before you deliver it. They will find criteria that cannot be evidenced and support you have not actually arranged. Employment arrangements in the UAE vary between mainland and free zone entities and between contract types, so the process and documentation expectations for your specific setup are a question for your HR function or qualified employment counsel, and they should see the plan while it can still change.

Step 6: Run four weekly checkpoints that can change the verdict

Twenty minutes a week, against the written criteria, recorded in two or three lines each time. The recording is what makes the final conversation short, and it is the thing you will be glad of if the decision is ever questioned.

The non-obvious rule: a checkpoint must be able to end the plan early, in either direction. If someone clears the bar convincingly in week three, close it in week three and say so. A plan that cannot conclude early is a formality, and people can tell. Equally, if something serious emerges, you do not have to run out the clock to preserve appearances.

Step 7: Decide on the date, and act within the week

On day 30 you say one of the three things above. The failure mode here is drift: a decision reached internally and then not communicated for a fortnight while you look for a gentler way to say it. The fortnight does not reduce the difficulty, it just extends it, and the person usually knows anyway.

If criteria are met, close the plan explicitly and in writing, and then genuinely close it. Someone who clears a plan and is treated as provisional for the next six months will leave, and they will be right to. If you are separating, do it properly, through the process your HR function has confirmed for your entity and contract type, with the handover planned in advance. Our developer offboarding checklist for Dubai covers the access, knowledge and continuity steps that are easy to forget during a difficult week, and the exit interview method is worth running even here, because the system questions from step one often get their most honest answers on the way out.

One last thing worth saying plainly. If you find yourself running this process repeatedly with different people in the same role, the process is not the problem and neither are they. Your hiring bar or your role definition is. That is a different fix, and it starts earlier, with a structured interview scorecard that tests the thing the job actually requires. Preventing one of these situations is worth more than handling three of them well, and it is considerably less painful. The same is true of the retention side: our notes on retaining senior developers in Dubai cover the conditions that stop good engineers drifting into this territory in the first place.

Frequently asked questions

How long should a developer performance improvement plan run?

Thirty days is the right default for an individual contributor, with one documented extension available if genuine progress is visible but incomplete. Under three weeks you are measuring noise, since a single sprint can swing on one awkward ticket. Beyond six weeks, the person lives under a cloud for a quarter, which damages the performance you are measuring, and the team concludes the standard is unenforceable. The length matters less than having a fixed end date in writing from the start, because an open-ended plan is exactly how a seven-month drift begins.

What is the difference between a performance problem and a system problem?

A performance problem persists when the conditions for success are present. A system problem disappears when you fix the conditions. Ask whether a strong engineer, dropped into this exact role with this exact context, would visibly succeed. If they would also struggle because ownership is unclear, reviews take four days or requirements arrive verbally, you have a system problem wearing a person as a costume. Replacing someone does not fix a system defect, so you pay for a departure and inherit the same results.

Should the improvement plan be shared with HR before the conversation?

Yes, and early rather than at the separation stage. An experienced HR partner will spot criteria that cannot be evidenced, language describing personality rather than behaviour, and support you have not actually arranged. Employment arrangements in the UAE vary between mainland and free zone entities and between contract types, so the process and documentation expectations for your setup are a question for your HR function or qualified employment counsel, and they should see the plan while it can still be changed.

What if the developer is a contractor or works through an outsourcing partner?

The diagnostic is identical, the mechanism differs. With an agency or managed team the performance conversation belongs to the partner, and your side is a specific, evidenced request to the account owner rather than a plan handed to the individual. Agencies respond well to dated examples and badly to general dissatisfaction, so the written gap from step two is the right artefact to bring. Check the replacement clause in your agreement first, because a good partner often offers a swap faster than you expect.