Skip to content
  • About Us
  • Our Services
  • Case Studies
  • Content Hub
  • Blog
  • Join Us
  • Contact Us
How to Use Systems Thinking to Find and Fix the *Root Cause* of Your Organisational Woes
Simon Copsey

How to Use Systems Thinking to Find and Fix the *Root Cause* of Your Organisational Woes

Systems Thinking is a tool for understanding complex systems—such as enterprise organisations—where no one person can see the whole, but where we must understand the whole in order to drive effective and long-lasting organisational change.

It provides a holistic way of diagnosing the root cause behind problems faced by our clients, and for identifying a targeted intervention that will provide long-lasting organisational-wide benefit—similar to how doctors diagnose their patients’ symptoms but then administer a cure targeted at the cause of the symptoms, rather than the symptoms themselves.

Problems we generally see our clients encounter include:

  • Projects getting ‘stuck’ in software delivery, being delivered late or over-budget
  • Value proposition being undercut by new industry players
  • Growing focus on SaaS products because delivering software in-house becomes increasingly complex
  • Leaders often needing to get involved with firefighting software delivery
  • Consultants or contractors often required to bring in additional knowledge

At Contino, we see that a number of our clients’ challenges arise due to the pursuit of Scientific Management, a traditional—and still widely followed—management theory devised by Fredderick Winslow Taylor in the 19th century.

In this blog, we’ll explore Scientific Management, the implications on your business, and how Systems Thinking can help alleviate emerging challenges.

What Is Scientific Management and How Does it Impact Your Business?

Scientific Management places a razor-sharp focus on improving productivity in an organisation.

It does this by separating strategic thinking (managers) from tactical operations (workers), and dividing the organisation (often by discipline) to make it easier to optimise each individual part.

The above diagram illustrates how Scientific Thinking encourages horizontal division between departments (developers and operations) and vertical separation within departments between the ‘strategic thinkers’ (managers) and the ‘tactical operations’ (workers).

Whilst separation of strategic thinking from tactical operations, and the division of disciplines, provided some benefits in manufacturing where processes needed to remain fixed and predictable, it inhibits today’s organisations from being fluid and adaptable in dynamic environments. This has led to many of the challenges we work through with our clients.


Dividing organisations divides the knowledge and authority needed for effective problem solving across many isolated teams: designers, developers, customer services, finance, strategists and other parts of the organisations. In times of crisis, we often see these divisions temporarily bypassed, enabling cross-functional teams to form that can deliver big changes quickly. A recent example is the major supermarket chains Sainsburys and Tesco who are rapidly adapting their online and in-store operations in response to the shifting needs of staff and customers in the wake of coronavirus.

“Right now, your company has 21st-century Internet-enabled business processes, mid-20th century management processes, all built atop 19th-century management principles.”

—Gary Hamel

Let’s first look at two frequent challenges that result from Scientific Management - and their impact on the business - before exploring how Systems Thinking can help.

Challenge One: dividing disciplines constrains efficiency and effectiveness

Scientific Management has encouraged organisations to divide themselves by discipline. However, this has impeded effective problem solving - such as delivering software - which requires collaboration across many disciplines to be successful (e.g.: marketing, design, engineering, testing, security, operations).

By segregating the disciplines of an effective software delivery team - and attaching them to different management lines with different (and possibly conflicting) objectives - we reduce the opportunity for the disciplines to work together toward a common goal, and do the right thing well.

Collaboration is replaced with documentation, handoffs and work queues as the primary form of communication.

In these conditions of constrained collaboration, the ability to be effective (to solve the right problem) decreases as context does not naturally flow between teams, and therefore each team will have a different and limited understanding of the problem to be solved.

To be effective, all team members must share a common understanding of the problem and therefore take on a coordinated approach on the solution. This requires frequent, regular interactive collaboration, not handoffs.

As an example: let’s imagine a software team delivering a new app for a large enterprise in a waterfall context. In this enterprise setting, success is often perceived as the ability to satisfy the iron triangle (delivering on time, on budget and to scope). 

In the face of the natural uncertainty surrounding any complex project, fixed scope and fixed deadlines, the team is encouraged to cut corners and lower software quality in order to deliver on time. The software will therefore require more handholding and manual workarounds, requiring greater time and cost from an operations team whose success is often measured by the cost of support. The ability to be efficient (solve the problem with the least waste) is also reduced, as rework and queue time is introduced between teams.

As the external environment becomes more volatile, uncertain, complex and ambiguous (VUCA), we see organisations doubling down on analysis and planning. The perverse effect of this additional upfront work is that it constrains our ability to be effective by further delaying customer feedback - which is vital to ensure we’re delivering the right thing.

The downward spiral of overplanning in a volatile environment, leading to reducing outcomes.

As our environment becomes more VUCA, we must be increasingly effective by ensuring teams have a shared understanding of the problem and by delivering value in small increments to customers - sensing and responding to their feedback as we go - and thus amplifying the effectiveness of what we deliver.

Challenge Two: Separating thinking from operations encourages misdiagnosis

Organisations are complex systems, where no one person understands the whole. They are interconnected, where one action often has multiple reactions - like pulling on the corner of a spider’s web.

As an example: a software team that wants to deliver value faster to their end users often must first break down their projects into smaller pieces. Breaking down projects into smaller pieces requires changes to how projects are defined, governed and financed, which in turn requires changes to how the software team collaborates with the wider business, e.g. how funding is divided and distributed, and how the success of the team and its members are measured. 

Dividing and separating enterprise organisations into smaller pieces often does not reduce complexity, but instead reduces how much any one person can see and understand. Staff are therefore less able to identify and diagnose the real cause of problems they see, and to anticipate possible negative consequences of their actions. Hierarchy further compounds this complexity, distancing leaders and their vision from on-the-ground reality, and vice-versa.

Like a well-intentioned but misled doctor, complexity encourages leaders to continue on a downward spiral of misdiagnosis and incorrect treatment.

As an example: Deming talked of leaders who installed inspirational posters on factory floors encouraging “Zero defects!”, and measured workers on achieving such lofty targets. Unfortunately, the cause of defects often lay in the hands of management through not responding to worker requests to replace faulty equipment, or not supporting sufficient on-the-job training. Whilst leaders had misdiagnosed the cause as the need to motivate their workers, the cause actually lay in their not responding to workers’ requests.

If management sets quantitative targets and makes people’s job depend on meeting them, they will likely meet the targets – even if they have to destroy the enterprise to do it.

-- W. Edwards Deming

As we encounter symptoms, we must first find their cause. Responding to the symptoms directly wastes effort and compounds their effect - such as adding further gates to the governance process in an attempt to improve software quality, only to increase hand-offs and slow delivery - encouraging more corners to be cut.

Enter Systems Thinking

Systems Thinking is a method for understanding an organisation as a whole. It provides a way of identifying the real root cause behind the problems we observe.

Every system exhibits a multitude of symptoms. Logic suggests that similar symptoms are generally linked to a common underlying root cause. Solving the root cause will remove the symptoms in one go, whereas attempting to tackle the symptoms individually will generally offer temporary relief at most. This is similar to doctors - they do not prescribe one treatment per symptom, but instead prescribe a single cure for the underlying cause of those symptoms.

I smile and start to count on my fingers: One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can be substantially improved; even the sky is not the limit.

-- Eliyahu M. Goldratt

Systems Thinking is different from analytical thinking, which is the traditional way we’re taught to solve problems. Analytical thinking involves attempting to understand the whole by understanding each part in isolation, neglecting the interconnectivity. We cannot understand how a car operates—and how to improve its performance—by analysing each individual piece in isolation. We must understand how the parts interact with each other, and how those interactions can be improved.

As an example: improving the efficiency of developers in isolation will often not improve the speed or quality of software delivery in an organisation. Techniques such as Value Stream Mapping allow us to understand how value is delivered through an organisation: the teams, activities, handoffs and waste. Using this technique to visualise the entire process as a pipeline allows us to find the narrowest point in that pipeline, and invest our efforts there. Investing our efforts anywhere else will likely have no significant or long-lasting impact on the speed or quality of software delivery.

Similarly, analysis is ineffective for complex organisational problems: it does not give us a method for identifying the root cause behind the symptoms. It also does not allow us to connect our actions with their—often distant and unintended—effects, and therefore understand if we’re causing more harm than help to the organisational as a whole.

Systems Thinking with Our Clients: A Case Study

We regularly work with global enterprises to help them understand the root cause behind the symptoms they face within their technology divisions, such as: reduced throughput, overburdened operations team, attrition, conflict between areas and emerging shadow IT practices.

Our consultants have successfully applied the Theory of Constraints across industries, a Systems Thinking methodology for identifying and tackling the most important limiting factor—or root cause—that stands in the way of achieving a goal in a complex organisation.

Let’s use a recent global professional services organisation as an example.

The organisation was experiencing slow software delivery, impairing their ability to remain competitive in a dynamic marketplace. Contino was asked to perform a broad assessment to identify initiatives that would enable accelerated software delivery.

Their initial focus was on attempting to work around the symptoms, for example by buying SaaS products to deliver the necessary capabilities to remove the need to build them internally. This had the unintended effect of further increasing the complexity of their technology landscape and further slowing the delivery of future software projects.

Contino held short interviews across the organisation to build a holistic understanding of the processes that were failing, and the human and technical factors contributing to their software delivery challenges.

The interviews helped surface that development teams hadn’t yet had the opportunity to build skill sets in the areas needed to accelerate software delivery, such as automation. This was not due to staff not wanting to learn, but due to the very limited time they had available outside of delivering against multiple projects. This staff busyness was in turn due to the head of each IT function needing to commit to as many projects as possible to maximise the amount of budget their area received, meaning each person then needed to be committed to many projects and be over-utilised, leaving no time for learning the skills that will help them deliver future projects faster.

As a result of this finding, we were able to propose a single, simple strategic recommendation of amending how budget is distributed across IT functions in a way that avoids overloading the teams with work.

And the outcome?

The annual project prioritisation process was changed, leading to the beginnings of increased collaboration across IT functions and paving the way for faster project delivery. We also observed continued use of systems thinking methods following our departure for understanding and communicating complex problems.

The Contino Systems Thinking Approach

The approach begins by gathering an understanding of the symptoms across the organisation, and how those symptoms interconnect. This is performed by interviewing staff and constructing a causality diagram (or ‘Current Reality Tree’). The diagram is also used as a story-telling tool that can be iteratively refined with staff through playbacks to validate our identification of the root cause of all symptoms.

The root cause usually relates to the processes or structure of the organisation, such as how work is defined, distributed or how outcomes are measured. These processes and structures often inform how people operate and solve problems, often implicitly influencing the behaviour - the ‘culture’ of an organisation. This makes any problems with the processes often harder to see, as they have become so embedded and tacit to staff.

This is where Systems Thinking can help identify and make explicit the processes that may require evolution to enable the organisation to remain adaptable, and - in doing so - influence the underlying culture.

Following the use of Systems Thinking we have observed leadership using the Current Reality Tree as an intuitive story-telling tool with their staff. We are also seeing the resultant beginnings of team building exercises, changes to the annual budgeting cycle - and are excited to support some of their ensuing grassroot change initiatives.

Further Reading

More Articles

MLOps and the Machine Learning Lifecycle

Best Practices for MLOps and the Machine Learning Lifecycle

12 May 2020 by Katinka Gereb
How to Hold Successful Value Stream Maps Remotely

How to Hold Successful Value Stream Maps Remotely

7 May 2020 by Carlos Nunez
FinOps: How Cloud Finance Management Can Save Your Cloud Programme From Extinction

FinOps: How Cloud Finance Management Can Save Your Cloud Programme From Extinction

4 May 2020 by Deepak Ramchandani