Admittedly, the title is a play on Deming “Every system is perfectly designed to get the results it gets.” Now I realize there seems to be some dispute with whom to attribute this quote too. But I am going with Deming for now.
The statement itself holds true regardless of who said it first. People work within the constraints of the system they are in. In our everyday work lives we can see symptoms of the system play out. When people are rewarded for hero work. When people produce buggy code as a result of a demand for speed. When those bugs are now tracked instead of fixed. When great big long term plans are created. When estimates are required. When there are multiple “high-level” projects that must all be completed. When frameworks are enforced. When more-faster is your software strategy and primary measure of success. And one of the oddest things I’ve experienced is, “This is the most important thing, but we aren’t ready to work on it yet.” These are all symptoms of what that system produces and values. These things, and many others I have not mentioned, are supported somewhere in that system and in order to change the undesirable outcomes or habits a system produces, you must find what is empowering those outcomes and habits.
“A bad system will beat a good person every time.” – Deming
I have experienced and heard the stories of people going out and getting “training”. Or joining an organization looking to make changes or “champion” change. Most of these organizations are talking about “Agile Transformations” and such. What typically happens is this person has an idea of an approach to change things in the org or within their team. Most often this is seen with people getting Scrum certifications. People are open to hearing these new ideas and approaches to how they work. At least they say they are. But what ends up happening is the system finds means to protect itself. People within the system see these possible changes to the way they work as an attack on what they know. This is where you will hear statements:
- “That won’t work here.”
- “But this is the way we’ve always done it.”
- “That’s good in theory, but not practical in the real world.”
When you hear these statements, try to think about what is really being said.
- “If we make these changes you are talking about, where does that leave me?”
- “Why should I trust that the things you say will work?”
- “Be careful and tread lightly. People around here do not respond well to change.”
The largest problem, I think, with a system is that it isn’t some wizard of Oz man behind the curtain pulling all the levers to keep the system going. There is no one single culprit. The people in the system support and maintain the system. The system you are in is interrelated and the various parts work together. If you are trying to make a change to a system, especially any significant change, you must change the influencing factors of the system. I quite like the wording Allen Holub uses:
“You cannot improve a system by tinkering with the parts.” – Allen Holub
I have experienced where the values and principles found in agile can make positive changes to dysfunctional systems. Rapid feedback enables us to make changes to the system we are in. This rapid feedback allows us to reduce and avoid waste in the system. Another thing agile focuses on are self-organizing and self-managing teams. This requires management and leadership in organizations to give up the command and control methods of working. Management shifts from giving orders and controlling the system to defining a goal in partnership with the talented people they have hired to join the organization, and letting them all work together to achieve the goal. Then management supports the people with what they need. This approach also requires, actually it demands, that we also stop having separate motivating factors per team member, manager, director, division, vp, budgets, OKRs or KPI’s.
“Does experience help. No! Not if we are doing the wrong things.” – Deming
We must start taking entirely different approaches to some of the more “traditional” ways of approaching the work we do. I saw this the other day on twitter from Ben at hiredthought.
To me, seeing peoples responses to this exercise is an extension of the system they are in. Some said they would do this:
Others said this:
Others had some really quite true, funny, and ultimately sad things they shared as further expressions of the frustrations of their system:
It is really quite an interesting and thought provoking thread and I can’t thank Ben enough for putting it out there as it provided visual clarity to some of the thoughts and conversations I have been having around focus and systems thinking that has been circling in my brain for quite a while. Thank you again Ben!
While I initially agreed with this approach:
And I think there is great merit to this approach. It has served many teams well and still does today. I also think there is something faulty in the logic. The above approach of attacking one project at a time, even with that extra unit of work being done on the second project per week, assumes that all of these projects must be done with all of the features and functionality that is defined in them. Now I am certain I am not the only one that has experienced more than a couple projects that ended with a product that had copious amounts of waste in them and even some that we probably should have abandoned long before completing. As odd as this might seem, I think a more logical systems approach to this would be from this image:
But there is a slight shift with this approach. If you are assuming you are going to complete 1 thing per project each week as this image and scenario is depicting, then you would be able to review progress on each at the end of that week. You could then look at what was produced, and make some decisions about these projects or products.
- “Should we stop any of these?”
- “Should we change direction on any of these?”
- “Did a different opportunity arise that nobody was aware of at the start of these that has now been exposed by this work and we should shift our product to now address this new information?”
- “If we were trying to decide where to invest, do we have enough information to shift our focus, people and resources to the more valuable project/product?”
This is also in product thinking, but I think of it from a systems thinking approach. If the system you are in doesn’t support learning through empiricism then this approach wouldn’t make sense to you. And ultimately wouldn’t be supported. This would require a system level change to approach work in this manner. You would no longer be able to plan your budget for the year for specific projects or products. Instead you would budget just enough on a week by week basis and spread that across the projects or products you think you need to complete or create. After each week, you would ask some of the questions above, and probably more, to determine if you continue to feed money into a project or product. This is referred to as drip funding. In my thought process, I would rather take this approach to these projects or products to determine which we should invest in, which we should throw away, uncover other opportunities we never thought of, and put our full support behind the one that can reach self funding in the shortest time frame.
Now, I could see an argument that maybe each unit of work for each project or product in this example isn’t valuable on its own. Well, that is another conversation around how you are narrowing your projects and products. But as a whole I call foul on that logic. You mean to tell me that after a week’s worth of building something, which by this example would be a quarter of the entire project or product, that you wouldn’t have learned anything that could help you make any decisions? That would then be yet another systemic issue to be dealt with.
Am I confident I am right about this? Well, it makes sense to me as a logical learning approach and solution to the common organizational chaos of everything being the same priority. If we take this approach, we can make decisions about what we should do. What is no longer feasible or valuable should be trashed. What shows true value to the organization, we should put our focus into. Another benefit of this approach is people get to see what is being built, the value that it currently has or could bring, and when a decision is made to move on with or without one of these projects or products, everyone knows why. It is shared knowledge and clear direction. It also allows us all to know what we are focused on.
Again, I want to thank Ben for providing these images and thought exercise as it really helped me to focus my thoughts around this matter. Well, at least enough to have droned on in this blog post.
I also want to thank Woody, Kevin, Fred, David, and Alfredo for the conversations we have had around systems thinking in recent weeks as that has been invaluable to my thought process.
As always, I am very open to having a dialogue about anything I post. And I am often looking for someone to point out how wrong I am or faults in my thinking. Please feel free to reach out.
-Chris
Chris Pipito 
One thought on “Systems Produce As Designed”