Danger zones on the way to cloud: the Mists of Confusion, the Mountains of No, and the Swamps of Error

‘We’ve tried this before. It didn’t work then. What makes this time different?’

Are there any more dispiriting words to hear when you’re leading transformation? If you’ve been in that job, the scene is familiar. You have built the business case. You have secured the investment for the programme. You have found your partners. You have prepared your slides and you have organised the launch meeting. You are ready to inspire, organise and motivate. You have delivered your pitch and you have opened the floor for questions.

The first hand that goes up is from a veteran member of the team. They have lived through many changes. They know the systems inside out. Their support is vital: other people will follow their lead. And then they ask that dreaded question.

‘We’ve tried this before. It didn’t work then. What makes this time different?’

You knew that this question was coming, but you still don’t have a good answer. You fumble your way through something about having stronger executive backing and better partners, about having learnt the lessons from the past. But you know that you have not been convincing.

Six months later. You are giving a presentation to the same group of people. The launch of the programme has not been easy. You are running behind. Your executives are nervous. Budgets are under pressure. But nevertheless, you put a brave face on things, and you present the positives. And, when it’s time for questions, that hand goes up again.

‘We knew this wasn’t going to work. How much more effort are we going to put into it before we call it quits?’

This time you sympathise with the questioner. After all, wouldn’t it be easier to pivot, to switch to a different strategy? You knew this was going to be hard, but it’s much harder than you ever imagined. And, despite challenges, you’ve had a few successes. Would it be so bad to just take those victories and walk away?

Transformation is difficult and the temptation to give up is constant. For some people, such as the questioner in the scene above, it’s there from the beginning. I believe that one of the biggest and most common mistakes in transformation is to give up part way through, to leave the journey half completed.

This is the fourth in a series of articles about non-technical essentials for cloud transformation, one of the biggest technology transformations that companies will undertake. The other articles covered motivation and ambition, leadership and thought, balance and empowerment. This was supposed to be a single article, but it turned out that there was a lot to say - and there’ll be one more article to bring all these themes together. Fittingly, for an entry in a series that wasn’t supposed to be this long, this article is about persistence.

The journey from a legacy, on-premise architecture to cloud is difficult, especially when you realise that you’re not just moving technical assets such as applications, servers and datasets: you are moving your teams and the way they work. Let’s consider three steps along that journey that present particular challenges, make the prospect of giving up ever more tempting, and require persistence to get through.

The Mists of Confusion

You will be shrouded in the mists of confusion at the beginning of your journey.

What is cloud? Why are we moving to cloud? Isn’t cloud just someone else’s computer? Is cloud even allowed in our industry? What about privacy? What about security? What about regulation?

All of these questions are legitimate and, as ever, we shouldn’t blame people for not knowing the answers. At the beginning of the journey, our job is to explain, patiently and carefully, in language that everybody understands, until the mists start to lift and we can see the path ahead. It takes time, and the effort required should not be underestimated.

Unfortunately, though, the Mists of Confusion are not a region you traverse once: they can descend at any time. You may find yourself in a steering committee, or a leadership meeting, or with a DevOps team, and find that all of these questions you thought you had answered are still on people’s minds. Why are we moving to cloud? Is cloud allowed? What about privacy? And security? And so on.

It’s easy to get frustrated if you have answered these questions already, but it’s better to recognise that they will never go away. You will never achieve perfect understanding, for all stakeholders, at all times. The patience and clarity you exhibited at the beginning of your journey are required until the very end: you just need to keep on summoning them.

In this case, persistence requires patience.

The Mountains of No

Encountering the same questions over and over again can be frustrating, but it can sometimes be worse to encounter answers, especially when those answers always seem to be, ‘No’. The Mountains of No are made of all those policies and procedures which tell you that cloud is simply not allowed. Their height and steepness will vary depending on your industry and company: in very hierarchical companies in highly regulated industries, they may be very steep indeed. However, they seem to exist everywhere: there is always a reason not to do something.

The key to scaling the Mountains of No is to know your ground and look for footholds. Often, policies are not intended to exclude cloud; they are simply intended to protect the company from particular types of risk. Can you show how that risk can be addressed on cloud? Similarly, it is very unusual for regulations to explicitly prevent companies from using cloud; rather, they ask them to show that they genuinely understand how to manage cloud effectively. Can you show that you have this understanding?

It’s important to recognise that the Mountains of No can almost never be avoided, and that to attempt to do so is usually a mistake. Even if you think you have evaded them, you will suddenly find them in front of you, blocking your path. Best to stop pretending that they don’t exist, understand the intentions at their roots, and get on with the work of addressing those intentions.

In this case, persistence requires diligence.

The Swamps of Error

You will make mistakes on your journey to cloud. Somebody will misconfigure permissions for an asset, and expose it to potential unauthorized access. Somebody will make deployment choices which expose a critical system to a zone level failure. Somebody will let a job consume uncontrolled levels of resources, resulting in an unexpectedly large bill. And these are just the small, system level fumbles. You’ll also make architectural mistakes and strategic mistakes, picking sub-optimal services and products when there were better choices available, configuring your network and permissions structures in ways you regret, selecting migration paths which turn out to be harder than expected.

The question is not whether you or someone else will fall into one or more of these patches of swampy ground, it’s what you do when they do. You can respond with blame and dismay, asking the person who is steadily sinking into the ground to explain why they were so stupid, before retreating in disarray. Or you can remain calm, help them back onto solid ground, figure out what you learnt, adjust your map, lay boards and bridges, and proceed on your way.

In this case, persistence requires generosity.

These are not the only danger zones that you will encounter in your journey to cloud: if you are part way on your journey, I am sure that you can think of many more.

Rather than exploring those, though, let’s return to the question at the start of this article.

‘We’ve tried this before. It didn’t work then. What makes this time different?’

Cloud is not new any more. Many companies are on their second or third attempt at cloud transformation. Or they are part way through their first and wondering why it is so hard. What do you say in response to this question? If you’ve mastered the three types of persistence outlined in this article, then you can remind the questioner patiently about the reasons for the transformation and why you believe it can work, you can show how policies and procedural obstacles are steadily and diligently being overcome, and you can explain how even errors, approached with generosity, are pushing the transformation forward. And, at root, you can say that this time it’s going to be different because we’re not going to give up: we’re going to persist.