Lots of companies have the same problems, this book explains why

I'd been noticing the same patterns for years before I had a name for them. Teams measured on velocity that never shipped anything users cared about. Processes designed to make managers feel informed rather than to help the people doing the work. Organisations full of busy people producing very little value. I could see it, but I couldn't articulate why it kept happening.

Then a friend recommended John Seddon's Freedom from Command and Control. It was written for service organisations. Housing associations, call centres, local councils. Not software teams. But reading it felt like someone had reverse-engineered every dysfunctional workplace I'd ever been part of. I still see the patterns he describes everywhere. Once you've read it, you can't unsee them.

The book's central argument is that command-and-control management, where decisions are made by managers and executed by workers, creates organisations full of waste, poor service, and demoralised people. Not because the managers are bad, but because the system design is wrong. Seddon's alternative is systems thinking: studying the work itself, understanding demand, and designing the system around what customers actually need.

Here are the ideas from it that have stuck with me the most.

Failure demand

This is Seddon's most useful concept. He splits all demand into two types: value demand and failure demand. Value demand is what your service exists to provide. Failure demand is demand caused by a failure to do something right for the customer the first time.

In a call centre, failure demand is the customer ringing back because their issue wasn't resolved on the first call. Seddon found that in some organisations, failure demand accounted for 40-80% of total call volume. The organisation was drowning in work it had created for itself.

One of his best examples is what happens when you give call centre workers a target for answer time. Rather than actually resolving issues faster, workers start bouncing callers to other departments, referring them to different numbers, or not dealing with all of the caller's needs, anything to get the call closed within the target window. Managers got creative too, gating the phone queue so most callers got a busy signal while the calls that did get through were answered within thirty seconds. The target was hit. Bonuses were paid. The customers got worse service. Not bad people, but a bad system.

This maps directly to software. Every support ticket that exists because a feature is confusing is failure demand. Every workaround a user builds because the product doesn't handle their case is failure demand. Every internal escalation because a system failed silently is failure demand.

Most teams try to handle this by scaling up support or building more features. Seddon's point is that the better response is to go upstream and fix the thing that's generating the demand in the first place. It sounds obvious when you say it. In practice, almost nobody does it because the system rewards handling tickets, not eliminating the need for them.

Study the work, not the workers

Seddon makes a sharp distinction between managing people and managing the system they work in. His argument is that 95% of performance variation is caused by the system, not by individual workers. If your team is slow, the problem is almost certainly the process, the tools, or the way work flows through the organisation, not the people doing the work.

This is Deming's influence. And it's something I think about every time I hear a team blamed for missing a deadline. Were they slow, or did they spend three weeks waiting for decisions? Were they unfocused, or were they context-switching between four projects because the organisation couldn't prioritise? Were they careless, or was the testing infrastructure so slow that catching bugs before production was practically impossible?

When something goes wrong, the instinct is to look at who was involved. Seddon's instinct is to look at the conditions they were working in. That shift in perspective changes everything about how you diagnose and fix problems.

Studying demand before designing supply

One of Seddon's core practices is starting any improvement work by studying demand. Before you redesign a process or build a new feature, understand what people are actually asking for and why. Not what the spec says they need. Not what the manager thinks they need. What they're actually doing, day after day.

In software, this is the difference between building what the roadmap says and building what the users are actually struggling with. I've lost count of how many features I've seen shipped that nobody asked for, while the thing users complain about most sits untouched because it wasn't in anyone's OKRs.

Seddon's approach is to go to where the work happens, watch it, measure it, and understand the actual flow of demand before making any decisions about what to change. It's slow and it requires patience. But it means when you do make a change, it's based on reality rather than assumption.

The separation problem

Seddon argues that the fundamental flaw of command-and-control is the separation of decision-making from work. Managers decide what to do. Workers do it. The people with the best understanding of the work have the least influence over how it's designed.

I always use the analogy of being in the trenches. The people doing the work can see exactly what's happening, but the decisions are being made from a chateau miles behind the front line. Product managers define requirements without understanding the technical constraints. Engineers build features without understanding the user context. Designers create interfaces without seeing how the system behaves with real data. Everyone's working with partial information because the structure keeps them in their lane. Image attached from the ending of Blackadder for no reason.

The alternative is what Seddon calls "getting knowledge." Leaders should be able to talk about how the work works with the people who do it. Not through dashboards and reports, but through direct observation and conversation. The people doing the work should have the authority to change it when they see it's not working.

Why this matters for software teams

Seddon's book is about service organisations, but the pattern he describes, management by abstraction, decisions made far from the work, metrics that measure activity rather than purpose, is exactly what I see in most product teams.

The fix isn't a framework or a methodology. It's a shift in thinking. Start with demand, not supply. Study the system, not the individuals. Measure what matters to the customer, not what's easy to count. And give the people closest to the work the authority to change it.

If you work in software and you haven't read it, I'd recommend picking it up. It'll make you uncomfortable about a lot of things you've accepted as normal. That's the point.