By coincidence, I had the same conversation this week with five different groups of people. I figured that I’d write my ideas down and chuck them up on the blog, since this chain of thought seems to resonate with so many. This conversation starts with a bias…Many of the people I work with are engineers. They may have since moved on to be senior leaders or executives but they were once upon a time engineers and they still think like engineers. What this often means is that, when it comes to cloud or Cloud Native, their thinking is miles ahead of their own people. So far ahead, in fact, they might not even have the words to describe what they think. Then they get annoyed at their own people for not reading their minds. This is the “curse of knowledge” and it appears in our Cloud Native Transformation book, on page 53:
Curse of knowledge
When better informed people find it extremely difficult to think about problems from the perspective of less well-informed people.
Cloud native relationship: Our clients’ engineers [or leaders who were engineers] frequently struggle to sell Cloud Native ideas to their managers due to this bias: they see so clearly why this is the right thing to do that they forget the managers have no background knowledge that enables them to understand it with equal clarity. Even our own engineers and consultants, so immersed in Cloud Native, need to stay mindful of seeing things from the perspective of clients who are new to Cloud Native.
The question then, is “is there a way to overcome this bias?” The first step is knowing it. The second step is to draw from some patterns that specifically help leaders to overcome it. Let’s look at those patterns, in order.
I have my co-founder and CRO Pini Reznik and the rest of the executive team, and they have me. When the curse grabs one of us, we can gently point out to the other person that they are being quite unrealistic. The same applies during a Cloud Native transformation, where the core team can help and support each other to clarify their message. In both cases this relies on high levels of trust between team members, and so maintaining psychological safety is critical.
Some people think a vision is one of those non-engineering, bullshitty things that MBAers do, but in our experience, successful Cloud Native transformations have a vision. A lot of the people I work with cannot articulate their vision clearly. Creating the vision is hard work, but it has to be done to overcome this bias. In fact, we work hard to overcome this bias in the same way we work hard to overcome all our biases.
Gradually Raising the Stakes
Cloud Native transformation is hard, prone to blow up in your face, and all encompassing, requiring many people. Those people should slowly learn together. We can gradually raise the stakes with an MVP or a reference architecture. We should start by helping just one team to succeed.
Reduce the Cost of Experimentation
Once we have started to gradually raise the stakes, something cool happens: the cost of experimentation goes down. This is another way of saying the cost of learning goes down, meaning that the rate of learning increases dramatically.
Only after a lot of hard work will an organisation be able to make a big bet. Those who have the curse of knowledge often start with a big bet. This is foolhardy. When it comes to Cloud Native, you should not make big bets until the odds are stacked in your favour.
There is one more important bias, and it appears on page 52:
The tendency to avoid options for which missing information makes the probability of the outcome seem “unknown.” An example of the ambiguity effect is that most people would choose a regular paycheck over the unknown payoff of a business venture.
Cloud Native relationship: This bias is the main reason to run experiments early in a transformation, to understand the project’s scope and fill in the missing information gaps. Otherwise, people tend to do what they have always done, because they know exactly how that worked, even when it no longer applies to the new context.
If the leader cannot overcome their own “curse of knowledge” and set a clear direction and encourage experimentation (the exact thing Cloud Native was created to enable), then they condemn their whole organisation to the “ambiguity effect”. The whole organisation will therefore do what it has always done. This is the real cost of the curse of knowledge.