Change Is the Only Constant

Transcript

Thank you very much for coming, everybody. I really appreciate your time. I know there's an awful lot of much better talks than mine, so if this gets a little bit hazy in about five minutes time, just run for the door. It’s OK, I'm going to speak anyway. It’s such an adrenaline buzz being up here and getting to talk about what Skyscanner has been up to, not because we're trying to sell a product, like a vendor, but it's basically therapy for me. I get to come up here and I get to talk about all our mistakes and all our failings and if anybody takes anything from that, then it's no longer a mistake, so data point. I can go in and feel so much better about it all.

Introduction

So who am I? I'm Stuart Davidson. I'm a Senior engineering manager at Skyscanner and I work for the Developer Enablement Tribe. The Developer Enablement Tribe is an organization within an organization that tries to enable developers. What we focus on are our services, an infrastructure and platforms that try and take away a lot of the day-to-day stuff that developers have to do to get their product out the door. A lot of that will come up here.

Surviving Uncertainty Zone

I was pretty excited when Ann came and asked me to talk about surviving uncertainty because it's all about change management and change management is really exciting. It gets everybody so excited. You'd be surprised how few people are actually excited about change management. It turns out change management isn't the most exciting thing in the world, unless you call it surviving uncertainty because all of a sudden, there's a primal urge there, so visceral. You're surviving, it's life and death and there's uncertainty. It's like that scene in "Jurassic Park," where the guy is sneaking up on the Raptor. He raises his gun and he's thinking, "That's great." And then all of a sudden, the bush next to him rattles and this Raptor comes out. I did wonder how well that would hit. "Jurassic Park" is 25 years old, so I know there are some people in this room that have no idea what Jurassic Park is. If you haven't seen "Jurassic Park," you should. There's lots of pop culture references in it like “this is Unix, I know this” and “you didn't see the magic word”. This is me just judging the sort of the mood of the room just to see the age and the clientele that I've got and who we are talking about.

I'm going to make an assumption, everybody here is in technology, has become part of technology, or has stayed with technology because it's fast, there's a lot of change going on. In fact, sometimes you get to control that change. You get to code something up, you get to commit it, you get to deploy it into production. You've made a change. You've made a real change to somebody's life somewhere around the globe.

There I a sort of enthusiasm in the room for change, but how many of us actually look at change management and how do we actually manage that change? What effect does that have? Maybe you've got the idea of what the code would do, but what happens to the people that use that code? What happens to that feature when it rolls out? I would say congratulations to all of you for coming along to this track because you've taken the right step. You want to find out more about change management. It's not that bad, change management is exciting.

Managing Change In A Large Organization

Skyscanner is going through an awful lot of change at the moment. We have tons of change, we have lots more customers, lots more travelers hitting our website, which is tremendous. We have a lot more people in our company, which is tremendous. We've moved over our data centers into AWS in the last year, we've changed our source control system, which is something I'll talk about and that's really only from our area. I complained about this last year: "Oh, no, we're growing again, what a terrible problem to have!". Every company wants that problem, but it is still a problem and it's my problem because I'm running the trade that deals with platform, it deals with infrastructure, and deals with services. As much as I would love to, and in certain circumstances I can, I'd love to just be able to horizontally scale the problem away, to just spin up more servers and it’s gone.

Sadly, AWS does have some limits because cloud computing is someone else's servers. In some circumstances, the things that we have to change are not necessarily how many servers are running, but how we work together. Sometimes, even more difficult than that, it's how we act as professional engineers to allow Skyscanner to scale, so we've got problems technologically and we've got problems organizationally, and in some instances we have problems culturally. What I want to do today is talk you through some of the things that Skyscanner does to try and resolve some of that friction, try and help us out.

Caveat on all this, none of the concepts I'm about to talk about are mine. There's far, far cleverer people than I that have written books about this stuff. If you zone out throughout this whole talk, that's absolutely fine. Make sure you get a photo of this list of books and go and read this stuff. Because these six books to me are the core of how you manage change in a large organization. However, I do promise you that they are all factually true anecdotes about how Skyscanner implements these bits and pieces. I promise you that all of the representations I talk about are true in terms of how Skyscanner takes the ideas that are in these books and implements them.

I can't really talk about Skyscanner and how it survives uncertainty without talking about how Skyscanner is organized.

Tribes and Squads-Spotify Summary

Can I get a show of hands about who knows about the Spotify model? Ok, so it's a pretty common concept. This is the first thing that people think of when they think about the Spotify model. Skyscanner, for reference, has been working with the Spotify model for about four years now, so we've had it for quite a long time, but we have adapted it over time to our own needs. We found over time, again, that there have been some flaws in the model, but let's walk through the model very quickly. You've got Squads are groups of 6 to 10 people, so collections are basically a team. Tribes are collections of Squads focused on delivery, so you have many Squads within a trade. Your lane management is held within a chapter, or this is how I understand it to be. The lane management is held in a chapter of subject matter experts in a particular area that are cross Squad and then you have guilds that are cross company interest groups, essentially.

I think this is the first thing that people think of when I talk about the Spotify model, how people are organized into teams. Actually, it's not the most important part of the Spotify model. I think this is [pointing] and that's how you empower these teams, these entities, and how do they work together. In this graph this is another part of the Spotify model video and if you haven't seen it, it's a good one. It talks about the crossover between alignment and autonomy. You want your teams to be aligned but you also want your teams to be autonomous. If they are neither, then they just aimlessly wander around. If they have alignment but no autonomy, then they've got a boss, a directive boss, who's pointing at them and saying "We need to cross the river, build a bridge," regardless of what's going on and you would follow the boss.

In opposite to that, if you have autonomy but no alignment, it's brilliant, it's a holiday. Autonomy without a responsibility is a holiday, you can do whatever you want. You can build spaceships, you can use Kotlin you can do whatever you like, but here's probably a manager, someone who's held responsible and they're thinking, "I hope somebody is thinking about same problems as I am." Alignment and autonomy are the key if you can get it together, if you can get autonomy and alignment all at the same time. You've got here “We need to cross the river”, figured out how, so empower that squad! If you tell them to build a bridge and they run over to the shore, there's a boat there and they think "Okay, we better build the bridge then," that's not what you want. You want these Squads to deal with uncertainty because you don't know what's at the shore. You don't want to give them that big plan because you don't want them to be focused on one path and one path alone. You want to set them up to deal with uncertainty.

Tribes and Squads-Art of Action

Skyscanner took this even further and we follow a book called "Art of Action" written by Stephen Bungay who's a military historian. You may have known about the Spotify model but I doubt many people in this room know about "Art of Action." Because he's a military historian, Stephen Bungay starts off by talking about the wars in the 17th and 18th century where everybody was formed, there were regimental ranks and it was all about fit drill, just to get people to be centralized and to all move up as one from a centralized point. Then, the Prussian Army led by Von Moltke the Elder came in and they decentralized all. He said, "As long as my field commanders follow my intent, they essentially have autonomy. They can do what they want if they're following my intent." And that happened, they took the initiative and they rotated all these armies. The Prussian army was the best army in Europe. That was Chapter I, it didn't go on about military history for the whole thing, but I thought that was a great start, I thought it was really engaging. Then he started talking about how large organizations deal with the same challenges as armies had in the 17th and 18th century, and how we're still learning the lessons that were learned back then with blood and steel. We're still making the same mistakes centuries on. It's madness.

He's got this nice model to explain what he's trying to say and we think it's just great. You've got these outcomes, you got these things you're trying to accomplish and to get that outcome, you decide to make a plan. And you give that plan to people and they action that plan and the outcome of those actions is the outcome you hopefully get. However, there are some gaps between these, the outcome you want and the plan that you write. There's often a gap between what you know and what you would like to know. Trying to build a plan on something that you don't know about, there's a bit of a gap there. Now you've written a plan and you give it to people and they maybe do something that you didn't expect them to do. The alignment gap is the difference between what you want people to do and what they actually go and do. These people have carried out your actions, but did it have the effect you wanted it to? There's a difference between what you wanted to achieve and what it actually achieved.

These are the three gaps that Stephen Bungay came across. He's identified as the core parts of how you run a large organization. Now, your knee-jerk reaction to all of this is normally the following: “This book is massive, these talks can go on for days, I’m condensing it down”. I really hope that you go and read more about it later on.

If you have a gap in your knowledge, your knee-jerk reaction is to do more study, to go and figure out more about it before you write your plan. You want this plan to be awesome, you want to detail this plan as much as you can, so the alignment gap to prevent people from going off and doing things that you didn't want them to do, you make the plan more detailed. You've got all this knowledge, now you make the plan exactly, take two steps and then tickle in, taste it. Make more detailed plans. The effects gap between what you wanted to happen and what actually happened, the knee-jerk reaction there is to get more control, to grab it, to say "Oh, you did that wrong. Come here. Let's have a governance meeting. Let's have maybe one every day for an hour and you can talk me through exactly what you did and we'll review it and make sure that you've done the right thing." That doesn't sound like the way to run an organization to me. I certainly wouldn't want to be the person doing the governance.

What Stephen Bungay suggests is a different approach to all of this. This is how we try and do things in Skyscanner. Instead of looking for more information, limit what your knowledge gathering is about, in order to define and communicate your intent. Just like in the previous set of slides, we're talking about that I don’t want you to build a bridge, I want you to cross the river, that's the intent. Instead of writing really detailed plans, you delegate, you defer how things are actually implemented as far down as you possibly can and allow each level to define how they will achieve the intent. To back-briefing, we'll talk very quickly about that in a bit.

Then you've got the effects gap. This is where we survive uncertainty. You allow people to change their minds about what they're going to do. You don't jump on them as soon as they change things because maybe they know something that you don't. Provided it's aligned to the intent of what you're trying to do finally, like fundamentally, then that's great. That's a great thing to empower your Squads to do.

Strategy Briefs are the way that Skyscanner deal with passing work down from level to level. We talk about intent and then we empower the Tribes and then the Squads underneath to decide what they're going to do. Back brief is about going back again and making sure that the intent is correct, so we've made the decision about what we're going to do, but we'll take half an hour just to make sure that we're aligned and maybe the boss hasn't forgotten to put something in the intent. That little iteration is key, and it saved us so much wrong work and it saved us weeks and weeks of wandering off and doing a thing.

Maintaining line management within Squads is better. It allows teams to form and be long lived and co-located and with a line manager in them so that they start to build that psychological safety that Andrea talked about so much in our previous presentations. That psychological safety is key to having really high performing teams. That goes counter to what the Spotify model is all about.

I’m not going to define SLIs, SLOs, SLAs. If you know what they are, Skyscanner are starting to use them and the initial signs are good. It's a way of us being clear about what to expect inter-service. If Squads are building services in this Tribes and Squad model, Squads will be reasonably autonomous, so they may build service separately. If one service is depending on another, it's a good way of defining that relationship and what to expect from one another.

We're seeing really good behaviors from that, and it's taught us a tremendous amount about our dependencies. For the first time in a long while, we've actually looked at what we're dependent on in order to make our SLIs and SLOs and we've found circular dependencies, we've found the tool that we deploy our infrastructure, deployed on the infrastructure that was going to deploy the infrastructure that was on the infrastructure that it was deployed. SLIs, SLOs, SLAs have been really good and the "Site Reliability Engineering" book from Google is ideal.

Continuous Deployment

This is what Ann wanted me to talk about and that's the reason I'm rushing. Continuous Deployment in Skyscanner has been around for over two years. It defines what we do in Skyscanner. We deploy as much of our code as possible using Continuous Deployment. We do conflict deployments, we do infrastructure deployments, Continuous Deployment. Let me very quickly go through the concept of what it is.

Continuous Delivery is where for each change you want to apply to the platform, you build it, you test it, and then you save it in a place and then there's a human that decides whether to push that into production or not. That might mean that there's time delay, your engineer might wait for a particular time or event that's happening on the platform. You might take each release and go through a testing phase, you might go into test environments. you might go through your QA team. Continuous Delivery is a very, very good thing because it means you can release any bundle of code, but we've taken it one step further and we follow Continuous Deployment. It means that every single change that's committed or merged into your master branch is deployed into production, provided it passes through the automated tests. Once you've merged into master, there's no human interaction. It goes straight into production immediately.

Who works at a company that does Continuous Deployment? There's a few people that practice it, I can't think of any other way of working. I'm a total convert and I do realize that there are certain software setups that you can't do Continuous Deployment. But in the vast majority of cases, there must be a way of doing it. I have engineering managers and engineers coming to me and saying, "You're mad. What a terrible risk you're taking automating this and throwing every change into production like that, you're insane. How can you survive such uncertainty?" Bringing it back to the track.

I would say, "Well, actually, let's look at this in a different way. Would you rather take all of the changes that you've done over a week and would you take all your Squads changes over a week and all your Tribes changes over a week and then throw on to production and see what happens? Or would you like to take each change and put it in production and see what happens? Then take the next change, put in production and see what happens. In addition, put in production and see what happens." Of course, you want to do the second one, you want to put a single change into production and see what the effect is. You don't want to launch 100 changes into production and just hope that it works.

That's the way that companies are working today, it's madness. The other way you can think about it is if you come across a problem whilst deploying into production. Would you rather roll back a week's worth of work or would you rather roll back one single change? Seems pretty obvious to me, but that's still the way that some companies work. They would much rather roll back a whole week's worth of work rather than one change, talk about uncertainty. You're going to have a week's worth of change in a release that's been rolled back. That means your production environment is one week behind your test environment that's, depending how long it takes you to test, maybe one week behind for your developers are developing, that's uncertainty. What we do in Continuous Deployment is the sensible approach.

The third way, the third thing I really want to talk about because it's my biggest bubble. You think I was passionate before, but this is the thing that really gets to me. There are some companies in this world that expect a graduate with an out-of-date Word document to get out of bed 3:00 in the morning and deploy the code into production. If it goes wrong, they have absolutely no support, because it's 3:00 in the morning, they're tired and you've asked them to put text in the text box. It's just madness the way that some big organizations try and operate, I would personally rather work in an environment where we can do 20 deploys a day. It's ubiquitous, it just happens, it's this thing that just happens.

We do so frequently that it's common. It's not a big deal when you deploy with a strategic enabler. Not only are we comfortable about deploying, we're comfortable about rolling back as well. We're comfortable about applying changes to get a set of problems. We're comfortable about applying it during the business day, so we can do when everybody's awake and aware and paying attention and really understand what's going on. That's the way to operate the software, so when you say surviving uncertainty, I think Continuous Deployment is certainly the approach I would take if I had the chance.

One of the books that talks about high performing organizations is "Accelerate", it's another one that I like. Jimmy and I have already had words about it and we will continue to have words in the bar later. Whereby, there's a survey that's done, "State of DevOps," it's called. These very clever people have gone away and taken all the data sets and analyze them and compared the capabilities of certain organizations in terms of Continuous Delivery, deployment and all sorts of other things, compared to how well they're performing in the market, how much money they're making, how well their shares are going.

There's a correlation between how quickly companies can get into production, how quickly they can make changes, how quickly they can recover from changes. It's a shame that a big study has had to take place for some people to be convinced. Being able to recover from change quickly seems like a good sign, that seems like the thing that you want a high performing company to get behind.

Source Control Changes

Migrating a source control system in a company isn't something you do through Continuous Deployment. You have to really think about it, this change in particular when we moved from GitLab to GitHub in Skyscanner. That's the first and last time I'll mention the vendors. This was it, this was a change that I really wanted to do for a variety of reasons and I will talk to you in the public if you want to hear more about it later on, open a drink, have a coffee.

We had a license coming up for renewal in August, this was January time. I had a time constraint, and I had to make a change that affected every single engineer in the business. I had to do a time of great change in the organization, anyway. Like I said, we moved from our data centers into AWS. There's lots of cool changes ongoing, lots of projects, it would have been pretty risky to get involved with. You're playing with source control, so actually, we had the source of Skyscanner in our hands as well. If we didn't migrate that appropriately, you know, my P45 is heading towards me very quickly if I lose the source code of Skyscanner.

I had to take a different approach to how I was going to migrate our source control system in Skyscanner. I went back and I looked at all the migrations that I'd carried out over the last sort of two to three years, because, like I said, in Skyscanner, we change all the time, we change tools all the time and as we scale, we find things don't work and we change, so there's been a lot of migrations over the last little while. I went through and I picked out the things that really worked and then the things that really didn't and I prepared a list of things that I was going to do in order to make this migration happen. It did happen and it happened flawlessly, it happened on time, on budget.

Every engineer in the company was affected, every engineer in the company was delighted, it worked so well that I got absolutely no praise for it because everybody just thought it was so routine. That is a great place to be as well as a slightly frustrating place when it comes to review, but it's a great place to be. This is my list and I'm going to share it with you today because this is the key to doing large migrations in a company.

Source Control Migration

These are the 10 tips, leadership and buy-in. Let's start off with setting the grind work. We want to talk to the key influencers in the company. I went to every single Tribe Engineering lead and I told them that we were going to migrate our source control, 80% of them didn't really care, but that's fine. I'd sat down and I talked to them, I prepared a document that talked about, specifically, management and operational issues, sort of a strategic level. I talked about all the benefits we were going to get, and I put it in front of them and I said, "We're going to make the source control change." And they went "Yep, fine, cool."

Leadership and Buy-in.When I started to get further on in this approach, knowing that the Tribe Engineering leads had all said, "Yep, that's cool," was a really important part. Not one of them could go, "Oh, lots going on. Not sure we could do this" , so prior to all, I went around the leadership got buy-in. That started off. And I see it so simply, it was pretty simple. I don't know if that's just unusual to Skyscanner, but it did seem pretty simple provided I put this document in front of them and explained why it was important to them.

Unity of purpose, number two. This is the thing that trips up a lot of people. When you're making such a vast change across the whole organization, you want to make sure that you're serious about it. Don't just muck around, "We'll just change this a little bit and this a little bit," because it gives people excuses to have hope that the old system is going to stay. That way, they don't need to worry about your new system, they don't need to worry about this change that's coming up, they would much rather de-fair that, so you need unity of purpose. When it comes to source control systems, that means it's at the nexus of everything that's going on in terms of engineering. You get your CI, you've got slack integrations, you've got all sorts of weird and wonderful scripts, our internationalization that was version controlled in our source control system, a lot of config was version controlled in there as well. There was a lot going on, and we had to have a plan to change every single component of it and make sure people were aware of that, because that unity of purpose, that strong intent, that direction made the company understand that this change was happening.

Understand the technical landscape. That kind into what I was talking about there. Understanding who's going to be impacted, understanding the technical landscape of where you're working was key. We could identify people right at the start who were probably going to be our biggest blockers. We're going to push back on it and get in front of it, and put in front of them solutions before they could say no and give us problems. We understood the technical landscape before we did all this. This is all before we wrote any migration code whatsoever. We were laying the groundwork, we were getting people excited about it, but yes, make the migration simple. We started to write some code, we could have given people a document because it's source controls get, so we could have given them a document and said, "Right, step one, take this command. Step two, take that command." Instead, what we did was we wrote a migration service that took all of the source code from an organization and put it into another organization in our second source control but updated all of our continuous integration tools. They updated all of our documents, it just took all of the sting out of this change.

It meant we could go to each team and instead of here's some work to do, we would say, "Oh, can we just get an hour of your time? What meetings are you up to in the next week?" "Oh, well, we've got this hour and a half design review." "Perfect. Perfect. We'll take it then." We will migrate your source control then and you'll come back out of that meeting, it will all be good to go. Again, no one can get in the way of that, no one can argue with that. Some people tried, but, we made it super simple so that people couldn't say no.

Neutralizing blockers. People still said no, no matter how easy I made this, so what we did was basically promised to fix a forum. There was one team in particular who said, "We can't possibly make this change, we're so busy, we've got all these things going. Can't possibly make this change." So we said, "Fine, we'll go into your code base and we will make your change for you. We'll do that, no problem. We will work every hour of every day to make your change for you." I'm hoping some people from the company will watch this, thanks though. Yes, we tackled real blockers, we neutralized them with enthusiasm, with effort, with sweat, we got into the challenge, the problem space, and we made it work.

Often people were coming up with stupid excuses not to migrate. Again, the number of times that people will, "Oh, we can't possibly do this because of X." And we went, "Oh, well, we'll just look at X." That's not a problem at all, it's fine. Then they went "Oh, well. Okay, well, what about Y?" "Oh, we looked at Y, it's fine. We looked at that overnight and we've got the solution." Neutralizing blockers, tackling things.

Gain and maintain support for the migration. Just because you've laid the groundwork doesn't mean that you shouldn't keep pushing it along. There's some momentum thing here, there's an initiative. As soon as we started to migrate people, we did interviews with them. We did one-to-ones with them and said, "You know, so Mr. X, how did the migration go?" And they were, "It was great." We take that and we put in a blog post. These little case studies not only got people supportive because we put them in a good light. "You've supported a really important initiative in Skyscanner. How does that make you feel?" "Oh, that was great, yes" Skyscanner take that and put in a blog post. People were starting to get the idea that this is a good thing. They started to see the company migrate and then they started to think, "Oh, wait a minute. I want to be migrated, too."

There was a momentum, began to build. It got to the stage where we couldn't migrate people fast enough because they all wanted to get over to the new system. That was key, that was a really simple thing to do, to talk to people, to write it down. It really, really worked.

Operate in accordance with the production standards. We did talk to the managers, the managers all went, "Yes, that's fine." There's also an engineering path of senior and senior and senior distinguished senior engineers. They've set the production standard. There is autonomy in our Squads but we still have production standards that each Squad should adhere to in order to get code out to production, things like unit tests. It's pretty obvious but we've written down so that we all follow them. We operated in accordance with the production standards just in case someone took umbrage to us doing this work so we could point to the production standards and say, "Look, all of our code is production standard ready."

We also aligned ourselves to things like SOX compliance, which we're really glad we did because we didn't really think about it at the start, but then it became this massive thing. Later on in the line while we were migrating, we're like, "Huh, we're already covered." Think about the laws and the rules that are coming up and really align yourself to it.

Be transparent. Oh, man, the amount of documentation I wrote, the amount of blog posts I did. I was as transparent, but people were so bored of this thing by the end of it. You're already getting bored of me talking about it, think about people living through 10 weeks of this, my enthusiasm. Getting people's faces saying, "We're migrating people. This is exciting." I had this confluence document that had every single Squad and every single repository, when they were going to migrate, if they had migrated, the whole thing was transparent to the whole company.

Again, you started to see the shift of the early adopters with a small box. Then we had a couple of people that were scheduled, and then all of the people who were unscheduled, and then as the early adopters started to build and build and as more and more people scheduled, the rest of them started to get nervous that they weren't getting scheduled and everything started to stack up, so the transparency formed a sort of a momentum of itself. I really, really advise that you're as transparent as possible when you're doing these big changes so that people aren't nervous about it and they can understand what's going on. We shared the code to allow all of our engineers to figure out what was going on.

Prepare for the long term. This is a contentious one. I had a license date of the third of August 2018. The easiest way to put teams on the defensive is to say, "You must migrate by the third of August 2018." Because that's a date. They can always say no to a date. They can always for some reason, "Oh, I'm going to holiday, I can't possibly make that." Instead what I did was I held the narrative of "Yes, the world will continue but what will the world look like past August the 3rd 2018."

I suggested, I didn't write it down, but anybody that was giving me any friction, I suggested that on the 4th we would form a guild of people who hadn't migrated, and they would own the old tool. They would be the ones to run and maintain and manage this tool and we would assist them with advice and we would pass the documentation over to them and the sales executive who run the previous account and they could figure out budget and they could figure out how they were going to maintain and operate and backup and restore and all that sort of stuff.

We didn't set a hard limit, but we did talk about what the long term looked like if they didn't adhere to the migration. That changed everything that gave them a decision rather than a point that they could disagree with. Nobody hung around, they were like, "I'm not doing that. Are you kidding?" They didn't say it like that but, "Oh, yes, I can see the cost benefit." Prepare for long term is a key one. Don't put dates in front of people, it's too easy to say no to.

Final point. This aligns to everything that we do, learn and iterate. We had an approach, it was doing ok, we weren't fast enough, we made some changes to how we migrated people, we got faster. Learn and iterate, this is me learning and iterating on this set of rules and I will continue to learn and iterate on it.

These are the books again. I really strongly recommend that you look at these books if you can. Because surviving uncertainty is just like Jamie talked about all about being prepared for change, change is a constant. You've deliberately thrown yourself into a realm that's filled with change. You should be prepared for it rather than trying to avoid it. "Art of Action," I have talked about that. "Site Reliability Engineering" talks about SLI, SLOs, SLAs and a lot of other really great stuff. "Accelerate," we've talked about. These three at the bottom we haven't.

"The Phoenix Project" is all about the theory of constraints, it's a great book. I'm not going to spoil it for you, but it does read like a novel. It is really easy to consume and I highly recommend it because you're going to learn so much about it, about IT. Anyway, Lean Startup, MVP. It’s about our Squads are given a copy or our Squad leads are given a copy of "The Lean Startup," because it talks about doing an iterative approach to your development. It's all about just doing the bare minimum to get to a level where you can learn something and then iterate and iterate. It's a key part of dealing with change. In an iteration you get to a point where you can deal with change at that point. You don't have a six-month project that will suddenly die. Finally, "Turn the Ship Around." It's all about delegation, it's a wonderful story about people in a submarine. You'll love it.

Questions and Answers

Moderator:The timing is perfect.Thank you very much for that, Stuart, very useful insights into how you do things at Skyscanner and how you continue to do that. Do we have any questions for Stuart?

Participant 1: I really liked your presentation and mostly the approach on how the change relate to those git repositories source portion in control. How you tackle a challenge where something gets imposed to you without anything that is presented then?

Davidson: How do I deal with something that's imposed on me, with the change that's imposed on me without having any of the stuff up there? Sadly, no matter what you do, some of this stuff up there are things that you can’t apply. These are books you could get them on your Kindle. These are ideas, and ideas are the most powerful things. Understanding the context, I think, is the key. Understand why this thing is being imposed on you. It might even be down to the manager and how stress they're feeling, how much pressure they're feeling, why are they imposing something on you. Understand the context and the why and that will lead to the what and that will lead to the how. If you've only got the what or even the how, start working back up the chain. What and why is this being asked of you?

Participant 2: I got a question in regards to your title. You are Senior Engineering Manager and I'm curious to see how it fits into that Spotify model that you explained. How many engineering managers do you actually have and what's your day-to-day job?

Davidson: Change is the only constant in Skyscanner. My job has changed, I don't know, two or three times over the last little while. Right now, my job is working for the platform Tribe. There's myself, there's a guy called Rob Harrop who has talked to you various times, and a guy called Paul Gillespie. The three of us are running the tribe of the platform Tribe and we have, at the moment, five Squads that work for us, so each Squad has an engineering manager. I'm a senior engineering manager but I'm relatively junior compared to Rob who's a senior director, and Paul Gillespie who's our Senior Principal Engineer. We have an IC track, and we have a management track, so Paul's our senior engineer, he's our technical lead, and we have Rob who's our management lead.

My day-to-day is around the Tribe health, so a lot about the psychological safety. Do we have enough people? Are we doing the right things? Just keeping people honest, I'm the Tribe conscience and sometimes the Tribe motivator. I don't know if you can see that from sort of how I bounced around. That's my day-to-day job, trying to get people focused on the right things and trying to make sure that people are motivated.

Participant 3: Just for reference, how large is the total population of engineers at Skyscanner roughly?

Davidson: No. The reason I'm so ping to that is I see no reason why I can't tell you that, but I have been told in the past that it is not acceptable to talk about that. When we look at our competitors, that is one of the metrics that our competitors look at and we look at our competitors, is how many people we employed compared to how many engineers we have in the organization. There are 1,200 employees in Skyscanner. There are an awful lot of engineers.

See more presentations with transcripts