Empowering Autonomous Teams From The Top Down

So, I wanted to talk today about empowering autonomous teams. You just heard Rory talk about connecting the dev experience, the op experience with the design experience. And it's really about empowering every team to be able to make the best possible product for their user and to iterate by having the best opinions from everybody involved.

So I thought to start this talk, I was putting this together and I realized, let me double check the definition of autonomy. And I love the second point here, the ability to make your own decisions without being controlled by anyone else. It sounds like the type of thing we probably all want. None of us really like to sit there and be told what to do by anybody else. But there's a number of organizations where this is actually not true. It might be some of the organizations you work in or used to work in.

So let's kind of look at this on a scale. If we think about what this looks like at 0%, it's probably some guy like this showing up at your desk every day, every hour, telling you just what to do. Okay, I need that next report. I need you to do this. I need you to do this. Flip it to the other side and you'll get 100%. It's like this, freedom, right? Nobody's telling me anything what to do. I'm going to make my own rules. I'm going to do whatever I want.

So I was thinking about what the best way to share information, because these are complex problems. When we have these organizations, once it's more than a couple people sitting around the same desk or sitting in the same garage, the way that we organize what we do, the way we communicate, the way we share, the way we stay in sync, this is just as complicated as any distributed system that we're going to build, except that at least computers are predictable time and time again. They do exactly what you told them to do. You might have coded a bug, but they do what you told them to do. And at scale, people are less predictable.

So I thought actually what I'm going to do is I tried to pull together just a number of different tips and techniques that we've learned that we employ along the way, and really just try to share as much content as I could. I'll warn you guys, I talk fast. There's a lot of points in here. I'm going to try to get through this as quick as possible, and then we'll have some time at the end for questions or afterwards. So let's do this. Let's just get into this. Let's get that meter from zero to 100%.

Item number one, trust your team. I want you to think about these points, about whether these are true for your team. Is everybody on your team smart? Hope so. If they're not, you should be having a different discussion with them. May not be the right organization for them. Is everybody capable? Again, people on your team should be capable of the job that you expected them to do. Is everybody rational? These points get kind of hard to argue with. If I work in a technology team, I should expect everybody to be smart, capable, and rational. If this is 100% true of every single member of your company, then what's the problem with autonomy? What is it that drives people to want to tell other people what to do? What is it that takes away that ability to make up your own decisions without anybody else telling you what to do?

I think the reality is there's just a level of frustration. At some point, you walk into a room, you talk to a team, you find out of a decision, and everybody decided to go left. You're going, holy shit, what happened? Why did we go left? We should have gone right. Here's all these other things. Here's all these reasons why left is a bad idea. The reality is if you take a second and pause, you'll usually find out that you have information that not everybody on the team did. If everybody's smart, capable, and rational, and they have all of the information, they'll make the right choice. That's a lot of what I want to talk about today.

Our job is leaders. This is not a management role. Leadership is a role that each and every one of us can play on our teams. It's how do we make those around us better? If you know the adage of fishing for somebody feeds them for a day, teaching them to fish feeds for a week, when you really look at these leadership roles, whether it's your team, whether you're managing a team, you're managing a number of teams, you're leading a whole organization, you're really teaching a village to fish. This is not easy. When we think about autonomy, when we think about everybody being smart, capable, and rational, what is our job as leaders?

It's really these three things. Set the principles of how we're going to work. Share context. The information in my head to know that we should go left instead of right, or right instead of left. That's my fault if I haven't shared that with the rest of the team. If you've set principles and agreed on them of how we're going to work, if you've shared the information that you have in your head, just get out of the way. This is what empowers teams. That level of knowledge, that level of information is what allows teams to innovate and to be successful. That's point one. Oh, I forgot about this. Sorry. If you just take these two things together, people will make the right choice. There we go. That alone, 40% of the way.

Let's go to item two, building trust. This is another piece, which is I just asserted that people will do the right thing if they're smart, capable, and rational, and they have information in context. How do you know? Eric Schmidt's pretty famous for this, saying that hiring is the most important thing that you do. It is. It is absolutely the most important thing. This is how you define who you're working with, who you're depending on to do the other half of that project, who you're depending on to build that UX if you're building the API or vice versa, who you're depending on to solve one part of the workflow while you solve another. It all comes down to who you work with, and who you work with is a reflection of who you hired. Now, we all get hiring pressures, but you really have a binary choice that you can hire fast or you can hire well. I'm pretty sure it's impossible to do both.

If you think your hiring model today is hiring for your organization, for your team, for your company, is it a tax on the team? Does everybody dread doing interviews? I got another one scheduled. It conflicted with my standup. It conflicted with my ops review, conflicted with a design review. Does everybody understand that who you hire is actually part of your company strategy? It's the people you get to work with that really help you to be successful. Companies sometimes are really shy or protective about how they hire, how they think about their hiring philosophy. I thought I'd actually just share what we've come to and evolved to at Skyscanner, because we think our system is pretty simple.

First, we're trying to answer effectively two questions. This is the first. Can the candidate perform the role? Whatever the discipline, whatever the function, whatever the location, will somebody be successful in the role? Whether this is a designer where we might do portfolio reviews, we might walk through scenarios, we might ask for them to iterate with us, developers. There is going to be maybe some coding, no coding on whiteboards, but you want to see people work in their native tools and their native environments. If you're looking for a sales role or a commercial role, you're looking for somebody to show you that they can sell.

Second is, we don't solve trivia when we're working day to day. We actually just solve problems. Why have an interview process that focuses on trivia? We've really pivoted ours to just really work on real world problems. Some of them are concrete that we face every day. Some of them are a bit abstract, but again, you're going through that problem solving experience. It might be a real problem just from another organization, but one that you want to see, how does somebody deal with something they haven't seen before?

Third, there is no right answer to this question. This is different for every single organization out there. It's different for your team. It's different for the other teams in your company. It's different for your company from the company down the road or upstairs or downstairs. Will this candidate be successful in our environment? Some places talk about this as culture fit. I think there's enough learning and enough evolution there that it's not quite looking for people that are exactly the same as everybody else there. It's, does this individual have the behaviors, have the beliefs, have the principles that will enable them to be successful in our environment?

This is another one, personal philosophy. The text you write for a job description for the person who does not exist and somebody see the as a text document, trying to get these things to match is like a 99% error rate. Part of the interview process is you actually get to know somebody and they get to know you. They get to meet all kinds of people at your organization. We look at it about hiring for the company, not hiring for a specific job. After we've gotten to know them and they've gotten to know us, then there's a discussion and a dialogue to figure out what's the exact right spot. Somebody may have talked to teams and say, oh, you know, I spent the last 10 years in data. I'm an expert on data. I'm kind of tired of it. I want to do something else. And we would, that is great expertise to have in the organization. How do you embed that data expertise maybe in the marketing team or in the mobile team or somewhere else? So, we look at this as very much doing this after we actually know things about people and after they know about us. And to be clear, this is not an engineering plan. We do this across every discipline in the business because we actually find the questions that we're trying to answer are the same. Can people solve problems, real problems, real world problems, not trivia like why is the manhole cover round or how do you weigh a 747? It doesn't tell you anything. Solving real problems that people are going to face every day. Can they be successful in our environment? And let's figure out the right way for them to join the team after we actually know who they are. Relatively simple.

Now you're up to 60%. So, figure out that we have to trust our team and we have ways to do that. A big part of that trust is who we put onto the team and who we help and who we hire. Now, let's say this. The most important meeting of the week, if you were in a consumer business, if you were in an enterprise business, you're in a B2B business, you're an internal IT team, anybody working on technology has a customer. Your operations review is actually your most important meeting of the week. This is your meeting where you're figuring out are we meeting the expectations of our customers? Is our product actually working? Are we delivering on the contract of the thing we have today? Because if you piss off your customers today, they're not going to care about that new feature you ship tomorrow or next week or next month or next year. This is a rhythm. It's every week. We work in the time of 24-7 customers. They could be halfway around the world. They could be in the same times and they could be in the same building, but you've got to be looking at this every week. If you take your eye off this, these things naturally start to drop. Agendas are really simple. What's the customer experience we're delivering on and what mistakes can we learn from? Invite everyone.

Everybody in an organization, this is not just an engineering item, everybody at the organization has a vested interest in what are we doing to meet our customers' needs. This meeting does set your engineering culture because it shows what you care about. Where you spend your time is a reflection of the things you care about and every single one of us only has a company, only has a product, only has a team because we have customers and it has to be our number one priority.

When people start to make mistakes, this can get really contentious. You can start saying, oh, you screwed this up, you screwed this up. The mistake is done. It's mitigated. There's nothing you actually gain by blaming somebody but rather look at it and say, how can we automate this so it never happens again? If it happened on one team, how do we scale that to every other team? Peer to peer. When we talk about autonomy, we talk about empowering autonomy. This is a big part of it. It's not top down. This is not a management job. This is every individual on the team, on adjacent teams, helping your neighbor next door, helping a team in another location.

Now that we get to 80%. Last piece. You guys have probably heard this expression before. Big, hairy, audacious goals. BHAG.. Originally, I think define Jim Collins in one of his books. But you need to inspire people to aim. You got to aim high. If you only look for what's two feet in front of you, you're never going to do anything great. When you look at hiring really smart, capable, rational people, you expect them to innovate. You expect them to create. You expect them to do something special. Help them aim. This is a quote, you guys may have seen this on posters and inspirational posters and all kinds of memes and stuff like this. But it's basically if you want people to do something great, don't just tell them what to do and say inspire them about why. What are they going to get out of this? How do they change things? If you're actually looking for specific techniques, I won't go into specific techniques for how to drive inspiration, how to drive purpose. This is an amazing book. It's probably the most practical book on this topic. Breaks it down into three things. Autonomy, mastery, purpose. This is square in the purpose section.

Just some examples of aiming really high. JFK in 1961 says, okay, we're going to put somebody on the moon in less than a decade. Somebody had even flown a rocket with a person at that point. That's pretty audacious. Have Google from Google's founding, they said we're just going to organize all of the information in the world. Again, pretty audacious. Or you look at Amazon saying, we're going to take every book in the world in every language and put it on any device anywhere in the world in under 60 seconds.

When things don't exist, these are those big audacious goals that gives your team something to dream about and gives them room to innovate and create. None of us are as smart as all of us and there's nobody that can just tell everybody what to do, how to get from here to there. So when you're working with your team, local team, big team, organization, doesn't matter. You should be thinking about what is your audacious goal, what is your BHAG, what is one, two, three of these things. You don't want 300. You want something that people focus on. And this doesn't have to be global, it can be local.

Simple things. How do you have your team? Let's say you have a small team, four, five, six people and you're running services. How do you challenge your team to get to a point where all alerts fix themselves? I've been woken up at two o'clock in the morning more than a few times. I would love for alerts to fix themselves. There are other examples here. It's really about saying how do we challenge ourselves to do much more than just that incremental next step. And our job here as leaders, we need to help the team dream, help them aim high. Challenge them that that next incremental step is not enough. And you don't have to dictate the path, but sometimes you'll have a great goal and everybody agrees and then they sit down and go, well, I have no idea how to get there. Right, we're going to go get to no alerts. All alerts heal themselves. Well, I don't know. I have no idea how to do that. And it doesn't mean that you have to solve it, but sometimes it's just planting those initial ideas, initial brainstorming that really gets people going, really gets people thinking about this.

Most importantly, if you want an autonomous team, you have to give them space to do the innovative piece. You have to let them find the path. So you're trying to seed that brainstorming, trying to kick this off, but you can't drive it. Again, this is not a management behavior. You might just be the senior engineer in your team. You might be the senior designer in your team. It's a group of six, seven people trying to solve the same problem. But if you're the most experienced, people will by default lean to you to say, you know, well, what's the answer? And you have to resist that urge. You have to pace yourself. You have to encourage others to participate, to jump in. Again, autonomy is for everybody.

And last one is be patient. In the short run, it is always slower to help bring other people along to get them to expand their point of view than just telling them what you've already learned by making 10 mistakes along the way. So it actually takes us to 100%. That's it. It's actually relatively straightforward.

So we're done. But not quite, because actually if you go to 100% autonomy, you end up with something like this. Everybody making their own decisions. Remember, nobody can tell them what to do. Making their own decisions, going their own ways, not following any rules, not following any guidelines, just let's just go for it. And anybody who's worked in a, in a, even a 30, 40 person organization where there's no, no alignment, no joint responsibility, no communication they're sharing, you end up with a crash pretty bad.

So I'll say this, autonomy absolutely requires alignment and responsibility. And this is where we're going to balance this a little bit. So alignment equals planning. If you plan software like this, quite frankly I feel sorry for you. I have personally never seen a timeline for software that is accurate more than three days from today. It's impossible to estimate software, right? We can estimate what we know, but the whole point of software, what makes this so challenging and fulfilling and rewarding is that as you go down the path of building something, you're going to learn all kinds of things along the way. You're going to learn that instead of doing this one thing for a customer, if I just spend an extra couple of days, I'm actually going to give them a 10X better experience. You find out this API that I thought was really easy and it works. Turns out not all the open source software is as dependable as others, right? I find some bug, I find some concurrency issue. I get lost down a rat hole of debugging. I find something that doesn't work at scale. There's all these learnings that we have along the way. This is the fundamental premise of why we have Agile, right? Why we have all these methodologies is because we can't really predict more than a couple days, maybe two weeks in advance, maybe.

But planning is alignment and you've got to find a way. How do you have everybody pushing in the same direction if you're not going to have a Gantt chart, which again, I do feel sorry for you if you guys try to play in 6, 9, 12 months software like that. So one, when we talk about these BHAGs, this is really, really important. There is no monopoly on where ideas come from. You have to support ideas and brainstorming coming from everywhere in the organization. Now at some point you've got to curate these things, you've got to prioritize. That is actually a leader's role. It is not to decide what the goals are, but rather to contribute as a peer and then somebody's got to help curate and prioritize these items.

A lot of times you'll focus on goals. What is the thing you're trying to achieve? And they'll be very, very internally focused. It's really important that you think about your goals in the terms of the customer that you're serving. The reason that we all have jobs, the reason that we all get to come to work tomorrow is because we have customers. Again, whether it's internal and you work in an IT group, it's external for consumers, it's other businesses, it's other enterprises, we all have somebody that we're building software to help.

Just a little sub note here. A lot of times we set goals and we say things that we define them in metrics. Metrics measure your progress, but they are definitely not the finish line. I think this is a bit nuanced, but a lot of people I think get trapped on this, which is, oh, I'm going to get conversion from X to Y, or I'm going to help customers finish this form. Average customer latency is going to go from 60 seconds to 40 seconds. Okay, sure, but what do they get out of that? Do they get more productivity? Do they get a bit more things done? Are they able to reduce costs? Are they able to increase sales, increase turnover, whatever the case is? Focus on the actual outcome for the customer.

Now this is where autonomy comes in. If you have these audacious goals, you curate them for the overall organization. The default instinct is say, okay, let's just start passing those down the management chain. We'll create a couple audacious goals and the CEO does that, and then they hand it to their direct reports, they hand it to their direct reports, and everybody just cascades out. Actually, what you're saying is the last people to decide what we do are the people who are closest to the details of what we're actually doing. Again, it's just a miss. It's comfortable. It's natural. We think, oh, yeah, yeah, let's just pass it down the line, or shit rolls downhill, depending on your point of view.

Really, the people who are closest to the details are really the ones that should be doing the goal. When you think about alignment, you're setting what is the audacious item that we're aiming for. We're going to put somebody on the moon, but then go immediately to the teams that are actually working on the details and ask them a simple question. What is the one or two things you plan to do over the next several months that will help us put a man on the moon? Let them nominate that. Again, our job as leaders is to help prioritize and curate. We're not setting the goals. We're asking our teams that know the details best, what should we do?

Last one. You heard Rory in his intro talk about bringing together DevOps and design. I think this is pretty fundamental. If you want a goal and you orient your goals around customers, do not organize your teams by discipline, please. No one discipline can actually solve a comprehensive problem. We have to think about what the user's going to interact with. We have to think about the backend services. We have to think about the data protection. We have to think about security. We have to think about global replication. We have to think about availability. We have to think about awareness. We have to think about retargeting. We have to think about re-engagement, user retention, churn. There's this whole compendium of things we need to do to actually build a great feature for customers. You need all the people who specialize in these disciplines working together towards that same goal.

Again, when we talk about autonomy, we talk about autonomous teams, these are the types of things it takes and the systems you have to put in place to help these teams be successful. I mentioned it takes planning and responsibility. Responsibility is simple for us. We talk about standards and principles.

Let's talk about technology standards. This is always a contentious one when you start to get, I think usually more than two engineers together. What's the standard you're going to pick? What's the technology you're going to bet on? What's the new cool thing I saw on Hacker News last night at 1130 at night and I think we should move our whole prod stack too? These are debates that happen every day. The important thing is one, if you're going to bet on technology standards now, as you grow there is benefits to using similar technologies. I'm helping on this part of the product and tomorrow we've got a crisis over there. If I'm working in Ruby and this product over here is in.NET, I'm not going to be a lot of help if the thing's on fire. I might be help over six months, but I'm not going to be help this afternoon. These standards help. Important thing, these are by engineers for engineers and this applies across any discipline. If you have design standards, what manager is going to be great at asserting design standards? Probably what designers do that. If you're going to have standards of how you give a commercial pitch to sell customers, probably have your commercial experts do that. It's about having your specialists and your experts define what is their standard and having them agree. Your job as leaders is to help facilitate that and make sure they know it's important, make sure they know why, but it's their job. Just like everything else, none of this stuff is set in stone. These things have to evolve. We work in a dynamic evolving industry. How do we do that?

Then you'll hear me use the two words, principles and standards. Principles fundamentally it's how we work. For example, if we're building software, everything gets a peer review. Simple statement applies to coding, applies to designs, applies to test plans, applies to global roll out plans, applies to marketing plans. Everything gets a peer review. Ask somebody else who knows your discipline to take a look at what you do before you go execute it. The standards are how we deliver success in production. Got to be available in multiple regions, has to be resilient, has to have backup and recovery plans so on and so forth. Actually takes us a little bit back behind the 100%. I think in our experience, we found this is really the optimal outcome. What you're looking for is empowerment and autonomy, but not without alignment and responsibility.

The last piece, this may all sound well and good. You heard Rory mention we have a pretty large team and there's a couple other things about how do you scale this across multiple locations, multiple teams, hundreds of people, multiple continents. Every single team should be able to answer these questions. Are they setting their own backlog? Are they shipping whenever they want? Can they do this without anybody else's approvals and can they control their own dependencies? That means they can choose to take dependencies. It means if they need a change in their dependency, they can go into that team source code and go fix it if they need to.

Second thing, this thing is called Boyd's law. This guy in the 1950s who was studying fighter jets and there were certain older jets that were beating newer jets in dogfights and he figured out that the speed that you can iterate at beats the quality of your iteration every time. It was basically an older, slower jet but could turn faster and maneuver quicker and you got X more maneuvers every minute, every 10 minutes, every hour and they were winning consistently. This is a principle to live by when we look at software. Again, internal software, enterprise software, consumer software, doesn't matter. If you can iterate twice as fast as anybody else, you only have to be right half the time. You get to double the learning. You compound that over a year. Imagine you're shipping twice a day instead of once a day. It's an extra 260 deployments a year. Shipping once an hour instead of once a day. You're talking 1,800 additional iterations. 1,800 more iterations, your product is going to be better than the other.

If our goal is iteration, goal is speed, these are things that start to matter at scale. If you're a team of five, this stuff matters less. If you're a team of 500, this stuff matters a lot. How do you help people do the right thing as often as possible as fast as possible? It's the boring stuff. We like doing the fun stuff. We like creating. We like inventing. We like sitting at the whiteboard and drawing what's the next thing we're going to go build. We like sitting down at Sketch and building out what's that new UX for that new customer experience for that brand new product.

Just some engineering examples. How do you push your team to say, as a team, let's ship to production 10,000 times a day? This is actually one of our goals, by the way. For 500 people writing software, that's a crazy goal. It's every single engineer, 100% of them shipping to production 20 times a day. If you actually just think about it, think about your code, that is a commit about every 20, 25 minutes depending on how long your lunch break is and how many smoke breaks you take.

But it's how do you build the infrastructure? How do you drive the automation? How do you get humans out of this? Again, audacious goals are not only, are not exclusive to company level. These are individual teams as well.

Last, if you want to know if you're doing the right stuff, if you know you're doing the right thing, I thought I'd share a couple of metrics that I watch that I worry about in terms of autonomy.

First, are we meeting our customer expectations? Is our product actually available? Now that doesn't mean it passes a ping test. That means does it actually work for what our customers expect it to do?

Two, production deploys per day. It might actually sound like a vanity metric and it's not, but you have to have about a thousand things right to have this number go up. If anybody, Rory was talking about DevOps at the opening as one of the founding principles for this conference. If you have not read the annual DevOps report, I strongly, strongly, strongly encourage you to do so. I forget the exact number, but something like organizations that deploy more frequently have 700% better performance. It's some crazy multiple, but Jez Humble and Nicole Ferguson publish that every year. It's free. Go check it out. Annual DevOps report. It is well worth the read.

Three hiring metrics. We're only as good as the people on our team. Hiring at scale is actually a skill. It is a strategy. It is a system unto itself. And how do we drive that? And again, just like your product. If you don't watch what your product availability, what your product impairment is, it's going to take a good dive off the cliff. Same with hiring.

So let's wrap up a couple of things. One, we look at the autonomy piece. How do we get that thing from zero to 100? Trust your team. View hiring as a strategy, not as a tax. Design ops meeting is critical. Absolutely critical. Sorry, as I keep wandering in front of the screen.

And four, aim high. Be audacious. Challenge your team to build what can't be done. Challenge them to achieve the impossible.

Now let's take it from 100% back just a little bit to 90%. How you drive alignment and responsibility. It's doing planning at scale without numbing everybody with a giant Gantt chart or project plan or something like this.

Make sure people are working towards the same goals, same technology standards, same principles. Optimize for how quickly you can iterate, how quickly you can change. Can you get to hourly deploys? Can you get to permanent deploys? Can you get 500 people working on the same code base and shipping to prod every second? How do you get there? How do you enable the iteration? How do you make it so cheap that every time somebody has an idea about an experiment you could do, you don't have to decide if that's a worthwhile experiment because it only takes a couple of minutes. It takes a couple of hours to build a whole new feature.

If ideas become cheap, again, that just further embeds innovation into your team. It further encourages that level of autonomy. Speed of iteration is really critical. And metrics know if you're doing this right. Availability deployments and hiring. Okay. So with that, I'm going to wrap it up. I think we're going to do a couple minutes for questions. But I challenge you to go in and