Empowering Autonomous Teams From The Top Down

Bryan Dove at UXDX EMEA. Video: https://youtu.be/l9pVGlBD1qM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What autonomy means

[00:00:06] I wanted to talk today about empowering autonomous teams. You just heard Rory talk about connecting the dev experience, the ops 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. As I was putting this talk together, 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.

[00:00:47] Let's look at this on a scale. If we think about what zero percent looks like, 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 get a hundred percent. It's like this freedom: nobody's telling me what to do, I'm going to make my own rules, I'm going to do whatever I want.

[00:01:11] I was thinking about the best way to share information, because these are complex problems. When we have these organizations, once it's more than a couple of 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, 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. At scale, people are less predictable.

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

Trust your team, and share context

[00:02:09] Item number one: trust your team. I want you to think about whether these points 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; it may not be the right organization for them. Is everybody capable? Again, people on your team should be capable of the job you're expecting them to do. Is everybody rational? These get kind of hard to argue with. If I work in the technology team, I should expect everybody to be smart, capable and rational.

[00:02:48] If this is a hundred percent 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 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 about a decision, and everybody decided to go left, and you're going, "Holy, 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. Because if everybody's smart, capable and rational, and they have all the information, they'll make the right choice. That's a lot of what I want to talk about today.

[00:03:34] Our job as leaders, and this is not a management role, leadership is a role that each and every one of us can play on our teams, is how do we make those around us better? You know the adage: fishing for somebody feeds them for a day, teaching them to fish feeds them for a week. When you really look at these leadership roles, whether it's your team, whether you're managing a team, managing a number of teams, or leading a whole organization, you're really teaching a village to fish. This is not easy.

[00:04:03] 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. And 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, to be successful. That's point one. I forgot about this, sorry: if you just take these two things together, people will make the right choice. There you go. That alone gets you forty percent of the way.

Building trust through hiring

[00:04:49] Let's go down to building trust. This is another piece. I kind of just asserted that people will do the right thing if they're smart, capable and rational and they have the information and the context. How do you know? Eric Schmidt is pretty famous for saying that hiring is the most important thing that you do, and 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 are 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.

[00:05:34] We all get hiring pressures, but you really have a binary choice: you can hire fast or you can hire well. I'm pretty sure it's impossible to do both. Think about your hiring model today, for your organization, for your team, for your company. Is it a tax on the team? Does everybody dread doing interviews? "I've got another one scheduled. It conflicted with my stand-up, it conflicted with my ops review, it's conflicting with a design review." Or 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.

[00:06:09] 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. We think our system is pretty simple. We're trying to answer effectively two questions. 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 a portfolio review, we might walk through scenarios, we might ask them to iterate with us. For developers there is going to be maybe some coding. No coding on whiteboards, but you want to see people work in their native tools, in their native environments. If you're looking for a sales role or a commercial role, you're looking for somebody to show you they can sell.

[00:07:03] Second, we don't solve trivia when we're working day-to-day. We actually just solve problems, so why have an interview process that focuses on trivia? We've really pivoted ours to just work on real-world problems. Some of them are concrete ones 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 where you want to see how somebody deals with something they haven't seen before.

[00:07:30] Third, and 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, 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, and I think there's enough learning and enough evolution there that it's not about looking for people that are exactly the same as everybody else. It's: does this individual have the behaviors, the beliefs, the principles that will enable them to be successful in our environment?

[00:08:05] This is another one, a personal philosophy. The text you write for a job description is for a person who does not exist, and somebody's CV is a text document. Trying to get these things to match is like a 99 percent 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. So we will go 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 said, "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." We would say 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? This is very much done after we actually know things about people and after they know about us.

[00:08:53] To be clear, this is not an engineering thing. 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-world problems, not trivia like why is the manhole cover round, or how do you weigh a 747? That 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%. We figured 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 hire.

The operations review is your most important meeting

[00:09:38] Now let's do this: the most important meeting of the week. If you're in a consumer business, if you're in an enterprise business, a B2B business, 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 the 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.

[00:10:08] This is a rhythm, every week. We work in the time of 24/7 customers. They could be halfway around the world, they could be in the same time zone, they could be in the same building, but you've got to be looking at this every week. If you take your eye off these things, they 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 the organization. This is not just an engineering item. Everybody in the organization has a vested interest in what we are doing to meet our customers' needs.

[00:10:42] 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. It has to be our number one priority. The last thing: when people start to make mistakes, this can get really contentious. You can start saying, "You screwed this up, you screwed this up." But the mistake is done, it's mitigated. There's nothing you actually gain by blaming somebody. Rather, we'll 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, when 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 we get to 80%.

Aim high: big hairy audacious goals

[00:11:36] Last piece. You've probably heard the expression before, big hairy audacious goals, BHAGs. The original, I think, was from Jim Collins in one of his books. You need to inspire people 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 may have seen on inspirational posters and all kinds of memes, but it's basically: if you want people to do something great, don't just tell them what to do; instead, inspire them about why. What are they going to get out of this? How do they change things?

[00:12:24] If you're actually looking for specific techniques, I won't go into specific techniques for how to drive inspiration, how to drive purpose, but this is an amazing book. It's probably the most practical book on this topic. It breaks it down into three things: autonomy, mastery, purpose. This is squarely in the purpose section.

[00:12:36] 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. Nobody had even flown a rocket with a person at that point. That's pretty audacious. Google, from Google's founding, 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 these things didn't exist. These are those big audacious goals that give your team something to dream about and give them room to innovate and create. None of us is as smart as all of us, and there's nobody that can just tell everybody what to do and how to get from here to there.

[00:13:13] When you're working with your team, local team, big team, organization, it doesn't matter, you should think about: what is your audacious goal? What is your BHAG? What are one, two, three of these things that you want people to focus on? It doesn't have to be global; it can be local, simple things. Let's say you have a small team, four, five, six people. When 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 an incremental next step in our job?

[00:13:57] Here, as leaders, we need to help the team dream, help them aim high, challenging them that the next incremental step is not enough. 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, "I have no idea how to get there. We're going to get to all alerts healing themselves? I have no idea how to do that." It doesn't mean that you have to solve it, but sometimes it's just planting those initial ideas, that initial brainstorming, that really gets people going, really gets people thinking about this.

[00:14:27] 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. 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 and say, "Well, what's the answer?" You have to resist that urge, or you have to pace yourself. You have to encourage others to participate, to jump in. Again, autonomy is for everybody. The 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 ten mistakes along the way.

Autonomy needs alignment: planning

[00:15:19] That actually takes us to a hundred percent. It's actually relatively straightforward, so we're done. But not quite, because if you go to a hundred percent 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 "go for it." Anybody who's worked in even a 30 or 40 person organization where there's no alignment, no joint responsibility, no communication, no sharing, you end up with a crash, pretty bad. So autonomy absolutely requires alignment and responsibility, and this is where we're going to balance this a little bit.

[00:16:07] 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. 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 that this API that I thought was really easy and works, turns out not all open source software is as dependable as others. 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, why we have all these methodologies: because we can't really predict more than a couple of days, maybe two weeks, in advance. Maybe.

[00:17:07] But planning is alignment, and you've got to find a way to 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 try to plan six, nine, twelve months out all the time. So 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. 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.

[00:17:53] 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 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 that's internal, you work in an IT group, or it's external for consumers, or it's other businesses, other enterprises, we all have somebody that we're building software to help.

[00:18:19] A little sub-note here. A lot of times we set goals and we define them as 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 get trapped on this: "I'm going to get conversion from X to Y," or, "I'm going to help customers finish this form; average customer time 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 more things done, are they able to reduce cost, do they increase sales, increase turnover, whatever the case is? Focus on the actual outcome for the customer.

[00:18:54] Now this is where autonomy comes in. If you have these audacious goals and you curate them for the overall organization, the default instinct is to say, "Okay, let's just start passing those down the management chain." We'll create a couple of audacious goals, the CEO does that, and then they hand it to their direct reports, and they hand it to their direct reports, and everybody just cascades it out. But 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. It's comfortable, it's natural. We think, "Yeah, let's just pass it down the line," or it rolls downhill, depending on your point of view. But really, the people who are closest to the details are the ones that should be setting the goals.

[00:19:37] 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 are the one or two things you plan to do over the next several months that will help us put somebody on the moon? And let them get it done. 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 we should do.

[00:20:03] Last one. You heard Rory in his intro talk about bringing together DevOps and design. I think this is pretty fundamental. If 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 is going to interact with. We have to think about the back-end services, the data protection, security, global replication, availability, awareness, retargeting, re-engagement, user retention, churn. There's this whole compendium of things we need to do to actually build a great feature for customers, and you need all the people who specialize in these disciplines working together towards that same goal. Again, when we talk about autonomous teams, these are the types of systems you have to put in place to help these teams be successful.

Responsibility: standards and principles

[00:20:57] I mentioned it takes planning and responsibility. Responsibility is simple for us: we talk about standards and principles. Technology standards: this is always a contentious one when you 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 11:30, and I think we should move our whole stack to it? These are debates that happen every day.

[00:21:26] The important thing is, if you're going to bet on technology standards, as you grow there are 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 that thing's on fire. I might be a help over six months, but I'm not going to be a help this afternoon. So these standards help.

[00:21:48] The important thing: these are by engineers, for engineers, and this applies across any discipline. You have design standards. What manager is going to be great at asserting design standards? Probably designers do that. You're going to have standards for how you give a commercial pitch to sell to customers; probably your commercial experts do that. It's about having your specialists, your experts, define what their standard is and having them agree it. Your job as leaders is to help facilitate that, make sure they know it's important, make sure they know why 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.

[00:22:21] You'll hear me use the two words, principles and standards. Principles, fundamentally, are how we work. For example, for building software: everything gets a peer review. A simple statement. It applies to coding, applies to designs, applies to test plans, applies to global rollout 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: it's got to be available in multiple regions, it has to be resilient, it has to have a backup and recovery plan, and so on and so forth.

[00:22:53] That actually takes us a little bit back, below 100%, and in our experience, what I've found is this is really the optimal outcome. What you're looking for is empowerment and autonomy, but not without alignment and responsibility.

Scaling autonomy: speed of iteration

[00:23:14] The last piece. This may all sound well and good, but you heard Rory mention we have a pretty large team, and there's a couple of other things. How do you scale this across multiple locations, multiple teams, hundreds of people, multiple continents? One: 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 that if they need a change in their dependency, they can go into that team's source code and go fix it if they need to.

[00:23:45] Second thing: there's this thing called Boyd's law. This guy in the 1950s was studying fighter jets, and there were certain older jets that were beating newer jets in dogfights. He figured out that the speed at which you can iterate beats the quality of your iteration every time. It was basically an older, slower jet, but it could turn faster and maneuver quicker, and you got extra maneuvers every minute, every 10 minutes, every hour, and they were winning consistently.

[00:24:19] This is a principle to live by when we look at software. Again, internal software, enterprise software, consumer software, it 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, and you compound that over a year. Imagine you're shipping twice a day instead of once a day: it's an extra two hundred and sixty deployments a year. Shipping once an hour instead of once a day, you're talking eighteen hundred additional iterations. Eighteen hundred more iterations: your product is going to be better than the other.

[00:24:58] If our goal is iteration, and our 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 five hundred, 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 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 that new UX for that new customer experience for that brand new product.

[00:25:26] Just some engineering examples. How do you push your team to say, as a team we will ship to production ten thousand times a day? This is actually one of our goals, by the way, for five hundred people writing software. It's a crazy goal. It's every single engineer, 100% of them, shipping to production 20 times a day. If you actually think about it, think about your code, that is a commit about every twenty, twenty-five 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 exclusive to company level. These are for individual teams as well.

Metrics that tell you it's working

[00:26:05] Last, if you want to know if you're doing the right stuff, how do you know you're doing the right thing? I'll just 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? That doesn't mean it passes a ping test. It means, does it actually work for what our customers expect it to do?

[00:26:27] Two, production deploys per day. It might actually sound like a vanity metric, and it's not, but you have to get about a thousand things right to have this number go up. As was being said about DevOps at the opening, it's 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 it's something like organizations that deploy more frequently have 700 percent better performance. It's some crazy multiple. Jez Humble and Nicole Forsgren publish that every year. It's free, go check it out, the annual DevOps report. It is well worth the reading.

[00:27:08] And 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. How do we drive that? Again, just like your product, if you don't watch your product availability, your product impairment, it's going to take a dive off the cliff. Same with hiring.

Wrap-up

[00:27:31] 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. Hiring as a strategy, not as a tax. The production ops meeting is critical, absolutely critical. Sorry, 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.

[00:28:00] Now let's take it from 100% back just a little bit, to 90%. How do you drive alignment and responsibility? It's doing planning at scale without numbing everybody with a giant Gantt chart or project planner or something like this. Make sure people are working towards the same goals, the same technology standards, the same principles. Optimize for how quickly you can iterate, how quickly you can change. Can you get to hourly deploys? Can you get to per-minute deploys? Can you get 500 people working on the same code base, 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 can do it? You don't have to decide if that's a worthwhile experiment, because it only takes a couple of minutes, and it takes a couple of hours to build a whole new feature. If ideas become cheap, that further embeds innovation into your team. It further encourages that level of autonomy. Speed of iteration is really critical. And metrics, to know if you're doing this right: availability, deployments, and hiring.

[00:29:03] With that, I'm going to wrap it up. I think we've got a couple of minutes for questions. Thanks.