When I first learned about the D. Edwards Deming’s idea that 95% of performance should be addressed to the system and only 5% to the people it seemed totally counter-intuitive to me. Not even the idea itself, but its consequences. I mean a simple thought that you can basically stop working individually with the people on their performance as it just doesn’t make any sense. The impact of suboptimal system improvements should be tenfold or better than the best possible people-related changes.
Then, after researching the subject a bit, I swayed to the other side. The examples shared by Deming or Eli Goldratt are undeniable. I can also find a lot of examples from my own experience how the system was impacting performance heavily. Not that I had the numbers, but it resonated well with me.
Now, finally, you know what I think? Both approaches are crap.
Yeah, I’ve just tried to piss of both: guys who strongly believe in Deming’s work and those who totally disagree with him with a single attempt.
What Deming Really Said
I guess this story started when I was looking for precise Deming’s quote on one occasion. It seems that the meaning people attach to his words wasn’t there initially. The original 95/5 thingy was not about performance literally but about variability in performance.
Let me use a sport analogy to explain that. Let’s take a basketball player. If he scores anything between 5 and 30 points a game, and neither of extremes is an extraordinarily good or an extraordinarily bad game for him (meaning: it happens on occasions) variability of his performance is high. As a comparison we can have another guy, a second-tier player, who regularly scores anything between 0 and 5 points. Variability of his performance is significantly lower, even though his average performance is significantly worse.
Now, it’s not a surprise that the system governs variability. I mean, the more repeatable the situation the less variability you can expect. If the team plays are consequently set to create situations for one player his performances will be sort of repeatable. He won’t be suddenly disappearing from the game. At the same the system also governs variability of performances of a role-player who joins the game only under special circumstances, e.g. when the team needs more three-pointers or maybe when one of important players is injured. Variability of performances of such a player will be significantly bigger.
Of course, to some point, the system also governs performance itself. Think what happens when the star sits on the bench throughout the whole game or when a guy who is typically a sub plays the whole game. It doesn’t mean, however, that you tell a third-tier player to substitute a team leader and expect them to score 30 points a game. It’s not going to happen in a consistent manner. (For basketball fans: yes, I know Jeremy Lin’s story, but that’s an exception.)
What Deming was talking about was basically that the system governance is responsible for creating a stable and repetitive environment so people performances are controllable. Again, it’s not about how exactly people perform, but how their performance varies from day to day.
In fact, the above statement is mostly an interpretation too. Deming was talking about the system being, or not being, in statistical control which isn’t exactly performance variability, but for the sake of this argument let’s leave it as it is and not complicate things even further.
Anyway, Deming Is Still Wrong
So far I made an attempt to convince you that: first, Deming was basically talking about performance variability and second, the impact of the system on performance itself, while existent, isn’t anywhere close to 95%.
However, we shouldn’t forget Deming’s background, which is a factory floor. In other words it’s a place where workers are supposed to produce same things in a repeatable manner. I could exploit the basketball analogy further pointing that every game, heck, every play is different, but I guess in software development we simply don’t need that analogy anymore. It’s enough to ask: how many times have you built exactly the same feature?
And for all three of you who accidentally had this chance: how many times have you built the feature second time in exactly the same way you did the first?
I bring this argument to show that in knowledge work, or sports, we naturally have significantly higher variability to deal with. And, unlike on a shop floor, that is good. What’s more, there is a different value attached to every single thing we develop. In fact, it’s even worse than that. Very often we don’t know exactly what value is attached to a work item we’re going to build.
This means that in such a situation we should use a very different statistic mechanism than Deming based on. We need to take into account both expected cost and expected payoff. The latter, naturally, isn’t taken into consideration on a shop floor as in this situation payoff for each part is well known. In knowledge work, on the other hand, payoff function is extremely important and never flat.
Coming back to the basketball analogy: if you wanted to bet which player is going to score 30+ points during the next game would you rather choose this reliable guy who averages 15.0 and who always scores double-figure but rarely, if ever, exceeds 20.0 or rather that crazy shooter who (surprise, surprise) averages 15.0 as well but, depending on a day, can score either nothing or 40+ points? Bravo! You’ve just chosen higher variability, which is totally against what Deming taught us.
This is because you’ve taken the payoff into account. In the former case any payoff is almost impossible as, because of low variability, it’s highly unlikely that the guy is going to score 30+ points. The other case is a different story though.
Now, especially when we think about product development we are in a betting business. We bet that this or that feature will bring a ton of new users or a truckload of money. We can’t ignore the payoff function. We can’t assume the payoff function is flat. In either case we’d be throwing the baby out with the bathwater.
By the way, if you want to dig deeper around this one I strongly recommend watching this Don Reinertsen’s session. Twice. Seriously.
Besides, Who Does Create the System?
I’m not done yet. I don’t challenge the idea that the system affects performance. I simply challenge the so-called 95/5 rule or, to be more precise, I challenge the way some people interpret the so-called 95/5 rule.
The question we should be asking is who (co-)creates the system. If we start with Deming he points shaping the system as a management responsibility. This is probably very true on a factory floor. We are not at a factory floor though.
Let’s stay for a moment within software development perspective and think what exactly an equivalent of a production line is.
Obviously, one part would be organizational culture. What are general ways things are done in the organization? Does the org use a lean / agile or rather a heavy-weight, formalized approach? How do your clients act? These general rules will be difficult to change.
However, when we consider a lower level it’s a different game. Let’s try to translate low-level manufacturing process to software development. Production line would likely be a sort of a process: analysis, coding, testing, deployment, etc. What’s interesting though is what is happening on each of these stations. How exactly the work is done? Who makes decisions how the work is done?
Take coding for example. Who decides whether unit tests are there or not? How many of them? What kind of tests? Who decides on a specific coding style? A manager? Um, no, not really. Most, or even every, of those decisions are made by a coder – a worker.
Now, the important question: do such decisions define the system which a developer operates in? Obviously! Just think what is going to be the outcome of work of a cowboy coder and what happens when a worker is an eXtreme Programming fan. These are different systems indeed.
The conclusion of this story is that in our world workers can influence the system heavily, thus completely change the Deming’s equation.
One might point that leaving people freedom and empowering them is still the part of the system design which is still the management job. I’d disagree. One thing is that adopting a technique or a practice isn’t comparable to moving the machines on a factory floor. I can perfectly start writing unit tests and it doesn’t instantly require everyone else to change the way they work.
Another thing is that it’s way easier to be a Grace Hopper follower in our industry. We can easily change the part of the system that goes through our desks, no matter whether we are empowered to do so or not. Eventually, if anyone notices (which isn’t that obvious by the way) we should have enough information to have meaningful discussion about the impact of how we’ve done our work.
All in all, in knowledge work there’s no clear line that separates the system from the people, thus the whole notion of addressing specific part of influence to one or the other is flawed.
It’s the People, Stupid!
The last piece of this puzzle is a story. Not that long ago I’ve joined the organization that is exceptional when compared to its surroundings. I’m far from saying that it is a perfect system already, but it’s definitely the most mature company that I’ve ever been working with.
In fact, it’s not only maturity of software development process we have but also this touchy-feely stuff we call the atmosphere. Not a dream job (yet) but pretty damn close to it when compared to everything else I’ve had a chance to experience.
Let’s try to translate this to a system definition then. It would be pretty effective. It would be delivering high-quality stuff. It would be a great environment to work at. It would help everyone to grow. How could one possibly not like it?
The only problem is that I’ve lost one third of technical stuff over the course of few months. The system? No, the people! Their individual needs, frustrations and dreams. Their unique contributions to what the system is, or has been.
Because at the end of the day, in our world, the system is not machinery with replaceable humanoid parts; it is inseparably connected with the people who operate within the system. Change a single person and the whole system is different. Suddenly the rules of the game have changed and everyone else operates in a very different system. And the only thing that has changed is a single person has left.
Summary
My message in all that is that we should first understand our work, how it gets done and what kind of system we operate in. Because when we think about that it becomes obvious that there’s no simple way of separating the people from the system in knowledge work domain, especially when we’re talking about a small scale, e.g. dozens of people, not thousands of them.
At the same time I’m challenging the common notion of Deming’s rule because it’s nothing close to what Deming really said and it is simply flawed in our domain anyway.
At the end of the day you should understand the system (obviously!) but focus on the people too if you want a significant change.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
17 comments… add one
Of course one must focus on people, because the “system” in this context is a “social system” and a “cultural system” more than a “system of (manufacuring) processes” — even though some still like to see and present it as such, for various reasons.
Hi Pavel,
You say that Deming’s background is in manufacturing, and that his 95/5 rule pertains to variability in performance. Then you say that Deming is “wrong” (without qualifiers). Then you explain how Deming’s observations about variability in performance on a factory floor don’t pertain to software development.
So, you changed the context in order to make Deming seem “wrong,” even after you first clarified that he was talking about variability in performance in a manufacturing context. It seems to me that Deming was “right” in the context where he was working.
@Dave – Thanks for a comment. You bring up a very good point. My basic goal here is to challenge our notion of Deming’s work in our context. It is not about Deming and his work only; it’s about how we (mis)use this knowledge. I started in the context where I learned about Deming’s work first and where it is frequently mentioned without paying attention to the fact that the context itself is very different to whatever Deming was operating in.
My goal wasn’t to prove Deming’s wrong. Not my league and, by the way, there are way more knowledgeable folks who do that. It was more about proving that people who simply copy Deming’s approach to knowledge business are wrong. I guess I might have added an explicit disclaimer there.
Then we agree. (I suspected we did.)
Nice train of thought! Of course the distinction your making is that Deming’s main toolbox works in closed systems where workers were little more than passive machine operators. The thinking actually came from the German’s military industrial practices like Takt Time. In the early 20th Century, they weren’t entirely enamored with their workforce, so let’s not go there. In fact the variability stuff was actually nicked from Shewhart and similarly Deming’s eventually philosophy of profound knowledge was a weak misinterpretation of the Toyoda/Ohno Bushido. As one commentator put it “a profoundly mental model, for physical work in a social organisation full of emotional people with moral obligations.”
I think modern software must respond to a complex adaptive model! It’s an open system, that may contain some closed loops but is not defined by them or the tools that create them. Got to agree with you on the people stuff, we are the system not separate from it and that context is more important than panacea rules, conventions and convenient ratios.
Perhaps 95/5 is more about balance, focusing on the characteristics of the individual Agent (person) is important but ultimately can only fiddle with an innate 5%. Meanwhile the 95% is about their Agency, their ability to interact with the system over time. Top Blog!
Nice post! For me both “sides” are roughly about as correct as each other. I see them as models or frames one can use to reason about various things and support the decision making process. As a general rule of thumb, when things go well, I attribute it to the people. When things go less well, I look to the system for root causes and improvement opportunities.
@nosapience – I think you’ve summarized important part of the whole argument pointing ability to interact with the system as something we should focus on. It isn’t the system per se, it’s the whole dynamics around that.
In fact, sometimes we have a better leverage for that on people side. One of my favorite tools here is encouraging people to ask for forgiveness, not for permission (this linking to Grace Hopper). On other occasions we’ll find tweaking the system an easy enabler of different (expected) behaviors.
It’s just not either or discussion for me anymore. As we are discussing sort of no-man land that, depending on a context, can be interpreted both directions, we can’t even precisely say what is the system and what is the people. It doesn’t matter though, as long as we understand what we are trying to achieve and what is the dynamic or interaction between one and the other.
Paweł,
As usually your post is a source for inspirations. Thanks.
What I find important in Demings ‘rule’ is not the proportion 95 to 5 (or anything else) but a simple notion that when we work in the system not all performance can be attributed to employee. I have seen organization where all performance, motivation, engagement, etc, issues were approached by mgmt by long and passionate addresses to the staff without even slightest reflection that major part of them was caused by systemic flaws. You’re right that the ‘ratio’ can be different for different contexts but still I find Demings’ statement useful to remind myself and others that ‘performance management’ solely on individual level makes not much sense if not considered in a context of the organization. So I’d say it is still system – with it’s all dynamics and people (agents) in it (with all implied complexity).
Greg
@Greg – The numbers weren’t made up – Deming was using them. Not a surprise, as an alternative in form of “system has big impact on performance” is neither that strong nor catchy nor disruptive. My problem here is not Deming literally. In fact, I agree with his conclusions and believe we can translate them to knowledge work. The key here is the translation.
Applying Deming’s work literally in our context is simply wrong. I don’t even think that simple system-people dichotomy makes sense in the context of software development. So I don’t argue with Deming personally. I argue with people taking shallow dive into his work and offering simplistic interpretation without understanding much of a context.
Finally, I’ve never said that the system has little or no influence on performance or performance variability or that we should ignore the system. Actually, I’ve said the opposite. The point is that we can’t ignore the people part or assume that working on the system will solve everything. It won’t. Without understanding how the work gets done in a specific context Deming will not help you (and likely make the thing even worse).
Pawel,
Interesting organizational models, from factory floors, to baseball teams, to the perfect software development company. It strikes me that the model used and its embedded assumptions, weighs heavily on the process vs people question.
As to people leaving, for people or process issues, Dan Pink (www.danpink.com) recently wrote that one should expect that high performers will always be sort of frustrated with the process, the pace and the people… e.g. maybe we should expect high performers to always struggle with continued engagement.
Hey another thought. I wrote a paper, tieing together some of the assumptions implicit in Demmings model and looked at that as it progresses into project management and beyond. Be interested in your thoughts. You can find it at http://www.managepro.com/MBOtoPM.html
Rodney
It is obvious that knowledge can not be separate from people. We also have to understand that even if we have a good environment, we live in an open system and people have free will to leave. For me performance is gained by trusting the people, in an open and dynamic system.
Ah my friend,my friend. I went to my first Deming 4 day seminar in early 1982 .i windsor not. I was working in a Detroit GM plant at the time.That was30 years ago.Since that timeI retired in1999 I have found nothing (except his personal history to confute).I accept his first two books and their implications ,in my experience with out challengeI fundamentally reject the third book Theory of New economic When I first met him personally in 1983 I said to him Sir it is not 80% 20% it is 99% and 1% I still maintain that.Workers work in the System ,Management Works on the Systems ..Read the National Labor Relations Act it applies to all workers union and non union.Workers work for wages they apply their physical and mental energies to the defined task,the task does not care about the worker attitude it is all drama.If management does not or cannot in specificity clearly state in writing why I am paid my wagest hen it is on themThese people get phd;s in management and over 95% of them are subject to what I first heard Deming say in 1992 “people get Phd;s in statistics and know nothing about statistics”!!!!If people in management ,on average did their jobs half as well as wage workers DO their jobs the increase in the competitiveness of companies would be astronomical
Contrary to the claim, tt’s the system, not the people. The inference “factory floor => repeatable => 95/5, so this does not pertain highly variable tasks, so 95/5 does not hold” is not justified. On the contrary, if process is poorly defined and features (products) are highly variable than the number of errors attributable to poor organization, tracking and mgmt methods is even higher than 95/5, say it’s 99/1.
To clarify: just bc product/features are highly variable does not mean it’s all dependent on people and not on work organization, tools and methods. Why take those out of scope and dump all on competence of individual worker again? There are no rational and detailed reasons to do that. The reasoning presented seems to be rather vague and unclear “back in the head” thinking to me. Why presume that you can’t have good methodology that reduces defects even if (or rather: especially if) products are highly variable? For a practical and see Joel Spolsky’s 12-point test of team quality. It’s accepted practice now that “we should have source code versioning system like SVN or Git or else we’ll suffer more defects”. Somehow nobody thinks that devs sending each other source code files by email is all OK and that if problems happen it’s because people are not careful when sending emails.
@Marcin – I don’t think you are addressing a point I’ve even made.
A side note: I don’t think I understood that fully: are you proposing that software products, and their derivatives which are features, aren’t highly variable?
You mention source control as an example. Is this really how you perceive a process? Because for me it’s a tool. A useful one and definitely helpful in terms of improving a defect rate but just a tool.
A process is how all the elements of the system interact with each other. It just so happens that in knowledge work it is mostly how people interact one with another. Would you agree that in each individual case these interaction would be driven by traits, moods and characters of those involved?
At the end of the day our system (and I’ll just repeat an argument from the post) is not machinery with replaceable humanoid parts; it is inseparably connected with the people who operate within the system.
In other words system versus people conundrum in our context is flawed as the two are inseparably interconnected.
I’m not sure you’ve quite understood what a system is. People work within the constraints of a system – a system that may have been defined or overseen by ‘management’ or a system designed and adapted by self organisation. It doesn’t matter which, a system still exists and the system will inevitably define the effectiveness of the organisation. How a group makes decisions on technology, recruitment, holidays or product decisions is all constrained by the system. The way the team has chosen to manage their workflow (scrum, kanban etc) – it’s all the system.
And in the example you gave ‘I can just choose to write some unit tests’, have you thought what impact that might have on other parts of the system? How does the system cope when one person chooses to use an approach that might impact other parts of the system? What impact will your decision have on other developers? What you’ve described is a local optimisation.
The examples you’ve given are not about people, they are about the system. How the work works for us is all about how the system has been set up to allow it. Even if you work in an completely management free environment, there’s a system underpinning every decision.
For further reading, please take a look at this article: https://samililja.wordpress.com/2013/07/24/exercise-to-illustrate-demings-955-rule/
We always tend to forget something:
The system is created by the leaders. Yes they are people but they are the specific individuals task to take care of everyone. That is the production system that provides the variation.
Leaders job is to help their people solve their problems so they can improve the way they perform their work.
In the thinking process or product development the leaders role is to create that environment where the best idea wins. That is the system. The best idea wins not the ideas of people in higher position wins. The other thing to remember is structured decision making. That is a system that promotes sound decisions and enables the right people to make the decisions. Again…system.