This repository captures a practical, leadership-oriented approach to measuring and improving engineering productivity, flow, quality, and security — without turning metrics into scorecards, targets, or surveillance tools.
It is grounded in real enterprise environments where:
- Multiple teams deliver through shared platforms
- Leadership decisions shape system behavior
- Metrics can either enable learning or damage trust
The focus is on using metrics to improve systems, not evaluate people.
- A reference model for engineering productivity metrics
- A set of principles, architectures, and playbooks used in large organizations
- A conversation guide for leaders, enablement teams, and engineers navigating delivery, risk, and speed
- A vanity metrics catalog
- A team or individual ranking system
- A prescriptive framework detached from organizational context
- A replacement for judgment, leadership, or experience
All content in this repository is constrained by a small set of explicit principles. These principles exist to prevent metrics from becoming performance tools and to keep them focused on decision support and system improvement.
Some principle documents are intentionally marked Work in Progress (WIP) and will be expanded incrementally.
-
Metrics are for decisions, not judgment
Metrics exist to support learning and informed decisions — not to evaluate or rank people or teams.
→01-principles/metrics-are-for-decisions.md -
Optimize for flow, not utilization
High utilization hides bottlenecks and increases risk. Sustainable delivery comes from optimizing end-to-end flow.
→01-principles/optimize-for-flow-not-utilization.md -
Metrics exist to enable decisions, not scorecards (WIP)
When metrics become targets, they are gamed. When used as signals, they drive improvement.
→01-principles/metrics-exist-to-enable-decisions-not-scorecards.md -
Systems optimize for what they measure (WIP)
Measurement shapes behavior — intentionally or not.
→01-principles/systems-optimize-for-what-they-measure.md -
Measure constraints, not people (WIP)
Productivity issues are almost always systemic.
→01-principles/measure-constraints-not-people.md -
Flow precedes quality, security, and reliability (WIP)
Teams struggling with flow will struggle to sustain everything else.
→01-principles/flow-precedes-quality-and-security.md
Engineering productivity metrics are organized into four complementary domains. Each domain answers a different class of questions and supports different decisions.
Metrics are treated as signals, not targets.
-
Flow Metrics
How efficiently value moves from idea to production -
Quality Metrics
How reliably changes behave once deployed -
Security Metrics
How risk is identified, reduced, and managed over time -
Enablement Metrics
How organizational systems enable or constrain delivery
Metrics only work at scale when they are architected intentionally.
The reference architecture describes how:
- Signals are emitted naturally from systems
- Data is aggregated without manual reporting
- Interpretation remains human-driven
Metrics are surfaced through different dashboards depending on who is making decisions and what decisions they are making.
-
Team Dashboards
Support local improvement and day-to-day delivery decisions
→04-transformation-playbooks/team-dashboards.md -
Enablement Dashboards
Translate team signals into system-level constraints
→04-transformation-playbooks/enablement-dashboards.md -
Leadership Dashboards
Support investment, prioritization, and systemic intervention
→04-transformation-playbooks/leadership-dashboards.md
To understand how these dashboards work together:
The walkthroughs demonstrate how metrics move from signal → insight → decision → action.
They are intentionally realistic and focus on:
- Removing constraints
- Justifying investment
- Avoiding metric misuse
This repository is designed to be explored, not read linearly.
Different audiences will naturally start in different places depending on the decisions they are trying to make. The sections below provide suggested entry points, not required paths.
Start here to understand where to invest, where risk is emerging, and where to stay out of the way.
Recommended entry points:
- Dashboard Relationships
How team, enablement, and leadership dashboards fit together - Leadership Dashboards
What belongs (and does not belong) on leadership views - End-to-End Walkthroughs
Concrete examples of how metrics drive investment and system change
Start here to identify systemic constraints, justify platform investment, and translate team-level signals into leadership decisions.
Recommended entry points:
- Enablement Metrics
Measuring how organizational systems enable or block teams - Reference Architecture
How signals are collected, aggregated, and interpreted - Enablement Dashboards
Turning metrics into actionable system insights - End-to-End Walkthroughs
Realistic scenarios connecting metrics to intervention
Start here to improve delivery without metric pressure and to understand how flow, quality, and reliability emerge from system design.
Recommended entry points:
- Flow Metrics
Understanding how value moves through the system - Team Dashboards
Metrics for local improvement and learning - Optimize for Flow, Not Utilization
Foundational principle behind sustainable delivery
There is intentionally no single “correct” reading order.
This repository is meant to support:
- Conversations, not compliance
- Inquiry, not evaluation
- System improvement, not team comparison
Readers are encouraged to start where they have the most questions.