Flight Risk Prediction: The COO's Case for Six Months' Notice
Most flight-risk programmes die the same way. A model produces a score; the score arrives in a report; the report is read once; nothing moves. The failure is rarely the model. It is the absence of a protocol — nobody named, no date set, no decision written down.
What follows is not an argument for prediction, and not a case for a retention budget. It is the operating manual: who does what, when, on which signal, and what gets recorded.
Scope: which roles this protocol covers
This protocol covers roles whose departure would move a delivery date. Not every role, and not every resignation. Define the list once, keep it short — a handful of critical programmes, each depending on a small number of named people — and rebuild it quarterly. Everything below assumes that list exists. If it does not exist, the first work is to produce it, not to buy a model.
The evidence base, and the boundary that comes with it
This protocol rests on one external piece of evidence, and its limits.
A 2026 study in Scientific Reports reported a hybrid machine-learning model reaching 91.44% accuracy with an AUC of 0.973 on employee turnover prediction (Scientific Reports, 2026). Two facts about that result decide how it may be used.
First, it is a result on a structured historical dataset. The model learns patterns that were already recorded, cleaned and labelled in a specific organisation's past. Second, it is not a statement about an individual. Strong performance on a historical dataset does not mean the model will name, in advance, which specific employee will hand in notice next quarter. Your organisation's own history is smaller than the dataset in the paper, and its patterns are noisier.
So the operating rule is fixed from the start: the model is a filter for attention, never a verdict. It ranks where to look. It does not decide who leaves. Any protocol that treats a score as an outcome has skipped the only step that produces a result.
That honesty is the point of the protocol, not a caveat bolted onto it. A tool that promises individual prediction gets used once, disappoints, and is abandoned. A tool that reliably narrows the field keeps working, because its output is actionable even when it is wrong.
Roles: who does what
Four named roles. If any are unfilled, the protocol is not running.
Programme owner (delivery lead): names the dependency each critical programme carries, and keeps that list current.
People lead (HR partner): owns the cadence, maintains the exposed-role list, and records the decisions.
Reviewer (COO or equivalent): chairs the monthly review, chooses between the three options, and signs the record.
Validator (a colleague who has seen the work): supplies first-hand evidence about whether a named person can do the target role.
The validator is not a formality. It separates a decision from a guess.
The calendar
The calendar is the product. A score without a horizon changes nothing; the horizon is what buys options.
Monthly — 60 minutes, standing item. Flight risk sits in the same review where capacity and delivery are discussed, not in a separate HR meeting. Take the exposed roles, name the dependency each one carries, and record one decision per role: defend, redeploy or restructure. One page. Signed by the reviewer. The same slot every month.
Quarterly — half a day. Rebuild the exposure list: which programmes now depend on too few people, and which dependencies can be designed out entirely.
Annually. Review the protocol itself against outcomes: did the recorded decisions hold, and did the calendar keep producing decisions?
The horizon is set deliberately at six to twelve months, not next month. A three-month warning is generally enough to start a search and little else. Six to twelve months is the minimum window in which more than one option exists: test an internal replacement, move the person onto work that re-engages them, or remove the dependency so the exit no longer threatens delivery. Only the first of those three fits on a short clock. The forecast horizon — not the probability score — is what determines whether a signal protects delivery.
The signal ladder
Define in advance what each signal triggers. Ambiguity here is what turns a control into a dashboard.
Signal 1 — an exposed role with no validated internal successor: open a capability review at the next monthly meeting.
Signal 2 — a named role flagged as elevated risk in two consecutive months: the people lead schedules a retention conversation and records the date.
Signal 3 — a dependency confirmed to be concentrated in one person whose exit would move a delivery date: the reviewer chooses one of the three decisions within the month, in writing.
Signal 4 — an internal move offered on a score alone, with no first-hand evidence of fit: the move stops until a validator has seen the work.
Signal 4 is the rule most often skipped, and the one that does the most damage. A redeployment based on a score alone is a guess wearing a decision's paperwork.
The three decisions
Every exposed role leaves the review with exactly one record.
Defend — invest in keeping the person. Name an owner, and set a date to check whether it worked.
Redeploy — move the person to a role that fits, subject to the validation rule above.
Restructure — redesign the dependency so that this person's exit no longer threatens delivery.
The choice is rarely about preference. In a market as tight as Singapore's, recruiting and restructuring compete for the same budget and the same management attention: a search is visible, slow, and priced by whatever the market is asking; a restructure is largely invisible, often faster, and requires someone to own a design decision rather than a hiring decision. The protocol forces that comparison into a dated record instead of letting it default to the search.
Measuring whether the protocol works
Measure the decisions, not the model. Three questions, answered at the quarterly review:
Of the roles recorded as defended, how many stayed through the following two quarters?
Of the roles restructured, did the delivery date hold?
Of the internal moves made, how many cleared the validation rule before the move?
If the answer to the third is "not all of them", the protocol is producing activity rather than control. No accuracy figure — including 91.44% (Scientific Reports, 2026) — compensates for a decision made without evidence.
Start Monday
Three gestures, in order, each finishable this week.
Name the list. Write down the programmes whose delivery date you could not absorb a surprise exit on, and beside each one, the named people it depends on. If producing that list takes more than an hour, the exposure is larger than the list.
Name the owner and the slot. Put the exposure list into the next standing operations review, with one named reviewer and one fixed monthly slot. A protocol without a chairperson and a date does not exist.
Write the first record. Take the single most exposed role and record, in one line, which decision you are taking — defend, redeploy or restructure — and by when you will check it. One line, dated, signed.
Then repeat monthly. The value was never in the first score. It is in the calendar that keeps producing decisions.
Frequently asked questions
Can a model predict which employee will resign?
No, and a protocol built on that expectation fails. Strong performance on a historical dataset, such as the 91.44% accuracy reported in Scientific Reports (2026), is a result about patterns already recorded in the past. It is not a statement about an individual. The model is a filter for attention, never a verdict: it ranks where to look, it does not decide who leaves.
Why six to twelve months of notice rather than next quarter?
Because that is the minimum window in which more than one option exists: test an internal replacement, move the person onto work that re-engages them, or remove the dependency so the exit no longer threatens delivery. Only the first of those three fits on a short clock. The forecast horizon, not the probability score, is what protects delivery.
Which roles does the protocol cover?
Only the roles whose departure would move a delivery date: a handful of critical programmes, each depending on a small number of named people. Keep the list short, rebuild it quarterly, and do not buy a model before the list exists.
What do we do with a score once we have it?
Follow the signal ladder defined in advance. Every exposed role should leave the quarterly review with exactly one record, dated, and a named owner. A redeployment based on a score alone is a guess wearing a decision's paperwork.
How do we know the protocol is working?
Measure the decisions, not the model. If not every exposed role leaves the review with a decision, the protocol is producing activity rather than control. No accuracy figure compensates for a decision made without evidence.
Comments