I Put a Developer on a PIP and Got It Backwards: the 7 Steps I Now Follow Before Any Singapore Exit

Six weeks of missed estimates, two production incidents traced to the same service, and a senior developer who had been excellent for two years. I did what the management handbook says: I wrote a performance improvement plan, booked the meeting, and delivered it carefully. He listened, and then he said the thing that made me realise I had run the process backwards. He had been moved onto platform and infrastructure work four months earlier, he had never done that kind of work in his career, and nobody, including me, had ever said out loud that this was now his job. I had written a capability plan for a role mismatch. He was not failing at his job; he was failing at a job he had never been given.

We redeployed him. He is still with the company and still good. But I came very close to running a clean, well-documented process toward entirely the wrong outcome, and a well-documented wrong decision is worse than a messy right one, because nobody questions it. What follows is the sequence I now use. It is written for engineering managers in Singapore, and it is legally shaped by Singapore employment practice. It is not legal advice; for a contested or high-value case, take proper advice early rather than late.

Step 1: Diagnose Before You Document

Three completely different problems produce an identical signature on a delivery dashboard: missed commitments, rework, declining output. They are not the same thing and they do not share a remedy.

• Capability gap. The person cannot currently do work that is genuinely within their role. This is the only one of the three that a performance improvement plan is actually designed for.
• Conduct issue. Repeated unexplained absence, dishonesty, refusal to follow agreed process, a serious policy breach. This follows a different process entirely: investigation, a fair chance to respond, and must not be folded into a performance plan.
• Role or scope mismatch. The work changed and the role definition did not follow, or the person was promoted or moved into something nobody explicitly scoped. The remedy is redeployment or re-scoping, not improvement.

There is a fourth category worth naming because it is common in engineering and easy to misread: a systemic or environmental cause. A developer owning the one service with no tests, no documentation and a two-hour local build will look underperforming against a team working in a healthy codebase. So will someone absorbing an undisclosed personal or health situation. If you have tolerated a blocker for months, you cannot fairly attribute its consequences to the person standing closest to it.

How to actually diagnose: ask the person first, before writing anything, in a conversation explicitly framed as diagnostic rather than disciplinary. “Here is what I am seeing. Help me understand it.” Then check the evidence independently, what work was assigned, when the scope last changed, and whether anyone ever said so in writing. In my case thirty minutes of that would have saved a month.

Step 2: Establish the Contractual and Statutory Baseline

Read the actual employment contract before you have any formal conversation. Specifically: the notice period on both sides, whether the employee is still within probation and what that changes, and the provision for paying salary in lieu of notice. Managers routinely assume a notice period that does not match what was signed, and that assumption surfaces at the worst possible moment.

Two framing facts matter here. First, a performance improvement plan is not required by the Employment Act 1968 and is not mandated by MOM. It is management practice, not a statutory step. Second, and this is why you do it anyway, if you dismiss someone with notice and cite poor performance, you need to be able to substantiate that reason. The Tripartite Guidelines on Wrongful Dismissal, issued by MOM with NTUC and SNEF, are the reference for what fair treatment looks like.

So the PIP is not a legal obligation. It is the evidence base for a decision you may have to defend. That reframing changes how you write it, because evidence is written for a reader who was not in the room.

Step 3: Write a Plan That Is Genuine, Not Procedural

A defensible plan contains four things, and one of them is routinely missing.

1. Specific, measurable expectations. Not “improve code quality.” Something closer to: design documents for changes above an agreed size, reviewed and approved before implementation begins; no more than an agreed number of review cycles on routine changes; estimates for assigned work communicated before the sprint starts and variances flagged within two days.
2. A realistic timeframe with dated checkpoints fixed at the outset.
3. The support the company will provide. This is the one that goes missing, and it is the one that decides contested cases.
4. The consequence if the standard is not met by the end of the window, stated plainly.

Writing measurable expectations for engineering work is genuinely harder than for sales, and the temptation is to reach for the metrics that are easy to count. Resist ticket throughput and lines of code; they are gameable and they measure the wrong thing. Prefer observable behaviours a reasonable peer would recognise: did the design document exist before the code, was the estimate communicated, was the variance flagged, did the change arrive with tests.

And the hard part. If you have already decided this person is leaving, a PIP is the wrong instrument. A plan written purely to manufacture a paper trail for a settled decision is visible as such, to the employee, who will usually start interviewing immediately; to an adjudicator, who reads the dates and the specificity; and to your remaining engineers, who will conclude that your performance process is theatre. If the decision is made, be honest about which conversation you are having.

Step 4: Resource the Plan and Record the Support

The question that decides a contested performance case is rarely whether the employee was good enough. It is whether the employer gave a real opportunity to improve. A plan that sets a higher bar and provides nothing to help clear it is the weakest possible position, and it is also the most common.

Concrete support for an engineering PIP looks like: a named senior engineer committed to a specific number of pairing hours per week; weekly one-to-ones with you at a fixed time rather than when you remember; temporarily reduced scope, because asking someone to improve while carrying a full load plus on-call is a contradiction; removal of a specific blocker you have been tolerating; and access to training if the gap is a defined technology.

Record both what was offered and what was taken up. That second column matters in both directions. If the support was provided and declined, that is relevant. If it was promised and never materialised, the pairing that got cancelled four weeks running because of a release, then in substance there was no plan, whatever the document says. I have seen employers lose on exactly that detail, and they deserved to.

Step 5: Run Documented Checkpoints With Written Acknowledgement

Schedule the reviews when you write the plan, not as you go. A 60-day window should have checkpoints at roughly day 15, day 30 and day 45, with the decision at day 60. The purpose of the mid-points is that a plan with no feedback until the end is not an improvement process; it is an exam.

At each checkpoint: write what was observed against each stated expectation, with examples. Invite and record the employee’s response, including disagreement. Ask them to acknowledge receipt, acknowledgement of receipt, not agreement with the content. Note any change to support or timeline and why.

Write the note on the day. Contemporaneous notes carry weight that reconstructions do not, and the difference is obvious to any experienced reader. A file of three dated notes written in the moment is worth more than a polished ten-page summary assembled the week of the exit, because the latter was written by someone who already knew the outcome.

Step 6: Decide at the End of the Window, on the Evidence

Four possible outcomes, and you must choose one explicitly on the date you promised:

1. Standard met. Close the plan in writing, say so clearly, and then genuinely stop treating the person as on probation. Half-closing a PIP is its own management failure and people leave over it.
2. Measurable progress, short extension. Legitimate once, with a new date and specific remaining gaps. Rolling extensions are a decision you are avoiding.
3. Redeployment. The right answer when diagnosis was wrong or the person is strong elsewhere. This is where my own case landed.
4. Termination. The standard was not met, support was real, documentation is coherent.

The failure mode is letting the window lapse in silence because the conversation is unpleasant and the quarter is busy. Everything you built is then worthless: the employee reasonably concludes the standard was not serious, the team sees the process has no teeth, and if you act three months later your own file argues against you, because you accepted the performance without comment for a quarter.

Step 7: Exit Lawfully, With Notice and a Clean Handover

If the decision is termination, the central point from Step 1 governs: poor performance is a dismissal with notice, or with payment of salary in lieu of notice per the contract. Not summary dismissal: that is reserved for misconduct. Honour the contractual notice period or pay it, and make sure the stated reason is consistent across the PIP, the termination letter and anything you say afterwards. Employers lose these cases on shifting reasons more often than on weak facts.

Know what happens next. A wrongful dismissal claim goes first to the Tripartite Alliance for Dispute Management (TADM): a mandatory step before the Employment Claims Tribunal, and must be filed within one month of the last day of employment. That one-month clock is useful to understand: it bounds your uncertainty, and it means your file is already final before you know whether a claim is coming. You cannot improve the record after the exit.

Then the operational tail, which engineering managers underestimate. For foreign employees there are work pass cancellation and tax clearance obligations with their own timelines, and these are not optional or flexible. And run knowledge transfer before the last day: a written handover of owned services, access and credentials revoked on a checklist, on-call rotation updated, and anything the person was the only one who knew documented while they are still there to be asked. The single most expensive consequence of a performance exit is usually not the legal risk, it is discovering six weeks later that nobody else understood the payments integration.

The Three Mistakes I Made or Nearly Made

Writing the plan before the diagnosis. Mine was a role mismatch dressed as a capability gap. Thirty minutes of asking would have caught it. The plan was well written and pointed entirely the wrong way.

Promising support I did not protect. On an earlier case I committed a senior engineer to pairing and then let a release eat those sessions four weeks running. The document said the support existed. In reality it did not, and had that gone to a dispute I would have been defending a plan that was never actually run.

Treating the team as uninvolved. Your engineers always know. What they are watching is whether the process is fair and whether it concludes. A PIP that drags for five months teaches everyone that standards are negotiable, and your strongest people, the ones absorbing the gap, are the ones who draw that conclusion first and act on it.

Frequently Asked Questions

Related Reading

• Remote Developer Performance Reviews in Singapore: 7 Steps
• Offboarding a Developer in Singapore: IR21 and Employment Pass in 7 Steps
• Developer Retention in Singapore: 7 Steps
• How to Set Up a Developer Mentorship Programme in Singapore
• How to Manage Remote Development Teams in Singapore and APAC