TL;DR
- The real failure point: collection, not presentation. Themes arrive at the executive meeting already abstracted past the point of action, and the slide says "management" or "progression".
- When doing nothing is right: in a stable team with under a handful of exits a year, where the leaver already gave the reason in the exit conversation and the manager has acted on it directly.
- What has to be true for this to work: the report names a team, a practice or a manager. Without that, no executive has anything to decide.
- How the options split: free-text coding for depth, a fixed taxonomy for comparability, cutting by tenure band for phase problems, and triangulation for context.
- Decision rule: if your themes won't survive being pointed at a specific person, they aren't themes yet.
- The outcome to expect: slower reporting, fewer themes, and a meeting where the executive asks the next question instead of changing the subject.
A Slide That Says Nothing
A people lead in a 380-person software company sits down on the Wednesday before the quarterly executive review. She has two years of exit notes on a shared drive. She has read the four most common articles on exit data this week and closed three of them when they became a pitch for a platform. She has twelve exits to report on, drawn from across four teams. The slide she has built says the top three reasons are management, progression and workload. The chief executive has seen that slide shape three quarters in a row. She knows how the meeting will go: a nod, a question about hiring, and an adjournment. The slide won't change a decision, and on some level she has stopped expecting it to.
The notes themselves aren't the problem. They're detailed, often candid, occasionally specific about a manager by name. The failure is what she did to them on the way to the slide. She took twelve detailed accounts and collapsed them into three words. A theme drawn at that level of abstraction isn't a finding. It's an instruction to an executive to act on a noun.
But the real issue isn't that the notes were thin. The real issue is that the report handed the executive no handle to pull. The data needs to keep enough specificity that the meeting can land on a team, a practice or a manager, and from there, on a decision.
Best tools for Employee Retention
When You Genuinely Do Not Need to Act Yet
A team of forty with one exit every couple of years. Nothing is wrong here. The leaver sits down with their manager, gives a real reason, and the manager closes the loop the same week. There's no aggregated dataset to build, no taxonomy to maintain, and no executive meeting to prepare for. Anyone who tells this team they need an exit programme is selling something. If the manager is the same person who would handle a retention conversation, the exit conversation is part of that work, not a separate process. The note goes in the file under that person, and the next time someone leaves that manager's team, the manager reads both notes together.
A scaling company with three or four exits a quarter across five teams. Here the surface starts to itch. Exit notes exist in inboxes, on laptops, in a shared folder that one person maintains out of habit. Nobody is reading them across quarters. The instinct is to build a programme. Resist it for one more quarter. The honest move at this stage is a single shared document, one line per exit, with the team, the manager, the voluntary reason given and the date. That document, kept by one person, is enough to spot a pattern when one starts to form. The mistake is to skip this step and jump to a survey or a dashboard. The infrastructure arrives before there's anything to put in it.
A 200-person firm where notes do exist but never surface. This is the stage where the discomfort is real. A year of careful conversations, and nothing in those notes has ever been read by anyone outside HR. That's the case most people in this position sit in, and it's the case this article is written for. The notes are good. The system is the problem. Themes have been drawn, but at a level so abstract that no executive can act on them, or they have been drawn accurately and then softened in the slide. Either way, the fix is in the presentation, not the notes.
A regulated environment where the data is genuinely dangerous to report. A small specialist team of six where one person has left under disputed circumstances, and the manager is also the subject of a separate internal process. Aggregating exit data here's not a neutral act. The shape of the exposure is that the leaver could request the notes under local personal data rules, and a report naming a manager in a team of six reads as identification. The right answer at this stage is to keep the data with the case owner, not to publish a theme. Confirm the local position before any cut of the data leaves HR.
The Questions You Ask Yourself at 11pm
Is this just a presentation problem? Almost certainly yes. If the notes on the drive are detailed and the slide is vague, the gap is in how the data was summarised, not in how it was collected. The fix is upstream of the slide, in the coding. If you can't point at a team from the report, you don't have a finding.
Are the themes I draw actually themes? A theme drawn from four exits in a team of eighty isn't a theme. It's a hypothesis. The 11pm version of the question is whether you would stake your credibility on the pattern surviving the next two quarters. If you wouldn't, don't present it as a finding.
Can I say which manager without naming anyone? If the theme only makes sense pointed at one manager, the report needs to be cut differently. Cutting at team level usually preserves the signal without identifying the individual. If the team is small enough that pointing at it names the manager, the data stays in HR until the team is large enough to report on.
Who in the room can act on this? If the executive can't change the manager, the practice, the pay band or the team structure, the data is being delivered to the wrong person. The honest version of this question is whether anyone in the room can do anything, or whether the report is performance art.
What does the leaver get back from this? In most organisations, the leaver has the right to ask what was done with their note. If nothing was done, that becomes a fair complaint. The 11pm question is what you would say if a former employee asked, six months later, why their note made no difference. If the answer is uncomfortable, the report needs to land or the conversation needs to happen before the report is filed.
How long do I have before the next exit lands and the picture shifts? The honest answer is that the picture shifts every exit. If you're reporting on twelve exits over two years, the data is already a moving average. Build the report so it can be re-run after each exit, not presented once a quarter and forgotten.
Three Honest Categories the Approaches Split Into
Free-text coding by a person who knows the business. Someone reads every note, tags each with a category that fits the actual content, and resolves overlaps by judgement. The strength is depth: a category like "promised promotion in Q2, never appeared" stays specific enough to act on. The weakness is the person. Two readers will code the same notes differently. A new HR lead, a reorganisation, or a long absence breaks the continuity, and the themes shift in a way that has nothing to do with the business. This approach is right when the exits are few enough to read in full and the reader has been in role long enough to know the players. It fails when the volume rises above what one person can hold in their head, or when the role changes hands.
A fixed taxonomy applied at the interview itself. A short list of categories that every interviewer ticks, plus a free-text box for the rest. The strength is comparability across quarters. The same word means the same thing in July and in January, and the slide looks the same in both. The weakness is the taxonomy. A taxonomy written before the exits happen will misclassify the most interesting ones. A leaver who quit because their manager blocked a transfer is forced into "career" or "management", and the actual story is lost. This approach is right when the leadership wants a stable comparable number across years. It fails when the leadership then stops asking what the categories mean.
Cutting the existing free text by team, tenure band or regretted-attrition status. The notes themselves aren't changed, but the report slices them differently. The strength is that the categories that matter to the business are usually not "management" or "progression" at all. They're "the platform team, exits at month fourteen, all voluntary". The weakness is that the cuts are only as good as the labels in the original note. A note that says "left for a new opportunity" can't be cut by tenure. This approach is right when the leadership question is concrete: who is leaving, when, and from where. It fails when the original notes are too thin to support the cut.
Five Diagnostic Questions You Can Self-Assess Against
Do your themes name a team? Look at your last quarterly exit report. Count the themes that point at a specific team or manager. If the answer is none, the themes have been over-aggregated. The fix is to cut the same data by team before the next report, and let the team-level picture write itself.
Could your most senior executive repeat the most important theme back to you tomorrow? If the theme is "career progression", no. If the theme is "the platform team has lost two seniors to a competitor in six months and both cited the same blocked promotion", yes. The test is whether the theme survives being said in a sentence to a person who has not read the report.
Is your report cut deep enough to act on, and not so deep that it identifies someone? A team of six is a reporting hazard. A team of forty is fine. The honest test is whether pointing at the team in an open meeting would be unfair to the people still in it. If yes, the data stays in HR. If no, the cut is the right one.
Do the notes from two years ago still make sense to you today? Read three notes at random from the oldest quarter in your folder. If the language, the team names and the projects are still legible, the data has aged well. If not, the data has a shelf life, and the report should be re-cut on a rolling twelve months rather than the whole history.
Have you ever changed a decision because of one of these reports? Be honest. If the answer is no, the report is being read as a ritual. The fix isn't to write a better report. The fix is to ask the executive what they would change based on a finding, and to find out what shape of finding would actually move them. Then write that shape.
Six Ways to Turn Notes Into Something Actionable
Free-text thematic coding
A person reads each note in full, tags it with a label that fits the content, and resolves overlaps by judgement. Two notes about a manager who blocked a transfer end up under the same label, even if one says "management" and the other says "career". The strength is that the label can be as specific as the evidence allows. The weakness is the dependency on the reader. The same notes, coded by a different person, will produce different labels, and a handover breaks the time series. This works when the exits are few enough to read in full and the coder has been in role across the period being reported. It fails when the volume rises or the role changes, because the next coder will reach a different shape.
A fixed taxonomy applied at the interview
A short list of categories, agreed in advance, that the interviewer ticks from during the conversation. The strength is comparability across quarters and across interviewers. The same word means the same thing in July and in January. The weakness is the taxonomy itself. A taxonomy written before the exits happen will misclassify the most interesting ones. The leaver who quit over a blocked transfer is forced into a generic category, and the actual story is lost. This works when the leadership wants a stable comparable number that survives personnel changes. It fails when the leadership then stops reading the free text under each tick.
Cutting by team and manager
The notes themselves aren't re-coded. The same data is sliced by team, and within team, by manager. The strength is that this is usually where the actionable signal lives. "The platform team has lost three seniors in twelve months" is a finding. "Career progression" isn't. The weakness is the team-size hazard. A cut at team level in a team of six can name a manager by implication, which is a real exposure if the leaver requests their notes under local personal data rules. This works when the teams are large enough that pointing at one doesn't identify an individual, and when the leadership has a way to act on a specific team. It fails when teams are too small to report on safely, or when the leadership has no standing in the team's people decisions.
Cutting by tenure band
The same notes sliced by how long the leaver had been in role. Under twelve months, twelve to twenty-four, twenty-four to sixty, over sixty. The strength is that tenure usually tracks the actual problem. A cluster of exits at month ten usually points at onboarding or first-year management. A cluster at month thirty usually points at the second promotion that never came. The weakness is that tenure only matters if the notes are detailed enough to support it. A note that says "left for a new opportunity" can't be cut by tenure, because there's nothing to explain the timing. This works when the notes contain enough detail about what the leaver was doing in their final months, and when the business has different interventions for different tenure bands. It fails when the notes are too thin, or when the business treats tenure as a proxy for something it doesn't actually measure.
Pairing exit reasons with regretted-attrition status
The reason given in the exit note, tagged with whether the manager or the business would have preferred to keep the leaver. The strength is that it forces the conversation past what the leaver said and into what the business actually lost. A cluster of regretted exits citing the same blocked promotion is a different finding from a cluster of unregretted exits citing the same reason. The weakness is that regretted-attrition is a judgement, and the judgement is made by the manager who is often the cause of the exit. This works when the regret judgement is made by someone other than the line manager, or by a panel. It fails when the manager is both the source of the problem and the one deciding whether the leaver was regrettable, because the data will flatter the manager every time.
Triangulating against engagement or recruitment data
The exit themes read alongside what the engagement survey said twelve months earlier and what the recruitment team is hearing from declined offers. The strength is that the same story starts to appear in three places. A manager who is named in two exit notes, has a low score in the engagement survey among their team, and whose open roles are taking twice as long to fill is a finding that will stand up. The weakness is that triangulation requires all three datasets to exist and to be linkable. Many firms have none, or have them in silos. This works when the data is already being collected for other reasons, and when someone has the authority to link it. It fails when the datasets don't exist, or when the linking itself creates a privacy question that nobody has thought through.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Stable team, occasional exit | Under 50 | One shared note per exit, kept by the line manager | None worth fixing | Stay where you are. Build nothing. |
| Growing firm, exits starting to cluster | 50 to 200 | Free-text notes in a shared folder, no aggregation | Themes being drawn too high to act on | Re-cut the existing notes by team and tenure before writing a new one |
| Multi-team firm, exit data exists but never lands | 200 to 1,000 | Aggregated report delivered quarterly, ignored | Themes arriving at the executive meeting already abstracted past action | Free-text coding by a single person, with the report cut by team |
| Firm needing comparability across years | 500 plus | Different HR leads, exits every quarter | Themes shifting with the coder | Fixed taxonomy applied at the interview, with free text preserved |
| Small specialist team, recent disputed exit | Under 50, single team | Notes held by HR, identifying risk | Reporting on the data would identify the leaver or the manager | Hold the data in HR. Do not publish a theme. Confirm the local position. |
| Multiple signals pointing at one manager | 200 plus, named manager | Exit notes, engagement data, slow hiring all converge | No current mechanism to act | Triangulate, then deliver the finding to the manager's manager with a concrete ask |
| Firm with rich notes, no taxonomy | 500 plus | Two years of detailed free text, no labels | Themes have to be drawn but cannot be drawn consistently | Code the last four quarters in full, then build the taxonomy from the codes that recur |
| Regulated environment, exit data is personal data | Any | Local rules on disclosure apply | A report that names an individual in a small team | Cut only at a level where identification is not a risk. Confirm locally. |
Building a Taxonomy That Survives Contact
A taxonomy is a promise. You're telling the leadership that the same word will mean the same thing next quarter, and the quarter after, and that any change in the number is a change in the business, not in the labels. The categories that survive are the ones tied to something the business can act on. "Manager behaviour" survives because there's a manager development programme to point at. "Compensation below market" survives because there's a benchmarking cycle. "Career progression" doesn't survive, because the leadership has no single intervention called progression and the category will end up holding everything from a blocked promotion to a bad reorg.
| Category | Survives a year? | Reason it holds or collapses |
|---|---|---|
| Manager behaviour | Usually yes | There is a discrete intervention (coaching, performance plan) and a named person to point at |
| Compensation below market | Usually yes | There is a benchmarking cycle and a pay review process |
| Career progression | Often collapses | Becomes the dustbin for blocked promotions, bad reorgs and unclear expectations |
| Workload | Sometimes | Holds when the team size is known and the workload is measurable; collapses when it becomes a synonym for "too much" |
| Culture | Often collapses | Means different things to the coder and the executive; usually needs to be cut further |
| Lack of flexibility | Usually yes | Tied to a policy decision the business can change |
| Reorg instability | Usually yes | Tied to a specific business event the leadership remembers |
The temptation is to start with the taxonomy and code backwards. Resist it. Code a quarter of notes in full, see what labels emerge, and only then write the taxonomy from the codes that recur. A taxonomy built this way matches the data the business has, not the data the textbook says it should have.
Presenting It to People Who Can Change Something
The format that gets a decision is the one that hands the executive something to do. A slide that says "career progression" hands them nothing. A slide that says "the platform team has lost three of seven senior engineers in the last year, two of them citing the same blocked promotion, and the team's engagement score has dropped in the same window" hands them a meeting. The shape is the same in both cases. The granularity is different, and the granularity is the whole job.
| Element of the report | What most reports do | What a report that lands does |
|---|---|---|
| Theme | "Career progression" | "Three senior engineers in the platform team, blocked promotion cited in two of three notes" |
| Volume | "A percentage with no denominator" | "Three exits from a team of seven in twelve months" |
| Comparison | None, or a benchmark the executive does not recognise | Same team, same period last year, plus the engagement trend |
| Recommendation | None, or a generic one | One ask, with a named owner and a date |
| Follow-up | None specified | A specific check at the next review, on a specific signal |
The report should fit on one page. The exec should be able to read it in three minutes. The ask should be the only sentence on the page that starts with a verb. If the report runs to a deck, it has already failed, because nobody will read past slide three.
What to Put in Writing
A decision that lives only in someone's head is a decision that will be relit every quarter. The artefacts below are what turn the work into something the next HR lead can pick up without starting over.
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| Exit interview notes (original) | HR or the interviewer named in the policy | Within five working days of the exit conversation | Loss of detail, drift between what was said and what was reported |
| Coded version of the notes | The person doing the coding | Quarterly, after the coding window closes | Disputes about what category a note sits in |
| Taxonomy definition, with examples | The HR lead | Once a year, before the coding window opens | The same word meaning different things across quarters |
| Cut of the data by team and tenure | The HR lead | Quarterly, before the executive review | Themes drawn at a level too high to act on |
| The report itself | The HR lead | Before the executive meeting | The next quarter starting without a record of what was discussed |
| The executive's response to the report | The executive's office, copied to HR | Within ten working days of the meeting | The same finding being relit three quarters later |
| Record of any action taken on a named team or manager | The relevant people lead | When the action is agreed | The action drifting because nobody owns it |
| Note of any cut withheld for identification risk | The HR lead | When the cut is considered | A well-intentioned report identifying someone in a small team |
| Local compliance confirmation for the reporting approach | The HR lead, with internal review | At least once a year | A report shape that exposes the business under local personal data rules |
| The taxonomy version history | The HR lead | When the taxonomy is changed | A trend line that breaks because the labels moved under the data |
Questions to Ask Before You Commit
On the data you already have. Ask your team: how many of these notes would still make sense to a reader who joined last week? A bad answer is "we would have to ask around". The notes should be legible on their own, with team names, dates and enough context that a new HR lead can pick them up without a handover.
On the taxonomy. Ask the team: if I picked three notes at random from last year and three from this year, would the labels mean the same thing? A bad answer is "mostly". The whole point of a taxonomy is that the labels are stable. If they drift, the trend line is meaningless.
On the cuts. Ask the team: at what level can we cut this data without identifying someone in a small team? A bad answer is "we've not thought about it". The shape of the exposure is real, and the question deserves an answer before the next report is built, not after it's challenged.
On the executive meeting. Ask the executive's office: if the next report named a team, a practice and a manager, what would you actually do with it? A bad answer is silence. The point of the report is to enable a decision. If the executive can't describe the decision, the report will be received as a ritual regardless of how good the data is.
On the writing of the report. Ask the team: who writes the slide, and how long do they have? A bad answer is "the night before". A report built under time pressure reverts to abstraction, because abstraction is faster. The coding should be done before the slide is built, and the slide should be built with time to spare.
On the action. Ask the team: when an action is agreed, who owns it, and when do we check it worked? A bad answer is "we'll see how it goes". Every action in the meeting should leave with an owner, a date and a signal that would tell you it had worked.
On the retention of the data. Ask whoever owns the policy: how long do we keep these notes, and what is the rule for letting the leaver see them? A bad answer is "we've not looked at it". Local rules on personal data and on the retention of employee records vary, and the shape of the exposure should be confirmed before the next report is filed.
On the connection to other datasets. Ask the team: can we link this to the engagement data and the recruitment data without creating a new privacy question? A bad answer is "we'd have to ask IT". Triangulation is where the strongest findings come from, but it's also where the most care is needed. The link should be designed, not improvised.
The Cost of Getting This Wrong
The cost that appears on no invoice is the leaver who reads the report. Not the current leaver, who has left and isn't watching. The next one. A strong performer in a team that has lost three people in a year, who goes looking for the exit report because they want to know if their own concerns have been heard, and finds a slide that says "career progression" with no mention of the team they sit in. That person is now making a decision about whether to stay, and the report has just answered it for them. The cost isn't the slide. The cost is the second departure, six months later, that the report was meant to prevent.
The other cost is the executive who stops reading. An executive who has sat through four quarterly exit reports that all said "management" and "progression" without naming a team has learned that the report is a ritual. The next report, even if it's the first good one, will be received with the same nod and the same adjournment. The cost is the credibility of the next person in the role, who will have to spend their first two quarters rebuilding a muscle the previous one let atrophy. So the question isn't whether this report can afford to be vague. The question is whether the next report, the one that finally has something to say, will be read.
When You Are Ready to Go Further
If the diagnostic questions above suggested that the gap is in presentation rather than collection, and the data on the drive is richer than the slides suggest, the next move is usually a structured re-cut by team and tenure, with a single-page report that hands the executive a specific ask. That work doesn't need a platform. It needs a quiet quarter, a taxonomy built from the codes that already recur, and a willingness to report fewer themes at a depth that will survive being pointed at a specific manager.
HROpsLab is a review publication. We don't sell software, payroll or advice, and we don't supply the people to run the re-cut. What we do publish, on an ongoing basis, is independent comparison of the tools that claim to solve this kind of problem, written for the reader who has already decided what the question is. If the question above has moved from "should we build this" to "what does the rest of the market say", our comparison work is the place to start.
Frequently Asked Questions
How many exits do I need before a theme is real?
A theme is a hypothesis until it has survived a second cut of the data, and a finding only when the same shape appears in more than one quarter. Four exits in a team of eighty is a signal worth investigating, not a finding worth presenting. The honest move at small volumes is to report the cut, name the team, and frame the next quarter as the test that will confirm or kill the pattern.
Should I code the free text or use a fixed taxonomy?
Both, and in that order. Code a quarter of free text in full first, build the taxonomy from the codes that actually recur, and then apply the taxonomy going forward. A taxonomy written before the data has been read will misclassify the most interesting notes. The free text stays as the source of truth under the tick boxes, because the leadership will sometimes want to read it.
Who should see the exit data?
The HR lead who codes it, the executive who can act on a team-level finding, and the manager of the team in question once an action is agreed. The leaver themselves, on request, under the local personal data rules. Beyond that, the data is read by people who can't act on it, and the report becomes a document that travels rather than a decision that lands.
How do I report on a small team without identifying someone?
Don't cut at a level where pointing at the team names the manager or the leaver. If the team is too small to report on safely, the data stays in HR and the report either covers a larger aggregate or skips that team for the quarter. Confirm the local position before the cut leaves HR. The shape of the exposure is that a report naming an individual in a small team can identify them, even without a name on the page.
How often should I review the data?
Re-run the cuts after every exit, and present a full report once a quarter. The re-runs are cheap if the coding is already done, and they catch a pattern while it's still a single quarter. The quarterly report is for the executive meeting, not for HR. The two should not be confused.
What do I do when the data blames one manager?
Take it to the manager's manager first, with the specific notes and a specific ask. Don't surface it in the open executive meeting on the first pass. The manager may already know, may have acted, or may have a context the notes don't capture. If the pattern persists across two quarters and the manager has not acted, the conversation moves up. The data isn't a verdict. It's the start of a process.
How do I combine exit data with engagement or recruitment data?
Link them at team level, not at individual level, and only where the local rules permit. The same team appearing as a hotspot in exits, in engagement, and in slow hiring is a finding that will stand up in a meeting that any one of them alone wouldn't. The link should be designed, not improvised, and the privacy question should be answered before the link is built rather than after it's challenged.
HROpsLab publishes independent, no-software comparison for HR teams who already know what they're trying to decide.
