Systems Thinking for Organizational Change

When Toyota succeeded in their change efforts and started doing roaring business during the early part of 2000s, the secret of their success pointed to be their adoption of Lean Management. Post Toyota’s success, many companies tried replicating this approach without much success but could not go a long way. The main reason for this was the companies tried to copy the Lean tools but was not able to recreate a culture the way Toyota was able to do. Only way to transform the culture is by thinking in Systems and thereby optimizing the Whole.

Let us see this in a little more detail. Right from the early age, what we are taught as a scientific way of problem solving is to divide and conquer. Break the problem into smaller number of manageable pieces, analyse and address those small pieces which would in-turn solve the bigger problem. This is called as reductionist way of thinking. What happens in most of the cases is that those smaller problems become departmentalized or Silos and create their own version of mini and micro-problems. And any problems that gets solved at this level would at best achieve local optimization. And the local optimizations many times would also have negative side effects to the overall system.

Systems Thinking is a powerful approach towards problem solving. It is a discipline for seeing whole. It is a Framework for seeing inter-relationships and for seeing patterns of change rather than parts. The approach was popularized by Peter Senge through one of his works called “The Fifth Discipline” though Edwards Deming is known to be one of the original thinkers of Systems Thinking school. It provides an alternative thinking about problems as a “Whole” instead of breaking it into pieces. Systems thinking as an approach to problem solving that attempts to balances between holistic thinking and reductionist thinking. It deals with:

  1. Interconnections of various elements acting in the system
  2. Inter-dependencies and impact these elements have on each other and on system
  3. Multiple context of these elements

Here is a very simple example of Systems thinking and Reductionist thinking. If we think of managing the software development process as one of the problems, it is easy to see how traditional way of development is more of reductionist thinking: Analysis-> Design -> Development->Testing->Deployment. That is to break software development into 5 phases and manage them as separate problems. With this model, fastest feedback loop is after the verification process which can be quite late to make any correction. Also, in most of the IT Organizations, these phases are treated as separate departments or entities. They have their own set of problems and mostly work in silos. Systemic way of thinking is to think of Feature teams that are cross-functional. The very idea of which is to eliminate the Silos and hence to bring down the time for systemic feedback.

Now, how can Systems Thinking be applied to Organizational change. And why many of Lean-Agile Transformations fail? Why is it that the organizations do not realize the complete benefits of Agility? Organizations decide to go Agile, make lots of investments in terms of hiring Agile Coaches, redefining the roles and structures and selecting the teams that need to be focused on. However 2-3 years down the line, these are some of the patterns that can be sensed:

  1. Tools like JIRA, Jenkins and Puppet are onboarded without the real idea of how to make use of these systems to integrate the flow. Teams often say, we are already Agile because we are using Jira.
  2. Daily Scrums and Sprint Retrospectives are done but in a mechanized way. They use Daily Scrums for status updates to their Managers. Retrospectives are rarely done because teams think they are a waste of time.
  3. Teams use the terms like Sprints for delivering mini-waterfalls and use the term “Stories” to refer to their often elaborate requirements. Sometimes a story can span multiple sprints. Teams interchange stories, tasks and epics without the knowledge of hierarchy.
  4. There are specific roles like Scrum Master and Product Owner. However, the Scrum Master is basically a Manager with a change in name. She still controls the team functioning and expects the team to report to her. And the Product Owner is not really a Business Representative but somebody from IT. Sometime, I have seen both the roles being played by one.
  5. Targeting the change at limited functions like Development or IT Teams. Only Onshore (in a distributed team environment) is targeted for Agility. Leadership believes that the entire transformation is for the teams and do not get involved.
  6. Teams think of Value statements as rigid. For example, I have heard lot of teams say, in Agile, there is no documentation. Or they say, we do not have to follow the process.
  7. There is a lot of resistance to change which results in a lot of conflict and changes being only cosmetic. Teams feel overwhelmed managing increased pressure of deliverables and also to follow Agile method. The resistance is also the result of belief system that the actors with-in.

There is a greater sense with-in the organization that they were doing much better off without Agile. And the whole blame starts shifting towards Agile. They start winding down Agile programs, reduce the coaches. The coaches themselves go through the churn of frustration and get a sense of not adding value to the organization. They either move to different companies or move into different roles. Some of the statements we often hear is “Agile doesn’t work here” or “Agile is too idealistic”.

The patterns mentioned above can be mapped to each of the systemic components mentioned in the model depicted. It goes from the order of what is given more attention in the change-efforts and to the ones that are given least attention. It also goes in the order of what can be easily changed to what becomes more difficult to change. For example it is easier to change practices compared to the Organizational Structure (and its functioning) or the Strategy.

These anti-patterns emerge because organizations fail to comprehend or realize the inherent Systemic nature. Each of the components above are treated in isolation and they do not see the whole. They do not understand the inter-relationships between each of these. Each of the component sitting on top is related to more than one component that is below them and should be aligned with all of them. Hence these components should never really be thought off an implemented in Isolation. For example if you decide to onboard the tools, that should be accompanied by the understanding of the language associated with it. And the change in Language should be associated with change in behaviours and practices. They need to be aligned to each other. The Structures should clearly define the how the roles interact in carrying out the practices. All the components mentioned so far should be aligned with the Value and Principles.

However one component of the system that often gets missed by the coaches and leaders alike is how these change initiatives impact people on the ground. How do they see these programs? Why is there a lot of resistance? How does this play on the collective and individual belief system of the individuals and the group? This component can be referred to Mental Model, Collective Mindset or simply Belief System. This works as an overall context where these change efforts play out. It is about how people in the organization would generally think of such initiatives:

  1. This is something that is imposed on us and hence we just need to do things on surface to satisfy some egos.
  2. Delivery is more important, and these initiatives are eventually going to die down.
  3. The consultant/coach is paid to run this so he/she will do all the heavy lifting. And our work as a team is only cosmetic.
  4.  Coaching is about training. They are all theory and idealistic.
  5. Agile is a set of standards like SEI-CMM. Hence it is more about compliance.
  6. Implementing Agile would make our lives harder and there would be more work pressure.

These are the stories that people tell themselves and their peers. And these stories have huge influence on the way the change is perceived and hence also on the success of such initiatives. Even though the Leaders and Coaches have the right intent in bringing this change, it may not not be received well by the target audience. If these are not addressed, people lose motivation and would knowingly or unknowingly sabotage the initiative.

Identifying these systemic components and how each of those affect the transformation would determine the success or failure of the transformation. It is important to understand the dependencies between each of them and also in a given situation which component has higher impact over the other. Most of today’s organization problems are complex and are the result of reductionist thinking. While we solve one problem, we see other problems arise. This sort of problem solving only provides symptomatic relief without addressing the root issues. Systems thinking helps bring the nuanced understanding of the problems without jumping into solutions. Hence it attempts to bring long-term and sustainable solutions to a complex problem.

What do you think?

3 Responses

    1. Thanks for reading, Vijay. Would surely go through the link that you have suggested though I believe thinking in systems can never get out-of-date.

  1. Excellent article which brought my understanding of the theory and working at my company together. Although this is a couple of years old this article, just wondering if you have created at some point a causal loop diagram or other diagram to illustrate Jira tools, daily scrums, sprints etc and what should be happening – ie where feedback loops are etc. That would enhance this article for me.

Leave a Reply

What to read next