What's really going on when a dashboard gets built
If you have ever inherited a team dashboard from a previous manager, you already know the pattern: eleven charts, three of which nobody has opened in a month, and at least one that quietly ranks people by lines shipped. Most engineering manager dashboards are built under pressure, either a new leader wants visibility fast, or a stakeholder asks "are we shipping" and the honest answer requires more digging than anyone has time for. The dashboard gets built to answer that question quickly, and speed is exactly what causes the wrong metrics to end up on it.
Quick Answer
An engineering manager's productivity dashboard in 2026 should hold three layers and nothing else: a delivery signal (lead time and deployment frequency), a quality signal (change failure rate and code churn), and a leverage signal (output relative to real effort, including what AI agents shipped). It should never rank individuals by commit count or lines of code, both of which an agent can inflate in seconds and both of which erode trust the moment someone notices. It works because every metric on it is expensive to fake, so the dashboard tells you something instead of just decorating a standup. Below: the panels worth building, the ones to delete, a tool comparison, and how to build this without turning your team into a surveillance target.
The metrics that are fastest to wire up (commit counts, PR counts, hours logged) are also the ones AI broke first. Claude Code, Cursor, and Codex sessions can produce a two-thousand-line diff in under a minute, so any dashboard tile built on volume now measures how a team batches work, not how the work went. This is the same failure mode covered in why commits do not equal work, just at team scale instead of individual scale. An EM dashboard has one job that a developer's personal dashboard does not. The moment it ranks people, it changes their behavior toward the metric instead of the work. What separates a dashboard that survives contact with a real team from one that gets gamed within a sprint is that constraint, and it is what every panel below is built around.
What to put on the dashboard
Most engineering managers who ask this question are really asking two things at once: what should I look at weekly, and what will hold up if an engineer asks me to justify it. The table below sorts the common candidates by both.
| Panel | What it reads | Team or individual | Hard to fake? | Verdict |
|---|---|---|---|---|
| Lead time for changes | Commit to production, timestamped | Team | Yes | Keep. The single best delivery signal. |
| Deployment frequency | Releases per interval | Team | Mostly | Keep, paired with a quality panel. |
| Change failure rate | Rollbacks and incident-linked deploys | Team | Yes | Keep. Hardest metric in the stack to game. |
| Code churn / rework rate | Rewritten-soon-after-written lines | Team, drillable | Yes | Keep. Rising churn is the fingerprint of unreviewed AI code. |
| Leverage (output per real effort) | Shipped output over telemetry-verified time | Individual, opt-in | Yes, with real telemetry | Add. The AI-era metric the others cannot see. |
| Commit count per person | Raw commit volume | Individual | No | Delete. One prompt inflates it. |
| Lines of code per person | Diff size | Individual | No | Delete. Agents broke it in both directions. |
| Hours logged (manual) | Self-reported time entries | Individual | No | Demote to a denominator only, never a ranking. |
Two things worth saying plainly about that table. First, the four team-level rows are DORA plus churn, and they earned their place because they read consequences (did production break, how long did a change take) rather than motion. The full breakdown of why those specific four survived is in DORA metrics explained. Second, leverage is the one row that is genuinely new, not a retread of an old idea with a new name. It exists because the AI era made the effort side of the ratio both measurable and worth asking about, and no delivery or quality metric alone can tell you whether your team's AI tooling is paying for itself. In practice this is the panel that turns "we adopted Claude Code" from a hope into a number.
How to build one without creating surveillance
Almost always, the failure mode of an EM dashboard is the framing, not the metric choice. The same churn panel that reads as "help us find risky code before it ships" reads as "we are watching you" if it is presented as an individual scorecard. Build it in this order and the framing takes care of itself; the rollout sequence that keeps a team's trust is in engineering team visibility without surveillance.
- Start at the team level, not the person level. Wire up lead time, deployment frequency, and change failure rate for the whole team first. These answer "are we shipping and is it safe" without naming anyone, which is also the question stakeholders ask.
- Add churn as a code-health signal, not a people signal. Surface which files or modules are churning, not which engineer's commits caused it. The code metrics that matter guide covers which churn reads are honest and which get weaponized.
- Separate AI-heavy periods before you look at volume. If your team shipped a spike of commits from an agent-heavy sprint, mark it. Comparing that sprint's raw activity to a hand-written one is comparing units that no longer mean the same thing, a mistake covered in depth in git analytics.
- Add leverage as opt-in, per person, owned by the person. This is the one individual-level panel worth having, and it only works ethically if each engineer can see and control their own number rather than having it fed into a ranking someone else reads. The full method, including where the denominator has to come from, is in how to measure developer productivity.
- Delete anything nobody has acted on in a month. A panel that has never changed a one-on-one, a retro, or a roadmap call is decoration. In practice this is the step most dashboards skip, and it is the one that keeps a dashboard trustworthy over time. This is why a shorter dashboard almost always outlasts a longer one: fewer numbers, but every one of them earns its place.
- Publish the definitions next to the numbers. Every metric on the board should have a one-line note on what it counts and what it cannot see. This is usually the point where a dashboard stops feeling like a black box, because the honesty about the metric's limits is what makes the metric credible.
Where DevClocked fits
If your question is purely organizational (deployment frequency, lead time, change failure rate across a fifty-person platform team), a dedicated engineering intelligence platform like Waydev or LinearB is built for exactly that scale and reporting cadence, and the Waydev alternatives page is worth reading if the price or the enterprise weight does not fit a smaller org. If you only need code-quality and churn analysis, GitClear focuses specifically on that layer; see the DevClocked vs GitClear comparison for where diff-delta analysis and individual proof diverge. DevClocked is not trying to replace the team-level DORA dashboard. It solves the layer those tools leave out: the individual leverage number, calibrated from a git baseline plus real telemetry from an editor extension and an editor-agnostic CLI (which is what actually sees Claude Code and Cursor sessions), and a profile each engineer owns and can show, rather than a metric a manager extracts. Full disclosure: I build DevClocked, so weigh the comparison with that in mind.
Common mistakes with engineering manager dashboards
Ranking engineers by anything derived from commits. It is the fastest way to teach a team to optimize for the metric instead of the work, and it is usually the first thing a new manager adds and the first thing a good one removes.
Treating DORA as an individual scorecard. DORA describes a pipeline's health. The moment lead time shows up in someone's performance review, the number gets gamed within a sprint.
Building the dashboard once and never pruning it. Panels accumulate. You will often see a board with three metrics that matter and eight that used to.
Skipping the AI column. If a meaningful share of the team's code comes from agents and the dashboard cannot see that split, churn and quality trends will move for reasons the dashboard cannot explain, and you will chase the wrong fix. If you have ever watched a churn number spike right after a team adopted an AI tool and blamed the wrong engineer for it, this is usually why.
