import { Image } from 'astro:assets'; import st1 from '../../../assets/pitches/st-1.png'; import st2 from '../../../assets/pitches/st-2.png'; import st3 from '../../../assets/pitches/st-3.png'; import st4 from '../../../assets/pitches/st-4.png'; import st5 from '../../../assets/pitches/st-5.png';
The Paradox of Technologists Who Can't Fix Their Own Organizations
Organizations, including technology organizations globally, struggle with the problem of deteriorating productivity, poor quality, low engineering effectiveness, which over the long term thwart their existence. The situation is deeply paradoxical. It is paradoxical because technologists who believe technology can solve every problem or dysfunctions the world faces, fail to solve the dysfunctions of their organization in which they suffer themselves.
The Core Assertion: Lack of Systems Thinking is the Root Cause
I assert that the root cause of smart, educated, and scientifically driven people failing to sustainably solve dysfunctions of their organizations and achieve their true collective potential is because they lack Systems Thinking and they lack Systems Thinking because they are unaware that they need Systems Thinking so put no efforts in acquiring it.
The Challenge of Explaining Systems Thinking Quickly
Making a general statement about technologists lacking Systems Thinking when their primary job is to architect, design, develop, operationalize, and maintain systems is a bold assertion. Now, if that assertion is indeed correct, providing evidence for such assertion should be easy. Describe what Systems Thinking is, and if the reader can realize "ah, I don't think that way", they will agree or otherwise disagree with my assertion. Unfortunately, I cannot take that path. After multiple failed attempts, I have concluded that I am incapable of explaining concepts of Systems Thinking in a few minutes to anyone. I plan to take a different approach. To unfold that approach, let me first describe how organizations have traditionally approached improving performance or eliminating dysfunctions in their organizations at scale.
Traditional Approaches: Tools, Best Practices, and Methodologies
Organization traditionally tries to solve above mentioned problems by procurement of best tools, the institution of best practices, defining metrics in the form of KPI, OKR, SMART goals, applying principles of responsibility and accountability, rolling out transformation & change management programs, and the list goes on. But all of that is done in the context or guise of adopting some modern ways of working such as Agile, Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), DevOps, DevSecOps, Lean, and countless other modern methodologies that keep popping up every few years. It's very much possible that as you are reading this article, your organization is going through some form of methodology transformation that promises to solve all issues of productivity, quality, engineering effectiveness, and all the dysfunction that exist.
The Failure to Learn from Past Attempts
There is nothing wrong with adopting famous methodologies. The problem is that every time organizations rollout programs for adopting a methodology, they fail to reflect on the fact that the same or similar adoption was tried multiple times in the past, which should be indicative of failures and not success.
The Endless Loop of Methodology Adoption
The question is how many times an organization needs to go through Agile, DevOps, or similar transformations to claim that their organizations have been agile-d or DevOps-ified and do not need any mass rollout of such program, at least for the next decade or so. My prediction is never. Organizations will continue the loop of trying the same thing, experiencing a temporal victory only to retract back to a similar or worse situation. We assert that when organizations lacks Systems Thinking, they will have no other option to stuck in methodology adoption loop despite failures.
Evidence in Support: Two Buckets
We will provide evidence in support of our assertion in two buckets.
- Nearly every methodology makes Systems Thinking a pre-requisite principle, thereby implying that if one ignores the base principle of methodology, one will fail to adopt the methodology successfully.
- Organizations have put nearly no effort in learning concepts of Systems Thinking and thereby explain that the struggles are due to a lack of applying Systems Thinking.
Starting Point: Principles of DevOps
Let's start by citing the principle of DevOps as a famous methodology used to transform organizations. Then we will cover the principle of other methodologies.
DevOps Principle #1: Systems Thinking
When I wanted to figure out the base principles of DevOps, I realized that one of the most credible sources would be Gene Kim. For those who do not know Gene Kim, he is the author of numerous books on DevOps, including The Phoenix Project, DevOps Handbook, and Accelerate, and the list goes on. There is a high chance that you have read one or more of his books—link to Gene Kim's books list. I cite Gene Kim's blog published on itrevolutions.com as evidence for my write-up, but you can find the same three ways/principles of DevOps mentioned in his books too. The picture of three ways of DevOps was copied from Gene's blog.
The first way/principle of DevOps: Systems Thinking.
As you can see in the pictorial representation by Gene, Systems Thinking is the first principle of DevOps. Gene defines Systems Thinking as "improving performance of the entire/whole system, as opposed to the performance of a specific silo of work or department." At this time, a question must pop into our minds. Why state Systems Thinking as the first way? What is the reason for being so explicit? There could only be one explanation; our current way of thinking is not Systems Thinking. In other words, we are not Systems Thinkers. Citing Systems Thinking as the first way would be a moot point if we were Systems Thinkers to begin with. The questions are: what kinds of thinkers are we, who taught us to think that way, and why that way of thinking drives us to improve the performance of a silo and not the entire organization. These are amazing questions and getting answers to those questions will be the starting point for you to begin the journey of becoming a Systems Thinker, if you want to become one. But we shall be able to deduce from Gene Kim's first stated principle that unless you are/become a Systems Thinker, DevOps is not going to work for you, irrespective of how many times you try to adopt it because you are using wrong thinking. That could explain the problems discussed in the introduction of why organizations continually keep on trying to adopt methodologies without success. Let's move to the 2nd way of DevOps.
DevOps Principle #2: Amplify Feedback Loops
Note: I fully agree with all the three ways stated by Gene but have serious disagreements with the descriptions of those three ways in the context of Systems Thinking. The disagreement is deep enough that it deserves a separate article which I promise to write.
DevOps Principle #3: Learning and Experimentation
The pictorial representation of the third way is feedback loops within the feedback loop. So visually, it means more Systems Thinking. The description of the third way talks about how we should learn from failure, constantly take risks, and conduct experiments. Now that's good reinforcement, but everyone knew about the need for continuous learning even before the word DevOps was coined. What does learning have to do with Systems Thinking? Everything, especially in the context of complexity. There is plenty of research that our current form of Thinking does not allow us to learn when embedded in complex systems. This inability to learn in a complex system is worse than it seems. Our current form of Thinking creates the delusion of learning. Meaning we believe that we have learned when we have not. That explains why organizations get stuck in the loop of adopting the same or similar methodology every year because each time, they believe they have learned when they have not. So, they try again, confident that they will succeed this time only to repeat the history. So how do we overcome our learning disability when dealing with a complex system.
As expected by all of you, the answer is Apply Systems Thinking. In his book The Fifth Discipline, Peter Senge, who coined the word The Learning Organization, lists five disciplines that drive organizations to become learning organizations. Systems Thinking is the Fifth Discipline. The book's name suggests that Systems Thinking is not simply one of five disciplines but has a more critical discipline for an organization to become a learning organization in a complex world. I will write on this topic in future.
Note: After reading my article, if you feel curious to buy and read the Fifth Discipline book, I suggest you don't. Most people I know tell me it's a difficult book but many people who said they understood what Peter has to say, in my experience, didn't. I suggest that you wait for my future write-up before reading this book.
I hope I have made a compelling case. All the three principles of DevOps in one form or another suggest applying Systems Thinking. Therefore, implementing DevOps without a Systems Thinking mindset will not work for your organization.
