I recently listened to “Thinking in Systems: A Primer” by Donella Meadows. I chose to listen to it via Scribd (60 day free trial via this link. Note: I get 30 free days too if you sign up this way). It’s also in book form, via the usual channels.
I found it to be a thoughtful, interesting and engaging read and I got several things out of listening to the book.
The first thing to point out is that this is NOT a book focused on computer systems or software systems. It focussed on a more general academic approach to considering a wide range of systems using well-known, rigorous analytical techniques and supporting tools. That said, it also not a detailed textbook.
Through listening, I got an overview of a technique I had not been exposed to before, although I ‘recognised’ aspects of it as a lifelong busines analyst. The section exploring how recording and explaining a series of events cannot, on its own, lead to deep understanding of how a system works resonated with me.
I found the sections on bounded rationality and the ‘pitfalls and traps’ particularly illuminating. They lead to ‘thought trains’ in my mind of approaches and habits to consider… which I plan to feature in a separate post.
I also started thinking how me might apply aspects of the theory to ourselves as a system… maybe that’s a stretch too far; let me know what you think.
I won’t be able to do justice to the full contents of the book here, so do dig it out and give it a listen/read if you find the this post interesting. In particular, this post won’t attempt to set out the system thinking techniques referred to in the book.
There are lots of websites, articles and books that cover it; from academic theory and application, to short magazine articles, with D. Meadows’s one somewhere in the middle.
So, what is this “non-IT system” thing?
System’s thinking starts from a simple set of concepts that make up any “system”. Any set of interacting, interrelated things or concepts that, together, form a more complex whole, which serves a purpose.
The more formal definitions of the concepts run something like this:
“A System is made up of Elements their Interconnections and, when these are combined, has a sense of purpose.”
Elements are the easiest for us to think about
We often miss the intangible elements when we analyse interactions
Interconnections are the often-missed parts in systems thinking
I also found it interesting to consider the following:
“The system has some integrity and an active set of mechanisms keeping that integrity. It is resilient and more than the sum of its parts”.
In my reading I have seen reference to the following real-world examples:
A system can, indeed, be a computer system
Also eight rowers in a boat, a bicycle, or a national park are all systems
Conversely, a pile of cutlery on the table is not a system; though forks arranged in a structure and supporting an apple could be considered a system.
Ok, so what - that all sounds a bit “nice… in theory”
Well, maybe that is true. However, the approach Donella takes is to set out how the theory can be applied to more everyday examples. She builds from a collection of system ‘building blocks’ using changes in the temperature of a room as a reference model, as well as others.
One particular “ah-ha…” moment of realisation, and indeed some illumination leading to increased self-awareness for me, was as follows.
Reconsidering the ‘boundary’ of a national park
If you were asked to define the boundary of a national park, you’d probably default to applying a map based, geographic boundary. This is arguably based on categorisation and boundary based approaches we have learnt in schools and have had reinforced by navigating our models of the world.
There are a large number of aspects of how we think about the world that are based on models with ‘boundaries’ around elements: counties, school catchment areas, voting boundaries, members of sports teams, and so on. For many contexts each of those boundaries is useful, well understood and serves a good purpose.
However, consider water as a key element of that ‘national park’ system; its lakes and so on. It is quite easy to see that we now also need to consider rivers and stream that start and finish outside of that ‘geographic model based’ boundary. Not to mention the underground sources of water and clouds that may be bringing water, and dissolved salts, from hundreds or thousands of miles away.
Considering clouds and rain and their impact on a national park’s water was what brought home for me the realisation: the artificial models and conceptual structures we choose to impose on a group of elements for one context often constrains our thinking about the same elements in other contexts.
That is, until we step back and widen our approach.
The “ah-ha…” that occurred in my mind was to recognise a notion I have been unknowingly driving towards for the past 4-5 years at work. Consider the artificial, ‘easy to understand’ and ‘specific purpose’ boundaries we place around teams at work that are based on line management and/or skillset (i.e. the team members are elements of a system, or perhaps a sub-system).
Probably unconsciously and out of habit over many years, these can become almost rigid mental walls. They then change our language, our approaches to problems, arguably fuel our defensive, or offensive, herd mentality and so on.
A thought led and self-awareness promoting exercise for this blog post.
I encourage you to consider how often the work and output of a team (a ‘system with a boundary’, if you like) relies on individuals (elements) that are ‘outside’ of the team. By definition, those ‘external’ to the team elements must be considered ‘inside’ the wider system that is required to execute the work.
I will bet you can radically change the efficiency of your working time by widening the system’s interactions: having more interactions where individuals (elements) on different teams work together to solve the problems required.
It is important to do so whilst avoiding language that reinforces the mental boundaries of the ‘teams’; those boundaries have been built for a different context rather than for solving problems that need elements from various teams.
Essentially you are looking at how to optimise the interactions between the elements of the wider system, breaking through/round/down the mental walls that, typically, have been implemented for an entirely different reason (Line management, skills alignment, balanced team sizes, historic reasons, etc..)
I feel this idea resonates with one of the main drives when forming Agile teams – get all the skills needed to execute work into one team, working together with a shared goal.
Whether or not the place where you work in has formally embraced a Agile approach, or even if it doesn’t want to, you can derive value and benefit from widening the ‘system of your team to include elements outside of the ‘normal’ boundaries we’ve grown accustomed to thinking within.