Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Two straight lines forms a circle

Two straight lines forms a circle

Thinking is hard. The quality of deep sleep you get every day is equally proportional to how much brain you use. According to my wife (KD), this theory of hers is as true as gravity. This is her standard response to my eternal complaint about how well she sleeps and I don’t.

 

All theories are correct until proven wrong. So, to test this theory, I decided to push my thinking even further (and also to test if there is anything left to push).

 

The first thing that popped into my head was the issue that my current team is facing.. I immediately wrote it down like this. This is how things looked from our team’s point of view. Linear. Cause and effect.

Three-part flow chart. First part says 'Team feels the pressure of a deadline' to 'They rush to finish and lower their guards' to 'Bugs introduced in the product'

 

If you have been in the software industry, the above example shouldn’t strike you as anything ‘new’. 

 

Is that how business sees too? Certainly not. From the business’ point of view things look something like below. Linear. Cause and effect. 

 

Three-part flow chart. First part says 'Bugs found in the product' to 'Features delayed. Loss of time and hence money' to 'Push team to get more done in same time to make up for time and money'

I dare say a lot of us (all you readers) see things this way - events unfolding in a straight line. However, the reality is rarely linear. If you look closely (the image below), those two lines form a circle. And in here it looks vicious.

Flow chart showing 6 parts. First says 'Team feels the pressure of a deadline' to 'They rush to finish and lower their guards' to 'Bugs introduced in the product to 'Bugs found in the product' to 'Features delayed. Loss of time and hence money' to 'Push team to get more done in same time to make up for time and money'

A problem is a problem. Labeling a problem (tech team issue, business issue etc) is just a point of view of a person who is looking at the problem. In the above example, to break this perpetual cycle, both sides need to recognize that their ‘standalone’ point of views are actually not standalone and it influences others’ point of view. Both teams are part of an organization.  An organization is a system whose purpose/function is to solve customer problems and create wealth for themselves. Both tech and business teams interact and their interaction affects the overall function of a system (i.e organization).

 

It’s about time to introduce, what is a system?

 

“A system is a whole that cannot be divided into independent parts without loss of its essential properties or functions.” [1]

 

When trying to solve a problem, thinking about interactions between those parts and how they influence each other and the overall functions of the system, is called ‘Systems Thinking’.

 

Hardly mind-blowing. Agree but the implications are.

 

Important to note here is that properties of a system derive from the interactions of its parts rather than their (parts) actions taken separately. So, when the performances of the parts of a system, considered separately, are improved, the performance of the whole may not be (and usually is not) improved.

 

Just think of any problem that you encountered recently. What did you do, when you learned about that problem? Analyzed it and put it in a particular bucket (i.e. tech team issue, budget issue, capability issue etc). And why not? This is how we have been taught - to isolate the problem area and then fix it. It works for certain problems but certainly not for complex ones. Thinking this way makes us focus on improving that particular problem area (part of a system) and ignore the interaction between that area and other parts of the system.

 

Imagine that you are from the business side and, as explained in the example above, you are not happy with the speed and quality of work that the tech team delivers. You have analyzed and isolated this as a tech team capability and commitment issue’. What would you do now? Apply more pressure on a tech team, watch over every step they take, threaten them with layoff or even get rid of them altogether? And would that solve your problems? Most probably not.

 

As mentioned above, a problem is a problem and we don’t need to assign a label. Instead we need to explore a different point of view and find which one, or combination of point of views, will give us the best solution.

 

In a Systems way of thinking, we would not just look at the events (i.e. bugs raised in the last iteration) but rather go deep and look for patterns/trends. Trying to understand the cause for those patterns/trends → underlying structure and eventually what allows those structures to persist → mental models.

 

With this understanding of the ‘whole’ we would be able to come up with a solution which not just improves the part but also improves the overall performance of the system. 

 

Of course there is a lot more to Systems thinking but the basic principles are as mentioned above. Let me also recommend a few books[2] for you to explore at your convenience to delve deeper into the concept.

 

Systems Thinking is a holistic approach and it leads to making informed choices, better solutions and of course to better sleep (it takes a lot of brainpower to think this way).

 

Unfortunately, my wife’s theory didn’t work for me. I still don’t sleep well. She insists that my efforts are not enough and asks me to think more.

 

[1] A talk by Russell Ackoff

[2] An Introduction to General System Thinking by Gerald Wienberg

[2] The Goal by Elliyahu M Goldratt and

[2] The Fifth Discipline by Peter M Senge

 

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Keep up to date with our latest insights