If your organisation is deploying a machine learning algorithm to predict customer churn while your senior engineers are updating their CVs, you haven't solved a retention problem — you've automated the wrong one. The customers leaving are a symptom. The engineers leaving are the cause. And no gradient boosting model is going to tell you that your Head of Platform Architecture handed in their notice because your CTO interrupted them in three consecutive all-hands meetings.
This is, unfortunately, not a hypothetical. It is a pattern I have watched repeat itself across organisations with depressing regularity — and I say that as someone who has spent over two decades helping organisations actually deliver digital transformation, rather than just announce it.
Why Do Organisations Build Churn Models Before Fixing Their Own Culture?
The honest answer is that predicting customer churn feels like strategy. It has a clean brief, a measurable output, a vendor who will sell you the platform, and a slide you can show the board. It is the kind of initiative that gets a name, a Gantt chart, and a launch event with branded lanyards.
Addressing toxic management, on the other hand, requires someone to look a senior leader in the eye and say something uncomfortable. There is no lanyard for that. There is not even a decent PowerPoint template.
According to Gallup's State of the Global Workplace report, managers account for at least 70% of the variance in employee engagement scores. Seventy percent. And yet the average organisation's response to rising attrition is to commission an engagement survey, wait four months for the results, and then hold a workshop about the results of the survey. The engineers, meanwhile, have already left.
Is This Actually a Technology Problem or a Leadership Problem?
It is a leadership problem wearing a technology hat. The decision to invest in a customer churn prediction model is not inherently wrong — churn prediction is a legitimate and valuable application of machine learning (ML). The problem is the sequencing, and the selective blindness that allows a leadership team to look at a dashboard of customer health scores while ignoring the fact that three of their most experienced engineers left in the same quarter.
I have sat in steering committees where someone has presented a sophisticated propensity-to-churn model with confidence intervals and feature importance rankings, and the room has nodded approvingly. Nobody asked who built it. Nobody asked what would happen when those people left. The model was the star. The humans were the set dressing.
What Does "Toxic Management" Actually Do to an Engineering Team?
Toxic management in engineering contexts is not always dramatic. It rarely involves shouting or obvious cruelty. More often it looks like: credit being claimed upwards and blame being distributed downwards; technical decisions being overridden without explanation; psychological safety being low enough that nobody flags the architectural debt until it becomes a production incident.
The result is not a sudden walkout. It is a slow, quiet withdrawal of discretionary effort. The engineers stop raising problems. They stop suggesting improvements. They start doing exactly what is asked of them — nothing more — and they begin, quietly, to explore their options.
By the time the first resignation letter lands, the knowledge transfer has already happened: out of the door, into someone else's Slack workspace.
What Does the Research Say About Engineering Attrition?
A McKinsey study on attrition found that the top driver of employee departure was not compensation — it was feeling that their work was not valued by the organisation. For senior engineers specifically, this tends to manifest as being excluded from architectural decisions, having their technical judgement overridden by non-technical managers, or watching a roadmap get reprioritised around a shiny new AI initiative that nobody consulted them about.
Stack Overflow's 2023 Developer Survey — which surveyed over 90,000 developers globally — found that the top factors influencing job decisions included learning opportunities, flexibility, and management quality. Salary ranked fifth. Your engineers are not leaving for money. They are leaving because someone is making their working life unnecessarily difficult.
What Is the Real Cost of Losing Senior Engineering Talent?
This is where the numbers become genuinely uncomfortable. The cost of replacing a senior engineer is typically estimated at 1.5x to 2x their annual salary when you factor in recruitment fees, onboarding time, productivity lag, and the institutional knowledge that walks out with them. That figure comes from research by the Society for Human Resource Management (SHRM).
But the salary multiplier is almost certainly an undercount for senior engineers in specialised domains — particularly those who have been maintaining systems for years and whose knowledge exists nowhere except their own heads. When they leave, you are not losing a resource. You are losing institutional memory, technical judgement, and the invisible scaffolding that holds your systems together.
How Does Engineering Attrition Affect the AI Programme Specifically?
Here is the specific irony that should keep a CTO awake at night. The people most likely to leave due to toxic management are the people most qualified to build, maintain, and govern your AI systems. Senior engineers with the experience to implement a churn prediction model responsibly — to interrogate its assumptions, monitor its drift, manage its edge cases — are exactly the people who have other options and will exercise them when the culture becomes intolerable.
What you are left with, if you are fortunate, is a model that works. What you do not have is anyone who fully understands why it works, what it will do when the underlying data distribution shifts, or how to explain its outputs to a regulator. You have launched the rocket and let the engineers go home.
The Comparison You Should Be Making Before You Commission the AI Project
| Factor | Customer Churn Prediction Model | Senior Engineering Attrition |
|---|---|---|
| Visibility to leadership | High — dashboard, KPIs, board slides | Low — treated as an HR metric, rarely escalated |
| Cost of the problem | Revenue loss from departing customers | 1.5–2x salary per departure, plus knowledge loss |
| Time to detect | Near real-time with the model in place | Often detected only at resignation — months too late |
| Root cause | Product-market fit, pricing, competitor activity, service quality | Management behaviour, psychological safety, lack of autonomy |
| Addressability | Moderate — many external factors beyond direct control | High — management behaviour is an internal controllable |
| Who owns the solution | Data science, product, marketing | Senior leadership — and this is why it often goes unaddressed |
| Typical organisational response | Commission a model, celebrate the launch | Run an engagement survey, hold a workshop, repeat |
| Likelihood of solving the actual problem | Medium — if well-maintained and acted upon | Low — until someone in leadership is held accountable |
Should You Actually Build the Customer Churn Model?
Yes — but not yet, and not like this. A well-implemented churn prediction model is genuinely valuable. The academic and commercial evidence for its effectiveness is solid. A logistic regression, a random forest, or a gradient boosting model trained on behavioural, transactional, and engagement data can give your commercial teams meaningful early warning signals that drive real retention outcomes.
The question is not whether to build it. The question is whether you have the organisational conditions to build it well, maintain it properly, and act on its outputs effectively. And if your senior engineering team is haemorrhaging, the answer to that question is probably no.
What Should Come First?
In my experience — and I have been part of enough programmes to have opinions on this that are grounded rather than theoretical — the sequencing matters enormously. Here is a more honest order of operations:
- Audit your management culture honestly. Not with an anonymous survey that produces a heatmap nobody acts on. With actual conversations, exit interview analysis, and — if necessary — external facilitation. This means senior leaders being willing to hear things they will find uncomfortable.
- Stabilise the engineering team. Identify who is at flight risk. Not through a predictive model — through their managers actually talking to them. Understand what would change their calculus. Act on it where you can.
- Define what "good" looks like for the AI programme. Not a launch date. Not a model accuracy metric. A clear articulation of the business decision you are trying to improve and how you will know if the model is actually helping.
- Build the technical foundations. Clean, governed, accessible data. Clear ownership of model monitoring and maintenance. A process for acting on the model's outputs that does not require a data scientist in every commercial conversation.
- Launch the model — and keep watching the humans. The model will drift. The business context will change. You need people who care enough and know enough to notice when it starts making bad recommendations.
What Does Good AI Governance Look Like When Your People Are the Risk?
AI governance frameworks tend to focus on model risk — bias, fairness, explainability, data quality. These are legitimate concerns and I am not dismissing them. But there is a governance risk that rarely appears in a model card: the risk that the people who understand the system well enough to govern it have left.
The UK Government's AI Ethics Guidelines and the EU AI Act both emphasise the importance of human oversight in AI systems. Human oversight requires humans. Specifically, it requires humans who understand the system, who feel empowered to raise concerns, and who trust that their concerns will be heard. None of those conditions exist in a team managed through fear or neglect.
Can You Use AI to Predict Engineering Attrition Instead?
You can. People analytics platforms now offer attrition prediction models for employees as well as customers. Some organisations have deployed these with reasonable results. But I would urge caution here, not because the technology is unsound, but because there is something troubling about an organisation that would rather build a model to predict when its engineers will leave than address the conditions making them want to leave in the first place.
It is a bit like fitting a carbon monoxide detector in a room you have already filled with carbon monoxide. Technically impressive. Not really the point.
What Should Leadership Actually Do Differently?
I am going to resist the urge to give you a five-point framework here, because five-point frameworks are how organisations make themselves feel like they are solving problems without actually solving them. Instead, three things that I have seen make a genuine difference:
- Make engineering attrition a board-level metric, not just an HR metric. If your board reviews customer churn monthly and engineering attrition quarterly (if at all), you have already told your organisation what matters. Fix the reporting cadence.
- Hold managers accountable for team health, not just delivery. Output metrics without input metrics are how you get teams that deliver once and then dissolve. Psychological safety, 1-1 quality, internal promotion rates — these are manageable and measurable if you choose to measure them.
- Create actual consequences for toxic management behaviour. Not a coaching conversation. Not a note on a file. If a manager is consistently losing good people, that is a performance issue. Treat it as one.
Frequently Asked Questions
What is customer churn prediction and how does it work?
Customer churn prediction is the use of machine learning models to identify customers who are likely to stop using a product or service before they actually do. These models are typically trained on historical behavioural data — login frequency, feature usage, support ticket volume, payment history — and produce a probability score for each customer. The commercial team then uses those scores to prioritise retention interventions. Common algorithms include logistic regression, random forests, and gradient boosting methods such as XGBoost.
How much does it cost to replace a senior software engineer?
Research from SHRM and others consistently estimates replacement costs at 1.5x to 2x annual salary for experienced technical roles. For senior engineers in specialised domains — machine learning, cloud infrastructure, security — that figure can be higher when you account for extended vacancy periods, contractor costs to cover the gap, and the time it takes a replacement to reach equivalent productivity. The knowledge that leaves with them is rarely captured in that estimate.
Is toxic management really that common in technology organisations?
Common enough that it has its own genre of conference talk, its own section in every developer survey, and its own dedicated subreddit. More formally: Gallup's research suggests that only around 23% of employees globally are engaged at work, with management quality being the single largest controllable driver of that figure. Technology organisations are not immune — and in some respects, the culture of moving fast and rewarding individual technical brilliance over people leadership can make them more susceptible.
Can you use AI to detect or predict employee attrition?
Yes, and several platforms offer this capability. People analytics tools such as Visier, Workday People Analytics, and Microsoft Viva Insights can surface attrition risk signals based on behavioural data including calendar patterns, collaboration network changes, and sentiment from communication metadata. These tools can be useful for surfacing early warning signals — but they do not address the underlying causes, and there are legitimate ethical questions about employee surveillance that need to be worked through carefully before deployment.
What is the relationship between psychological safety and AI programme success?
Psychological safety — the belief that one can speak up without fear of punishment or humiliation, as defined by Harvard researcher Amy Edmondson — is one of the strongest predictors of team performance in complex, uncertain environments. AI programmes are complex and uncertain by definition. Teams with low psychological safety are less likely to flag when a model is producing suspicious outputs, less likely to raise concerns about data quality, and less likely to push back on unrealistic expectations. The correlation between team health and AI programme outcomes is not coincidental.
How do I make the case to leadership that engineering attrition is a higher priority than the AI project?
Translate it into the language leadership already uses. Calculate the cost of the attrition you have already experienced — replacement costs, productivity lag, project delays — and compare it to the projected value of the AI initiative. Then ask the question that tends to land: "Who is going to build and maintain this system in eighteen months if the current trajectory continues?" The answer to that question usually focuses the conversation.
What are the warning signs that a technology team is approaching a cultural breaking point?
In rough order of severity: declining participation in optional activities (retrospectives, knowledge sharing, team events); increasing time-to-respond in internal communications; senior engineers stopping to volunteer opinions in design reviews; a cluster of LinkedIn profile updates; and the moment when someone who has never been cynical starts making dark jokes about the roadmap. By the time you have an official resignation, you are typically six to twelve months behind the actual problem.
Nicholas Hodder is a digital transformation and technology leader with over 20 years of experience delivering programmes across the public, private, and third sectors. He is also a professional speaker and stand-up comedian — which, it turns out, is reasonable preparation for explaining to a board why their AI strategy needs to start with a conversation about management behaviour rather than a model architecture decision. He writes about the gap between technology strategy and organisational reality, with occasional jokes.