A Conversation About John Seddon

A Conversation About John SeddonWhen Experienced Software Developers First Meet Systems Thinking

I had one of those conversations recently that left me genuinely surprised. I was talking with a group of experienced software developers—people who’ve been building software systems for years, who understand the pain of technical debt, who’ve lived through countless ‘transformations’ and process improvements. Smart people. Seasoned people.

And none of them had heard of John Seddon.

These developers, who instinctively intuit that systems thinking matters, who’ve seen agile transformations fail because they focused on process rather than folks’ real needs—had never encountered the work of perhaps the most practical systems thinker of our time.

So when John Seddon’s name came up in passing, their curiosity took over. What followed was one of those conversations where their questions and insights drove everything, with me occasionally sharing what I knew when they wanted to explore an idea further.

Their Curiosity Takes Over

‘I’ve never heard of him,’ one said immediately. ‘What’s he about?’

‘John Seddon,’ another repeated. ‘That name means nothing to me. What’s his field?’

I mentioned that he’s a British occupational psychologist who developed something called the Vanguard Method—a combination of systems thinking and intervention theory for transforming service organisations.

‘Service organisations?’ someone asked. ‘Like what?’

When I mentioned that John focuses on how management thinking determines organisational performance, they started making immediate connections.

‘Wait,’ one said, ‘is software development a service organisation? I mean, even when we’re building products, each is quite unique. We’re not stamping out identical widgets like in a factory.’

This sparked an immediate discussion. They started listing characteristics of their work:

Each product/feature is largely unique and contextualRequirements emerge and evolve during developmentHeavy customer interaction and feedback loopsQuality depends heavily on contextWork is primarily collaborative, intellectual knowledge workProduction and consumption often happen simultaneously, with continuous delivery

‘So we’re definitely a service operation,’ someone concluded. ‘That explains why every time management tries to treat us like a factory, everything falls apart.’

Diving Into the Ideas

‘So what’s this Vanguard Method about?’ they wanted to know.

I shared how Seddon challenges most conventional management wisdom, particularly around targets, metrics, and organisational design.

‘Like what?’ they pressed.

When I mentioned his concept of ‘failure demand’—work created by failing to do something right the first time—their interest was clearly piqued.

‘Bazinga!’, one said. ‘How much of our work is failure demand? Hotfixes, rework because requirements weren’t clear, support tickets that could have been prevented by better design…’

‘Probably sixty per cent,’ another estimated. ‘And management keeps asking us to be more efficient in dealing with our failure demand, instead of questioning why we have so much.’

They wanted to know more. ‘What else does he say?’

I mentioned his distinction between ‘economy of scale’ and ‘economy of flow’—that optimising individual components often makes the whole system worse.

‘We learnt this the hard way,’ someone said immediately. ‘We had these “efficient” specialised teams, but so many handoffs that simple changes took months. When we reorganised so teams could handle customer requests end-to-end, everything flowed better.’

Making Their Own Connections

‘Does he have books?’ they asked. ‘What are his main ideas?’

‘What’s he written about specifically?’ another wanted to know.

When I mentioned he’d written something called ‘The Case Against ISO 9000’, one immediately perked up: ‘ISO 9000? Bejabers, we spent months getting ISO certified. The process was so bureaucratic it actually made it way harder to ship good software. What’s his take on it?’

‘He argues that quality standards and specifications actually impede quality in service organisations,’ I shared.

‘That makes complete sense,’ they said. ‘What else has he written?’

I mentioned ‘Freedom from Command and Control’, and someone asked: ‘What’s that about then?’

As I described it briefly, they started connecting: ‘This sounds like he’s talking about the same principles we use for system architecture, but applied to organisations.’

‘Does he write about corporate, government and public sector stuff?’ another asked.

When I mentioned ‘Systems Thinking in the Public Sector’, there were knowing looks around the room: ‘Oh, this sounds like every large company I’ve worked at. The same dysfunctional patterns. What does he say about that?’

‘What strikes me,’ one reflected as we talked, ‘is that we understand how architecture decisions affect the whole system’s behaviour. We know that optimising one service can slow down the entire application. But somehow we don’t think about applying that same approach to how the organisation itself works.’

‘Right,’ another said. ‘We know our work is service work, not manufacturing. But we haven’t thought about what that means for how the work should be designed.’

Their Discoveries

‘So traditional management follows Plan-Do-Check,’ someone said, ‘but you’re describing Check-Plan-Do. Understanding current reality before planning interventions.’

They started exploring this on their own:

Check: Understanding the current system, actual needs, real pain pointsPlan: Designing interventions based on evidenceDo: Implementing changes and studying results

‘This is exactly what we do for debugging,’ one realised. ‘But imagine if we did it for feature development too.’

The conversation kept evolving organically. Someone brought up metrics gaming: ‘We had a team measured on velocity, so they started breaking stories into smaller pieces. Velocity went up, but we weren’t meeting folks’ needs any faster.’

‘Right,’ another said, ‘the measure became meaningless because it wasn’t connected to actual purpose. What does Seddon say about that?’

When I shared his sequence of Purpose-Measures-Method, they immediately grasped it: ‘You need to understand what you’re actually trying to achieve before you can measure whether you’re achieving it.’

Challenging Sacred Cows

The questions kept coming. ‘What about shared services? We see that everywhere.’

I mentioned how Seddon argues that shared services often create more waste through coordination overhead.

‘Makes sense,’ someone said. ‘We tried a centralised platform once. It was supposed to improve efficiency but became such a bottleneck that teams started working around it.’

‘What about standardisation?’ another asked.

When I shared Seddon’s view that attempting to standardise inherently variable work creates bureaucracy without improving outcomes, more stories emerged:

‘We spent two years standardising our deployment process across all teams. The “standard” was so complex that every team had their own workarounds. We would have been better off letting each team optimise their own pipeline.’

Understanding the Deeper Patterns

‘This is fascinating,’ one reflected. ‘He’s basically saying that most management approaches assume work is predictable and controllable, right? Like manufacturing?’

They started exploring the difference between command-and-control thinking and systems thinking:

Command and control assumes:

Work can be specified in advanceIndividual optimisation improves the wholeVariation is badPeople need external motivation

‘But software development is emergent,’ someone said. ‘You learn what folks need by building it. Services are contextual—you can’t specify them completely upfront because you don’t know what folks really need until you start delivering value.’

Systems thinking recognises:

Work is emergent and contextualSystem design determines performanceVariation provides informationPeople want to do good work

‘That’s why every time we try to estimate work upfront, it feels wrong,’ another realised. ‘We’re operating in command-and-control mode, but the work is inherently emergent.’

Their Bigger Insights

As the conversation continued, they kept making larger connections:

‘This isn’t just about management theory,’ one reflected. ‘This is about work design. Seddon is talking about the same principles we use to design good software architecture, but applied to the design of how the work works.’

‘Exactly,’ another added. ‘We know how to build software that works, but we’ve been building it inside dysfunctional organisations that don’t work. No wonder so many efforts fail despite good technical practices.’

‘And most transformation efforts fail because they change processes without changing mental models,’ another observed. ‘Like most ‘Agile’ transformations that just become more sophisticated command and control.’

The Deming Connection

‘Where do his ideas come from?’ someone asked.

When I mentioned his foundation in Deming and Taiichi Ohno’s work, they got interested: ‘We’ve been talking about Lean and DevOps for years, but we never really understood why these practices work. It sounds like Seddon explains the underlying principles.’

‘Right,’ someone said. ‘The practices that work are the ones that focus on understanding what customers actually need and organising work to meet those needs effectively.’

Making Deeper Connections

As our conversation continued, I shared how Seddon’s work builds on the thinking of W. Edwards Deming and Taiichi Ohno—names that resonated with them somewhat from their exposure to Lean and DevOps practices.

‘We’ve been talking about Lean and DevOps for years,’ one reflected, ‘but we never really understood why these practices work. It sounds like Seddon explains the underlying principles.’

They were particularly intrigued by how Seddon didn’t just adapt Lean manufacturing principles—he understood them at a deeper level and applied them to service organisations. This explained why blindly copying practices often fails while understanding principles succeeds.

We explored Ohno’s concept of ‘economy of flow’ over ‘economy of scale’, and how this directly challenges the tendency to create large, specialised teams and shared service platforms. Through their own experiences, they were discovering that small teams delivering end-to-end value consistently outperform larger, ‘more efficient’ organisational structures.

Uncovering Mental Models

This led to perhaps the most intense part of our conversation. I asked them to think about the assumptions underlying traditional management approaches they’d experienced.

‘What do you think management believes about work and people?’ I wondered.

They started listing assumptions they’d encountered:

You can specify the work in advanceYou can measure individual components and optimise the wholeVariation is bad and eliminatedWorkers need to be controlled and motivated

‘And how does that match your experience of software development?’ I asked.

‘It doesn’t,’ came the immediate response. ‘Software development is inherently emergent—you learn what you’re building by building it.’

This opened up a rich discussion about the difference between command and control thinking and systems thinking. Through our conversation, they articulated the systems perspective:

Work is emergent and contextualThe system’s design determines performance, not individual effortVariation is information about how the system worksPeople want to do good work; poor performance usually indicates system problems

‘And that’s because we’re doing service work, not manufacturing,’ one added. ‘Services are contextual and emergent. You can’t specify them completely upfront because you don’t know what the customer really needs until you start delivering value and getting feedback.’

The Obduracy Problem

‘You know what’s really frustrating?’ one said. ‘It’s not that we don’t know what works. We absolutely know what works.’

‘Right,’ another agreed. ‘There’s this brilliant piece about “obduracy” – how organisations will absolutely not do the things that they know make software development successful.’

They started listing examples they’d seen:

Everyone knows teamwork produces better results, but organisations reward heroic individualismEveryone knows people skills matter most, but hiring focuses on technical skillsEveryone knows workers owning how the work works produces better outcomes, but management mandates processesEveryone knows quality comes from prevention, but organisations rely on testing and inspectionsEveryone knows intrinsic motivation works better, but organisations use carrots and sticks

‘It’s maddening,’ someone said. ‘The things we need – trust, systems thinking, focus on effectiveness rather than efficiency – these aren’t secrets. But organisations choose the opposite every single time.’

‘And that’s the category error again,’ another reflected. ‘They’re applying industrial-era management to knowledge work, even when they know it doesn’t work.’

An Unexpected Realisation

‘It’s odd that we’ve never heard of him,’ one reflected. ‘Everything we’re discussing aligns perfectly with what we intuitively understand about good software development.’

‘Right. We’ve absorbed pieces through Lean, DevOps, Agile,’ another said, ‘but we missed the deeper theoretical foundation.’

‘It’s like we’ve been doing systems thinking instinctively but didn’t have the framework to understand why it works,’ someone added.

Their Next Steps

‘Where do we start reading?’ they wanted to know.

I suggested ‘Freedom from Command and Control’ as the most accessible introduction.

‘What about applying this stuff?’ someone asked.

‘Start with your own context,’ another suggested. ‘Identify failure demand in our development process. Study how work actually flows through our organisation. Question whether our measures really tell us what we think they do.’

‘Right, but we’re getting ahead of ourselves,’ someone else reflected. ‘Seddon would probably say we’re being too theoretical here. We’re talking about solutions without doing the actual work of studying our system. We haven’t mapped what our demand actually looks like, how work flows from customer request to delivery, where the real constraints are.’

‘And we’re doing that thing where we complain about management without understanding what they’re responding to,’ another added. ‘What’s driving their behavior? What pressures are they under that make them act the way they do?’

‘Exactly. And Seddon probably wouldn’t want us treating him like another management guru with answers to copy. The whole point is that we need to study OUR work, not read about his.’

‘Actually, we’re probably still thinking too narrowly,’ someone else said. ‘We’re talking about “software development” as if it’s a separate system, but it’s really just part of the larger business system. What’s the business actually trying to accomplish? What’s our role in that?’

‘Right, and we’re doing that problem-solving thing – “fix the organization” – instead of asking what the system is actually FOR. What’s the real purpose here? Are we trying to deliver software, or help the business achieve something? And where’s our constancy of purpose? We haven’t even defined what we’re actually trying to accomplish.’

‘And we’re just trading anecdotes and complaints,’ another added. ‘Where’s our data about variation in the system? How long do things actually take? What’s the real distribution of our cycle times? We’re not studying the system, we’re just telling war stories.’

‘Plus we’re talking like this conversation is going to change something,’ someone said with a wry smile. ‘Deming would probably point out that transformation takes years of consistent work, not conversations in meeting rooms. We sound like we want quick fixes.’

‘And we’re still doing that thing where we blame people – “management won’t change” – instead of understanding the system that creates those behaviors. What constraints and pressures make management act the way they do?’

‘Good point,’ another agreed. ‘Before we can design anything better, we need to understand what we have. What percentage of our work really is failure demand? How long does work actually sit in queues? What do our customers actually need versus what we think they need?’

‘That’s the “Check” part of Check-Plan-Do,’ someone said. ‘Study the work as it actually happens, not as we think it happens.’

Realisations

As our conversation drew toward a close, they began articulating why this exploration had been so valuable:

‘This isn’t just about management theory,’ one reflected. ‘This is about system design. Seddon is talking about the same principles we use to design good software architecture, but applied to organisational design.’

Another added: ‘I feel like I’ve been missing a huge piece of the puzzle. We know how to build systems that work, but we’ve been putting them inside organisations that don’t work. No wonder so many projects fail despite good technical practices.’

They identified several key insights:

Understanding software development as service work changes everything about how it is organised and managed. Most management dysfunction in software comes from applying manufacturing thinking to service work.Systems thinking provides tools for organizational design that focus on how work flows through the organization rather than optimizing individual roles or departments.Most ‘transformation’ efforts fail because they focus on changing processes rather than changing how managers think about the work itself.Effective practices work because they organize work around customer needs rather than internal convenience or efficiency metrics.The root cause of many frustrations can be traced to the mismatch between the nature of their work (service) and how organisations try to manage it (manufacturing approaches).Reflecting on the Conversation

What struck me most was how naturally they engaged with these ideas. Everything Seddon talks about—understanding how work flows, measuring what actually matters to customers, designing organizations around the work rather than abstract efficiency—aligned perfectly with their intuitive understanding of what makes teams effective.

‘The fact that experienced developers haven’t encountered this work is interesting,’ one said. ‘There seems to be a real disconnect between the people thinking about organisational design and the people actually doing the work. Which is exactly the problem, isn’t it?’

‘Right,’ another said. ‘That disconnect isn’t a mystery, it’s the core problem. Organisations designed by people who don’t do the work, imposed on people who aren’t consulted about the design.’

‘And apparently businesses have decided they can afford to keep wasting good technical work through organizational dysfunction,’ someone else added wryly.

By the end, they’d arrived at their own conclusion: ‘Seddon has spent nearly fifty years proving there’s a better way to organise work. For software developers, his insights aren’t just theory—they’re practical tools for creating organisations that actually support the work instead of getting in the way.’

The question they left with wasn’t whether his approach works—they could see the evidence in their own experiences. The question was whether management is ready to engage with the deeper thinking required to create truly effective organisations.

Their curiosity had taken them from never hearing the name John Seddon to recognising him as someone who might help them understand why good teams often get undermined by organisational dysfunction—and what they might do about it.

Further ReadingPrimary Works by John Seddon

Seddon, J. (1997). I want you to cheat!: The unreasonable guide to service and quality in organisations. Vanguard Education.

Seddon, J. (2003). Freedom from command and control: A better way to make the work work. Vanguard Education.

Seddon, J. (2008). Systems thinking in the public sector: The failure of the reform regime… and a manifesto for a better way. Triarchy Press.

Seddon, J. (2014). The Whitehall effect: How Whitehall became the enemy of great public services – and what we can do about it. Triarchy Press.

Seddon, J. (2019). Beyond command and control. Triarchy Press.

Case Studies and Applications

Middleton, P., Joyce, D., & Pell, C. (2011). Delivering public services that work: Vol. 1. Triarchy Press.

Pell, C., Middleton, P., & Joyce, D. (2012). Delivering public services that work: Vol. 2. Triarchy Press.

Related Thinking on Organisational Design

Marshall, R.W. (2018). Hearts over diamonds: Serving business and society through organisational psychotherapy – an introduction to the field. Leanpub. https://leanpub.com/heartsoverdiamonds

Marshall, R.W. (2021). Memeology: Self-help for organisational psychotherapy. Leanpub. https://leanpub.com/memeology

Marshall, R.W. (2021). Quintessence: Ground-breaking new approach to software delivery for the 2020s. Leanpub. https://leanpub.com/quintessence

Marshall, R.W. (2021, February 21). Management monstrosities. FlowChain Sensei. https://flowchainsensei.wordpress.com/2021/02/21/management-monstrosities/

Marshall, R.W. (2012, September 5). Obduracy. FlowChain Sensei. https://flowchainsensei.wordpress.com/2012/09/05/obduracy/

Related Systems Thinking Literature

Checkland, P. (1999). Systems thinking, systems practice. John Wiley & Sons.

Deming, W. E. (1986). Out of the crisis. MIT Center for Advanced Engineering Study.

Ohno, T. (1988). Toyota production system: Beyond large-scale production. Productivity Press.

Senge, P. M. (2006). The fifth discipline: The art and practice of the learning organisation. Random House Business Books.

Academic Papers

Jackson, M. C., Johnston, N., & Seddon, J. (2008). Evaluating systems thinking in housing. Journal of the Operational Research Society, 59(2), 186-197.

O’Donovan, B. (2012). Editorial for special issue of SPAR: The Vanguard Method in a systems thinking context. Systemic Practice and Action Research, 25(6), 393-407.