Business Context

Nimbus, a B2B workflow SaaS company, has 14 product engineering squads and ships weekly. Over the last two quarters, customer-reported bugs rose from 38 to 71 per month, while roadmap delivery slipped from 84% to 68%, and leadership wants a clear metric framework for engineering team performance.

Metric Scenario

The CTO does not want a single vanity metric such as lines of code or story points completed. Instead, they want a balanced scorecard that captures delivery speed, quality, reliability, and long-term team health. Current operating data shows median PR cycle time increased from 18 hours to 31 hours, deployment frequency fell from 22 to 15 deploys per week, change failure rate rose from 9% to 16%, and voluntary engineer attrition increased from 7% annualized to 12% annualized. At the same time, employee engagement survey scores dropped from 8.1 to 7.4 out of 10.

Requirements

1. Define the core metrics you would use to measure engineering team performance, including which are primary KPIs versus supporting diagnostics.
2. Explain how you would balance leading indicators (e.g., cycle time) and lagging indicators (e.g., production incidents, attrition).
3. Show how you would decompose performance to identify whether issues come from process bottlenecks, code quality, release practices, or team health.
4. Recommend a dashboard structure for executives, engineering managers, and team leads.
5. Identify 3-4 risks of using the wrong metrics and how you would prevent metric gaming.

Data Available

• jira_issues: issue_id, team_id, created_at, started_at, resolved_at, story_points, issue_type, sprint_id
• github_prs: pr_id, repo, author_id, opened_at, first_review_at, merged_at, lines_changed
• deployments: deploy_id, service, team_id, deployed_at, rollback_flag, incident_flag
• incidents: incident_id, severity, service, team_id, started_at, resolved_at, root_cause
• hr_roster and engagement_surveys: employee_id, team_id, start_date, exit_date, survey_score, survey_date