What’s the best approach to visualising business transformation? Why do people go about it in such different ways?
Back in 2018 I got a call from Jonathan Whelan, a business architect who was writing a book on the subject. For a while I’d had a mind to start writing my own ideas down for publication, so I was curious to see what he was creating. When we met, we immediately hit it off. Although his background was in business architecture and mine in change management, we both had huge respect for the value of each other’s approach, even though on the surface they seemed very different. As the conversation unfolded, it became clear that a book from only one of our perspectives would be unbalanced.
There followed a really productive eighteen months of dialogue and collaboration, resulting in our co-authored book, which hit the shelves in February. It has some important things to say that don’t seem to have been said much elsewhere, and while I won’t rehearse them all here, I want to share a few, in order to set up some broader reflections on why they’re not talked about.
A model of models
Visualisation is not an optional part of business transformation: to have a meaningful conversation about an organisation, you need some kind of model to be able to talk about how it works, and the linearity of words just isn’t enough to cope with the dynamics of a complex system. Everyone draws pictures and diagrams, but different silos do it in very different ways, and the different visual languages often don’t join up. The cover art by my colleague Mark Nicoll summarises the problem nicely:
Jonathan and I realised we were onto something. Why does this happen? What are the characteristics of the different varieties of visual language people use? After some whiteboarding we came up with a model that became the central framework for the book: the visualisation continuum. Here’s how it works:
Visual languages can be characterised along two dimensions. The first dimension is how constrained the visual language is:
At the freeform end, think of a whiteboard in a meeting room; anyone can, in principle, draw anything they want – one style of arrows or boxes is as good as another to mean whatever you want it to mean at that moment. At the constrained end, think of an IT specialist creating a reference architecture; in order to conform to a standards-based modelling language like Archimate or UML, each type of line pattern or arrowhead or shape has a pre-defined meaning.
The second dimension is the concreteness of the visual language:
Abstraction measures how far removed a form of visual language is from the set of experiences it stands for. An entity relationship diagram is just words, boxes and arrows, but this abstraction allows it to stand for a huge number of possible situations that it doesn’t visually resemble at all; the viewer has to add contextual knowledge in order to interpret it correctly. A cartoon drawn by a graphic facilitator, on the other hand, can be understood by a broader audience because it looks like the situation it represents, but this experience will normally be much narrower than the set of experiences represented by the boxes and arrows. In the examples above, a box saying “Payment Service” could be any payment service, whereas the picture narrows it down to card payments.
When you put these two dimensions together, and plot the commonest varieties of transformation visuals against them, you realise that they tend to fit on a diagonal continuum, like this:
Visualisation and communities of change
The categories of visuals plotted here are only intended as a representative sample, and the exact location of each element is up for debate. In the book, we take the reader on a journey along the continuum, exploring the approaches in more detail, and describing who uses them, and to what end.
And that’s where things get interesting: the more Jonathan and I talked, the more we realised that we both naturally associated particular kinds of transformation people with different ends of the continuum; broadly speaking, you had the People and Change community at the top left and the Technical Implementation community at the bottom right. While both of us wanted to think of ourselves as belonging somewhere in the middle, the reality is that our backgrounds are heavily biased towards, in my case, community 1, and in Jonathan’s case, community 2:
The reasons why people cluster on one end of the continuum or the other are not hard to see: there is undoubtedly a correlation with personality type, and we discuss at some length in the book how different individual paradigms of organisation inform the way people see and therefore visualise change. But the shortest explanation is that each group is trying to achieve a different outcome. In the people and change community, the priority tends to be aligning a broad audience around a set of high level messages. In technical implementation, the priority is to align technical experts around the workings of a complex technical solution. In community 1, the overriding question is “do people understand and buy into what we’re trying to do?”; in community 2, it’s “will this do what we expect when we press the ‘on’ switch?”
Now, it seems pretty obvious that these two questions are hugely interdependent. On one hand, engineers and architects and developers need to understand the big picture of what the organisation is trying to achieve in order to build the right solution, and on the other, the organisation will have a hard time buying into change when it has a history of messing up technical implementations. Yet, and this is really the nub of it, how often have you worked on transformation programmes where these two communities don’t even sit in the same building, let alone share a common language to explore and understand one another’s points of view?
Visual archetypes
To understand why people use visuals in such different ways, take a moment to step outside the world of business transformation altogether, and just think about the visual archetypes the matrix implies. Here are four representations of a steam train. The top left picture is Turner’s familiar depiction of a steam train, the bottom right is an engineer’s depiction. The other two are by members of my family: the bottom left by my six-year old daughter, and the top right by my late father (who was a railway artist).
Each archetype has advantages and disadvantages. The visualisation continuum implies that most transformation programmes only really use two of the archetypes:
- Concrete / freeform (top left): creating a strong but narrow impression for a large number of people
- Abstract / constrained (bottom right): creating a detailed technical depiction for the small number of people with the technical skill to interpret it
So what about the other two?
You might associate the bottom left quadrant with the kind of ‘back of an envelope’ thinking that leaders often do, and then somehow expect to see implemented. More optimistically, one could associate it with innovation, which is often born through eccentric individuals seeing the world in weird ways that no one else, to begin with, understands.
Either way, whatever insights are created in the bottom left are no good to anyone until they can be made intelligible, and as our focus is on implementation rather than ideation, it is the top right quadrant that is curiously empty. Engineers (bottom right) want technical accuracy over breadth of audience legibility, but are belittled for creating illegible “spaghetti diagrams” (the schematic above doesn’t look like a train). Comms (top left) want a broad understanding, but are belittled by engineers for creating “pretty pictures” (Turner’s Rain, Steam and Speed is pretty useless if you actually need to build a train).
But who, on a typical transformation programme, is trying to maximise both legibility and accuracy at the same time?
Maximising shared meaning
Not many, in my experience. It’s hard. It’s time consuming. It requires not just a solid grasp of the technical details, but also the skill to depict it in a meaningful way. My favourite example of this historically is the classic Haynes “Owners Workshops Manuals” of the seventies and eighties (before the exploded diagrams started to be replaced by photos):
These manuals were written for owners, not just professional mechanics, so they couldn’t make assumptions about technical literacy. The authors deconstructed an entire car before putting it back together again. That took time! They then needed the skill to visually document each step in a way that brought meaning to the accompanying text, so that the reader wasn’t overwhelmed with detail. Sadly as the home car maintenance market has largely disappeared, these beautiful diagrams are no longer being created.
I have to be careful here, in case anyone thinks I’m saying we can treat an organisation as a mechanical thing like a car. I’m only using the example to say something about our approach to visual language. There are good examples of people in other domains pursuing not just technical accuracy or just breadth of legibility, but both at the same time. So who is doing this for business transformation? Having worked for a couple of decades now in change consultancy, I can’t begin to say what a difference it makes when more of the people affected by change have a more accurate understanding of how things actually work, how they need to change, and why the change is necessary. So why is the top-right quadrant so bare?
There are things going on. We give a number of examples in the book: Annika Klyver’s wonderful Milky Way method, Milan Guenther’s Enterprise Design framework, our own work on interactive operating models. But these examples are few and far between. One of the reasons, I think, is that working in this quadrant is just hard. It requires two sensibilities, not one. The hardcore engineer is not willing to lose accuracy in order to entertain a general audience, and the average change manager is as likely to see their technical ignorance as a virtue as they are to see it as a weakness. Then there’s the time investment: by the time you’ve finished a high-fidelity map, the territory has changed, a common problem for Enterprise Architecture teams. There’s also very little theory to work off. Most of the frameworks and reference models of change are deeply embedded within one or other of the two communities, so to find a hybrid you have to go it alone to some degree. Followers of more modern change processes (agile, design thinking, dev ops) might want to lay claim to some of this territory, but I’d need a whole other article to address this – or you can read the book.
I’m going to write a lot more about this in the future, but what this project with Jonathan has really confirmed in my mind is that the organisational world needs a new practice around the concept of Shared Meaning itself, creating community, methodology and practice not in isolation from the other two communities, but as a way of drawing them closer together. And I think the grounding for this practice, the thing that’s missing from all the current attempts, is not better organisational theory, or better design theory, or even nicer pictures, but a more solid grasp of human cognition. Why’s that? Because cognitive science gives us evidence-based insights that describe what is common (within normal bounds of variation) to how humans think about things. It explains how shared meaning actually works, both biologically and phenomenologically.
I’ll just give one simple example as a flavour of what I’m talking about. One of the most basic principles of perception, described by the Gestalt school a century ago, is the distinction between figure and ground. Thinking is always intentional, that is, it has an “about-ness” to it: when you are thinking, you are thinking about something, but in order to perceive it as a thing it needs to stand out from its context. This relationship is crucial; if you want to create shared meaning, you need a shared ground, and this is one of the patterns I’ve started noticing with work that’s pushing into the top-right quadrant. In Annika Klyver’s Milky Way methodology, for example, organisational capabilities are laid out in a spiral, which could be at any level of detail. This then acts as an “anchor model” for other information to be traced across: value flows, customer journeys and so on. Here’s a schematic outline of an example:
We have adopted similar language into our own consulting practice, through the use of “base maps” and “overlays”, although with more concrete representations of the organisational elements. There has to be something underlying that doesn’t change, in order for the things that do change to be intelligible to different parties. When this is done well, it enables conversation about systemic patterns that are larger than the domain of any one stakeholder, because those patterns are portrayed against a visual representation of what is familiar to all parties.
I hope the continuum model gets you thinking about your own approach to visualisation and change. If you’d like a deeper exploration of all of this, then obviously please do buy the book and read more. If you think you either occupy, or use a methodology that exemplifies, the top right quadrant in our framework then please add a comment below or drop us a line – I’d love to hear from you!