Burnout Risk

Overview

Engineer burnout is expensive: the average cost of replacing an engineer is 6–9 months of salary. By the time someone resigns, the warning signs have usually been visible in their work patterns for months.

Koalr's Burnout Risk page surfaces those signals automatically — without surveys, manager check-ins, or self-reporting. It uses objective GitHub activity patterns to identify developers showing early-stage burnout indicators.

How burnout risk is computed

Burnout risk is computed per developer as a composite of four signal categories:

1. Work hour patterns

• After-hours commits — commits pushed outside 8am–7pm local time (using contributor timezone from GitHub profile)
• Weekend activity — commits, PR opens, and code reviews on Saturdays and Sundays
• Late-night streaks — 3+ consecutive days with commits after 10pm

2. Workload trajectory

• Throughput spike — week-over-week commit/PR velocity significantly above the developer's own 90-day baseline (not a comparison to peers — this is personal baseline deviation)
• Sustained overload — 3+ consecutive weeks above 120% of personal throughput baseline
• WIP accumulation — number of open PRs trending upward without completions

3. Focus fragmentation

• Context switching rate — high multi-repo days (see Context Switching)
• Review-to-coding ratio — a developer spending a disproportionate percentage of activity on code reviews vs. writing code (review burden signal)

4. Disengagement signals

• Review participation drop — a sudden decrease in PR reviews submitted relative to baseline (withdrawal signal)
• PR size inflation — PRs growing larger over time (batching work, avoiding the overhead of small PRs)
• Comment volume drop — fewer comments on PRs the developer authors (reduced investment in quality)

Composite score

Each signal is scored 0–3 (none / mild / moderate / high) and combined into a Burnout Risk Index (BRI):

BRI = Σ(signal × weight) / max_possible_score × 100

BRI	Level	Recommended action
0–25	🟢 Healthy	No action needed
26–50	🟡 Watch	Note the pattern; no intervention yet
51–75	🟠 At risk	1:1 conversation recommended
76–100	🔴 High risk	Proactive support + workload review

Dashboard sections

Organization summary

• Count of developers in each risk band
• Trend: how many developers moved from healthy → at risk in the last 30 days
• Average BRI across all active developers

Developer risk table

Sortable table showing each developer's:

• Current BRI and risk level
• Top 2 contributing signals
• 30-day trend (improving / stable / worsening)
• Link to their developer profile

Click any developer to see a detailed signal breakdown with 12-week sparklines per signal.

Team comparison

Average BRI per team. Platform/infrastructure teams often show higher burnout risk due to on-call load and context switching across many repos.

Risk trend chart

Organization-wide BRI trend over 12 weeks. Spikes often align with major release periods, incident weeks, or under-staffing events.

Privacy considerations

Burnout Risk data is sensitive. Koalr applies the following defaults:

• Managers and above can see BRI scores for all team members
• Individual contributors can only see their own BRI breakdown (via developer profile)
• Aggregated team averages are visible to all roles by default

These defaults can be changed in Settings → Visibility.

Individual signal data (e.g., "worked past midnight on 4 of the last 7 days") is only shown to the developer themselves and their manager — never as a public metric.

What burnout risk is not

• It is not a performance metric. High workload can reflect ambition and engagement in short bursts. The signal is sustained patterns, not single-week spikes.
• It is not a disciplinary tool. After-hours work is not penalized — it is surfaced as a care signal.
• It is not a replacement for human connection. Use BRI as a conversation starter, not a verdict.

Reducing burnout risk

1. WIP limits — limit open PRs per developer to reduce accumulation (WIP Limits)
2. Review rotation — distribute review requests across the team to reduce individual review burden
3. Context switching reduction — assign developers to focused epics; monitor context switch rates (Context Switching)
4. On-call balance — ensure on-call rotations are evenly distributed; correlate BRI spikes with on-call weeks
5. Well-being surveys — complement objective signals with anonymous pulse surveys (Well-Being Tracker)

Relationship to other metrics

• Context Switching — high context switching is both a cause and a symptom of burnout (Context Switching)
• WIP Limits — excessive open PRs are a leading burnout signal (WIP Limits)
• Well-Being Tracker — subjective well-being scores correlate with BRI direction; use both together (Well-Being Tracker)
• SPACE — Satisfaction — BRI directly feeds the Satisfaction dimension of SPACE metrics (SPACE Metrics)