Predicting Employee Attrition Responsibly

The tempting version and the responsible one

Replacing an experienced employee commonly costs a sizeable share of their annual salary once recruitment, onboarding and lost productivity are counted. So the pitch for attrition prediction is easy to make: a dashboard listing every employee with a percentage chance of resigning, so managers can step in before the notice letter arrives.

We are wary of that version. A named flight-risk score is personal data about someone's future, generated without their knowledge, and it can quietly change how they are treated: passed over for a project, left out of a promotion round, managed out before they had any intention of leaving. The responsible version asks a different question: which parts of the organisation are losing people, and what do they have in common?

What the data usually shows

Attrition models built on ordinary HR data tend to rediscover causes that managers half-know already, but with the benefit of numbers attached.

• Pay that has fallen behind the market for a role, especially after two years without a meaningful rise
• A manager whose teams lose people at well above the company rate
• Long stretches in the same grade without promotion or a change of work
• Commutes lengthened by an office move or a change in hybrid policy
• Heavy overtime or on-call load concentrated in a few people
• A poor first 90 days, visible in early leavers from particular hiring channels

None of these need a sophisticated model to find. What the model adds is the ability to separate effects, such as whether a department loses people because of its manager or because it is also the lowest-paid team.

The legal and ethical lines

Employee data is among the most sensitive data a business holds, and the law treats it that way.

This is not legal advice, and any business considering attrition modelling should involve its employment lawyers and staff representatives early. Our post on what is allowed with AI in HR covers the wider picture.

A safer design we are happy to build

1. Model attrition at group level: team, role, location, tenure band. Suppress any group small enough to identify individuals
2. Report the drivers, not the names: which factors are associated with higher leaving rates, and by how much
3. Tell employees what is being analysed and why, in plain language
4. Exclude protected characteristics and test outputs for disparities across them
5. Use results to change policy (pay bands, workload, manager training), never to act against an individual
6. Review the analysis with HR, legal and staff representatives before anything is shared with line managers

In this form, attrition analysis looks more like workforce planning than surveillance, and it still produces the thing leaders want: early warning that a part of the business is about to lose people.

An illustrative example

Consider a 500-person logistics firm with warehouse, driver and office roles across six sites. Annual turnover is high in warehouses, which everyone expects. A group-level model might show that turnover at two sites is much higher than at the other four, and that the difference disappears once shift pattern is accounted for: sites that moved to rotating nights lose people at twice the rate. The fix is a scheduling conversation, not a list of names.

The example is invented, but the pattern, where an operational policy explains more than any individual trait, turns up in almost every real workforce analysis we have seen.

When not to do this at all

Small companies should not model attrition. With 40 staff, any 'group' is a handful of identifiable people, and a manager having honest one-to-ones will learn more. Nor should the analysis go ahead where HR data is sparse or inconsistent, since conclusions drawn from bad data about people do real harm.

And if the organisation's intent is to identify and remove likely leavers before they resign, we will decline the work. That is not a model problem to engineer around.

How we approach it

At SpiderHunts, workforce analytics projects start with a scoping session that includes HR and someone responsible for data protection, before any data moves. The build itself is modest: a secure analysis environment, a group-level model with suppression rules, and reports that explain drivers in plain terms. Our data science team treats the documentation and impact assessment as deliverables, not paperwork.

If the business is also facing change driven by automation, our guide to managing AI-driven workforce change is a useful companion, since uncertainty about roles is itself a common cause of people leaving.

Frequently asked questions