Measure engineering friction: Replace productivity KPIs this quarter
Engineering orgs are shifting from measuring developer productivity to measuring and managing delivery friction: constraints, handoffs, queue time, and enabling limits that preserve quality.
Table of Contents
Decide whether to replace developer productivity KPIs with a friction register and a quarterly removal plan before the next planning cycle. LeadDev’s November 2026 argument to stop measuring developer productivity and measure friction instead lines up with parallel writing on constraints and capacity, and the overlap points to an operating-model change, not a metrics tweak.
Engineering leaders keep reaching for “productivity” because boards and executives ask for proof that spend turns into output. The problem is that productivity metrics almost always turn into incentives that increase local output while slowing system throughput.
Trend: from output proxies to flow constraints
Three separate threads, from three different angles, converge on the same move:
- Measurement: LeadDev argues that productivity metrics distort behaviour and recommends measuring friction, the obstacles that prevent work from flowing.
- Capacity and system thinking: Refactoring.fm’s “Customer work, answers, and readings!” (Edition 233) sits in the ongoing conversation about capacity, scaling, and the reality that delivery is bounded by constraints, not individual effort (Refactoring.fm).
- Constraints as design tools: “TBM 450: The Loss of Positive Friction” frames constraints as simultaneously enabling and limiting, and warns against removing the wrong kind of friction (The Beautiful Mess).
The shared implication for CTOs is operational: treat friction like a managed backlog with owners, SLAs, and a budget. The “productivity dashboard” becomes less important than the “friction register.”
What should replace “developer productivity” metrics?
A friction-based model starts with a different unit of analysis.
- Productivity metrics usually measure outputs or activity: tickets closed, story points, PRs merged, lines changed.
- Friction metrics measure impediments to flow: time waiting for review, time blocked on an environment, time spent on rework, time to get a decision, number of handoffs, number of teams required to ship.
LeadDev’s specific recommendation is to focus on friction because friction is closer to what leadership can actually change: process design, staffing shapes, tooling, architecture boundaries, and decision rights (LeadDev on measuring friction).
A CTO does not need perfect instrumentation to start. A weekly or biweekly capture of “top friction events” already beats a quarterly productivity scorecard, because friction is actionable.
A practical friction taxonomy
A friction register works when categories map to levers a CTO can pull:
- Decision friction: approvals, unclear ownership, architecture review bottlenecks, security sign-offs with no SLA.
- Coordination friction: cross-team dependencies, handoffs, unclear interfaces, “four teams to ship one feature.”
- Tooling friction: slow CI, flaky tests, local setup pain, missing golden paths.
- Environment friction: staging parity gaps, data access constraints, brittle feature flag practices.
- Quality friction: late defect discovery, rework loops, unclear acceptance criteria.
Refactoring-focused writing tends to land on the same point: capacity is consumed by invisible work, and the system’s constraint determines throughput more than individual effort (Refactoring.fm Edition 233).
Which friction should you remove, and which should you keep?
“The Loss of Positive Friction” adds the nuance most friction programs miss: some friction is a guardrail. Some friction is a tax.
Positive friction examples:
- A lightweight design review that prevents expensive rework.
- A production readiness checklist that avoids repeat incidents.
- A dependency upgrade policy that prevents silent security drift.
Negative friction examples:
- Review queues with no service level.
- Manual environment provisioning.
- Ambiguous ownership for APIs and shared libraries.
The Beautiful Mess piece argues that constraints can be enabling and limiting at the same time, which is the right lens for CTOs: do not remove friction by default, classify it by the failure mode it prevents (TBM 450 on positive friction).
A useful rule is to ask: does the friction reduce downstream variability, or does it merely delay work? Guardrails reduce variability. Queues increase it.
The anti-pattern to avoid
A friction initiative fails when leadership removes guardrails because the guardrails are visible, while leaving queue time untouched because queue time is “nobody’s fault.”
Queue time is always somebody’s job.
How does this change planning, incentives, and org design?
A friction-first approach changes three CTO-level mechanisms.
1) Planning: allocate capacity to friction explicitly
If friction is real, friction work needs a budget. Refactoring and capacity conversations keep circling the same trap: teams plan at 100% feature capacity, then friction work arrives as interrupts and the plan collapses.
A workable pattern:
- Reserve a fixed percentage (often 10 to 25%) for friction removal.
- Make friction items first-class roadmap work with acceptance criteria.
2) Incentives: stop rewarding local throughput
Productivity metrics reward local throughput, and local throughput often increases WIP. High WIP increases cycle time.
Friction metrics reward reducing waiting and rework. Reducing waiting and rework improves cycle time without pressuring individuals.
3) Org design: friction exposes the real topology
Coordination friction often points to mismatched team boundaries: too many shared components, unclear platform responsibilities, or too many “complicated subsystem” responsibilities spread across stream teams.
A friction register becomes a map of where Conway’s Law is hurting delivery. That map is more useful than any productivity number.
What to decide this quarter
- VP Engineering: Replace any “developer productivity” KPI in the next quarterly OKRs with 3 friction KPIs (review queue time, deploy-to-restore time for broken releases, and % of work blocked by dependencies) by the end of the first month of the quarter.
- CTO: Stand up a friction register with an owner per item and a 30-day SLA for triage, then review the top 10 friction items every two weeks starting next sprint planning.
- Head of Platform or DevEx: Commit to two measurable friction removals with dated outcomes (example: cut CI median time from 25 minutes to 12 minutes by quarter-end; reduce flaky test rate to under 2% of runs).
- Product + Engineering leadership pair: Classify the top 10 frictions into “remove” vs “guardrail” using a one-page rubric, and publish the rubric internally within six weeks to prevent accidental removal of positive friction.
- Engineering Ops or CTO Chief of Staff: Build a lightweight baseline of cycle time and queue time from your existing tools, and refresh it monthly. Use the Engineering Metrics Dashboard as the single place to capture the baseline and track whether friction removal is improving lead time and MTTR, not individual output.
Sources
▶ Interactive tool
Put this into practice — free, no sign-up
Run your own numbers in this interactive tool built for exactly this decision.