We Ran 31 Developer Exit Interviews and Learned Nothing From the First 20: the 7-Step Format That Finally Worked

For a long time our exit interviews were useless in a very specific way: they were not empty, they were uniform. Twenty conversations, and almost every one landed on compensation and career growth. Both are real, neither is actionable, and the uniformity should have been the clue. When every departing engineer gives you the same two reasons, you are not learning why people leave. You are learning what is safe to say to someone who still controls your reference. The format below is what we use now, and the answers stopped matching each other almost immediately.

Why the standard format produces nothing

Three structural problems, all of them fixable without a budget.

The conversation happens on the last day, when the person has already mentally left and wants to get out cleanly. It is run by the manager or by someone who works closely with the manager, which means any honest answer about management is a risk the person has no reason to take. And the output is prose in an individual file, so nothing can ever be compared across departures and no pattern can ever become visible. Each of those alone would weaken the exercise. Together they guarantee that it tells you only what the departing engineer thinks you want to hear.

In Singapore specifically there is a fourth factor worth naming: the market is small and reputational. Engineers here reasonably assume they will work with these people again, possibly within the same few buildings. That raises the cost of candour well above what it would be in a larger, more anonymous market, and it is why the identity of the interviewer matters more here than the question list does.

Step 1: Change who asks the questions

This is the highest-leverage change available and it costs nothing. Move the conversation outside the reporting line. The departing engineer should be talking to someone with no stake in the answer: an engineering leader from a different area, a people partner who does not support that manager, or a third party.

Say why, explicitly, at the start: this conversation does not go to your manager in attributed form, it goes into a quarterly pattern review, and here is who will read it. Vague confidentiality promises make people more careful, not less. A specific description of where the information travels is what actually unlocks the answer, and it has the advantage of being verifiable later, which matters in a market where the person will hear from former colleagues whether you kept your word.

If your company is small enough that everyone is in the reporting line, use a peer company contact, an advisor, or run it in writing with the explicit commitment that only aggregated findings are shared. Anything is better than the manager whose behaviour might be the finding.

Step 2: Move the conversation off the last day

Run the main conversation in the second or third week of the notice period. In Singapore, engineer notice periods are commonly one to three months, which is a genuine luxury compared with markets that run on two weeks: the decision is final, the resentment has usually cooled, and the specifics are still fresh.

Then add a short follow-up six to eight weeks after they start the new job. This second conversation is where the most useful material appears, because the comparison is now concrete rather than hypothetical. “What is different about how your new team works” produces better operational insight than any question you can ask while someone is still inside your building. It is a fifteen-minute call and most people take it.

Keep the last-day administrative session separate and leave it administrative. Mixing offboarding logistics with the diagnostic conversation degrades both. If you need the logistics checklist for Singapore specifically, we wrote it up as the developer offboarding process covering IR21 and the employment pass.

Step 3: Ask about the decision, not the satisfaction

Satisfaction questions invite summary judgements, and summary judgements are where the polite version lives. Decision questions force recall of specific events. These are the five that changed our answers:

1. When did you first seriously think about leaving, and what was happening that week? People remember the trigger with surprising precision, and it is almost never the thing they list as the reason.
2. What does the new role offer that we could not? Note the phrasing. Not “why are you leaving”, which invites a verdict on you, but a comparison of two concrete options.
3. What would we have had to change, and by when, for you to have stayed? The “by when” is the important half. It converts a wish into a deadline you either could or could not have met, and it frequently reveals that the window closed months before the resignation.
4. What are you glad to be leaving behind? This is where the process pain comes out: the release procedure, the on-call rota, the meeting that nobody cancels. People consider these too small to raise as reasons and they are often the most fixable.
5. Who should we be worried about losing next, and why? Asked plainly, with no promise of action, most people answer honestly. It has been the single most predictive question we ask.

Ban scale ratings from this conversation entirely. A four out of five tells you nothing you can act on, and the act of assigning it lets the person escape the specific answer.

Step 4: Separate the three reasons people actually leave

Nearly every departure we have examined resolves into one of three categories, and they demand completely different responses. Conflating them is why “compensation and growth” feels like an answer while fixing nothing.

• Pull. Someone offered them something genuinely better, and no reasonable version of your company was going to match it. This is not a retention failure. Record it and move on. Treating pull departures as failures is how teams end up making panic counteroffers that distort their bands.
• Push. Something here made staying unattractive: a manager, a project, the on-call load, a promotion that did not happen. This is the only category that generates a fix, and it is the one the default format reliably hides.
• Drift. Nothing was wrong and nothing was right. No growth conversation happened for a year, so when a recruiter called there was no reason to say no. Drift looks like pull in the notes and behaves like push in reality, and it is usually the largest category once you can see it.

Make the interviewer assign one primary category per departure, with a one-line justification. The discipline of choosing is what makes the data useful, and the disagreements about which category a departure belongs to are informative in their own right. If drift turns out to be your largest bucket, the fix is in the review cadence rather than the pay band, and our developer performance review format is the more relevant document.

Step 5: Capture the knowledge risk in the same session

The departing engineer is the only person who knows what they alone know, and nobody ever asks them directly. Add a short second half to the conversation that is purely operational:

• What runs that you are the only person who understands? Expect at least one answer, usually a scheduled job, an integration or a vendor relationship.
• What is undocumented because it was faster not to write it down? People answer this honestly on the way out in a way they never do while staying.
• Which credential, access or account is in your name? This question has saved us more incidents than any handover template.
• What would you fix first if you were staying another six months? The best technical debt inventory you will ever get, free, from someone with no remaining political reason to soften it.

Route the answers to the engineering lead as tasks, not as notes. The diagnostic half of the interview stays confidential and aggregated; this half is operational and should be acted on this week. Keeping that distinction clear is also what lets you promise confidentiality on the first half without lying. The backfill decision that follows belongs in a separate conversation, which we cover in the engineering backfill planning guide.

Step 6: Code the answers so they aggregate

Prose notes in individual files are where exit interviews go to die. You cannot compare them, so you never see a pattern, so nothing is ever decided, so the next interview feels pointless. Fix it with a deliberately small structured record per departure:

• Primary category: pull, push or drift. One only.
• Primary driver, from a fixed list of no more than eight options. Resist adding a ninth: the constraint is what produces comparability.
• Trigger month, from the “when did you first think about leaving” question.
• Manager and team, so you can see concentration without attributing any individual answer.
• Two verbatim quotes. These are what move a leadership conversation when the aggregate numbers do not.
• Whether a documented growth conversation had happened in the previous six months. Yes or no.

That last field was the one that embarrassed us. Once it existed, the concentration was immediate and undeniable, and the drift category stopped being invisible. A spreadsheet is entirely sufficient for this; the value is in the fixed fields, not the tooling.

Step 7: Commit to one change per quarter, and tell the team

Decide in advance that each quarter you will act on the single largest push or drift driver. Not all of them, one. Then tell the remaining engineers what changed and why, naming the fact that people left over it.

That last part is the step teams skip, and it is the one that converts the whole exercise from administration into retention. The engineers who stayed already know why their colleagues left; they talked to them. What they do not know is whether you heard it. An announcement that says the on-call rota is changing because three people cited it on the way out tells the team that leaving is not the only way to be listened to. That is the actual mechanism by which exit interviews reduce attrition, and it has nothing to do with the quality of your questions.

Set a floor too: if a quarter passes with no change made, say that out loud in the review and record why. A documented decision not to act is honest and survivable. Silence reads as the findings being filed, which is what everyone suspected in the first place.

Three mistakes worth avoiding

Treating every departure as preventable. Pull departures are a sign you hire people other companies want. Chasing them produces distorted counteroffers and resentment among the people who did not threaten to leave.

Letting the manager read the attributed notes. One breach of this ends the usefulness of the format permanently, and in a market this size the breach will be known within a month.

Running the diagnostic half with someone already managed out. If the person was on a performance plan, the conversation is a different one with different incentives, and mixing it into the same dataset corrupts the pattern. Keep those separate, and handle them with the performance improvement process instead.

Frequently Asked Questions