When systems(thinkers) collide

When I come across a great thinker that opens my eyes to new ideas I always try to look for errors in their reasoning. The obvious reason to do this is as a safeguard against being carried away by new ideas that are intuitively right but actually wrong. A second reason for this scrutiny is a guiding principle of mine. If I am unable to find anything wrong in someone’s thinking it is a sure sign that I am becoming dogmatic. So when two people I greatly respect started arguing, I saw this as a good thing. Simple logic told me that at least one of them would be wrong in some sense…

There are some great videos on Vimeo from the Lean & Kanban 2011 Benelux conference. Donald Reinertsen’s talk: Is it time to rethink Deming? is a great talk only marred by that fact that he makes frequent references to slides that you cannot see. Reinertsen pours some cold water on the relevance of Deming’s thinking to software development. One of the reasons I like the talk so much is probably confirmation bias. One of the things Reinertsen “attacks” in the talk is Deming’s 94% rule which is something I have also been sceptical of.

John Seddon’s talk It’s the system stupid is as always both entertaining and thought provoking. He has his trademark style which is weirdly self-contradicting: he spreads scorn over people that do not understand his message, that problems in an organization are caused by the system and not the people. About halfway through his talk, Seddon takes on the 94% issue and dismisses Reinertsen’s arguments as typical of an unenlightened manager.

Where do they go wrong?

So who is right? In my view both Reinertsen and Seddon are partly right and partly wrong. The trap both fall into is in not being precise in the context of their arguments.

I think Reinertsen is right when he argues that Deming’s famous 94% is not a precise estimate. It is simply Deming’s way – as a statistician – of saying that the system is a lot more important than the people. But then Reinertsen backs this up by comparing the variation in ability of individual programmers. The problem with this example is that it is largely irrelevant to the discussion of what affects the way a system works. As most people know, a bad system can beat a good person.

After his disparaging remarks about Reinertsen, Seddon embarks on an example that is meant to prove how misguided the notion of people over system is. He shows how a sales manager is amazed when she discovers the the performance of sales representatives in a call center is mostly due to the system. Seddon seems to imply that this example proves that even in sales, the most important factor is the system. I hope Seddon knows more about sales that to think that sitting in a call centre answering calls is all there is to sales. I have worked with some great salesmen in my life and the last thing they would do is to sit and wait for a telephone to ring. They work with multi year strategies where they gather information about a target customer and slowly convince this customer to buy. Taken to its logical extreme Seddon’s view seems to imply that Picasso was just lucky in the canvasses he got.

So, to sum it up: Reinertsen is right in that some programmers are better that others but wrong in believing that this demonstrates much about the importance of individuals over a system. Seddon is right about how important the system is, but wrong in implying that this is true of all human endeavour. There are a lot of things people do that are not constrained by a system.

Niklas Björnerstedt

Posted on 2011.10.22 at 20:38

Comments are off for this post.

One Response to When systems(thinkers) collide

  1. smalltalk80 says:

    Bob Marshall on October 23, 2011 at 9:28 am said:

    How does it help to make judgements about who is right and who is wrong? And what does “right” and “wrong” mean, anyway?

    BTW I was there and would not have described John Seddon’s remarks as “disparaging”. Confrontational, maybe (that’s his chosen style). I choose to appreciate the remarks of both gentlemen as “helpful in context”.

    Thanks for the post!


    – Bob @flowchainsensei

    Yuval yeret on October 23, 2011 at 5:33 pm said:

    My perspective on this ( as I stated on twitter around the time of Seddons talk both at LKBE11 & LKCE11) is the following:

    A bad system can indeed beat good people
    BUT good people should work on changing the system
    Great organizations create double loop learning systems where people are empowered to change their context/system based on how bad/good it’s serving them.

    Some examples of this are retrospectives, kaizen, improvement kata, evolving standard work / explicit policies.

    – Yuval ( @yuvalyeret)

    Niklas Bjørnerstedt on October 23, 2011 at 8:43 pm said:

    Bob, I agree that the words right and wrong are very absolute. On the other hand, I do not want to fall into a relativistic trap where everything is equally valid. For my part I try to teach myself to like being shown to be “wrong”, it should be an integral part of learning.

    Look at the video. Seddons reaction to Rinertsens (inaudible) explanation of what he meant is not nice, neither is his handling of what Reinertsen had said in his talk.

    (Nice of you to comment, btw. When I wrote this I used you as my mental model of a critical reader 🙂

    Niklas Bjørnerstedt on October 23, 2011 at 8:49 pm said:

    Yuval, I agree with you with one reservation. The things you list at the end (retrospectives, kaizen, improvement kata, evolving standard work / explicit policies) are all tools/approaches that must be evaluated in context. In some situations some of these tools/approaches may not be appropriate.

    Niklas Bjørnerstedt on October 24, 2011 at 9:03 am said:

    Donald Reinertsen and I had an exchange about this blog on twitter (reproduced here with his permission):

    @smalltalk80 Does the fact a bad system can beat a good person mean that the system is the dominant influence on performance?

    @smalltalk80 5g of salt can ruin a 250g Michelin meal. Does that mean 94 percent of cooking is getting the salt right? 🙂

    @DReinertsen I think we agree that assigning a percent to the relative importance of system vs individual is meaningless

    @DReinertsen That said, the core message from Seddon is that in many orgs you will get a lot farther by improving the system

    @smalltalk80 Strongly agree. There is wide spectrum of orgs and situations and great danger in assuming leverage always lies in same place.

    Yuval yeret on October 24, 2011 at 11:09 am said:

    Sure, the tools are just examples. The basic thinking of a system that includes people in the feedback loop for how the system works is quite generic. Cannot think of many scenarios where this would be a bad idea
    Kris Lander on October 24, 2011 at 11:55 am said:

    Reminds me of something I tweeted a while back about what I called the Deming paradox – if you don’t have individuals in an org that understand how the system will impact the effectiveness of people/org/system then as an org you may be doomed to failure.

    There is no doubt that in my mind that in the case of software development and the systems we create around that process people are a highly variable, highly significant factor in the performance of that system. The important thing is that all the people in that system both recognise how that system impacts them and how their unique individuality effects the system. The greater this awareness exists in your people the more you can empower them to self-organise and let the system adapt and emerge naturally.

    Don Reinertsen on October 24, 2011 at 4:07 pm said:

    I’ve mentioned this in other settings, but it may be worth restating. I think it is fundamentally wrong to think that (systems + people = performance). In the Navy we used to joke about systems designed by geniuses to be run by monkeys. On nuclear submarines our model was multiplicative (systems x people = performance). In such a model you need to pay attention to both factors. In an additive model, if you believed the system was 94 percent of performance, then you could populate a great system with idiots and you would only lose 6 percent of its potential performance. This is not what really happens. In a multiplicative model performance drops severely when either factor becomes small. I find it a much better fit with my experience.

    Chris Matts on October 24, 2011 at 4:26 pm said:


    I’m with Don here. Its about people and systems. A great system populated by monkeys will fail. A poor system populated by motivated high performers might fail but just as likely the high performers will rise up and change the system, or subvert the system until it works well enough. The sweet spot is obviously good system and good people.

    I’ve observed that those who elevate the system way above the people are often consultants (rather than practitioners) who want the world to know that as far as they are concerned, the manager is the MOST important person in the organisation. Whether they are command and control or a more facilitative manager, the message is the same, “The manager is king”. As the manager normally has strict control of the company chequebook. They might as well say. “Hire me, it safe to do so because I think the manager is the most important person the organisation, because they are the one who owns the system (even if they delegate responsibility to some facilitative process)”.

    The problem with the people thing is that is messy. No consultant is going to stick their neck out and say “I can fix your people problem with a few amusing soundbites”.


    Niklas Bjørnerstedt on October 24, 2011 at 8:36 pm said:


    I both agree and disagree with your reasoning. It is certainly true that a system is the product of both people and process. On the other hand I think Seddon is right in that it is extremely common in areas such as banking, insurance and government to find that the core problem they need to fix is the system, not the people. You tweeted that salt could not be considered 94% of the cooking. If you, like Seddon had continually met cooks that where adding salt by the bucketload you would be right in saying that salt was the dominant issue in their cooking. (I know I am mauling an analogy here, but I couldn´t help myself.)

    Niklas Bjørnerstedt on October 24, 2011 at 8:50 pm said:


    I hope you are not trying to imply that Seddon is only a consultant trying to puch his wares. There is a lot more to him than that. If you have not heard it before, listen to this podcast by him: http://www.thesystemsthinkingreview.co.uk/index.php?pg=18&backto=18&utwkstoryid=186&title=Rethinking+Lean+Service&ind=0

    Seddon has an abrasive style. I guess this in part comes from the environment he works with. Great Britain’s public sector seems to be extremely dysfunctional and poorly managed. But if you just ignore his style and listen to what he has to say i think you will find that he has some tremendously important insights.

    Chris Matts on October 25, 2011 at 10:48 am said:

    Hi Niklas

    Not at all. In fact, Seddon’s experience is with service centres where its probably truer (word?) to say that the system has a bigger impact than the individual. Service centres are the mass production end of knowledge work where the system dominates. IT Development is not a mass production process. My concern with Seddon is not with Seddon himself. My concern is with people in IT who promote him as having something profound to say about IT. Who say “Seddon says the system is important so it must be”. Lets be clear. Seddon has not worked on an IT project. We have.

    IT development is not like service centres. The system has an impact on development, but the individuals are much more important than just the 6% that Deming ascribes to them. From my experience, individuals have been much more infuencial than the system. So I am firmly with Don here. Individuals make a big difference in high performance teams, whether in formula one, or running a nuclear submarine… where they are following procedures. In IT, where the team are WRITING the procedures, the individual is even more important.

    I have listened to Seddon. I first saw him talk at the Agile Business Conference in 2004. I listened and was inspired enough to read “Freedom from Command and Control” which was less inspiring. I saw him present at the Lean Kanban Conference in London 2009. I arranged for him to talk at the London Business Analysis Conference. He said he would tell the BAs stuff they would not like to hear… The reality is that he has delivered the same talk at each conference (with minor variations, the Portsmouth Housing Authority Story was a new addition in 2010). His main contribution (and its a big one) is to call out “Failure Demand” because IT Developers saw fixing bugs as important value creating work rather than rework because they did not do it right the first time. Having said that, you may find “Sense and Respond” by Steve Parry to be a more useful test on how to address “Failure Demand”.

    So for clarity. I see the individual and the system being important. The system does not dominate in software development.

    Consider why people would consider the system more important than indiviudals. Sub-consciously, they probably realise they have something to say ( and sell ) and systems but not about people.


    Mark Stringer on October 25, 2011 at 12:37 pm said:

    What would the experiment look like that would prove that “it’s 94% down to the system?” Is this experiment different for software than for other kinds of systems? Why? Could this experiment be run?

    If we can’t say what that experiment would look like then all Seddon and Deming are saying is “The system’s quite important, you should pay attention to system issues.” And all Reinertsen is saying is “Mmm. People are quite important too.”

    Niklas Bjørnerstedt on October 25, 2011 at 9:15 pm said:


    I agree with most of what you say but still feel you are in some ways short changing Seddon. True, he does not know much about software development (he acknowledges as much at the beginning of the talk). What he does have experience with is seeing how some of the systems we build work in practice. Using an agile approach does not help much if you are building the wrong thing. I find it symptomatic that so many people hate workflow systems. People can gripe about their word processor but would scream if you tried to take it away from them.

    You say that his message is mostly relevant to service centers. I would argue that it is also relevant in many other areas (but not as much in software development). I would also argue that it is much more common for managers to manage their employees closely but be clueless about how things work than erring the other way. I suspect there is a basic cognitive bias in humans which makes us prone to place blame on people rather than the system.

    A last point. Failure demand in software development is about a lot more than bugs. Every time a customer has to ask about a desired feature more than once is also failure demand. I am not saying it is easy to eliminate this kind of waste, but waste it is.

    Niklas Bjørnerstedt on October 25, 2011 at 9:29 pm said:

    Yes, the 94% thing is meaningless. I blogged about this a while back: http://www.leanway.no/?p=362
    The core message from Deming and Seddon here is not the percent but the fact that many businesses are focusing way to much on “people” problems when these are in fact caused by the system. If it was common for businesses to focus too much on the system the case would be different. I have never seen this in practice though, have you?

    Chris Matts on October 26, 2011 at 11:45 am said:

    Hi Niklas

    Thank you for this interesting conversation. I think we agree on a lot but we are misunderstanding each other on the other. I suspect that I am not being as clear as I could be.

    I am not short changing John Seddon. I am crediting him for his major contribution, which is “Failure Demand”. As I mentioned before, I would recommend “Sense and Respond” for a much more practical and useful coverage of the subject. Seddon’s other contribution is that he is an engaging and entertaining speaker which makes him an easy and safe keynote (I should know, I was involved in hiring him for the London BA conference). Although a great keynote, I’ve never seen a tutorial in the Vanguard method at these conferences where people can learn about the techniques he inspires them to learn.

    My problem is that whilst Seddon is on stage, he is taking the place of someone who has relevant experience to IT Development. There are many experts in system thinking in IT development. Many people who have seen dysfunctional systems and fixed them. Why aren’t we listening to them?

    My view is that Seddon’s lack of experience with IT development is why he thinks the system is so important compared to people. In call centres his view is probably correct but I couldn’t really say because I have no experience with call centres.

    In IT development, practitioners view both people and the system as important.

    My concern is not with Seddon. My concern is with people in IT Development who place too much importance on the views of someone who’s experience is not relevant to IT Development. Quite often, because what he says fits with their agenda. The same applies to Deming and it was refreshing to see Don Reinertson take a critical look at the relevance of Deming to Product Development ( which is more similar to Software Development than designing call centres ).

    From my view, a customer who keeps asking for a service that the company does not provide is not failure demand. I do it intentionally to companies to annoy them. Obviously Seddon will be the authority on the true definition of failure demand. As I say, try reading “Sense and Respond”, you might development a different perspective.

    Many thanks


    Lasse Koskela on October 26, 2011 at 12:04 pm said:

    > I’ve never seen a tutorial in the Vanguard method at these conferences
    > where people can learn about the techniques he inspires them to learn.

    Seddon has said on various occasions that Vanguard’s way of doing business is to spark interest and wait for the phone call. Then their consultants go and do their magic. They don’t offer training. What they do is their IPR. It’s difficult to copy and obviously Vanguard likes it that way.

    Chris Matts on October 26, 2011 at 12:11 pm said:


    Thank you for that insight.

    So basically the keynote is an advert for Vanguard’s services, and they have no intention of sharing knowledge.

    A few years ago at an Agile20xx session, someone said “If you want to know how to solve these problems/do that stuff, you have to hire me.” A friend who sat in the audience was horrified. It would appear that if that person was delivering the keynote, they would probably gotten a round of applause at that moment.

    David Joyce on October 26, 2011 at 12:59 pm said:

    It is my understanding that some of Seddon’s people have worked on IT projects. I have seen some examples of their work in this area. So to say Vanguard haven’t worked in IT is incorrect. They havent published anything yet in terms of case studies.

    I have worked in software organisations (service and non service) where the workers are hindered by imposed targets, KPIs, objectives, processes, procedures etc. all of which are outside of the workers control. Created by management.

    Its not a question about how skilled a person is (or how talented a software team are) but how much these systems conditions affect their performance or ability to improve. You could have the best people in the world, but they will still be hindered. The point made about building the wrong thing is another good example.

    That is the message the red bead game/”experiment” tries to convey, it’s management’s job to remove these red beads (system conditions) as the worker is unable to. No matter how many retrospectives an agile team holds.

    Deming was fond of say that quality comes from the top. Only top management has the knowledge and the right to change the system the worker works in (the Japanese say “the fish rots from the head”).

    It was Juran who first made the distinction between defects coming from the system and defects coming from the worker. His experience was that 85% are caused by the system and only 15% by the worker. Deming attributed his statements on the system affecting performance to Juran. Towards the end of his life, Deming was more and more inclined to suggest that the the relation should be 94% and 6% respectively. Seddon says it’s 95-5.

    I personally think the % is irrelevant, in my experience though it is the majority whatever the figure.

    It is also ironic that many “solutions” that we in IT produce actually end up hindering our fellow workers (becoming system conditions). Again I have seen this many times myself, people using all sorts of workarounds or vent their frustration about IT “solutions” cascaded down upon them that do not help and make things worse.

    It is however pointless to argue. Unless you have seen it for yourself you are unlikely to believe it. Im not commenting on here to defend Seddon or Deming or Juran or Scholtes or Joiner or Middleton or the Deming Institute etc my reasoning is that as I have seen this occur myself, in multiple organisations, then I believe it (the majority regardless of actual %) to be true.

    What I see on this post (and is true to of any argument really) is we just end up talking past each other as we each feel we are “right”. Experience is key.

    Niklas Bjørnerstedt on October 26, 2011 at 9:25 pm said:


    Yes, I also suspect we agree on a lot. As they say: “Communication is hard, especially between two people”. In a way a central theme in my post and the following thread is the difference between what you intend to say and what different audiences hear. Some people will hear Reinertsen and think that he “proves” that people are always more important than the system. Others hear Seddon and think that the system is everything. I am trying to balance the debate by basically saying: 1. Yes, every context is unique in terms of where the problems lie. 2. It is much more common for managers to underestimate the importance of the system than to err the other way.

    As to what is failure demand, my view is that the meaningful distinction is between interactions with the customer that create value and those that do not. If I understand Seddon correctly he does not view the reporting of a problem as failure demand. It is when customers repeatedly have to contact an organization to solve one problem that it becomes failure demand. One could argue that in an ideal world even the first call is unnecessary. In software I can not see any value being created when customers repeatedly have to ask for the same problem to be fixed. Many software businesses have a whole layer of people whose sole job is to help customers push their issues through the system.

    Niklas Bjørnerstedt on October 26, 2011 at 9:50 pm said:


    I am also bothered by the implicit message: Only the Vanguard method works and we are the only ones that know it. Seddon should open source it. That said, my understanding of the Vanguard approach is that the core element is to get managers to study the system by immersion. I could have said “go to the gemba” but it makes my skin crawl.

    Chris Matts on October 27, 2011 at 10:16 am said:

    Hi Niklas

    I think we are very very close to agreement here.

    I think the argument is slightly more nuanced. Deming said 94% of the performance of the manufacturing system was down to the system. Seddon says in call centres it is 95%. This message means “the individual is insignificant compared to the system. Now this may be true for manufacturing or call centres.

    Don Reinertson is saying (and I agree with him) that for product development (and I agree for software which is similar in form to product development), that both the individuals AND the system are important. From experience, the context determines which one needs the most work to improve the system. I agree that managers AND their staff have a problem in that they are scared to challenge the system, and are not aware that it can be changed to improve things. (There is a nice HBR article on how Toyota train their managers that covers this. Cannot remember which.)

    Neither Deming or Seddon have experience of working on an IT Development team. If they did work on several, they would probably agree with Don.

    I would argue that a customer calling about a bug for the first time is failure demand.


    Chris Matts on October 27, 2011 at 11:05 am said:

    Hi David

    Thank you for joining the party. 🙂

    I do not believe I said that no one at Vanguard had worked on an IT Development project. I said that Seddon had not. Perhaps “Going to the Gemba” has been replaced by “Send your people to the Gemba”? Is this part of the secret Vanguard method I wonder? Will we ever know?

    Given Vanguard’s stated intent to keep their methods closed, I do not see any point in them sharing their experience in experience reports. The experience report would simply be yet another advert for Vanguard with no learning for the community apart from “Wow, I must hire Vanguard”. I look forward to a time when they “open source” their material in the same way that DSDM did with ATERN. Until they want to share I think we should ignore them.

    The message of the red bead games is simple. If you have a random process, nothing you do will change the distribution of the results. We could change the game slightly and have the player roll a number of dice. Every dice with a “1″ would be a defect. The same game. The difference is that you could modify the game to say you want a defect free result set. Roll the dice and then intervene with the “defects”. You can then see the impact of management intervention. When considered as a rolling of the dice, the red bead game is revealed as fatuous. Its the same as saying “If I chew gum, England will win at Football”.

    As far as I am aware, none of Seddon, Deming, Juran, Scholtes, Joiner, Middleton or Deming worked in software development. If they did, they may have a different view. I respect their opinions in their domain but consider the difference to be significant enough that I will take inpsiration from their words but will not follow them dogmatically. (FYI. I first studied Deming 20+ years ago as part of my degree. I have followed his ideas since, especially thinking for myself. 🙂 ). As you know, Don has worked in Product Development and has a different view to the list you provide.

    Over the past 20 years I have encountered projects where the people were the dominant factor and others where the system dominated. The ones where the system dominated tended to be ones where I did not know enough to challenge the system. Mainly at the start of my career. One story comes to mind. Years ago I worked for Thoughtwork at a client. The client had processes and governance that made it hard to run an Agile project effectively. Rather than complain about the system, the Agile Managers collaborated with the Client’s IT management to make their projects look like a normal project. They called this approach “Square Peg Adaptor”. Individuals created this approach. They mitigated the impacts of the system.

    You are saying that your experience tells you that the system dominates.

    My experience tells me that both the system and the individual are important, and one may dominate based on context.

    What experience or data could I provide that would allow you to break out of your current system of thought. Similarly, what data do you have that would convince me that my experiences are an anomoly?


    Bob Marshall on October 28, 2011 at 8:49 am said:


    MMM on November 10, 2011 at 2:13 am said:

    Personally thought Donald Reinertsen’s talk was a good comedy act.

    I don’t know who he is and therefore cannot speak about his intention, only describe what he delivered so convincingly as a speaker in Belgium. He makes people go and read what Deming really wrote by presenting an ironic mix of Deming/Shewhart misrepresentations, straw-man arguments, historical fabrications and mathematical gibberish (didn’t you get suspicious when he said sampling isn’t empirical experimentation?). He mocked many of the staple foods of the agile and lean world and makes us question the basics. See it as a form of hidden retrospective at the start of a conference. I hope it works and people will get a better understanding of statistical variation, systems thinking, that there is no six sigma limit (and why it’s regular mocked by lean people), that software development is not the same as product manufacturing (hint: Poppendiecks) and question the management delusion that a few great heros can fix systemic flaws.

    What a great concept to start a conference with humor. Looking forward to next year, maybe we can surprise the audience by showing that waste is creating money and how pull systems can be pushed from a scientific management point of view!

    Many greetings from an agilist in Sweden.

    Niklas Bjørnerstedt on November 10, 2011 at 7:56 pm said:

    Hi MMM (whoever you are),

    It might not be your intention but you come across as a true believer of Deming. An infidel has dared criticize some of his thinking and must be dealt with. If you had bothered to do a little research you would have realized that Reinertsen has written books that have influenced a whole lot of people (hint: Poppendiecks). As I stated at the outset of my post; if you can not find any errors in an authority’s thinking, you are in trouble.

    MMM on November 14, 2011 at 3:03 pm said:

    I am sorry for my sarcastic posting, Niklas. I was very disappointed from the talk.

    Patrick Steyaert on November 18, 2011 at 4:51 pm said:

    Good story of a team that previously excelled and then is breaking down because of presence versus absence of one man: http://blogs.hbr.org/cs/2011/11/what_colts_football_can_teach.html

    Very special cause of variation 🙂

    I prefer to think about this in CAS terms: System constrains agents, agents modify system


About Niklas

Born in Sweden, grew up in New York, lives in Norway. Yes, I have problems with identity, but I do think that my background helps me see things from a different perspective.

Read more