Business Context

Fabrikam runs a B2B SaaS platform with 9 engineering squads and 74 engineers. Over the last 2 months, leadership has heard concerns about workload sustainability after a major roadmap push. The VP of Engineering wants a metric framework to detect whether a team is becoming overloaded before attrition or delivery failures occur.

Metric Scenario

For one 6-person backend team, the last 8-week snapshot shows: average weekly after-hours commits rose from 6 to 21, mean PR review turnaround increased from 9 hours to 26 hours, open Sev-2/Sev-3 bugs increased from 14 to 31, sprint carryover rose from 12% to 29%, and PTO usage fell from 2.1 days per engineer per month to 0.8. Team eNPS dropped from +24 to +5, while regretted attrition remains flat at 0 in the period. Leadership is asking which signals are leading indicators of overload vs lagging confirmation of burnout, how to combine them into a practical KPI, and what thresholds should trigger intervention.

Requirements

1. Define a primary metric or score that indicates engineering overload risk.
2. Identify which inputs are leading indicators and which are lagging indicators.
3. Explain how you would decompose the metric to find the main driver of overload.
4. Propose threshold values for green/yellow/red status and justify them.
5. Recommend actions leadership should take if the team enters yellow or red.

Data Available

• git_activity: engineer_id, commit_timestamp, local_hour, repo, lines_changed, weekend_flag
• jira_issues: issue_id, team_id, priority, status, created_at, resolved_at, sprint_id, carryover_flag
• pull_requests: pr_id, author_id, created_at, first_review_at, merged_at, review_rounds
• hris_attendance: employee_id, PTO_days, sick_days, tenure, manager_id
• engagement_survey: employee_id, survey_date, eNPS, workload_score, stress_score, intent_to_leave