People Health Monitor: Catch Attrition With 4 Weak Signals, Not One Dashboard

Your strongest engineer's commit messages collapsed from prose to fragments three weeks ago. PR review turnaround drifted from four hours to two days. Optional meetings stopped getting accepted. Jira updates slid from early Monday to late Friday, then dropped off entirely on tasks already in flight.

Any one of those is noise. Short commits happen. Slow review weeks happen. Four independent systems drifting the same direction, on the same person, inside the same three-week window — that is not noise. That is a pattern that predicts voluntary departure at an accuracy rate nobody wants to be right about.

This is not a monitoring problem. It is a correlation problem. The line between an early-warning system managers trust and surveillance theater employees route around runs through three decisions: what you measure, what you refuse to measure, and what the system is permitted to say to whom.

Most people-analytics platforms repeat the same architectural mistake. Track one variable per person. Set a threshold. Fire an alert when it crosses. Commit frequency drops below X — flag. Meeting attendance falls below Y — flag. The alert lands in someone's inbox. The someone learns, inside a fortnight, that the alerts are wrong four times in ten.

The dashboard goes unread by week three. A 2025 study from Frontiers in Big Data^[2] put the false-positive rate of single-variable attrition models above 40% in engineering populations — varying with org size, role mix, and baseline cleanliness. The mechanism is mundane. People have off weeks. They take leave. They sit inside a design doc for ten days instead of shipping code. None of those are pre-resignation patterns. All of them trip a single-metric threshold.

The fix is not a better threshold. It is a different question. Stop asking is this one metric bad? Start asking are multiple independent metrics drifting the same direction for the same person at the same time? That correlation is the load-bearing variable. Single-metric systems treat noise as data. Composite systems use noise as a filter.

The cost of getting this wrong is not just wasted engineering time. Gallup's 2025 State of the Global Workplace report put disengagement's economic cost at $438 billion in lost productivity worldwide in 2024 alone — and that figure only captures the employees who stayed^[7]. Voluntary departures in engineering compound the damage: replacement costs for a senior software engineer run 80–130% of annual salary once you account for recruiting, onboarding lag, and the institutional knowledge that walks out the door^[8].

The reason this combination holds is not the choice of metrics. It is the source topology. Commit behavior lives in version control. Review latency lives in the code review platform. Meeting patterns live in the calendar. Jira updates live in the project tracker. Four systems. Four owners. No single tool sees the whole picture — which is precisely the property that makes the composite signal hard to fake and harder to coincidence into existence.

A rough sprint produces one or two signals for a week. Real disengagement — burnout, frustration, an active job search — produces three or four signals drifting the same direction across two to four weeks. The predictive power is not in any individual reading. It is in the temporal correlation across independent sources. That is the load-bearing claim of the entire architecture.

Why these four and not others? Slack message sentiment is an obvious candidate. The problem: sentiment analysis requires content inspection, which crosses a line this architecture refuses to cross. Network centrality metrics are another candidate — whether someone's collaboration graph is shrinking. They require more infrastructure and produce weaker signal on individual contributors who were always low-centrality. The four signals above are deliberately chosen to be content-free, thin to collect, and stable enough to baseline. Add signals only if you can source them from a fifth independent system — otherwise you're inflating the weight of one source, not adding information.

Before correlation comes a deceptively expensive problem: entity resolution. The same person is jsmith on GitHub, jane.smith@company.com in Google Calendar, Jane S. in Slack, and Jane Smith (Engineering) in Jira. If those four identities never reconcile to one internal ID, no signal correlates. The whole architecture collapses on the first join.

Most organizations do not run a clean universal identity graph. SSO closes part of the gap. It does not close all of it. Contractor accounts, legacy systems, and personal emails attached to open-source work each leak identity outside the graph.

In practice, deterministic matching (corporate email) closes 70–80% of identity links with near-perfect confidence. The remaining 20–30% requires probabilistic matching — and probabilistic matches must never write to production identity without human confirmation. The failure mode is not missed matches; it is false matches that silently corrupt signal for two people at once.

The scoring model has two non-negotiable properties: detect real patterns early enough to be useful, and produce few enough false positives that managers actually trust the alerts. Miss either one and the system is dead on arrival.

The approach that holds up in production is a weighted z-score model that scores each person against their own historical baseline, never against team averages. The distinction is load-bearing. Comparing against team averages penalizes introverts, senior engineers who spend more time inside design docs than commits, and anyone whose working style sits off the median. Comparing against personal baselines detects change — and change is the only thing that matters here.

Two parameters determine almost everything about false-positive rate: the minimum number of signals required to fire an alert (set this too low and you're back to single-metric theater), and the persistence window (set this too short and rough sprints look like departures). Three signals over fourteen days is the operating point that consistently outperforms in backtests. Below that threshold, you're measuring noise.

Every engineering team has rough sprints. Deadlines compress. A production incident eats a week. A key dependency ships late and everyone scrambles. The behavioral shift produced looks identical to disengagement — for about one to two weeks.

The composite model's primary defense against false positives is temporal persistence. A rough sprint generates a signal spike that resolves within one sprint cycle, typically two weeks. Real disengagement generates a signal that persists or worsens across two or more cycles. The model does not alert on the first deviation. It alerts on the sustained trend.

A secondary defense is team-level correlation. If three engineers on the same team show the same signal pattern during the same week, the most likely explanation is a shared external stressor, not three independent departures. The model discounts individual signals during periods of team-wide drift. The threshold for team-wide suppression is more than 30% of a team showing the same signal deviation in the same seven-day window.

Correlating behavioral data across four workplace tools is technically trivial. Building a version employees accept requires a fundamentally different design philosophy than most people-analytics platforms ship with.

The core invariant: the system monitors team health patterns, never individual behavior in detail. That is not a marketing distinction. It shapes every technical decision downstream — what data enters the pipeline, how long it persists, who can access what level of resolution, and what action the system is permitted to recommend.

If you're deploying this architecture inside the EU — or processing data about EU-based employees — you need to read Annex III of the EU AI Act before you ship anything. AI systems used to monitor or evaluate the performance and behaviour of persons in work-related contractual relationships are explicitly classified as high-risk^[9]. That classification is not optional and does not require intent. A behavioral pattern detector built on the architecture described here qualifies regardless of what you call it internally.

The August 2, 2026 deadline is the operative date for most organizations. High-risk AI systems must be conformity-assessed, registered in the EU AI Act database, and operating with documented risk management, data governance, logging, and human oversight mechanisms before that date. Systems deployed after August 2026 that are not compliant face fines up to €15 million or 3% of global annual turnover, whichever is higher.

Two documents are required before deployment in most EU contexts. A Data Protection Impact Assessment (DPIA) under GDPR Article 35 — required any time you process data that involves systematic monitoring of employees. And a Fundamental Rights Impact Assessment (FRIA) under the AI Act — required specifically because the system is high-risk. These are not the same document. You need both. Note that France requires CSE consultation under French Labor Code Article L. 2312-38, and Germany requires a Betriebsvereinbarung negotiated with the works council before activation. Neither is optional.

The practical upside: a system designed from first principles around the rules-list above — no content analysis, aggregate-only reporting, employee access, documented opt-out — is substantially easier to DPIA than a surveillance-first system retrofitted with privacy controls.

Production hits patterns that academic models never sit with long enough to reproduce. Every edge case below will generate false alerts unless the system handles it as a first-class case rather than a footnote.

The most dangerous pattern: a new hire returns from a two-week onboarding off-site, has no baseline, is still learning the team's Jira process, and is on-call their third week. Every single signal fires. The system has no ground truth. Without explicit protections for each of these states, the model confidently alerts on its worst possible false positive: someone actively trying to onboard.

Managers do not see scores. They do not see z-values. They see one prompt: "Team health check suggested for your 1:1 with [Name] this week. No specific details available — just a general check-in recommended."

That is the entire output surface. The system never tells the manager why the alert fired. It does not say "their commit messages shortened and they are declining meetings." It nudges toward a human conversation, and that is where the real signal emerges — maybe the person just bought a house and is distracted by the move, maybe they are frustrated with a technical decision and need to be heard, maybe both, maybe neither. The system does not know. It does not need to.

The detection agent is not a replacement for management. It is a reminder to manage.

Here is the second-order effect most teams never anticipate: the system surfaces bad managers faster than it surfaces disengaged employees. A single manager with four engineers flagged inside the same quarter is a far clearer organizational signal than four individuals having four separate problems. Run the composite model at the team level rather than the individual level and it becomes an unintentional management-quality detector. That is either a feature or a threat depending on who is reading the data. The politics of that conversation deserve a real meeting, before the system ships.

Before you spec a single connector, answer these three questions honestly.

Do you have a team large enough to maintain signal anonymity? Below 10 engineers, aggregate reporting is effectively de-anonymized. A team of 6 with one person flagged is identifiable by elimination. Below 10, run self-service mode only — employees see their own dashboard, no alerts route to managers. Between 10–15, apply k-anonymity: alerts fire only when 3+ people share the same pattern flag, so no single person is spotlit.

Do you trust your management layer to use a nudge, not a weapon? The system's value depends entirely on managers treating the alert as an invitation to care, not as performance evidence. If your org has a history of surveillance-as-control — or if managers will forward the alert to HR as documentation — don't ship this. It will make things worse.

Do you have the engineering capacity to do entity resolution properly? A system with 15% identity-match failures silently corrupts signal for that proportion of your team. Bad entity resolution does not fail loudly. It produces plausible-looking alerts that are wrong in ways you can't detect without ground truth. If you can't invest 2–3 weeks in identity graph setup and ongoing reconciliation, build a simpler system or use an off-the-shelf platform like Worklytics that handles this for you^[10].

Weak signal detection for people health works precisely because it refuses to be dramatic. No urgent alerts. No risk scores leaking into leadership meetings. The system quietly notices when multiple small things drift the same direction on the same person, and it nudges someone toward a conversation. That is the whole product surface.

The engineering — entity resolution, z-score baselines, composite weighting, temporal persistence — is genuinely interesting work. The system's value is measured in conversations started, not in dashboards built. The best outcome is a manager who walks into a 1:1 and says "Hey, I noticed we haven't caught up in a while — how are things going?" and actually means it.

Start with entity resolution. Get the identity graph right before anything else. Add one signal at a time and validate against historical data before flipping any switch. Ship the employee self-service dashboard before any manager alert exists. Trust gets built before features do. The technology is not the whole problem — it's the part most teams will mistake for the whole problem, and that mistake is what turns a useful system into one more dashboard nobody reads.