What is Engineering Friction and How to Measure It

Every engineering team has friction. Some have a lot, some have a little. But most teams can't tell you how much they have — because they're not measuring it. Here's what engineering friction is, what it costs, and how to quantify it.

What engineering friction looks like

Friction is anything that slows down engineers without adding value. Common forms:

CI failures: Tests that fail, builds that break, flaky tests that waste time
Stale PRs: Code waiting for review, blocking the author from moving on
Deployment issues: Failed deploys, rollback confusion, environment drift
Context switching: Engineers jumping between tasks because previous tasks are blocked
Dashboard switching: Checking GitHub, CI, Jira, Slack, Vercel, and monitoring separately to understand a single incident
Tooling gaps: Missing integrations, manual handoffs, duplicated work

These aren't exceptional events. They're ongoing conditions that drain energy and time every day.

Dashboard switching: the friction nobody measures

Of all the friction types above, dashboard switching is the one most teams never quantify — because it's invisible. It doesn't show up in sprint retrospectives or incident post-mortems. It just happens, constantly, as background overhead.

The typical engineer switches between 6+ dashboards daily: GitHub, CI, Jira or Linear, Slack, a deployment provider, and a monitoring tool. Research on attention residue shows each context switch costs ~23 seconds of re-orientation time. At ~40 switches per day, that's 15+ minutes lost daily — or 60+ hours per engineer per year — before a single actual problem is solved.

For a 10-person team, that's 600+ hours per year paid as a "dashboard switching tax." It's recoverable overhead — but only if you recognize it as friction first.

Why teams can't measure it

Most teams don't measure friction for three reasons:

It's distributed: Friction lives in many places (CI, PRs, deploys, issues). No single tool shows it all.
It's intermittent: A CI failure today and one next week doesn't feel like "a problem." It's just "bad luck."
It's invisible: Engineers adapt to friction. They stop noticing it's there, even as it costs them hours every week.

The result: teams know they have friction, but they can't say how much, where it's worst, or if it's getting better or worse.

The Friction Score approach

A Friction Score solves two problems at once: it quantifies friction so you can measure and reduce it, and it consolidates all friction signals into a single number — eliminating the need to open six dashboards to answer the question "how is the team doing?"

A Friction Score is an aggregate metric that combines all engineering friction signals into a single number (0-100):

0-20: Healthy. The team is shipping with minimal friction.
20-40: Moderate friction. Some delays, but manageable.
40-60: High friction. Noticeable impact on velocity.
60-80: Critical friction. Significant productivity loss.
80-100: Severe. The team is spending more time on friction than on features.

How to calculate it

Start with these signal categories, each scored 0-10:

CI health: Pass rate on main branch
PR flow: Average time from open to merge
Review responsiveness: First review time
Deploy reliability: Production deploy success rate
Test stability: Flaky test count

Weight each category by severity (e.g., CI failures on main are more severe than flaky tests on feature branches). Sum to get your score.

What the score tells you

The Friction Score is useful because it's:

Comparable: You can compare this week to last week, this quarter to last quarter
Actionable: A rising score tells you where to focus
Communicable: A single number is easy to share with stakeholders
Trackable: You can set goals and measure progress

It's not a perfect measure. But it's better than "I feel like things are slow."

What to do with it

Measure weekly: Track your Friction Score every week, same day, same methodology
Set a target: Where do you want to be? (e.g., "Under 30")
Identify hotspots: Which category is contributing most to your score?
Prioritize interventions: Fix the highest-scoring friction first
Iterate: After 4-6 weeks, measure again. Has the score changed?

The goal isn't to have a friction score. The goal is to have a feedback loop that helps you reduce friction over time.

A good place to start: score your CI pipeline health right now with the free CI Health Score Calculator. It grades your build speed, failure rate, flaky test rate, and recovery time against elite benchmarks — and tells you exactly which dimension to fix first. For a complete view across all friction types, Deviera's Friction Score aggregates CI health, PR flow, deploy reliability, and test stability into a single 0–100 metric — updated automatically as new signals come in.

Engineering friction vs. technical debt: what's the difference

Technical debt is future work you owe because of shortcuts taken in the past — missing tests, outdated dependencies, inconsistent abstractions. Engineering friction is present-tense overhead that slows the team down right now, regardless of debt level. A codebase with zero technical debt can still have high friction if CI is unreliable, PRs stall in review, and deployments fail unpredictably.

The relationship: high technical debt tends to increase friction over time, because complex code takes longer to review, tests become harder to maintain (increasing flakiness), and deployments become riskier (increasing failure rates). But they are distinct problems with different measurement approaches and different interventions. TODO debt is one of the few friction types that bridges both categories — it is friction now (engineers encounter it during review) and debt for the future (it represents deferred work that compounds).

How to reduce engineering friction: the priority order

Not all friction is equally expensive to eliminate. Start with the types that block the most people most often:

Main branch CI failures first. A broken main blocks every engineer from merging. Fix this before anything else — even a 10% improvement in CI pass rate on main has team-wide impact. Use the CI Health Score Calculator to benchmark your current pass rate.
Stale PRs second. Code waiting for review accumulates merge conflicts, loses context, and blocks the author from starting new work. Set a review SLA (4–8 hours for most teams) and automate alerts when PRs breach it.
Flaky tests third. Flaky tests erode trust in CI — once engineers start dismissing test failures as "probably flaky," real failures get ignored. Quarantine flaky tests immediately and fix the root cause within the sprint.
Deployment failures fourth. Untracked deployment failures create invisible technical debt and on-call burnout. Every deployment failure should generate a structured ticket with context — not a Slack message that gets buried and forgotten.
Dashboard switching last. Consolidating your signal view reduces the overhead of the above — but it's a force multiplier on top of healthy CI, review, and deployment practices, not a substitute for them.

Frequently asked questions

What is engineering friction?

Engineering friction is any recurring overhead that slows down engineers without adding value to the product or codebase. The most common forms are CI failures (tests failing, builds breaking), stale PRs (code waiting for review), deployment failures (deploys failing or rolling back unexpectedly), flaky tests (tests that pass and fail non-deterministically), and dashboard switching (engineers checking 6+ tools manually to piece together a picture of team health). Unlike a one-time incident, friction is a persistent condition — it shows up every day, drains a little time each instance, and compounds into significant velocity loss over weeks and months.

How is engineering friction different from engineering velocity?

Engineering velocity measures how fast the team ships — deployment frequency, PR cycle time, lead time for changes. Engineering friction measures what is slowing the team down — the conditions that cause velocity to degrade. The two are inverses: high friction produces low velocity, and reducing friction is the most direct lever for improving velocity. Velocity metrics tell you the outcome; friction metrics tell you the cause. A team with declining deployment frequency and rising PR cycle time has a velocity problem — looking at their Friction Score reveals whether the root cause is CI health, review bottlenecks, or deployment reliability.

Can you measure engineering friction objectively?

Yes — the main friction types all have objective, data-backed measurements. CI pass rate on main (GitHub Actions API, GitLab CI API), PR time to first review (GitHub PR events API), deployment success rate (Vercel logs, GitHub deployments API), flaky test rate (CI run history), and context-switching cost (number of tool switches per incident, calculable from webhook event patterns). A Friction Score aggregates these into a single 0–100 metric so the team has one number to track over time rather than five separate dashboards.