Engineering Team Health Metrics: Burnout Indicators, Developer Experience Surveys, and Retention Signals for Engineering Leaders

Your DORA metrics look fine. Deployment frequency is healthy, change failure rate is low, mean time to recovery is within target. Then two of your strongest engineers give notice in the same month, a third discloses they have been working 60-hour weeks for six months, and the sprint that “looked fine” was actually held together by one person doing everyone else’s review queue.

Velocity and pipeline metrics measure what ships. They do not measure who is shipping it, at what cost, or whether that cost is sustainable. Team health sits upstream of delivery. When it degrades, delivery degrades six to twelve months later. The problem is that by the time you see it in the metrics you already measure, the damage is done.

This guide covers the leading indicators that precede that damage: burnout signals visible in your existing tooling, how to design developer experience surveys that produce data you can act on, retention risk patterns that show up before someone updates their LinkedIn, and how to assemble these signals into a dashboard that informs without surveilling.

The Problem with Lagging Indicators

Most engineering dashboards measure outcomes. Cycle time, deployment frequency, incident rate, sprint completion percentage. These are useful, but they are all lagging indicators. They tell you how the system performed last week, not what is accumulating underneath.

Leading indicators of team health are earlier in the causal chain. A team that is burning out will show the signal in commit patterns, review behavior, and survey responses before it shows up in missed deadlines. The gap between signal and visible impact is typically one to three quarters. If you are only looking at delivery outcomes, you are flying on instruments that lag reality by months.

The goal is not to replace delivery metrics with health metrics. It is to run both in parallel so you can act on the leading signal before the lagging one fires.

Burnout Indicators in Your Existing Data

You almost certainly already have data that contains burnout signals. Most engineering teams do not look at it through this lens.

After-Hours Commit Patterns

Pull the commit timestamp distribution for your team across the past 90 days. Normal distribution centers around working hours with a tail into evenings. When a team member’s commits consistently cluster between 9 PM and midnight, or start before 7 AM on weekdays and bleed into weekends, that is a signal worth a direct conversation.

A single period of after-hours work is not a signal; it is a sprint. A sustained pattern across six or more weeks is different.

interface CommitPattern {
  authorEmail: string;
  timestamps: Date[];
}

function classifyCommitHours(timestamps: Date[]): {
  offHoursRatio: number;
  weekendRatio: number;
  earlyMorningRatio: number;
} {
  const total = timestamps.length;
  if (total === 0) return { offHoursRatio: 0, weekendRatio: 0, earlyMorningRatio: 0 };

  let offHours = 0;
  let weekends = 0;
  let earlyMorning = 0;

  for (const ts of timestamps) {
    const hour = ts.getHours();
    const day = ts.getDay(); // 0 = Sunday, 6 = Saturday

    if (day === 0 || day === 6) weekends++;
    if (hour < 7) earlyMorning++;
    if (hour >= 21 || hour < 7) offHours++;
  }

  return {
    offHoursRatio: offHours / total,
    weekendRatio: weekends / total,
    earlyMorningRatio: earlyMorning / total,
  };
}

// Flag: offHoursRatio > 0.25 sustained over 6+ weeks

The threshold is not universal. Someone in Tokyo on a team based in New York will have a skewed distribution by default. Calibrate per person against their own baseline, not against a team average.

PR Review Fatigue

Review throughput per person is easy to pull from GitHub or GitLab. The signal to watch is not raw volume, it is quality over time. Review fatigue shows up as:

• Increasing time from PR open to first review by the same reviewer
• Decreasing comment depth (fewer substantive comments per PR over time)
• Rising rubber-stamp approval rate (approved with zero or one-line comments)
• Reviewers who were previously active going silent or being removed from rotation by others without explanation

If your top reviewer’s median time-to-first-review has drifted from 4 hours to 18 hours over eight weeks while their queue size stayed constant, that is not a process problem. That is a capacity or morale problem.

Sprint Carry-Over Patterns

Sprint carry-over at 10-15% is normal. Work gets scoped wrong, blockers appear, priorities shift. Carry-over at 30-40% for three or more consecutive sprints is a signal that something structural is broken: either scope is consistently unrealistic, there are persistent hidden blockers, or the people doing the work are not operating at full capacity.

What matters more than raw carry-over rate is whose work carries over. If the same two engineers are responsible for 80% of carry-over across multiple sprints, the issue is localized. They may be taking on too much, blocked by dependencies they are not escalating, or quietly struggling in a way they are not comfortable disclosing.

Designing Developer Experience Surveys That Produce Actionable Data

Most developer experience surveys fail because they ask the wrong questions, aggregate the results in ways that hide the signal, or get run once a year and then filed away. A survey that produces actionable data has a few characteristics.

Frequency and Length

Run a short pulse survey every four to six weeks rather than a long annual survey. Five to eight questions, answerable in under four minutes. Response rates on quarterly or annual surveys drop sharply after the first two rounds. Pulse surveys maintain higher participation because the ask is small and the cadence creates an expectation.

Question Design

Avoid questions that invite socially desirable answers. “Do you feel supported by your manager?” will cluster at 4-5 on a 5-point scale regardless of reality. Replace it with behavioral and comparative questions:

Instead of: “Do you feel supported by your manager?” Use: “In the past two weeks, when you raised a concern with your manager, what happened? (options: addressed directly, acknowledged but unresolved, not raised because I didn’t expect it to help, not applicable)”

Instead of: “Are you satisfied with your workload?” Use: “In the past sprint, how often did you work more than 9 hours in a single day? (0 times, 1-2 times, 3-4 times, 5+ times)”

Instead of: “Do you feel your work is meaningful?” Use: “Looking at the last two weeks of work, what percentage of your time was spent on work that you consider high-impact? (less than 25%, 25-50%, 50-75%, more than 75%)”

Questions that force the respondent to recall a specific behavior are more reliable than questions that ask for a general feeling. Feelings are easily rationalized. Behavior is harder to revise in memory.

The Questions Worth Asking Every Cycle

A minimal pulse survey that covers the major health dimensions:

1. How would you rate your energy level coming into work this week? (1-5 scale, labeled: 1 = exhausted, 5 = energized)
2. In the past two weeks, did you work evenings or weekends to meet a deadline? (Yes / No / Occasionally but by choice)
3. How clear were your priorities this sprint? (Very clear / Somewhat clear / Unclear / Changed mid-sprint)
4. How often did you feel blocked without a clear path to resolution? (Never / Once or twice / Frequently)
5. What is one thing that, if changed, would most improve your day-to-day work?
6. On a scale of 1-10, how likely are you to still be on this team in 12 months?

Question 6 is your retention leading indicator and deserves its own section below.

Making Results Actionable

Aggregate by team, not by org. A health score that averages across 40 engineers is meaningless. A health score per squad of 5-7 people shows you which team needs attention this sprint.

Run a 15-minute team retrospective on survey results the week they come out. Do not present the data to leadership first. Present it to the team, discuss the one thing question answers publicly (anonymized if needed), and commit to one change. If survey results consistently go to a dashboard that engineers never see action from, response rates will drop to zero within three cycles.

Retention Risk Signals

Retention risk is observable before the resignation letter. The signals are softer than burnout signals, but they cluster in ways that are recognizable.

Disengagement Patterns

Disengagement is not always visible as low output. It often shows up as narrowed scope: the engineer who used to volunteer for cross-team projects stops. The person who ran the architecture review club cancels the next session and does not reschedule. The team member who used to comment substantively in design documents starts writing “LGTM” and nothing else.

Contrast current behavior against a baseline from six months ago. If someone has demonstrably contracted their engagement footprint without a personal explanation (new baby, health issue, explicit need to focus), it is worth a direct conversation that is not a performance conversation.

Skill Stagnation

Engineers who are not learning will leave. Not immediately, but the trajectory is reliable. Skill stagnation shows up in a few ways:

• The same person has owned the same component for more than 18 months with no rotation
• No new technologies, tools, or domains in their last three project assignments
• Their contributions to design discussions reference the same patterns they have used for two years with no exploration of alternatives

A structured growth conversation twice a year, separate from performance review, with explicit attention to what skills the engineer wants to develop and what opportunities exist in the current work portfolio, is one of the higher-leverage retention activities available to an engineering manager. It is also one of the first things that gets deprioritized when delivery pressure increases.

Compensation Drift

Market rates for engineering talent move faster than most company compensation bands. An engineer who was well-compensated two years ago may now be at the 40th percentile for their role and market. They may not know this yet. When they do find out, typically through a recruiter conversation or by asking a peer, they have already framed it as a trust problem: you let the gap open and did not proactively address it.

Track compensation percentile against market data for your key contributors annually. A gap above 15-20% from the 50th percentile for their role is a retention risk, particularly for engineers with three to seven years of experience who have the most active external market.

Connecting Team Health to Delivery Outcomes

The case for investing time in health metrics is not abstract. The connection to delivery outcomes is direct and quantifiable.

Studies from Google’s Project Aristotle and subsequent organizational research consistently find that psychological safety and team health correlate with output quality, not just output quantity. Burned-out teams make more errors, take more shortcuts, and accumulate more technical debt than healthy teams operating at the same pace on paper.

A practical framing for this in your organization: track three health metrics alongside your DORA metrics for two quarters. Plot them on the same timeline. You will typically see that health metric degradation precedes deployment frequency drops or change failure rate increases by four to eight weeks. That gap is your intervention window.

Implementation Considerations

Building a team health measurement system has real tradeoffs. Getting them wrong turns a useful practice into surveillance or performative process.

Approach	Benefit	Risk	Mitigation
Automated commit-time analysis	Objective, no self-report bias	Engineers feel monitored, changes behavior	Anonymize at team level, never per-person in dashboards shared with leadership
Pulse surveys every 4 weeks	High frequency, actionable	Survey fatigue, low response rates	Keep to 5-8 questions, publish what changed as a result
Annual engagement survey	Comprehensive, benchmarkable	Too infrequent for leading indicators	Use as supplement to pulse, not replacement
Manager observations	Contextual, relationship-aware	Inconsistent, manager-dependent bias	Pair with structured questions and data
Retention risk scoring	Proactive, quantified	Can feel reductive; engineers may learn to game it	Use as a private manager tool, never as a label
eNPS (employee net promoter score)	Simple, single number	Single dimension, hides variation	Always ask follow-up: “what would change your score?”

The surveillance risk is real and worth taking seriously. The moment engineers believe their commit timestamps are being monitored per-person to flag productivity, or that their survey responses are being reviewed by someone who can affect their performance rating, data quality collapses and trust damage is done. Design your system so that individual-level data stays with the individual’s direct manager, team-level aggregates are visible to skip-level leadership, and survey results are shared with the team before they are shared with anyone else.

A Lightweight Health Dashboard

You do not need a dedicated tool to start. A shared spreadsheet updated monthly by each team’s manager is a viable first version.

Track six things per team:

1. Pulse survey average energy score (1-5, monthly)
2. After-hours commit ratio (automated, weekly rolling)
3. PR review median response time (automated, weekly rolling)
4. Sprint carry-over rate (per sprint)
5. 12-month retention confidence score from pulse survey (monthly)
6. Number of growth conversations held in the past quarter (manager self-report)

When two or more of these metrics degrade in the same team in the same month, trigger a structured conversation: not a performance review, but an honest “what is making this hard right now” discussion between the manager and team.

The goal is not to generate a health score and act on the score. It is to create a structure that forces the manager to look at the right things regularly so that the “how is your team doing?” answer is not just a feeling.

Closing

The best engineering managers I have worked with do not wait for engineers to raise burnout or retention concerns because they already know. They know because they built a lightweight habit of looking at the right signals every week, asking direct questions in 1:1s, and treating the answers as information worth acting on.

The signals are in your data. The conversations are harder, but they are also available. The only thing missing is the practice of looking.