The Cost of Value Never Created

The finance team wanted printouts.

Not out of stubbornness. They needed to check the numbers, and checking meant reading them on paper, line by line, against another set of numbers, by hand. That was the control. It had always been the control, and it worked, in the sense that errors were caught.

It also meant that every month a group of capable people spent days doing something a machine could do in seconds. Everyone involved knew it. It carried on anyway, because the people who understood what the checks were for and the people who could automate them sat in different parts of the organization, speaking to each other through requirements documents.

So we tried something small. One person from finance came and sat close to the team building the thing — not as a stakeholder to be consulted at milestones, but close enough to be asked a question and answer it the same hour.

The printouts went away. Most of the manual validation became automatic. A bonus came with it that nobody had asked for: quality went up, not because the machine was more careful than the people were, but because once the checks were automatic we could afford to run far more of them than anyone would have done by hand.

Nobody in that story was doing anything wrong. Finance was protecting the numbers, which is their job. The team was building what was specified, which is theirs — and what was specified is where the whole problem was hiding, because a specification is what you need when the people who understand the work aren’t in the room. The friction wasn’t inside the work. It was between the work.

One person moved, and thousands of hours went away. It is worth being exact about what that means, because “saved hours” is the phrase people reach for and it is the wrong one. Nobody was let go and nobody worked harder. The hours went away because the work that consumed them no longer had to be done by anyone.

What those people did next is the actual point. They went back to the work only they could do — the judgement calls about what the numbers meant, the questions nobody had been free to ask, the analysis that had been waiting behind a stack of printouts for years. Same salaries, same people, same week. A different amount of value coming out of the far end.

That is what structural friction costs. Not effort, not salaries, not even time exactly. It costs the value those hours would have created if they had been spent on anything else.

There is a team building software in that story, which makes it easy to file the whole thing as a technology problem. It isn’t, and the examples that convinced me had no technology in them anywhere.

A recruitment team I worked alongside was measured on time to hire, and they were good at it. Roles that used to sit open for four months were closing in six weeks. Everyone was pleased, and reasonably so.

What nobody was measuring was what happened after someone said yes. The people arriving were a good fit on paper and knew very little about why the work mattered — partly because the slower conversations that would have told them were exactly what had been compressed out to save those weeks. Their new teams spent the first months filling that in, mostly in corridors, mostly without noticing they were doing it.

Six weeks was real and got reported. The months afterwards were just as real and appeared in nobody’s numbers, because they arrived as a team that was quietly slower than it looked rather than as a cost of recruiting.

Nobody was wrong here either. Recruitment optimized what it owned and hit the target it had been given. The teams owned the consequences and not the decision. The friction was the distance between those two facts, and there was nothing to buy, nothing to build and no technology anywhere in the problem.

What I find striking about both stories is that you could interview every person involved and none of them would describe a problem. Ask each one whether they are doing their job well and they would say yes, and they would be right. The loss is real all the same, and it is sitting in the gaps between them, which means it belongs to nobody and removing it is nobody’s job.

That is also why it stays hidden for years. Failure announces itself — a project cancelled, a system down, a customer lost. Friction does none of that. Projects continue, meetings continue, people stay busy, reports get delivered, approvals happen. Everything looks productive. The organization simply creates less than it could have, with exactly the same people, and there is no moment where anyone could reasonably have pulled a cord.

Friction turns up in a small number of recognizable shapes. I have found four worth separating, mostly because they fail differently and need different things done about them. They come back throughout the paper, so they are worth a minute here.

The first is ownership nobody can say out loud — where you can find plenty of people involved and nobody whose it is.

Ownership nobody can name. Two teams given the same capability on different time horizons — one building the future, one maintaining the past. It looks efficient on an org chart. In practice both teams are technically right, neither is fully responsible, and every decision between them escalates.

Governance grown to fill the gap. Where ownership is unclear, people don’t stop working — they start compensating. Meetings. Committees. Approval chains. None of it comes from incompetence. It comes from uncertainty, and uncertainty always builds something in its own defense.

The second is context rebuilt at every boundary, which is what a handover actually costs when you watch it closely.

Handovers, meaning any point where work passes from one group to another. Each looks like a clean transfer on a process diagram. Each is really a small act of forgetting, paid for later by whoever has to reconstruct what the previous team already knew. Sales to delivery. Recruitment to onboarding. Procurement to the department that has to live with what was procured.

The third is the gap between a decision becoming necessary and being made, which is almost never about anyone deciding slowly.

A decision waiting on a forum. The decision itself takes four minutes. Reaching the forum authorized to make it takes three weeks, and nobody counts the three weeks, because nobody bills for waiting.

Information that arrives correct and late. The report was accurate. It was thorough. It reached the person with authority to act on it after the window to act had closed. This is the most expensive form of friction and the least likely to be treated as a problem, because everyone involved did their job well.

A rhythm mismatch. The work needs a decision this week. The structure around it can produce one in April. Nobody is being obstructive; the two things simply run at different speeds, and the slower one sets the pace.

And the fourth is what happens after, or rather what does not: the outcome that never travels back to whoever chose.

Nothing changed as a result. Execution finished, results arrived, and nothing about the next decision was different. The organization didn’t learn, so it will solve this problem again, at full price.

None of those are technology problems, though several will be presented to you as technology problems, which is its own kind of friction. Each is cumulative and invisible at once: no single instance is worth escalating, which is exactly why the total never gets escalated either.

If you want somewhere to start looking, count how many times a single piece of work changes hands before it reaches anyone outside the organization. The number is usually higher than people expect, and less interesting than how long it takes to establish it.

Playing with the numbers

What follows is not research. I have not measured this across a sample of companies and, as far as I know, neither has anyone else. What the numbers are good for is showing the shape of the thing — how something that never looks like much adds up to a great deal. Put your own figures in. Halve mine if you like; the conclusion is stubborn.

The part that still catches me out is how dull the inputs have to be. Nothing here needs a villain, a crisis or even a particularly badly run company. Four hours and three weeks are enough.

Start with the easy one. Ask a receiving team how long it takes before they can act without going back to ask. Four hours is a common answer and a modest one. Take a boundary crossed weekly:

4 hours × 52 weeks = 208 hours a year, on one boundary.

More than five working weeks, spent reconstructing something somebody already knew. A mid-sized organization has eight or ten such boundaries without trying:

208 × 8 = 1,664 hours, or roughly a full-time role, doing nothing but remembering.

Nobody is employed to do that. It appears in no budget and has never been justified to anyone, because at four hours a time it does not look like anything.

Waiting is the more expensive one, and it hides better, because the people waiting are not idle — they move to something else, which is precisely why nobody counts it. Take an initiative worth €50,000 a month once it is live, modest for anything a company bothers to fund at all. It needs eight cross-team decisions, made in sequence, each waiting a median of three weeks:

8 decisions × 3 weeks = 24 weeks of waiting, about six months.

6 months × €50,000 = €300,000, in delay alone.

Total deliberation across those eight decisions: perhaps a day. The organization did not lose six months of effort. It lost six months of value creation.

Nobody approves a six-month delay. Everybody approves this particular three-week wait, because this one has a good reason — and so does the next one. That is how a cost this size gets incurred without anyone ever deciding to incur it.

It is also why friction survives being obvious. It rarely shows up where it started. It shows up as slower delivery, more meetings, more approvals, more governance, more dependencies — symptoms, and often quite a reasonable response to uncertainty. Which is why removing a governance forum without settling the ownership question underneath it rarely creates speed. The symptom goes. The cause stays.

Faster is only half of it

There is a reading of all this that stops too early: clear the friction, and things move quicker.

That is true, and it is half the story. Moving quicker only helps if what comes out the other end is worth having. An organization can become extremely efficient at producing more of something nobody particularly wanted, and friction is just as much in the way of finding that out — the feedback that never travels back, the person who would have said not like that sitting three handovers away, the outcome nobody checks because the project was already marked delivered.

So there are two things to work on and they need each other. Producing more of what we already know how to produce. And getting more real value out of what we produce — value as the person on the receiving end actually experiences it, rather than as it appears on our own dashboard. The same friction sits in the way of both, which is the good news, because the same work moves both.

What comes back for the trouble is not only speed, though speed is what gets noticed first. The more useful change is that you end up watching both halves: how easily the work moves, and whether what came out of it actually landed with anyone.

Which is worth being concrete about, because it decides what you count. The four shapes above all measure movement — ownership, handovers, waiting, learning. Not one of them can tell you whether the thing that moved was worth moving. That takes a fifth measure, sitting on its own and pointing outward: did anybody end up better off. Most organizations have some version of the first four, in one form or another, and have never quite got round to the fifth.

Neither half is something you install. Both have to be cultivated, and I spent years doing only that — working on culture and confidence while a structural problem sat untouched underneath. You do not cultivate your way out of one capability split across two departments; that one you fix with a decision. But once it is fixed, nothing improves on its own either.

Organizations rarely need dramatically more capacity. They need more of the capacity they already have to actually become value — and then they need to find out whether it did.