From dashboards to decisions

Brian Houck (Engineering Enablement / DX newsletter) · email · 2026-07-08 Reader 🖥️

Burnout & Recovery Developer Experience & Flow DORA & Engineering Metrics Focus Time & Meeting-Free Design Goodhart's Law

A developer-productivity measurement system creates value only when it changes what leaders decide to do next, not when it simply reports whether a number went up or down — which requires measuring outcomes (Speed, Ease, Quality) across multiple dimensions simultaneously with Thriving as a non-negotiable guardrail, because any single activity metric, examined alone, will tell a confident and sometimes completely misleading story.

practical · narrative/argumentative — A newsletter essay by a Microsoft researcher (Brian Houck), built around three real-world case studies drawn from his co-authored paper 'EngThrive: Make It Fast and Easy to Do Great Work'. Not a thin digest — full first-person argumentative prose with specific, cited numbers, though short (1,653 words) and promotional of the underlying paper and an upcoming DX webinar.

Structure

Part	Role
Opening frame: measuring is easier than improving; a dashboard that doesn't change decisions isn't creating value	thesis statement
The EngThrive framework: outcome dimensions (Speed, Ease, Quality) with Thriving as a guardrail, versus activity metrics as mere diagnostic clues	conceptual framework
Opening cautionary example: Microsoft's early-2020 remote-work transition, where PRs and stock price rose while 78% of developers reported burnout	evidence of the single-metric failure mode the framework is built to avoid
Case 1 (focus time), Case 2 (Time-to-First-PR), Case 3 (Health Days)	three worked examples, each showing a different way single-dimension measurement would have misread the outcome
Closing reframe: 'what should we measure' should become 'what decisions are we trying to make, and what would help us make them'	conclusion / call to action, tied to a forthcoming DX report and webinar

Key terms

North Star metrics (outcome-oriented)
A small set of metrics tied directly to outcome dimensions (Speed, Ease, Quality) rather than to activities (PRs, commits, tasks completed) — the thing an organization is actually trying to achieve, not a proxy believed to correlate with it.
Thriving (as guardrail, not metric)
Developer wellbeing treated as a hard constraint that can veto an otherwise-successful intervention — if something makes developers faster but leaves them burned out, it does not count as a success, regardless of what the Speed numbers show.
diagnostic metrics
Activity-level measurements (PRs, commits, meeting counts) that explain *why* an outcome metric moved, but are explicitly subordinate to outcome metrics and never used as the target themselves.
a well-designed (ungameable-in-the-bad-sense) metric
A metric where gaming it and genuinely improving the underlying system become indistinguishable, because the only way to move the number is to do something that actually helps — illustrated by Time-to-First-PR, which can only improve by removing real onboarding friction.

Propositions

explicitThe hardest part of developer-productivity work is not measuring software engineering but improving it; a measurement system creates value only insofar as it changes what leaders decide to do next.conf: high
explicitActivity metrics (PRs, commits, tasks completed) are frequently and silently treated as proxies for outcomes (delivery speed, quality, effectiveness) when the two are not the same, and this substitution is the central measurement failure the EngThrive framework is designed to correct.conf: high
supportsDORA Community Discussion - DX Core 4 · p6 — Both argue that any single isolated metric used as a target invites Goodhart's Law and must be replaced by a spectrum of metrics across dimensions; this piece supplies three concrete, numbers-backed cases of exactly that failure mode and its multi-dimensional fix.
explicitIn the first two months of mandatory remote work at Microsoft (early 2020), PRs per developer rose over 20% and stock price rose over 15%, while 78% of developers simultaneously reported feeling burned out — three contemporaneous signals pointing in incompatible directions, any one of which alone would have told a confident but misleading story.conf: high
explicitProtecting focus time for Microsoft's CoreAI organization (targeting the bottom 20% of developers up to 25 hours/week) raised focus time 2.1 hours/week (about 2x control), cut 'Bad Developer Days' 25%, and raised PR velocity 13% (about 4x control) within eight weeks — a combined gain the authors estimate as roughly equivalent to adding 350 developers' worth of output.conf: high
extendsThe Office Amenity That Actually Improves Teamwork · p6 — That extraction argues superteams protect focus via scheduled focus blocks and meeting-free days; this piece supplies a measured, longitudinal magnitude (2.1 extra focus hours/week, 25% fewer Bad Developer Days, 13% more PR velocity) for exactly that practice at organizational scale.
explicitOnly about half of the reduction in Bad Developer Days in the focus-time case was explained by the added focus time itself; the rest came from teams using their newly protected capacity to pay down technical debt and remove other friction sources the intervention never directly targeted — a spillover effect that single-dimension measurement (focus time alone) would have missed entirely.conf: high
explicitAn organization of ~4,000 developers deliberately 'gamed' Time-to-First-PR by assigning every new hire a trivial PR on day one, improving the metric by 30% — and those same developers went on to complete 23% more PRs in their first year than a control group, because the forced-early first PR was really forced-early environment setup, tooling familiarity, and review-process onboarding.conf: high
explicitA well-designed metric should be difficult to improve without doing something genuinely valuable; when gaming a metric and improving the underlying system become the same action, that convergence is itself evidence the metric was well chosen, not a flaw to be engineered away.conf: high
refinesAre You Getting Your Money's Worth from AI? · p14 — Shore's Goodhart's-Law discipline says metrics should evaluate an approach and then be retired, implicitly treating gameability as a universal risk; this piece's Time-to-First-PR case refines that by showing a metric can be deliberately gamed on purpose and still produce a genuine, durable improvement, when gaming and improving are structurally the same action.
explicitGiving every developer two unexpected 'Health Days' during the 2020 burnout crisis caused a temporary drop in PR output that fully recovered within two weeks, while the burnout relief the days produced lasted roughly fourteen weeks — making an apparently costly intervention, measured against Speed alone, effectively free once measured across dimensions, with a durable wellbeing benefit on top.conf: high
supportsBurnout Looks Different Across the Org Chart. Watch for These Signs. · p1 — Both treat burnout as addressable by structural, organization-level intervention rather than individual resilience; the Health Days case is a concrete instance of a near-zero-cost structural fix (unconditional time off) producing a measured, multi-week burnout-relief effect.
explicitLeaders commonly assume wellbeing and productivity trade off against each other, but in practice — across the cases the author has observed repeatedly, not only Health Days — that trade-off is frequently much smaller than expected, or does not exist at all.conf: medium
explicitNone of the three interventions (focus time, Time-to-First-PR gaming, Health Days) emerged from optimizing a single activity metric; all three came from measuring outcomes across multiple dimensions and using diagnostic metrics to explain why outcomes moved — which is the generalizable lesson the three otherwise-unrelated case studies are meant to jointly establish.conf: high
explicitEngineering organizations should stop asking 'What should we measure?' and start asking 'What decisions are we trying to make, and what measurements would help us make them better?' — the metric should serve the intervention, not become the intervention.conf: high
implicitBecause the Health Days case rests on one organization's uncontrolled experience rather than a controlled study, its specific numbers (two weeks to recover output, fourteen weeks of wellbeing benefit) should be read as illustrative of a repeated pattern the author has observed, not as a validated, generalizable effect size.conf: medium

Arguments

Organizations should organize developer-productivity measurement around multi-dimensional outcomes with a wellbeing guardrail, not around single activity metrics, even when activity metrics look favorable. strength: medium

Explicit premises:

The Microsoft 2020 remote-work data shows activity metrics (PRs, stock price) and wellbeing (burnout self-report) moving in opposite directions in the same quarter.
In all three case studies, the intervention's effect was invisible or misleading when viewed through only one dimension, and only became clear or defensible when viewed across Speed, Ease, Quality, and Thriving together.
In at least one case (focus time), the most valuable effect (tech-debt paydown enabled by protected capacity) was not the one the intervention was designed to produce, and would have gone undetected under narrower measurement.

Implicit premises:

Spillover and guardrail effects of this kind are common enough across interventions to justify the overhead of multi-dimensional measurement as a standing practice, not just a post-hoc explanation for these three cases.
Leaders are willing to act on counter-intuitive, multi-dimensional evidence (e.g. approving unproductive-looking days off) rather than defaulting to whichever single metric is easiest to report upward.

Inferences:

An organization that adopts outcome dimensions and a Thriving guardrail but keeps activity metrics as the thing leadership actually gets evaluated on will likely see the same single-metric distortions the framework is meant to prevent, just one layer removed.

Narratives

The Microsoft early-2020 mandatory-remote-work vignette: PRs per developer up >20%, stock price up >15%, yet 78% of developers reporting burnout in the same quarter.
→ Establishes, before any of the three main case studies, exactly how confidently and wrongly an organization can read its own situation from activity metrics alone — sets up the need for the EngThrive framework that follows.
A team lead's summary, quoted directly: 'Metrics led to questions, questions led to improvements, improvements reinforced the metric's value.'
→ Compresses the focus-time case's causal chain into a single aphorism, illustrating the paper's broader claim that a good measurement system is a learning system, not just a reporting one.

Questions addressed

✅ Why do developer-productivity dashboards often fail to improve anything even when the numbers on them move?
Because activity metrics are treated as proxies for outcomes without verifying the connection, and a single metric viewed in isolation can tell a confident story that is directly contradicted by other dimensions (e.g. rising PRs alongside rising burnout).
✅ Is 'developers will game the metric' a sufficient reason to avoid activity-adjacent metrics like Time-to-First-PR?
No — gameability is reframed as a design test: if gaming a metric requires doing something genuinely valuable (as with forced-early onboarding), the metric is well designed, not fragile.
✅ Does protecting a specific outcome (e.g. focus time) only improve that outcome, or can it have broader, unplanned effects?
It can have broader effects — in the focus-time case, roughly half the reduction in daily friction came from spillover (technical-debt paydown) the intervention never explicitly targeted, visible only because measurement covered multiple dimensions.
⭕ How robust is the specific claim that wellbeing and productivity 'don't trade off as much as leaders assume' — is that from controlled comparison or pattern-matching across anecdotes?
The author explicitly flags the Health Days evidence as one organization's uncontrolled experience, while asserting (without presenting the underlying data here) that it fits a 'pattern we've seen repeatedly.'

Gaps

incompleteAll three case studies are drawn from the author's own EngThrive program (built largely at Microsoft); the newsletter doesn't report an independent replication at an organization with different scale, culture, or tooling maturity, so it is unclear how much of the framework's apparent success depends on resources (a dedicated measurement team, longitudinal survey infrastructure) that most engineering orgs lack.
Read next: Look for a non-Microsoft, non-DX-client case study applying the same Speed/Ease/Quality/Thriving framework, especially at smaller scale.
incompleteThe piece doesn't address what happens when the four dimensions (Speed, Ease, Quality, Thriving) themselves conflict in a way that isn't resolved by Thriving acting as a simple veto — e.g. a Quality-improving intervention that measurably slows Speed with no wellbeing effect either way, where the framework as described gives no explicit tie-breaking rule.
Read next: Read the full EngThrive paper (Houck, Bozarth, Liu, Carignan) for how dimension conflicts, as opposed to single-dimension misreads, are actually adjudicated.
illogicalThe Time-to-First-PR argument generalizes from one successful case ('a well-designed metric is one where gaming equals improving') to a design principle without acknowledging that this property is a post-hoc observation about one metric, not a general test an author could apply prospectively when designing a new metric — the piece offers no method for predicting in advance whether a candidate metric will have this property before trying it.
Read next: Compare against Goodhart's-Law literature in the corpus (DORA/DX community material) for any proposed ex-ante test of 'ungameable-by-construction' metrics, rather than only ex-post classification.