Engineering Team Health: Signals Before the Resignation

TL;DR: Resignations look sudden from the org chart and slow-motion from the data. Team health degrades along four measurable systems (flow, load, knowledge risk, and ramp), and every one of them leaves evidence in your repos and trackers months before anyone updates LinkedIn. The catch: none of it can be read off a single metric, and none of it is about ranking people. You're diagnosing the system your engineers work inside, not the engineers.

The resignation email always reads as sudden. It never is. By the time someone quits, the system around them has usually been failing for months: their review queue quietly became everyone's dependency, their calendar became a wall of interruptions, their domain became a silo nobody else could enter, and every retro logged the same friction that never got a fix. The org chart shows a person leaving. The data shows a system that had been leaning on them until it fell over.

Engineering team health is the practice of reading that data early, while the fix is still a conversation rather than a counteroffer.

What engineering team health actually is

Not morale posters, and emphatically not a dashboard that scores developers. Team health is the condition of the system a team works inside: whether work flows or waits, whether load is spread or piled, whether knowledge moves or pools, whether newcomers ramp or flounder. Healthy systems make ordinary engineers look great. Unhealthy systems make great engineers look tired, and then make them leave.

The research is blunt about the measurement part. The SPACE framework (Forsgren, Storey, Maddila, Zimmermann, Houck, and Butler, writing in ACM Queue) states plainly that developer productivity "cannot be measured by a single metric or dimension," and the same is true of health. You need a handful of signals in tension with each other, plus the team's own account of how the work feels. (The full breakdown is in Developer Experience Metrics: SPACE, Explained.)

Four systems cover most of what goes wrong.

Signal 1: flow, and whether deep work survives the day

Building software requires holding a large mental model, and that model shatters cheaply. Parnin and Rugaber analyzed 10,000+ recorded programming sessions from 86 programmers and found that in only about 10% of sessions did the first code edit come within a minute of resuming work. In roughly 30% of sessions, more than 30 minutes passed before the first edit (Resumption Strategies for Interrupted Programming Tasks). Every interruption buys that resumption tax; a workday diced into fragments is a workday where nothing hard gets built, no matter how busy everyone looks.

Flow problems are measurable without watching anyone: how long PRs wait before first review, how many round-trips a change takes, how often work stalls on a dependency. A team whose changes routinely sit for days is a team paying the re-context toll on every single one - the payroll math on that is uncomfortable.

Signal 2: load - who is actually carrying the team?

Every team has a gravity well: the person all the reviews route to, the one who takes the gnarly incidents, the name on every "quick question." From the outside this looks like your best performer performing. From the inside it's a queue with one server and no backpressure.

The health question is never "who is doing the least." That's a stack-rank wearing a wellness costume, and it poisons everything it touches. The question is who is carrying so much that the team breaks if they bend. Look at review-load distribution, incident-response concentration, and after-hours activity patterns as protection signals: the point of finding the overloaded person is to unload them before they make the decision for you.

Signal 3: knowledge risk - what breaks when one person is gone?

Knowledge concentration is the slowest-moving and most expensive health failure. In the 2024 Stack Overflow Developer Survey, 45.2% of professional developers agreed that knowledge silos prevent them from getting ideas across the organization, and 30% said silos hurt their productivity ten or more times a week. That's the everyday drag. The catastrophic version arrives with a departure: an entire subsystem going dark because it lived in one head.

This risk has proper names: bus factor for the codebase-level view, key-person risk for the organizational one. Both are computable from git history before they're ever tested by a resignation. If your continuity plan is "hope nobody leaves," you don't have a continuity plan; you have a countdown.

Signal 4: ramp, or how fast newcomers become contributors

Onboarding is the health check most teams never read. A new hire ramping slowly is rarely a hiring mistake. More often it's a mirror held up to the system: undocumented setup, knowledge locked in heads, review queues that leave first PRs hanging. The time-to-first-PR and the ramp curve after it tell you exactly how much of your team's competence is written down versus carried around, because newcomers are the only people who experience your system without the workarounds veterans stopped noticing.

Fast, confident ramps are also one of the strongest signs the other three systems are healthy: flow lets newcomers get feedback quickly, spread load gives them multiple people to learn from, and low knowledge concentration means the map exists outside anyone's head.

How to act on health signals (without a leaderboard)

Three rules keep this honest:

1. Diagnose systems, prescribe to systems. "Reviews wait 18 hours" is a queue problem with queue fixes: routing, load spreading, smaller changes. It is not an invitation to find the slowest reviewer and have a word.
2. Pair every metric with a perceptual check. The SPACE authors recommend including at least one measure of how the work feels, not just what the system logs. The numbers tell you where to look; the team tells you what it means. In the same Stack Overflow survey, technical debt was the top frustration at 63% - a system condition, reported as a feeling.
3. Protect, grow, coach - never rank. The output of a health review is a list of people to unload, silos to spread, and friction to fix. The moment it becomes a ranking of people, your best engineers will treat it as the threat it is, and the resignation you were trying to prevent gets a reason.

The door: pick one system this week. Pull your review wait times, your load distribution, or your single-owner areas - one of them will be worse than you think. Fix that one visibly. Teams believe health efforts when the friction they've complained about actually dies, and that belief is the thing that gets you told about the next problem while it's still small.