Efficiency Can Make You Less Effective.

Every team in your organization can hit its efficiency targets, and the product can still ship late — because the thing being measured and the thing being delivered aren't the same object.

Most performance dashboards measure the wrong thing, and they measure it very precisely. Utilization, velocity per team, capacity booked — these are all resource efficiency metrics: how busy is the resource. None of them measure whether the thing the customer is actually waiting for is moving any faster. It's entirely possible — common, in fact — for every team in a value stream to run at high, well-managed efficiency while the end-to-end product takes longer to ship than it used to.

Two Kinds of Efficiency, and One Wins by Default

Swedish researchers Niklas Modig and Pär Åhlström built an entire framework, in their book This Is Lean, around a distinction most organizations never make explicit: resource efficiency (how well you use the resources doing the work) versus flow efficiency (how quickly a unit of value — a feature, a patient, an order — moves through the whole system from request to delivery). Organizations default to optimizing the first because it's what's visible on an org chart: a manager owns a team, a team has a capacity number, and that number is easy to push toward 100%. Flow efficiency has no natural owner — it belongs to the *path*, not to any single department, which is exactly why it's the metric that gets ignored.

Modig and Åhlström illustrate the gap with a healthcare example that translates directly to product delivery. A patient — the book calls her Alison — needed a straightforward diagnostic workup. Each department she passed through (referral, imaging, lab work, specialist review, follow-up) was individually well run and efficiently staffed. The full process took 42 days across five separate visits. The actual clinical work — the time someone spent looking at her case — was a small fraction of that elapsed time. Every station was efficient. The path between the stations was not. That's the same shape as a feature that touches five teams, each of which closes its ticket inside its own SLA, while the feature itself takes two quarters to ship.

Org Structure Becomes Product Structure

There's a reason locally efficient teams so reliably produce a globally slow system, and it has a name: Conway's Law, computer scientist Melvin Conway's 1968 observation that organizations design systems which mirror their own communication structure. Organize teams around technical layers or specialties — a frontend team, a backend team, a data team, each individually well optimized — and the product inherits exactly those seams. Every feature that crosses them pays a coordination tax at each boundary. Matthew Skelton and Manuel Pais built Team Topologies directly on this observation: most organizations size and shape teams around technical convenience rather than the flow of value, then wonder why fast flow never arrives even though every team is delivering on its own sprint commitments. Their concept of cognitive load makes the mechanism explicit — push a team past what it can hold in its head, and it stops behaving like a team capable of independent, fast delivery and starts behaving like a group of individuals waiting on each other.

Skelton and Pais go further than diagnosis: they describe teams as needing an explicit "team API" — a clear, documented interface for how other teams are meant to engage with them — and they name distinct interaction modes, from tight collaboration to a clean, self-service handoff, so the amount of coordination two teams need is a deliberate choice rather than an accident. Most organizations never make that choice explicitly. Every team defaults to the heaviest, most collaborative mode with every team it touches, because no one decided otherwise — and heavy collaboration is the most expensive interaction available, chosen by default instead of by design.

The Coordination Tax Nobody Puts on a Roadmap

Matrix and cross-team structures compound the problem, because they turn coordination into a standing cost rather than an occasional one. Research by Rob Cross, Reb Rebele, and Adam Grant, published in Harvard Business Review, found that the time managers and employees spend in collaborative activity — meetings, email, calls — has grown by 50% or more over the past two decades, and that at a typical organization, 20% to 35% of value-adding collaboration comes from just 3% to 5% of employees. None of that shows up as a resource-efficiency problem on any single team's dashboard. It shows up as slower cycle time everywhere, and as burnout concentrated on the handful of people every team depends on to unblock it.

None of this is an argument against efficiency. It's an argument against measuring only the kind that's easy to see on an org chart. The fix isn't to make each team less disciplined — it's to give someone ownership of the flow *between* teams, and measure that path with the same rigor currently reserved for each team's own utilization.

It's also worth naming why this is hard to fix once it exists: every incentive in a matrixed organization points a manager toward defending their own team's efficiency number, because that's the number they're evaluated on. Nobody is evaluated on the queue between teams, so nobody owns it, and it grows precisely because it's rational for every individual manager to leave it alone.