Meaning Guide

Easy-to-understand vs hard-to-understand misunderstandings

I gave a talk at the IRM Innovation and Business Transformation conference last week with the title “Getting the ducks on the same hymnsheet: How shared language enables transformation”.  The response was lovely, and one of the points that seemed to particularly resonate with the audience was just how hard misinterpretations can be to spot, and how long they can go unnoticed for.  Language is like the air we breathe – our default setting is to ignore it until something starts to smell bad.  I made this point by drawing a distinction between “easy-to-understand” misunderstandings and “hard-to-understand” misunderstandings, which I want to re-iterate here.

An easy-to-understand misunderstanding is one that makes good newspaper copy once discovered:  People weren’t talking to each other, they made a stupid mistake, the mistake can be captured in a simple newspaper headline and we can all point and laugh at them.  The Mars Orbiter fiasco in 1999 falls into this category.  No one on the programme team noticed that Lockheed Martin was writing software in imperial measures while NASA was using metric.  Until, that is, the Orbiter actually got to Mars, descended into the atmosphere at the wrong angle and exploded.

This is a nice, easy-to-understand misunderstanding, a simple tom-ah-to / tom-ay-to type problem that (we might like to think) could have been solved with better programme controls, a better set of definitions, a better programme glossary, co-located teams, or whatever.

But this is not how most misinterpretations arise.  Most of the time on organisational transformation programmes we don’t have a clear and complete idea of what we’re dealing with, because the objectives are not clearly defined, the context is evolving, different stakeholders want different things, pilot projects throw up new information, new constraints are enforced that reframe the situation, and the problem we’re trying to solve is so complex and emergent that one person could never get their head around it all anyway, let alone the whole team.  It’s a completely different kind of challenge to just getting everyone to use the same naming or measuring or modelling conventions.

When things are complex and ambiguous, what usually matters more to us is feeling safe, and in the early days of a transformation programme when people don’t know each other, being heard to sound knowledgeable / in control / confident is usually more important than whether the words actually mean anything.  In other words, you end up in a situation that’s more like this:

This is pretty basic human stuff and it applies to all aspects of life, but on early transformation work where people don’t know each other, it becomes marked.  The solution I suggested last week and I want to repeat here comes down to leadership, specifically the ability of the programme leadership to establish a culture of curiosity from the outset.  This means a culture in which it’s OK not to know the answer, where new and seemingly stupid questions can be asked openly, where new team members are not censured for not being up to speed, and in which core concepts are framed in terms of concrete experiences rather than abstract theories or conjecture.

I suggested a really simple way of telling if you have this kind of culture, and it wasn’t by doing detailed analysis, audits or surveys, but by just looking at the body language of your colleagues in meetings.  You can usually tell when everyone understands what the conversation is about, because they become much more animated.  I’ve talked about this before:  People care about the things they understand, and want to understand the things they care about.  If your team reviews are fairly turgid affairs with lots of vacant expressions and periods of silence, then maybe it’s time to ask how much of the meaning of the words you are using are genuinely shared across the team?

Subscribe to new content:


Subscribe to new content: