Skyscanner’s Chief Technology Officer Andrew Phillips joined the Scottish unicorn fresh out of uni, turning down a glamorous role at GCHQ in favour of a scrappy start up that started as an idea sketched out on a pub beermat. It was a big gamble – and one that paid off. Fast forward 14 years and that business has grown to be a global leader with over 110m monthly users across the world…and Andrew has gone from the most junior coder in the building to leading a team of over 700 engineers across Europe and Asia.
What does it take to make that shift? For Andrew, the constants have been learnings, mistakes, and, of course, change. Come along to hear how to scale your team from 20 engineers, to 100 engineers, and then again to 500. As a leader, how do you shift your mindset and approach as your organisation accelerates – and how do you ensure you’re continuing to adapt and be of value to your team? For anyone who is looking to understand how to grow and develop in their current role, how to scare themselves, how to stretch and how to embrace failure, this talk is for you.
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Thank you. Hi there. Thanks. Yes. As Scott said, I've been at Skyscanner nearly fifteen years. When I was thinking about this presentation, I wasn't sure how many people here would have been at Skyscanner. As I started walking around, we've got everyone from Gareth, founder, to people who've who are currently here.
So apologies in advance for anything I say that's mildly offensive to anyone who's been there at the time. If I get it entirely wrong, thankfully, there's no q and a straight after this. So you can't correct me despite some hecklers who've been trying from the back already.
So, yeah, I'm gonna I'm gonna take you through a little bit of my view of Skyscanner over the last about fourteen years and nine months and a bit. As I said, I I joined straight out of university, had no idea what I was getting myself into.
I had a job offer at GCHQ, which sounded quite interesting in that I had to do even to do the interview, had sign the official secrets act and get also some background checks. But it was not the rocket ship that has been explained.
It felt like a slow and steady, you know, you just keep keep ticking on and that just wasn't wasn't my wasn't my thing. So I didn't know, obviously at the time, Sky's gonna be the huge success it's been. But hopefully over the next half hour or so, give you a bit of insight into into what's happened, what we've got right, but predominantly what we've got wrong.
So I I will try and avoid anyone's names from the from the where where we went wrong. For any of you who don't know, Skyscanner found in two thousand three in in Edinburgh, Gareth, Bonham Barry, Grew quite a bit to start with and as I like to show on some of the pictures around two thousand nine when I joined, the hockey stick really started to grow up, to grow nothing at all to do with me.
But that is around the point where things started to get really quite interesting and where where you see that that that growth curve. It's we are predominantly B2C and all of you hopefully have heard of Skyscanner, have used Skyscanner at some point to book travel or not to book travel directly.
We don't actually book tickets on Skyscanner. Although we get lots of questions from people of, can I get a refund? Can I change? Can I can I cancel something? Which always baffles me is the amount of money you've spent and you don't know where you've actually put your money.
So, yeah, I joined and there's about twenty twenty one people at the time, only about ten people in engineering. And we've always been about fifty fifty in terms of engineering to the rest of the company. That that's important to know and realize in the context of how big we've been as a company and some of the lessons we've had because a lot of it, a lot of the changes that we've done have always kind of come from engineering as being that engineering led company.
And a lot of the things we've said, oh, let's let's try it in engineering, see if it works. If it does, great, maybe it will work for the rest of the company. So there's a there's a bit of a bit of that in there.
We're global, mobile, etcetera. We've had a few interesting lessons along the way, nothing to do with our size, but one of the things that always entertain me was when we first launched our mobile app. We thought, well, we'll probably get to about a million downloads in the first year or so.
And I think it was the first week that we hit a million downloads. It just exploded overnight. And so we of course had not planned for it. Didn't have the infrastructure, hadn't thought that that would be the success it was. It was great fun.
Everyone, all hands on deck, like let's figure this out. So, things like that have always been quite entertaining to to to experience and live through. But today I'm gonna talk through a few things. As if I've kind of tried to group them into themes or areas, whilst I'm an engineer at heart, I'm not allowed to do any coding anymore.
When I first joined, think one of the things I said was my mission will be to remove all of Gareth's code. Now everyone says that about me. So definitely not in the detail of things anymore. And so some of this is a bit about more of culture, people, process, organizational design.
And there are extra slides on software because it wouldn't I wouldn't be doing my job if I wasn't spending a fair bit of time talking about that. To give you a bit of kind of context history, I've done this in headcount and the graph of success kind of looks fairly similar in volume of sessions, revenue, etcetera, etcetera.
But I wanted to call out a couple of points and they are what I would call inflection points or what's commonly referred to as inflection points. The orange piece is where we've got to a hundred and then five hundred as a total headcount.
And they've been bigger tipping points, but some of the time it's been fairly fluid in terms of the challenges all the time. But that there, I've tried to anchor around those points in history. Where it's blue are roughly double that, so that half of the engineering team was about one hundred people around twenty twelve and around five hundred people in twenty seventeen.
You can see this drop weirdly the year after COVID, not COVID, but it was COVID related. When as we have grown as a business and everything, it was a really unfortunate situation to be a tech company in travel. While all the tech companies, lots of you I'm sure, were out there hiring their way through COVID and growing hugely and everything.
We were, yeah, we were losing money, we were struggling, we had a really hard time. And so we got a sort of slightly lagging drop in overall headcount. We're still, while we're back to give or take the same numbers now, we've kind of shifted a little bit as a business and took a lot of learning from that actually.
Was, I was just saying to Grant before I came up that just before that, was like, I've been at Skyscanner ten years now, I wonder what will be next. And slightly morbid thing to say, but COVID was actually really interesting in a, you're managing a company through a lot of change, a lot of adversity.
We had thirty something percent year on year attrition for several years. We we had a huge turnover of staff. All the intrinsic knowledge that's built into the system from that, you lose. So it gets quite it gets quite hard. So yeah, I'll touch on some of those points as we go through.
And so I'll start with custom obsession. Custom obsession is probably the kind of wrong term. The way that when even when I first started, we talked about being traveler first. And traveler first has been it's not it wasn't a value of ours. It was not a way of thinking or wasn't a way of talking in some ways, but it was a way of thinking.
It was always really deeply seated in there. And I think it was a lot down to Gareth and the rest of the founders where we were actually solving a problem for a real customer. And as things evolved in that way, we got some things right, we got some things wrong.
I remember as you're going through the kind of the history or the timeline here, we did a huge campaign, marketing campaign to drive lots of traffic in. I think we were kind of trying to get to fifty million unique monthly visitors. And so we bought in lots of traffic, but we bought in lots of traffic through social channels as that was becoming big for us, paying very little for the traffic which resulted in very little.
It was a huge, huge effort, huge campaign, but we didn't see that turning into people who actually wanted to come back to Skyscan or even booked in the first place. So there's a bit of a lesson there of like, what metrics, what you're looking at, what numbers do you index for.
If you just index for pure session growth, as we were kind of thinking about the time, you can trip yourself up. And around the kind of twenty fourteen, twenty fifteen mark, we started thinking more about the partner side of things. And partners had obviously been very important, airlines, travel agents, hoteliers, etcetera, always been very important in the industry and for us.
But we started building products around them, and actually starting to give them data back and empower them to do better in our ecosystem. And that may seem funny in some ways, obviously we're building something to serve travelers. But we started having these tools we could use to push airlines or travel agents to be better, to do better for the travelers.
So that traveler first, partner second, and then ultimately the kind of revenue and everything that comes from doing the right thing is the Skyscanner third piece. We were also We also always thought quite globally, and I was I was impressed when I joined, within within the first year or so of joining.
We hired country marketing managers, and and they were people who were really focused on each market. They owned the market. They did some SEO and SEM, but they also understand the customer. They understood product market fit. They were not product people. They were a blended role.
But he had this kind of global and local lens where we would do things that were right for certain markets. And as we grew, we became much more global. And over the years though, would say we lost that edge a little bit. And that's much more recently where we've ended up building big things and big, the kind of, you know, the rocks and pebbles analogy or sand being.
If you fill everything out with sand, you've got no space for the rocks and pebbles, likewise pebbles, no space for rocks. And we we we went, we we swung the pendulum too far one way and we said, okay, we're gonna build these big things, these big things that work for everyone.
But then you lose the nuance of a per market approach. You lose the ability to really connect. And so a good example of this, good, bad example of this. We have had rail on our site twice before, we've just added it for a third time.
And you might say, why would you keep coming back to something? It doesn't make you any money. It's not valuable in that way. I think we had a hundred bookings last month. It's not a huge revenue stream for us. But it's important. It's important in France because they've added The regulation has said, you can't do domestic on certain routes.
You can't do domestic flights anymore. Okay, well there's now a market level need. Now we would not be competitive in France if we didn't have that ability to serve the customer. So a few examples where we've kind of ebbed and flowed along along the way.
Touched about being traveler first and that's very much in our people and culture. As I said, we when we first started, we didn't have values written on the walls. A lot of it was what men remember Gareth standing up on a red pedestal in our office and sort of just talking to us because there was so few of us at the time that we could do that.
So things felt very embedded. You all had that shared context. But that in itself doesn't scale. It doesn't, once you open more offices, once you grow bigger, that becomes a harder thing to do. So we started to write down our values. We still didn't write down Drawzler first, which think when we came back to it more recently and we said, how do we actually live and breathe?
Oh, well, we we think traveler first. That is is now one of our values. And that was that was interesting because if you overlay that onto who you're hiring, who you're looking for. I certainly think when I started, there was a bit of a mix.
A lot of it was, I I was hired as someone who had written, had translated VB script into Python. My first job was translating VB into Python. My previous job had done that, but I was very much hired on a skills based side of thing.
There was a lot of absolute and everything involved. Over the years, shifted into a more culture focused layer. Do you fit in and not fit in in a kind of sometimes that can sound quite negative in some ways, but do you add to the culture?
Do you contribute positively to the culture through diversity, through all the positive inclusion side of things? Then again, we kind of got this wrong at several points. At one point, we tried to hire a hundred people within, I think it was a six month period.
And bear in mind, we're not much more than four hundred at the time. So huge influx, but we haven't really thought about how do we onboard people. We haven't really thought about what our bar is from a cultural point of view. We haven't thought about what does this do to us as a company.
We're suddenly much bigger. And we we learned a lot through that. We introduced the concept of what's called a bar raiser or a keeper of the culture, as we called it at the time. And that was really focused on making sure that as we hired, as we continued to grow quite rapidly, that we never lost that cultural alignment and the passion that goes with it.
And then more recently, we've learned those lessons, but then again, sometimes you forget them as you grow and as you go along. We swung back to more skills based. We're hiring people who are specialists in certain areas, specialists to do certain jobs. And then you go, okay, well, right, that person might be a specialist, but can they work really well with other teams?
As as we are still a heavily engineering or products engineering dominated company, do they, Can they talk to techies in the way that can techies talk to non techies? And so we've done a bit there where we've said, okay, well we want skills, but we have to have the culture.
You can't let the culture slip in that way. And so again, a bit of that those ebbs and flows over time. More recently, I say this with a huge amount of irony is tenure has become a problem for us as someone who's been here a long time.
And there's a lot of just institutionalized knowledge. Now we as I we've we have hired a lot of people over the last few years, but now we've kind of got this this split. And you've people who've been at Skyscanner for, you know, eight, ten plus years.
And then those who have only been here one or two. And there's this this that creates in itself an interesting challenge because we're we're at a point where we're we're kind of, okay, what do we do next? Where what's our future strategy? Where are we going?
You've got lots of good ideas for people who've joined recently. You've got lots of ideas that they're slightly stuck in their ways, myself included, of how things have been in the past. Do you go back to things that weren't well in the past or do you try and look forward and evolve and morph from there?
So that's been interesting and very live conversations at the moment, which I don't have a full answer for yet. Moving on slightly, something I have said since I joined is I really don't like process. Part of the reason for not joining GCHQ, no offense to anyone who's worked at GCHQ, was the processes.
The huge amount of overhead and toil effectively that seems to be there. And I kind of had an allergic reaction to that. And ironically, I'm now the person who's actually implementing lots of processes that Skyscan have done for a while, but it's processed in the right places.
And as you see along the bottom, we didn't have a lot to start with. A lot of it was just how we operated, we talked to each other. But at a certain point, things start to become valuable. And so, around twenty fourteen, fifteen, five hundred ish people, we started writing down our engineering principles.
How do we actually code? What are we, do we test upfront? How do we test? How do we deploy? Are we deploying frequently? Are we deploying big monoliths? We started to try and codify some of that into our ways of working as a process.
Now that worked well for a while and then people didn't didn't use it. They they it it it kind of tailed off. And so most recently, we've now written what we call the handbook. And it is meant to be a cheat sheet of this is actually how we do software engineering at Skyscanner.
And we did it from a more recent hiring drive where we actually had a lot of people joining us again, obviously during COVID. And you get people coming from certain companies where they've got a QA team, we don't have a QA team. So there's a process, there's a change of that.
And so how do you onboard lots of people and change mindset, change way of thinking? Well, let's write this down. Except when we wrote it down, it became a forty page document. It's very text heavy. I don't like lots of text. So it's one of these things that even though we've evolved the process and how we want to operate, we've also not got that right yet.
And we're currently going through it with a lot of red pen, just removing things saying, people can figure this out, we hire smart people. What are the negotiables and the non negotiables of our size that give us the kind of the ground rules or the framework, so to speak, but without being super prescriptive?
I think that's where we went wrong in our most recent processes. Processes and metrics as says, I think when we started, it was very much it was solving a problem. And yes, we were in a very fortunate position where we were bootstrapped, we were not taking in loads and loads of money.
We didn't have a lot of those pressures. We could focus on the customer, could focus on that. We became profitable relatively early on. We're profitable before I joined, though I never thought to ask that when I joined. It was an interesting personal learning.
And but as things evolve, we started bringing in clearer KPIs, clearer metrics. What what are we actually shooting for? What's our North Star? Where where are we going? We got that wrong at times too, where the list of of I think at the time were OKRs, really read like a lot like a laundry list like, know, it's not the move the number, it's do this thing, build this thing, create this thing.
And we changed that. We learned through it. Something I think is being in Scotland, we're quite self critical of ourselves. I think that's that's embedded into the culture where we go, well, that's not working. Let's change. Let's pivot. Let's do it quickly. And so that as said on previous slide, that kind of culture of learning is quite important, but it's gone into even how we metric things.
And so we had KPIs, we removed to OKRs. Most recently, probably two years ago, we moved something called goals, objective, strategy and tactics. And it's just a different framework. They're all just frameworks very similar, all have a very similar outcome. But GOS has been really interesting because it's been first time where as a structure, as a company, we've not changed and then changed and then changed again.
And we were in a almost yearly cycle of let's treat this, let's change this, and that got by itself becomes quite disruptive. Now, we're becoming the incumbent rather than the startup. And so startups, you will inevitably change much more frequently. That is just part of life.
So we are still growing quite significantly, but we're moving from a way of being as a company. I say that slightly into the org design side of things because when you think about organizational design for whatever size of company you are, you do need to think about, okay, do you, what's everyone laddering up to?
How you structure? And we spent a lot of time kind of doing the bottom of this first. We spent a lot of time reorging the business, changing our structures. And I honestly think it was probably a yearly event. Someone will probably correct me and say it was more frequent than that.
But we'd we'd change what all the teams owned. We'd we'd pass services around. Six months later, the team would say, okay, I now finally understand this thing you gave me. And then six months later, we change everything again. And that was exciting, it was fun, it was necessary to a degree.
But getting this GOST framework in place has actually allowed us to move more to this domain mapping. So we map the goals, objectives, strategies and tactics into the teams down to the squads that actually own them. And that's been quite powerful. That's stopped us having to do regular re orgs, although we're about to do another one.
But that's two and a half years between re orgs rather than six to twelve months. I said there about squads, we at the start when I said when I first joined, very just departmental focused, it was a small, it was like ten, twelve engineers.
We adopted the Spotify model, so squads tribes. We didn't actually adopt the Spotify model. We said we did. I think lots of people will realize that what Spotify said they did, they didn't actually do. Well, they did bits of it at the time.
Never trust what you read on the Internet, obvious lesson. We actually went and spoke to Spotify though. We went out to San Francisco, spoke to them and lots of other companies and understood about how they actually operated. And so we adopted the kind of constructs and some of the underlying principles of having relatively small teams.
We call them lots of whimsical names. We've got like Neutron and Aqua and Capybara. I don't even know what it means, but we've made teams quite fungible that they could move around because that's what they were doing at the time. And now, we're like, well, actually, I've got no idea what the Aqua Squad does, but they do actually own a domain.
So the fungibility of the names not calling the squad that owns the pricing service, the pricing service team, has now lost its, some of its appeal, some of its value. So again, we've learned a bit from it. We actually had to build our own system to, so that everyone could understand what every squad did.
So there's now a name mapping service that maps from the squad name to the thing that they actually do. You know, is that necessary? Probably not. Although, as one of my team members pointed out to me yesterday when we were talking about, do we go back to non whimsical names?
That's another six months to go and update all of the systems. Said, okay. There are battles I will choose to win and lose and fight or not fight. And the other thing that's happened which I guess is inevitable and I haven't talked about the hybrid versus or remote hybrid and insight.
When we were much smaller, obviously single site based. We were all, well, I started down in Leith, moved up to Waverly the old stamp office, and then up to quarter mile most recently, although at points we had two, three, four offices in Edinburgh.
Didn't have this in the slides, but in the deck, but there was one point where we bought a new office and this will last us for a long time. I think some several people here joined when we opened the new office. And then within six months, we're like, okay, we've run out of space in this office.
So we got a new office and we're like, and again six months later, oh, run out of space in the office. And that's a great thing to have if you are scaling. Obviously now that's slightly easier because people can work remotely and hybrid and everything and balance that out.
But it did change a lot. It changed, you had to spend a lot of time thinking about the coach you want to have in those other offices. And I've been very lucky that I spent time as we've opened offices around the world. I've spent time in those places.
I spent a couple of weeks, but multiple times in Japan when we opened our office there. Same for Singapore. I now spend a huge amount of time in in Southern China in Shenzhen when we acquired a company and then spent a lot of time there.
And a lot of that has been about embedding the culture. It's about spending time in the site kind of by proxy kind of imparting some of the things that we do. That's hard and that continues to be hard. During COVID, as I said, lost a few team members, but we also closed a few sites.
And we've now gone to a more focused sites strategy. So I think engineering is now across five different sites globally, whereas at one point it was eight. We've got ten offices globally, but not all of them are engineering sites. So it does even that, learn a lot along the way because sometimes we open things and they're actually this isn't it's not sustainable.
You you kind of need fifty plus people in a site to actually make it viable. Anything less than that, you don't have movement, you don't have freedoms to go and learn new things and everything and that's been important to us too. So the bit that you actually all want to hear about in the last five minutes.
We've I have gone on a lot of this journey from starting junior engineer to being CTO now. Not all of it is obviously my doing or anything, but I've definitely I've observed it from kind of both sides of the stage in some ways.
When I first joined, we had a dedicated testing team that worked for us at that size and that scale. We moved to a engineering own testing. So a lot of the testing team moved to being software engineers. And that was really powerful. It helps speed us up.
There was not the kind of sometimes you get the throw over the wall and just see what sticks kind of approach, which definitely did not for us at the time. But then more recently, we started to see that that testing mindset slipping from things.
And we've not had, by not having a dedicated team or teams, we've seen quality issues coming out. And so we've then started, well, how do we fix that? We've been doing like hackathons, we've been doing like quite spot fix things recently. And then we've gone, well, no presentation would be valid without Gen AI somewhere in it.
And then we're going to look at, there are now AI testing systems. Like what can we do to bring some of those in to kind of catch where we've not done it. Someone who's here, Rich Lennox, remember this. We used to do monthly at best.
Release cycles, had again fun whimsical names. Think for a while there were Simpsons characters as the theme. It was painful. It was really, really painful. We started breaking it down, moving to microsites, trying to split out that monolith, make us go faster. I will add, the system I was responsible was already doing daily releases.
This was the main site that was a bit slower. And we're up to doing four or five hundred changes a day now, is great. But you also get the trend starting to go back the way you're now getting micro lifts where people are saying, well now I've got so many microsites, so many microservices.
How do I manage them? Well, every one of them needs updating, everyone needs deployed on a regular basis. So then you start to get people squeezing a few things back together, and that's partly where our domain ownership model has worked quite well, because we group things together.
People like, well, these two things kind of do something similar. They could be the same thing. That would actually simplify our stack, simplify what we're doing. The last point around limited languages, when I first joined, were a dot net and Python house, that was it.
And over the years through acquisitions, through basically everyone doing whatever they wanted to do, had one of our old CTO said, have all of the programming language and we genuinely did. There's a picture, I don't have it here, there was a picture of just about everything.
We had Rust and a bit of Scala and a bit of PHP. And something I always said, didn't always win the battles, was when we were acquiring companies, was like, we will have to remove some of this code because it's gonna get really chaotic for us.
Not in a I told you so way, but slightly I told you so that we did. We ended up pretty much for everything we've ever acquired. We've ended up deleting a lot of the code. Now some of that was quicker, some of it took a bit longer.
But that became a problem for us as we grew because suddenly you're saying, well, the team that we acquired, they, you know, over time they leave. It's written in a particular language that no one else in the company actually fully understands. What are we gonna do with it?
Are we gonna upscale people to learn that and then you just perpetuate in the niche or are you gonna rewrite it to something that actually everyone else can understand? And for me, the understanding piece is super important because I've spent time moving around all of the areas of Skyscan.
I've worked in data, I've worked in platform, worked front end app, etcetera. And that ability to rotate, be able to move around, I feel has been quite a part of my journey and that without having moved, I don't think I would have got to where I am.
I remember our old COO saying to me, you're basically a one trick pony. You've done data acquisition in Python for a long time. You'll never be CTO if you don't move around. And I was like, I don't want to be CTO. But he was right.
If I hadn't moved around, I wouldn't have been CTO. Not sure that I've necessarily wanted the gig at the time, love what I do. And that goes to the then how do we embed this stuff? And it's like, well, actually we wanna have just certain core languages.
Certain languages that everyone, not everyone knows, but at least if you wanna move from one team to another team, you've got the freedom to do that. You're not having to pick up something that's completely fresh. And that kind of goes into a lot of a lot of the things we we do.
And so it's quite embedded in how we how we operate now. I realize the timer is about to run out, I've only got a couple more slides. I also realize I'm in between you and lunch, so apologies in advance. I'll go quickly. Data as said, there's more slides on software engineering obviously than the rest, but data has been something that I spent a lot of time working over the years.
When we first started, we had some data and not lots. We swung the pendulum to logging basically everything. We had our own in house built system. We logged everything. That system for obvious reasons, didn't scale. It fell down. We had an outage, which was nearly a two week outage where we couldn't rebuild all the data fast enough.
It was a real problem for us. And that's partly because we logged just about everything we could get our hands on. But it was also how we built it. We built basically a monolith, everything was in the same place. Now, I said we log data, we have data in the right places.
And what I mean by that is, we still probably log just as much if not more. But we've gone okay, well we're gonna use New Relic for all of our operational stuff. And we just went all in. We said, this is, they can do this.
They will improve way faster. They've got five, six hundred engineers versus the ten people we had on it. Like fairly obvious, we went there. We've got Databricks for a lot of our kind of more business platform side of things, but even that we've split up and we started to segregate and say, there's some stuff that's business critical.
Okay, let's run that on one cluster. There's some stuff that we can lose. Well, let's not have the same level of kind of parity in that way. So that that's been a painful lesson, a very, very painful lesson for us, but but quite interesting I think in that way.
We were originally data center based as everyone did, everyone went to AWS or other cloud providers are available. When we moved, we did a lot of lift and shifter, and we just said, okay, what worked in DC? We lifted and shifted a lot into AWS.
And that was a necessity. We had to shut data centers down, we were running them way past end of life, and we couldn't scale in them. The thing on why I call this out is that when we first moved, part of our problem in scale and size was EKS, Amazon's Kubernetes cluster did exist, but it didn't work for us.
We run entirely on spot instances, spot instances can get killed at any point in time. So it just wasn't working for us. And I was actually with some AWS team over the weekend, and was talking to them about this is like, we said to them, well, this doesn't work, and we actually influenced them to go and improve EKS in order to to to be something we can move to, and then we moved to it.
And that slightly goes to the last line where we were Our mindset was very much, well, we build lots of things, we buy a little bit, but it was really mostly build. And we moved to let's build things, but let's also try and reuse and then try and buy things.
And I'm happy with where we are now that we generally try and reuse what's available. The fact that the team who had rebuilt a whole Kubernetes infrastructure ourselves, And then the second that EKS was at parity, we were like, cool, bend that all and move.
And I think that's culturally as well as kind of from an engineering principles practice point of view. That's quite a powerful thing to get embedded into the team and try and get them to do that themselves. There was no tops down pressure to do it's just like do the right thing.
So final slide is takeaways. You probably have heard me talk, traveler, a lot of what we've done has really been baked in and there's a famous quote from Peter Drucker that says, culture eats strategy for breakfast, and that for me is the main thing.
Like the culture of Skyscanner has always been one of this learning. There's lots of failures, but failure is an opportunity to learn and improve from. You can read the rest at your own leisure, I'll leave it up there, but I probably should finish as as we're out of time.
But yeah, that for me is the thing that's really stuck with me over the years. I might call out founders mentality in that what I mean by that as well as Gareth being great, not just because he's actually here, but is the fact that the obsession, there's a good Baines and Company YouTube video if you can find it, that just talks about that focus and obsession with the customer.
And that goes to the traveler first, that goes to how we've always operated, how we've always tried to be. And I think that's hopefully a lesson for everyone in that. We have over the years, particularly in COVID, we got distracted by the necessity to survive.
We had to be revenue focused. We had to think about our bottom line and everything. I quite often describe at work, we've got the COVID hangover, which is we still talk about revenue a lot, like too much for my liking. And getting back to that way of thinking where you're just you are focused on on the customer more than anything else.
