(or how I learned to stop worrying and love the Thinking)
Why I’m writing this
I have a new client. They’re a large Financial Organisation, therefore operating in a highly regulated market, with heavy compliance etc. requirements. The sorts of things that end up creating a paranoid organisational mindset, with a significant audit theme running through everything that they do.
The nature of this client is such that new ideas take a while (if at all) to establish. That pace isn’t helped by the fact that organisations like these generally are flush with cash – they can afford to overspend as well as maintain “death-march projects”. This is a functional characteristic and is neither good nor bad. It does, however, mean that delivery techniques that are radically different culturally to the prevailing winds are unlikely to be welcomed with open arms (i.e. there is no urgency to change). One such idea, is “User Centric Design”. This is a premise that the right thing to do is design services specifically for your Users. This cultural anchor (the Customer is central to everything) is more prevalent in front office teams (e.g. for a Bank, those might be branch staff), but isn’t necessarily the case in back office teams (e.g. the “IT Department”). User Centred Thinking may lead to better bank accounts, savings accounts, or interest rates, but is less likely to be adopted to improve the systems that an actuary might use.
Enter the labels “Design Thinking” and “System Thinking”.
What is “Design Thinking”?
The term has been gaining popularity over the last few years. I currently believe the term “Design Thinking” that represents a design thinking process (with terms like empathise, define, ideate, prototype and test) was popularised by the likes of Tim Brown and others at IDEO. The term Design Thinking might have been coined in the seventies, but ancestor terms such as “wicked problems” are far older. Even older are a lot of the concepts – divergent thinking to gather options, followed by convergent thinking to make a choice, test, learn, rinse and repeat – must have been around for about as long as humans have been experimenting. The Double Diamond process was created by The British Design Council for example. This a sketch:
How about “Systems Thinking”?
Disclosure: My introduction to “systems thinking” (lowercase, not branded, definitely not a Proper Noun) came from my undergraduate degree. Except I learnt about this under the banner “Systems Engineering”. Well, more specifically, when in a Mechanical Engineering lecture, my professor got us all to play a heavily modified version of Mousetrap (I’m sure other games are available). That was my first introduction to stock and flow diagrams. That also made me realise that I’d been using a system thinking mindset for a while leading up to that lecture. It turns out that my dad and I playing with Meccano and Dominos at the same time – building mechanised arms to tip dominos over is surprisingly good fun for most of the time, although the clean-up at the end is a royal PITF (pain in the foot) – is a good way for me to begin to work out how to build models in my head to predict the future, especially complicated when there are multiple events occurring simultaneously. That Engineering thing carried on into my Electronics and Control Theory (academic) life.
In business, the term seems to have more than the abstract analytical mindset that I learned about at University. The work that Deming did with Japanese manufacturers during the ‘50s and onwards started with a very basic model:
In this diagram, the customer (consumer) is another component, interacting with everything else. “Frameworks” such as Vanguard and books such as The Fifth Discipline etc. have moved the customer to be far closer to the centre of the system model. More precisely, in order to better define the purpose of the system. In itself, that’s not a problem, but it did take me a surprisingly long time to reconcile my perspective (systems-thinking-is-an-analytic-discipline) with the customer-centricity that I was seeing. Mostly because, I was seeing that human-centricity aspect as “Design Thinking” (rightly or wrongly, probably wrongly).
My View of the Differences between Design Thinking and Systems Thinking…
One of the things I find helpful for my focus when learning (or even just thinking) about a topic, is the ability to detect when I go off track and get distracted. To help me reason about either Design Thinking or System Thinking, it helps if I can create some space between the two concepts, just so that if necessary, I can also think about what a concept is not. It’s a form of abstraction and an aid to my thinking.
…and Why it doesn’t really Matter
Assuming that the previous section resonates with you, dear reader, the main reason why I don’t believe it really matters where the precise boundary is between the two concepts, is because you need to incorporate both thinking models into your overall problem solving to genuinely make a difference to your customer. For example, whether you think about User Needs because you’re using Design Thinking or System Thinking isn’t relevant. What is important, is the fact that you’re actually considering User Needs.
Why is my client trying these?
This is an interesting question, and I’ve no real way of getting a completely accurate answer from anyone I’m in contact with, so this is where I get my theorising kicks from.
From what I’ve been able to observe, this client has had multiple attempts at one form of “agile transformation” or another over the past several years. While all of these attempts moved the organisation forward (for some definition of forward), none of the attempts did much more than improve the practices in effect at that organisation. Manager types still managed (although the role names did change a few times over the years). Requirements specialists still produced documents (although the name of the documents and the templates followed changed). Business engagement was still limited – in this case, limited to Product Managers. Product Owners (there is a difference at this client) were more likely to be a subject matter expert or a requirements specialist. In other words, a proxy to someone who more may be more appropriate to “own” what’s being delivered, but has insufficient time away from the day job. A centralised architecture function would determine standards to adhere to, and would be where approvals would be sought when teams wished to implement a design pattern (sometimes quite a low level decision).
The underlying culture appears to be quite resilient to change, and is what I would expect to see in a typical hierarchical, command & control, low trust, low empowerment organisation. Again, no value judgements from me, but it is a prevailing culture that’s a polar opposite to the empowered, distributed authority, high trust, high collaboration culture that an agile way of working would require to truly shine. I think this underlying cultural resistance is one of the drivers for using these “differently termed techniques”. In particular, there’s a keenness by (very) senior leadership to adopt Systems Thinking, as the term doesn’t match any of the existing organisational silos or fiefdoms. In that respect, “Design Thinking” is a little harder, as one could argue (for example) that “As the Enterprise Architects are responsible for Service Design, that’s clearly where Design Thinking fits in”. Granted, your sanity could be questioned if you argued that point of view, but still, it’s possible. That is one of the strategies that a resilient bureaucracy can use to negate the risks associated with an invading culture – convert the new concepts into existing ones, and thereby eliminate the need to change. In order to stand a chance of converting the status quo, one needs to be careful about the battles that are picked.
Amateur Coach 