Great landing, wrong airport
I read this phrase a while ago and it got to me. It fitted the projects I was working on. <Enter attentional bias>. These organisations I was working with were building great solutions (technically). Unfortunately, not always what their customers were expecting. It confirmed for me that Systems Thinking is really important. Combined with some new insights from behavioural sciences, you will land at the right airport.
Small side confession: reading this phrase triggered two things in me.
- A memory of that time I planned a fun getaway to Mallorca with a friend but ended up at the wrong ‘Weeze airport’. Which made me think of changing this title to “Great holiday plan, wrong airport”.
- The realisation that this phrase beautifully articulates the million-dollar question: ‘Which problem are we actually solving with this solution?’
Although the story of the first is – in hindsight – brilliant, I’ll focus on the second one in this post.
Building the desired solution for the right problem: Same questions, different answers
Imagine you’re telling me amazing stories about a perfect technical masterpiece you have been working on with a level of detail the perfectionist in me gets jealous of. Now imagine me asking “So, what exactly are you building? Why would I want to use it? How will it help me?”. Risking a crushed reputation there, but over time I got comfortable with that. I am convinced that this is where we should start. Always.
“But didn’t you read report blabla?” “You did get briefed, right?” “Shouldn’t we talk about why we’re actually here?” You’ll probably (unconsciously) mark me as naive, a mediocre listener, not very knowledgeable, and not immediately helpful. That’s ok. If all goes right, we will eventually have the right conversations where we can answer crucial questions so we can start working on the right solution for the right problem.
The thing is, when I get in a similar conversation with one of your colleagues, I’ll probably get a whole different response to my questions. And that’s exactly where it becomes interesting. A team can work on the same ‘solution’ for a problem, yet not be in consensus of what they are building, and why it’s so important. Great landing, wrong airport.
So, how do we end up in ‘great landing, wrong airport’ situations?
There are lots of reasons I can come up with, but for me it boils down to two important things:
- Not enough Systems thinking
- We want to change, innovate, scale (or all of the above), but we didn’t properly define the problem, results and behaviour
Allow me to elaborate a bit on this.
Systems Thinking – do I really need that?
If you’re new to this, I recommend reading Thinking in Systems, by Donella Meadows. She states that some of the biggest problems in the world – war, hunger, poverty – are essentially system failures. Which cannot be solved by fixing one piece in isolation from the others, because the interrelationships between them shape the behaviour of the systems.
Let’s be honest; if systems thinking is good enough for severe problems, it’s good enough for whatever problems cause your ‘great landing, wrong airport-situations’.
Systems are everywhere; our bodies and minds, the organizations we work at, economies, sports teams, universities… They contain different elements that are interrelated and influence other systems. The elements are easy to spot: the system called ‘your organization’ is made up of managers, building(s), engineers, HR specialists, computers, clients, and so on. Recognizing these single elements as systems is step 1. Define and validate systems; make sure everyone has the same perception.
Your takeaway: you are not solving problems that are independent from each other. You’re solving dynamic situations with complex systems that influence each other. Best you can do in most cases is manage this chaos. IF you treat them as systems, that is.
So, what if you don’t think in systems?
Well, you’ll probably have a great landing, but at the wrong airport.
I’d recommend you take a critical look at the solutions (landings) you’re building. More specifically, which problem(s) do they solve? Which airport do we need to land at? Note the (s) in problem(s); are we working on different solutions for the same problem or is every solution solving a specific problem? Very often, teams and organisations are so caught up in building the perfect solution, without regularly stepping out and asking: what problem are we actually solving and for whom?
Possible outcome: using or building a solution independent from the problem
- Using a software quality assessment when you have behavioural problems
- Using a strategic approach for an operational problem
- Creating a custom, high-end, top notch IT solution that can do a gazillion things, when the customer needs that one thing it cannot do
You’ll agree that this is suboptimal at the least, but once we’re caught up in such a situation it’s very likely we would do one of the above. Recognise, define, know and validate the systems. Make sure you can do your landing at the right airport.
We want to change, innovate, scale, or all the above, but we didn’t properly define the problem, results and behaviour
“And we’re going to adopt <insert buzzword> to get there!” Spoiler alert: probably not.
If you want to optimize performance, make a change last or scale successfully, it takes a bit more than that. I’m a fan and practitioner of OBM (Organizational Behaviour Management) – a tangible approach based on the science of Applied Behaviour Analysis.
In a nutshell – I could and will write another post on this soon – the OBM protocol states that any successful change starts with pinpointing the specific desired results. Which is way harder than it sounds. “Improve customer satisfaction”, for example, is way too generic. To operationalise this, it needs to be fully decomposed to observable, measurable, controllable, active behaviours and specific results.
Specifying behaviour is hard and takes time. You should avoid values, generalities, attitudes and states. Honesty and proactiveness are not behaviours. Let’s say we want/need to share more knowledge. We need to decompose that into small specific behaviours that we can observe and measure. For example:
- Document decisions in architecture decision records daily.
- The Product Owner schedules and invites relevant stakeholders for the monthly demo.
- Every blog we write is reviewed by at least 2 colleagues.
These are just examples, there’s no real right or wrong here. You decide with the team how you define results and behaviour. Starting here makes it easier to measure, analyse, provide performance feedback, add (sub)goals, assess and evaluate later.
Flight plan ready, Captain?
As said, this is hard. Make sure you invest the necessary time and bring in someone who can help you with this. The thing is, up until that great landing you can still be under the impression that everything is going great and that you built that awesome technical solution. And then you step out of the plane only to find out you landed at the wrong airport… To prevent surprises, you want to know as soon as possible if you’re heading towards the right airport. It will save you time, money, and – very importantly – a whole lot frustrations. Nothing beats a great landing at the right airport.