The Purpose of Performance Reporting

Performance reporting serves one purpose: to create shared visibility that enables better decisions. It is not a control mechanism. It is not evidence collection for performance management. It is not a way of demonstrating to leadership that you are busy.

Reports that exist for any reason other than enabling decisions are wasted effort. Before building a dashboard or a report, the design question is: what decision does this information enable, and who makes that decision? If you cannot answer that question, do not build the report.

Most engineering organisations have the opposite problem: too much reporting, too little decision-making. Dashboards with fifty metrics that nobody looks at. Monthly reports that circulate and receive no response. Quarterly reviews where the same numbers are presented and the same vague commitments are made. This is reporting as ritual rather than reporting as tool.

Good engineering performance reporting is characterised by fewer metrics with clearer owners, a cadence matched to the decisions being made, and a visible connection between reported information and subsequent action.

The Reporting Hierarchy

Performance information should be organised by the level of the organisation it serves. Information that helps a team make daily decisions is different from information that helps engineering leadership make quarterly resource allocation decisions.

Team-Level Reporting

Teams need operational metrics: the information required to understand how their system is performing and whether their delivery is on track.

The core team-level metrics:

Deployment frequency and lead time for changes: are we deploying as often as planned? Is our pipeline performing as expected?

Change failure rate and MTTR: is our quality holding? When things go wrong, are we recovering quickly?

Work in progress: how many active workstreams does the team have? Is this within the team's capacity to manage effectively?

Cycle time: from "started" to "done," how long are individual items taking? Is this stable, improving, or deteriorating?

Incident load: how much engineering capacity is being consumed by operational issues rather than planned work?

Team-level metrics should be visible to the team in real time, not delivered as a report. The team should own this dashboard and review it as part of their regular practice - in planning, retrospectives, and daily stand-ups. The data is for the team first, not for management.

Engineering Leadership Level

Engineering leadership - heads of engineering, principal engineers, the CTO - needs a higher-level view: how is the engineering organisation as a whole performing, and what are the signals that warrant attention?

The key metrics at this level:

Aggregate delivery performance across teams: DORA metrics rolled up, with visibility into which teams are in which performance band and whether the overall position is improving.

Capacity allocation: what proportion of total engineering capacity is going to new development versus maintenance versus incidents versus non-delivery work? Is this consistent with plan?

Engineering health: engagement signals, attrition trends, team health assessment summaries.

Financial performance: spend versus budget, infrastructure cost trends, headcount versus plan.

Dependency and risk: what cross-team dependencies exist, which are at risk, and what is the escalation status?

This level requires a monthly reporting cadence at minimum, with a weekly pulse on anything that is in a heightened state of risk.

Board Level

Board-level engineering reporting is covered in the Financial Reporting section. In brief: summary financial performance, headline delivery and reliability metrics, and key risks. One page or three slides. Quarterly.

Cadence Design

Cadence design is the decision about how frequently to report each category of information. The principle is that cadence should match the frequency of relevant decisions.

Deployment metrics: daily or continuous. Teams need to know immediately if their pipeline is broken or their deployment failed.

Incident status: real-time during an incident; weekly summary in normal operations.

Sprint or iteration progress: per iteration (usually every two weeks).

Team-level performance summary: monthly, at the team retrospective or dedicated review.

Engineering leadership summary: monthly report, with a quarterly deep-dive.

Board report: quarterly.

The most common cadence mistake is monthly reporting for things that need weekly attention. A cost overrun that appears in the monthly report was a problem three weeks ago. A team that is consistently failing to hit its delivery targets needs a conversation in week two of the quarter, not a slide in the quarterly review.

Single Source of Truth for Engineering Metrics

One of the most common sources of credibility loss in engineering performance reporting is metric inconsistency - different people quoting different numbers for the same metric in the same meeting. This happens when there is no single authoritative source and different teams or individuals calculate the same metric differently.

Building a single source of truth requires: agreed metric definitions documented somewhere accessible, a designated data source for each metric (which system, which query, which date range), and a process for resolving disputes about the numbers before they surface in meetings.

The metric definitions matter as much as the data. "Deployment frequency" sounds clear but has multiple possible interpretations: deployments per service, deployments per team, deployments to production only, or including staging. Agreeing on the definition and documenting it eliminates a significant proportion of metric disputes.

Tooling for metric aggregation: most organisations use a combination of data from their CI/CD platform (for DORA metrics), cloud billing portals (for cost metrics), HR systems (for headcount and attrition), and project management tools (for delivery metrics). Aggregating this into a single dashboard requires either a BI tool with integrations or a dedicated engineering metrics platform. Options include Sleuth, LinearB, Jellyfish, and Waydev, though the build-vs-buy decision here should be made with the same rigour applied to any tooling decision.

Common Reporting Anti-Patterns

Vanity metrics: metrics that look good but do not indicate anything meaningful about engineering performance. Story points burned, lines of code shipped, number of pull requests merged. These are output metrics that can be gamed and that do not connect to outcomes. Drop them.

Metric overload: a dashboard with thirty metrics ensures that nobody pays attention to any of them. Limit engineering dashboards to eight to twelve metrics maximum. If you cannot decide which twelve matter most, the problem is not the dashboard - it is that you have not decided what you are optimising for.

Reporting without action: the ritual of reporting that generates no decisions and no changes. If a metric has been in the red for three consecutive reporting cycles with no intervention, either the metric is wrong or the organisation is not responding to it. Either problem needs addressing.

Presenter-owned reporting: reports that are built by and interpreted by the person being evaluated. This creates inevitable bias toward positive framing. Engineering performance reporting should involve data that is independently verifiable and reporting structures where there is appropriate separation between producer and consumer.

Dashboard Design Principles

A useful engineering dashboard follows a small number of design principles:

Current state and trend: every metric should show its current value and direction. A current value without trend is ambiguous - you cannot tell if a 15-day lead time is improving from 25 days or deteriorating from 10.

Red, amber, green thresholds: define what good looks like and mark deviation. Thresholds should be based on your own baselines and industry benchmarks (DORA bands, for example), not arbitrary choices.

Owner for each metric: someone should be accountable for every metric on the dashboard. If a metric goes red, there is a named person who is responsible for investigating and responding.

Minimal prose: dashboards are for scanning, not reading. Save the narrative for the report or the review meeting.

Running the Engineering Performance Review Meeting

The engineering performance review is the meeting where the data leads to conversation and decision. It is not a presentation meeting - it is a discussion meeting where the dashboard provides context.

A format that works: fifteen minutes of async pre-read before the meeting (everyone reads the dashboard and the written summary before the meeting starts). Five minutes to surface questions or observations at the start. Fifty minutes on the metrics that are amber or red - what is driving them, what is the response, who owns it. No time on metrics that are green and stable.

The output of the meeting is not a decision about whether the metrics are acceptable. It is a set of specific actions, with owners and timelines, for the metrics that require intervention. These actions are tracked to the next meeting.

Engineering leaders who run this meeting well know when to push deeper and when to accept the explanation. A one-time variance with a clear cause does not need an action plan. A persistent trend with an insufficient explanation needs escalation.