Sir Winston Churchill is credited for saying, never waste a good crisis. And there are few industries that experienced more existential crises due to the global pandemic than the travel and hospitality industries. In this presentation from Pieter Jordaan, Group Chief Technology Officer, Technology Transformation at TUI, shares one of the most remarkable stories of how an organization was able to use a global pandemic as a way to radically transform their organization, and also accelerate their pre-pandemic goals.
TUI Group is the world’s largest integrated travel company. Before the global pandemic it had generated nearly 20 billion euros in revenue. When the pandemic hit, they simultaneously needed to figure out how to bring nearly 2 million passengers safely back home, as well as figure out how to survive a period when almost no one wanted to travel, and still leave the pandemic even stronger than when it entered it.
This post features a transcript of Group Chief Technology Officer – Technology Transformation Pieter Jordaan’s story of TUI’s transformation amid a global pandemic. You can watch the full video of his presentation in the IT Revolution Video Library.
I am going to talk about how to DevOps the hell out of your COVID crisis.
What I would like to try and achieve is to really tell the story about how our journey as a 20 billion Euro group company went all in on cloud, totally transformed ourselves into a DevOps group, and moved our organization to the cloud during the COVID crisis. I’m going to try to tell you a little bit of how we started this journey—how we initially started with small local initiatives—and how we then eventually ended up transforming at the global scale. And, what we learned through the COVID crisis, how it accelerated us, and what we discovered. I’m going to share with you all the textbook rules I broke.
First a little background.
Who is TUI?
TUI is the world’s number one integrated travel company. What does that mean? We take about 27 million customers on vacation every year (this is pre-COVID). As an integrated travel company, we have our own airplanes (150+); 380+ hotels, contracted hotels, branded hotels, resorts; and 16 cruise ships; and 1,600 travel shops all over the world. We go to over 115 destinations worldwide. Pre-COVID, our turnover was around 19-19.5. We had our best year ever just before COVID hit us.
On the IT side, we have 20 datacenters, 400 million product combinations, 8 million price updates on a daily basis, and 58 billion searches during peak hours.
I come from a technology background, working for investment banks and building large automated trading platforms. Coming to TUI was very interesting because of the type of company it is. It’s not just an airline; it’s not just a hotel. Actually, it’s a trading company with heavy assets it needs to operate. You’d be surprised how many different ways you can price an airline seat.
Start of TUI’s DevOps Journey
So how did our journey start? Not very different from most people. Before COVID hit, we decided that we needed to go to the cloud. TUI was a very traditional company. We started by trying to mov small assets to the cloud first—trying to get buy-in in the cloud—and focused on migrating our datacenter. We were going to close all our datacenters. That was our goal.
From an Agile perspective, we had these eight big countries who all have their own e-commerce teams spearheading Agile in their country, in their initiatives, but really these were very localized initiatives. When we do big programs, they’re big programs, big projects. We measure time, we measure cost, and we really focus on risk management. Don’t touch the revenue, deliver on time.
But just before COVID we realized that as a business we needed to change. We had to consolidate. We couldn’t continue to operate as tons of small markets. We needed to start to come together.
So, we set up a big program. Every managing director of all the markets was there, all the CIOs, and the group CEO. We had this big plan, and it was going to take us years to get there. Years. Because everyone’s protecting their revenue, everyone’s protecting their local initiatives, their local nuance.
And then COVID hit. COVID hit the travel industry really, really hard as you know. Suddenly we found ourselves in a situation where we had more than 2 million customers abroad that we had to repatriate. We have cruise ships to support. Airlines couldn’t even fly back to some countries. We had cruise ships that couldn’t port.
Suddenly we have to repatriate all these customers and all the focus is back to: How do we control our burn rate? How do we bring all our customers back?
One of the number one decisions the board made was that this initiative to consolidate that we had started cannot go to waste. Especially the fact that we as a company probably will experience prolonged reduction in revenues due to the pandemic.
That’s when we decided we have to change the way we do our transformation. We have to do it now, and we’re going to have to do it fast. We went from small, local transformations, picking the best, moving one country at a time, to consolidating the whole organization now. Use this crisis, use this depression of our revenue to consolidate the business, consolidate IT.
The Fast Path to Transformation: Breaking All the Rules
So what did we do? We decided to go from a project structure to a product structure. We had to totally change the way our local organization system was organized. We had to change the way IT was organized. We had to have one IT, one platform, that delivered value and capabilities to all the markets. And, we had to change the business to also consolidate around a single capability, no half, five, six, eight different e-commerce teams and five different ways to contract.
We had to contract once, price once, sell once, and really digitize the processes.
This was the agreement given to us, given to me, and that set us on this journey. We managed to achieve in a few months what probably would have taken us years. Looking back at our pre-COVID program plan, it would have taken us years to get to what we’ve already achieved.
Now I’m going to tell you how we did it, what principles we followed, and also what rules we broke.
What was our goal? Our goal was pretty similar to most companies. We wanted to have a global product organization powered by a single digital platform. What does that mean? We don’t want to have 10 selling platforms. We don’t want to have 10 contracting platforms. We don’t want to have 10 customer service desks. We want to do stuff once, which is the right thing to do, which is the right condition.
The question isn’t whether you should do it, the question is how do you get there? And this is really what we started to do. We decided we needed to consolidate all of our IT, and then let the business capabilities consolidate around IT, but we still needed to serve the local markets. And of course, in any big program, markets fight for their little nuances. Well, with the crisis, suddenly that changed massively.
We ended up deciding to build a single IT platform, based in the cloud, totally DevOps and focused on flow. If we had done this the textbook way it would have taken us 20 years to complete.
Broken Rule #1: From Moving in Small Increments to Big Migrations
Instead, the first rule we broke was actually on cloud migration. Everyone always says, “Take your smallest little application, move it to the cloud, learn, grow, get people’s confidence.” What we decided to do was take the selling platform, which is responsible for 50% of our revenue, and move it through the cloud. Because of the program timelines, we only had six months. I asked the team, “How long is it going to take you? They said, “Oh, it’ll take us two years.” I said, “Well, you have six months.”
Of course we didn’t have the skills, so we got cloud experts in. But we trained our staff alongside these experts. We migrated this whole stack in six and a half months. And this was the catalyst for us to be able to start to feel confident that we could do this program. We could do this total transformation. And it changed the way that the business started to view IT and IT transformations, because they started to see the benefit.
Broken Rule #2: From Executive Buy-In to Changing the Mindset
The next thing I want to talk about is the transformation our business is undergoing and has to undergo because of this transformation. We are a big group. We grew through acquisitions, and those acquisitions meant different PNLs existed in certain groups. Each PNL then has their own CIO looking after their KPIs and uptime. You have different general managers looking after their sales and their purchasing and their product indication. And each one of them is responsible for their revenues.
But if you want to consolidate all of that into a single group use, you have to give up some autonomy. You have to trade autonomy for the benefit of doing stuff once.
That requires three fundamental shifts in leadership: 1) change from a wide to a deep single-domain ownership; 2) move from hiring general managers who are managing third-party suppliers and toward people who can lead and transform in-house; 3) and finally it requires a mindset shift from risk aversion to managing the creative process (failing fast).
I would say that this is the biggest single accelerator you can have in your business. If you talk to anyone about cloud migration, if you talk to them about transforming your business, they will say executive buy-in.
But what does executive buy-in really mean? I think it’s not just buy-in and saying, “Yes, here’s the money. Go do it.” You also need to get the buy-in to change the way the leaders are acting and making decisions on what they are protecting.
In the old world, where you have different PNLs and smaller companies, each one of them protecting their little KPIs, the CIO has a very wide remit, they have ITIL capabilities, they have KPIs and they must report to the board. They manage this risk. The CIO basically tries to avoid breaking things and only touch stuff if the business wants to do it. So avoiding failure is their number one goal.
What we are at TUI are shifting toward is we had to change from a wide to a deep single-domain ownership. What that requires is a technical leader who can transform and who can also perform transformation. What does it mean when I say transformation? I mean, maturity, maturity of cloud, maturity of DevOps, maturity of your flow of business value out of the door.
And that requires technology understanding, it requires organizational understanding. It requires understanding what the market is doing. It’s a very different type of leader.
We had to change our top structure. We started to recruit very differently, away from general managers who are managing a third-party supplier and toward people who can lead and transform in-house. We made a conscious decision that we want to own our destiny, our future, our intellectual property. And that required us to change the way that we recruit.
I think the main difference for me is in the mindset of these leaders: Instead of managing risk as their first motivating principle, managing the creative process was their focus. Because instead of trying to not make mistakes, it’s essential to see that failure is part of the creative process. And in order for you to deliver flow, in order for you to transform quickly, you have to fail. You have to fail fast, you have to fail safe, and you need your blast radius small. But this is a mindset requirement. This is not a tool set. This is not something you can download and get your team to use. This is a way to think, and this is a way to make decisions.
Broken Rule #3: From Migration to Net New Design
Next we decided that we needed to make some fundamental decisions in our process of making this transformation. So at this stage, just as COVID hit us, we already had this big program set up, but suddenly our timeline shrunk massively. Instead of having years, we had months. And actually we had a window that was quite uncertain. It was closing in on us all the time. Where we were making decisions based on revenue, now we were making decisions based on “how fast can I bring this transformation about in the safest way so that I can protect the benefits instead of my previous way of thinking that I need to protect risk all the time?”
Our first success was really the change in leadership. All our leaders started to read the books that helped us think about the transformation progress and process in terms of flow and creativity and incremental delivery, instead of milestones and cost.
The next bit we realized was that the cloud is oxygen. We had made the decision to move to the cloud a long time ago, when we first made this large migration. You can’t really do this large type of technology migration without going through the cloud.
What we decided was we needed to change our cloud migration strategy. Our early strategy was to close our datacenters, and all of our decisions were based around that. It was based around taking the easiest asset, migrating it, slowly, slowly, moving it, that would have taken us years.
So we changed that and said, “No, we’re going to build net new and just retire the datacenter. We’re just going to close it. We’re not migrating anymore. We’re building what’s required for this business, for its technology and business transformation.” So I’ll talk a little bit more about that in the next slide on what rules we then applied, but cloud is, for me, the fundamental starting block with a different type of leader.
Broken Rule #4: From Team by Team to Whole Organizational Move
The next thing we changed was instead of saying, “Okay, which business wants to change?” We said, “No, no, let IT consolidate then let the business migrate.” Why? Well, the CEO came to me and said, “Pieter, until you give me a single platform, I can’t consolidate my business because my business is organized around individual capabilities.” I realized I had to go much, much faster and consolidate building the platform so that there was a single commercial platform, there was a single pricing platform. And that’s why we decided to shift to both product and all in on cloud. And what you get is being a product-focused organization helps you become an Agile organization. And cloud helps you Agile and DevOps to become the default.
Starting with cloud and product as your primary goals, Agile and DevOps is the natural outcome, the culture that you adopt and the organization’s way of behaving and changing.
Changing How You View Risk
I talked about the way we had to change our view of risk, and we had to adopt a day-one mentality. We decided we’re not going to solve problems that don’t exist. We have to move fast. We’re going to deliver in global increments. We had a global hackathon where all the teams worked together, and we decided that hackathons would become our way of working.
Today, we run in six-week increments. We have a hackathon day, a demo day, and then we deliver.
The last thing is we moved to focus on visibility, on flow and business value. How does this translate into practical decision-making? Well, we came up with rules.
The first rule we decided was we have to move fast and we have to move in increments. And because of COVID, because of this accelerated timeline, the business also suddenly had to make decisions quickly. So I would say, “Hey, I’m building a pricing module, which one of your ten pricing structures do you want me to build? I’m only building one, so which one do you want?”
That was the second rule, capability exists once. I’m not building ten different pricing structures; I’m building one. I’m not building ten web platforms; I’m building one. That forced the business to break the universe down, join the transformation, join the incremental thinking process, and our creative flow of business value started to really take value.
The third rule we made was everyone will go to AWS. We basically abandoned all activities that were multi-cloud. We said, “You will go to AWS. Not just that, you will use the highest level available service possible. You won’t build something that already exists. You will choose serverless and step-function first and only build something if you can’t do it with those.”
What that did is it helped us to really accelerate and focus on business value. We built net-new services. There are services we migrated, existing SAS services we used, and there’s other services that we said, “Okay, we will migrate, or we will transform over time.” But the majority of our platform now is net-new. I don’t have to worry about migrating old third-party legacy platforms to the cloud because frankly, those guys were not interested. So I’m just going to retire it, I’m building what I need, and I will retire my datacenters.
The fourth rule was avoid one-way door decisions. Why? So I can make decisions quickly and I can stay flexible. I can change in the future. We talked about investing once but using multiple times, so I’m building it for everybody. I’m not building it for this market or this market, their nuance, their little different green button versus that pink button on a different page. I want to build once.
That really helped with the business flow, and that’s probably one of the hardest bits, to get all these markets to agree on what they want. The pressure of COVID helped to distill this down to the most essential business value components that we needed to deliver.
The fifth rule was to consolidate large business value first. Why is that important? It’s important because in the past, we’d leave our biggest business to come onboard last, because they’re like, “Hey, I’m making too much money. Don’t touch me. You build first then I’ll decide to come on board. Let me see what you deliver for me.” No, no, no, no. Suddenly it’s about the laid benefits. “Okay, you come on board, you immediately get the benefit of the other market.” If in the past I invested $5 million, and then $5 million, and then $5 million, today I’m investing 20 minutes and I’m only moving forward $5 million once. Now I can invest $10 million in everyone collectively, moving forward twice as fast.
Consolidating the largest business is really important. That is the biggest challenge, but it’s also one of the biggest shifts that we made. And that really forced the business to break the universe into smaller parts.
So we focused on nothing bigger than one increment. We ran incremental, global increments, six weeks, then to Hackathon and a demo day, and then we release. Why did we need to do this? Suddenly our teams were not in the same office. They were sitting anywhere in the world. We needed to now collaborate from home, both develop and release in an Agile DevOps fashion, move to cloud, and move to a pro-organization all at once while everyone’s working at home.