Business Context

Nimbus, a B2B SaaS company with 420 employees, has seen product delivery slow over the last 2 months. Engineering leadership is worried that several teams may be approaching burnout after a major launch and wants a metrics-based way to identify risk before attrition or sustained performance decline occurs.

Metric Scenario

One 12-person product engineering team shipped 18 story points per engineer per sprint last quarter, but is now at 14. Weekly after-hours Slack messages rose from 9% to 22% of total messages, average PR turnaround increased from 11 hours to 27 hours, PTO usage fell from 1.8 days per person per month to 0.6, and regrettable attrition risk from the HR model increased from 6% to 14%. Pulse survey results also dropped: sustainable workload fell from 7.6 to 5.9 out of 10, and manager support from 8.1 to 7.2. The VP of Engineering asks whether this team is truly at risk of burnout, which signals matter most, and what threshold should trigger intervention.

Requirements

1. Define a primary burnout risk metric or score for a team, including numerator, denominator, and time window.
2. Identify which signals are leading indicators versus lagging indicators.
3. Propose how to decompose the metric to distinguish temporary crunch from sustained burnout risk.
4. Recommend thresholds for low, medium, and high risk, and explain how you would validate them.
5. Suggest 3-4 actions leadership should take if a team crosses the high-risk threshold.

Data Available

• slack_activity: message timestamp, sender_id, channel_type, after_hours_flag
• jira_sprints: team_id, sprint_id, committed_points, completed_points, spillover_points
• github_prs: author_id, created_at, merged_at, review_cycles, reopen_count
• pto_records: employee_id, requested_days, taken_days, leave_type
• pulse_surveys: employee_id, week, workload_score, stress_score, manager_support_score
• hr_roster: employee_id, team_id, tenure, level, manager_id, attrition_risk_score