Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Optimize for Time

Optimize for Time



Andy Walker talks about Time - the most precious commodity at hand. He gives advice on how to use time in a way that enables teams to improve. He shares some practical advice on how to get the most out of the time, and proposes some principles to develop personal approaches.


Andy Walker has been doing software engineering for nearly 30 years. He is currently the founder of Kraken Industries and was previously at Google, Skyscanner, Netscape, Sony, IBM and various startups. For the last 10 years he's been fascinated by engineering culture and how people are at the center of everything.

About the conference

Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.


Walker: I spent 10 years at Google. A couple of years at Skyscanner. For the last 10 years, I've been very interested in what makes teams high performing. I've also had a lot of material to work with, because I've either managed directly or indirectly a large number of teams. Back when I was at Google, I was part of rolling out the Project Aristotle work on effective teams. I spent not an inconsiderable part of my life talking to people in fairly broken situations. One of the common things that I've seen in teams, particularly ones which are performing well is their relationship with time. The teams which are really high performing seem to have more time than everybody else to get things done. They're never hurried. They always hit their deadlines. They have flex. They're able to take on new crises as they show up. Teams which are struggling never have enough time. They'll always feel like they're behind. They're under pressure. This has a serious knock-on effect. The way we think about time, can help us have a much greater impact in our life. Benjamin Franklin said that time is money. Time is the most valuable currency that we have as human beings on this planet. We have a finite amount of it. Once it's gone, we don't get to earn more of it, unfortunately. Therefore, every moment of our existence is a precious piece of currency.

Why should we care? Why does your company care? Can you have more impact in less time? One of the things which was brought up earlier was people need to instill a sense of urgency into their teams. Actually, it's about having more effect in a shorter space of time. From a personal perspective, the more impact you have, the faster you progress your career. If you're able to do that, without it consuming your whole life, you have a personal life to go with that as well. That should not be underestimated.

First of all, for the managers in the room, change comes from within. It is very difficult to externally force a change on another human being. If you would like to try this, I have a small social experiment. Take out a pen, turn to the person next to you, and try and write idiot across their forehead. I guarantee, you are going to have a really hard time making this change happen. If they choose to write, idiot, that's another matter and probably self-fulfilling. Second of all, you need to lead by example. If you are not walking the walk in terms of how you're using your time and other people's time, nobody else is going to either. In fact, the limiting factor on organizations is how their leaders behave and how they use their time, and actually employ people around them. Lastly, using time well is not being busy. Busyness is a curse. Actually, having time where you're not busy, where you're available to take on things as they come up, because they will, is vitally important. The more senior you get, the more important it is to have that flex time. Finally, when I stopped working, I had about 200 people working for me. If I was not keeping half of my week free of meetings, then I was not able to be there when people needed me, either for support, for guidance, for air cover, or any of the random things which happens to human beings in their lives. The last thing, while thinking about time can help teams progress themselves. As a manager, the last thing you should do is try and measure the time people are spending on things. In particular, do not try and centralize the measurement of how people are managing time. That is one of the fastest ways to get people to quit their jobs. Believe me, it really is. As soon as my manager says, "What are you doing at 11:00 this morning?" "I don't know." Concentrate on outcomes. This is a set of principles which will enable you to become more effective. Please do not use my teaching for evil.

The Value of Time

What is the value of time? You can think of it a number of ways. Back in the day, I was on call for part of Google's ad business, which at the time was worth about $10 billion revenue a year. I can very quickly extrapolate the value of this. I also was on call during both the Fukushima nuclear disaster and Hurricane Sandy in New York where the internet was about 36 hours away from being bifurcated because most of the networking across the Atlantic goes into one building in downtown Manhattan and that was flooded and the water levels were rising steadily. The stress when things go wrong is quite high. If you look at it, you can lose $27 million in a day, which is both motivating and terrifying at the same time. In that instance, it is well worth employing a number of people to make sure the system is running smoothly on a full time basis. That may not be the best use of all of their time.

What's your time worth to you? I did a quick search on Glassdoor, and the average software engineer in London earns £52,000 a year. Which if we extrapolate that out rocks out at roughly £200 a day. The cost of employing somebody is double that. To your company, just the cost of your time, is £400 a day. That's before any return on your investment. Let's assume that your company gets back a pound in revenue, and they breakeven. Your time spent not working is worth £800 a day to your company. If you are profitable your time is worth £1200 a day to your company. A simple sum means I can work out the cost of QCon, which is not going to endear me to the organizers. If you look at the cost of everybody being here, it's about £2.8 million. Once you throw in the cost of your time in terms of paying you for your normal employment, and the opportunity cost of you not being here, it works out at over £5 million to your company. You could probably start a couple of kicker startups with that money. This is three days of people's time. When I'm saying thank you for investing this time, this has real value. It's a little bit scary once you work the numbers out.

Back when I was at Google, my first manager, who was deeply misanthropic, shared an essay in philosophy with me called the basic laws of stupidity. At the time, I thought he was celebrating our shared hatred of the human species. Looking back, I realize what he was trying to say was stop doing stupid things. I have adapted this to how people spend time. You can look at it as quadrants, there's two axes. Across the bottom is the value you're bringing to yourself. Up the side is the value you're bringing to others. The intelligent person brings value to themselves and to people around them. If we were to use an analogy of pies for this, an intelligent person makes a bigger pie so people can eat more. A person who indulges in a zero sum game, takes your pie and eats it for themselves. A person who is hapless doesn't know this pie being served and therefore doesn't have an opportunity to eat. People who are harmful start a food fight with the pie so that nobody gets to eat. When we're thinking about how we spend our time, think about the value we're bringing to ourselves. If we are not in the top right quadrant, we are either not going to be very happy with life or we're going to be causing harm to other people. There's not really such a thing as a zero sum game. Because if you're in a work relationship with somebody and your success is predicated on them losing something, the next time you interact with them is going to be much harder for you. Therefore, you want to create these situations where everyone's success is aligned. Somebody in a team, who sees everybody else get promoted when they've been working just as hard as everybody else, but has no route to promotion to themselves, is not likely to support the team's success in the long term.

This comes to four things I hold to be true with high performing teams' relationship with time. The first is they invest in how they use time over a period of time. They are getting better over time. Second, they respect other people's time. When I started this talk after 30 years in the industry, I realized that we have a real problem in our industry and how we respect each other's time. There are about 500 slides of people who have pissed me off over the years and wasted my time. Once I got that cathartically out of my system, I realized I had to reframe it into something positive. I have a lot of examples, both good use of time and not so good use of time. They're ruthless about time. They don't do things which don't bring them value. They are willing to say no to things which don't make sense. Lastly, they're able to anticipate things in advance. They know that there are unknown unknowns in any situation, and yet they're able to mitigate them effectively in the course of getting things done, so that they're not crippling to what they're working on.

Invest In Improvement

First of all, at any point in time, if you talk to somebody in an engineering team, and say, how are things going? They're likely to say everything is shit. Because they look at the things which are stopping them getting things done and there are going to be no situations in your life where somebody comes to you and says it is too easy to get things done here. You are never going to have that conversation as a manager, which is sad. If you look at a single data point, you are never going to be a happy person. It's very easy to join that person in a mutual despair, how the world is so unfair, and you're swimming through treacle, and it's never going to get better. If you have two data points, however, you have an opportunity to have a real conversation about things. If your trajectory is up and to the right, then you can talk about what other things we did, which enabled us to get better. How do we do more of those things? If we were like that six months ago, in six months' time, we're going to be up here, and things are going to be much better again. Let's keep doing this. If things are down and to the right, you have a problem. You now have an opportunity to course correct that problem. It could be you're generating too much tech debt. It could be that there's not enough domain knowledge in the team. It could be people are leaving the team. It could be the requirements are broken. Knowing the trajectory across different data points means you can chart that the team is doing well. You have that feedback loop to tell them, keep doing the things that you're doing.

How Hard Are Simple Things?

If you have a team which is struggling with time, the first question you should ask them is how easy is it to do the simple things? I had a team a few years back where they hadn't actually pushed to production in three years. They were not happy with life. They had just inherited the code base for a quite large number of millions of user's product from another team with not much support on how to get things done. They had a lot of pressure from a part of the organization around support costs for that product. One of the things that they wanted to change was actually a button. It took them five weeks to change that button, once they'd gone through the privacy reviews, the legal reviews, the testing, the internationalization, the experiments to demonstrate it was having the effect it was going to have. This is not particularly motivating. This is the shortest cycle time they could go through to learn how to get better. The teams which are really great are the ones that make the simple things look effortless. A change which should take an hour to get from conception to production takes an hour. How you're getting down that journey is how many times you can go through that cycle, reducing steps every single time. If a team is struggling, and you give them an 18 month project to invent a new tech, they're never going to deliver it. When a team is having a hard time, start them with the simple things. Once you get good at the simple things, then you can progress to things which are more complicated.

Features vs. Infrastructure

The next question is the eternal friction between product and engineering. Product wants features and the business wants features. Engineering wants to build infrastructure. This is the wrong question. What if the team is the product? What if part of the work you're doing is to make your team as effective as possible and invest in that? What are the feedback loops and conversations which need to happen to enable that to happen? I'll also say as well, if you're not investing in moving faster as a team and removing friction, you're going to be moving slower. Because you're going to be accruing tech debt, you have short term gain.

I had another team who were really struggling with this to the point where their weekly Sprint goals, they were missing 85% of them. Their stakeholders were quite vocal about things not going well. We came to an alignment that, before we try and come up with your six month plan and a plan for these milestones, which if we can't plan over a week, there's no point in trying to plan over six months. That is cruel and unusual punishment. Why don't we get to the point where we deliver on our promises every week? At the end of every week, we'll look at whether we achieved what we said we were going to achieve. If we did, great, if we didn't, why not? Is there a way of adding something to the backlog which will allow us to move quicker next week? We found that a one-two week cycle gave us a good number of iterations where we can make small cumulative improvements where you get the compound interest of 2%, 3%, 4% gains, which don't feel like much at the time, but over the course of a year, can turn a team into a completely different creature all together. It also gives ownership to the team over how they go about working. If a team is not investing in making their lives better, they are going to be pretty miserable. That sense of ownership and purpose cannot be underestimated.

Respect Each Other's Time

Respecting each other's time. Even more years ago, I used to work with somebody who they worked 7:00 to 3:00 in the afternoon because they had family commitments. On Friday afternoon at lunchtime when they went home, they committed all their code into CVS, which is how long ago it was, and just went home. The problem here was there were no unit tests, and they hadn't even bothered to compile their code. For the next eight or nine hours, the rest of the team basically were forced into debugging their code. In fact, this was the motivator in my life towards test-driven development so that I could quickly work through the chain of suffering that this person's changes had come through. Time is also the basis of trust. If time is the most valuable currency we have, if other people are spending our most precious commodity, and they're not spending it well. This is not going to lead to a healthy relationship between us. The way we spend each other's time is as important or maybe more so in a high performing team, than the way we spend our own time. Thinking about using each other's time as constructively as possible and bringing value to other people with your interactions is the bedrock of every high-trust, high-performing team.

What Would The Do Nothing Scenario (DNS) Outcome Have Been?

One of my more cynical questions, and DNS does not stand for domain name resolution service, is, what would be the outcome of the do nothing scenario in a situation? Take, for example, hypothetically, there's a board meeting tomorrow. Your manager at 5:00 in the afternoon says, "I need you to get me some numbers and write some slides for me for tomorrow." You stay up to midnight, you get the slides done. They don't use the slides. The outcome there, if you had gone that night and gone out and done something completely different, the outcome would have been the same. Every time you spend somebody's time and there is no value created as a result of it either to that person or other people, you are harming your relationship with them. There are a finite number of times you can ask somebody and put them into that situation before they basically say, "Thanks, bye." They go off and find another job. You have to be really careful when you're doing those things.

I had another situation where the manager wanted me to run an initiative. I wrote a proposal. Peer reviewed it, got started. This was a side project for me. I didn't have my full bandwidth. As things were just starting to happen two months in, they said, "Actually, we'd like you to change what you're working on." Not super motivating. Rewrite the proposal, get started again. Two months later, same thing happened again. Deep breath, I'm going to be calm and rational about this. The next iteration of it, I actually had to recruit a group of people to help work on the next initiative. I found about 20 people around the business who were willing to invest their time in making things better. I spoke to each of them individually. I got them excited about things. I got them aligned with what they needed to do. Two months later, same thing happened again. I had to go and tell every single one of those people that their efforts were not appreciated, and that actually we weren't going to be doing that anymore. I quit three days later, after a cooling off period where I removed all of the expletives from my resignation letter. If we go back to the other quadrants, this is the harmful. This is starting a food fight with the pie situation. If you are spending people's time and actually the net benefit is negative. This is not intelligent behavior. This is not something which is going to inspire people to turn up and to give their all, and to be committed to the cause.

What They Say, What They Mean, and What You Hear

There are also some phrases, we should probably get rid of our vocabulary. Always amused by the English people, what they say, what they mean, and what Americans hear kind of things. Interestingly, there's a column for me which is, you are absolutely insane and you do not want to know what the next two columns on that actually say. These are phrases which we frequently use when we are trying not to do something. Each one of these phrases, in some respect, is a microaggression. It is telling the other person that your time is more valuable than theirs is. "I'm too busy to do a task," is not a discussion you need to have. It is, what is the priority of what we're working on? Usually, people say I'm too busy. Reality is they're crap at managing their time. Or, it's not important. It's ok to say this is not important. It's an adult conversation rather than talk to the hand, "I'm too busy." "Sorry, I'm late. My meeting overran." Actually, meetings overrun all the time. We should get better at running meetings. The message you're sending to people is my time is more important than yours. It's ok for you to wait around. These things happen from time to time. Life gets in the way. If this is a regular tone and content of communication, people are not going to want to work with each other. I particularly like the task update one as well. That's another one which is great. The, let's have a status update meeting, which is, I have no idea what's going on. Which should actually be, how do we communicate better and share context, rather than here's a last minute panic to get some information, which we maybe should automate as part of a future iteration.


When I did a Google image search for interruption, this was one of the first things which came up. It seems particularly apt. This is Kanye West interrupting Taylor Swift at the MTV Music Awards to say that somebody else should have won the award. Not the most polite thing that a human being has ever done. Interruption is an interesting thing, because when we're interrupted, we lose our entire train of thought and have to start again. If you want to completely screw somebody's productivity, interrupt them every 15 minutes over the course of the day, they will get nothing done. In fact, the quality of their decision making goes down by anything up to 25%, over the course of an interruption. If we want people to do high quality work, we should only interrupt them when there is an important reason to do so. The person who comes over to you and asks you that question, which you type verbatim into Google, and then read them the answer in the hope that they will stop doing that having discovered this incredible tool called Google. That interruption brings you no value. It takes value away from your life for something the person was capable of doing themselves.

When I go back to the example of Google SRE and pager duty. While it may be interesting, from a monetary perspective, to interrupt people when there's any possibility of an outage at Google, if you're paging somebody every 30 seconds or so, eventually, you're going to get pager fatigue. They're just going to stop answering their pagers because the signal to noise ratio is going to be simply too low for somebody. When you're interrupting people, think of the signal that you are bringing to that person versus the noise that you're bringing into their life. If you're bringing noise into their life, you are disrespecting their time.

Speed, Cost, and Commitment

This is another very passionately held subject for me. When you're developing code, imagine you run in a world where you've agreed you're going to submit code in 200 line blocks, or a fairly low number of things so that you're not overloading people. It takes you about an hour maybe to write 200 lines of code. It then takes three days for somebody to send the first review back for that code. That review needs more work. Then you write some more code, so that's another 20 minutes. Three days later, they come back and go, "That's ok." The dominant amount of time required to make that change is not in you doing the work, it's in the feedback cycle to get that to the next stage. High performing teams know this, and they commit to each other to respond quickly and to run through these decision making things as quickly as possible.

Think of it from a company perspective, have you ever been in misalignment with another team in your company, and you pour a month of your life into arguing a particular course of action. Until eventually, one group of people just says, "I just don't have the energy for this conversation anymore, just do what you want." They're not really committed to it. They've just given up. That month of emotional energy you just poured into that decision making has just been flushed away. It's wasted. How do you get through that decision making loop as quickly as possible? One of the roles of a leader is to be very clear about how decisions get made, and to make sure that they happen in a timely, constructive, and inclusive manner. If that is not happening, then people are not committed to decisions which are made. They will still secretly sabotage each other afterwards. Everything grinds to a halt.

Investing Time in Each Other

What you do see when teams behave well is a set of behaviors, which is quite uplifting. They're responsive to each other. They are available when people need them. It's not like schedule a meeting for a week's time because everyone's calendars are full of recurring status update meetings. They say thank you for people's time. One thing I had at one of my teams at Google was we had a lot of new grads. Coming to Google where your code was peer reviewed and there are readability standards, and other things that you had to go through, was new to a lot of the people joining the team. It became quite adversarial, initially. It's like, "Why are you reviewing my code? Just accept it and push it through." That's not a good way to be. We agreed that actually the person who has given time to review your code has given time, their most precious gift of all. If someone's giving you a gift you say thank you. Before you get into your diatribe about why yours is the only canonical Python idiom, maybe say thank you for reviewing my code. The tone of those conversations changed overnight, because people realized that somebody had invested in them. In fact, research shows that if people don't say thank you for you doing something, you are half as likely to help them in future. That's pretty terrifying.

They volunteer to help each other. One of the highest performing teams I ever managed, any time one of the team was going through a launch, everybody else would drop what they were doing, and make sure that they had the support to go through it smoothly. Rather than one person having to stay until midnight, worrying that they were about to bring down everything. They've left five hours earlier, and they have that safety net because they were all invested in each other's success. They had the highest promotion rate of any team I'd ever seen, 45% a year. That's insane. When they spend each other's time they spend it respectfully. They spend it well. If you're not seeing those behaviors in your team, if people are siloed off with their headphones on refusing to talk to each other, and only doing code reviews at the end of the week, you're not having an environment where people are going to be high performing.

Here are some simple rules for a social contract for respecting each other's time. The teams which invest in each other achieve more. A victorious example from earlier with the data scientists and the software engineers, when they realize they could help each other and accelerate each other's own efforts. That is what we want to see. That is the team which is greater than the sum of its parts. Understanding the gift of time. Do not underestimate how valuable this is, particularly as you get older and you have less of it left. The misuse of time destroys trust faster than nearly anything else. If you want to move faster, reduce your decision making and feedback loops, compare them down. One of the nice anti-patterns when you screw up this feedback loop or cycle is people start to behave in antisocial ways to work around the problem. This happened to me, somebody sent me a 20,000 line change list, Thursday evening, it said, "I need to commit this by tomorrow, so can you just approve it?" Computer says no. I have some concerns with your code, 20,000 lines. First of all, this is going to take me about two weeks of time to give you an adequate review. You don't have the time to make any corrective changes to it. This is Python and you have no unit tests. Banks also know. When the system's not working people find novel ways to make it even more broken. Finally, interrupts. Only do it when there's value. As a manager, there is a temptation. You need some information. Your boss has just asked you a question. You can ask someone, can you just answer this for me? They will answer this for you. They'll stop working on the thing they were working on, which hopefully, was the most important thing for them.

Being ruthless about time. One of my old tech leads was insanely ruthless about time and about meeting time well. We used to have a weekly team meeting where people would demo things, and we talk about what we were doing. More importantly, why we were doing, and the impact it was having. We didn't always take the time required for this. At the point the meeting stopped being useful, he'd just close his laptop, get up and say, "We're done here," and start walking out. This was not good for my ego. Actually, it was positive on a number of levels. First of all, he has chosen the most effective use of his time and he is exercising that right. This is a good thing. Second of all, he's showing that authority can be told where to go, which, while I didn't want to encourage too much of, is actually positive from a perspective of building psychological safety. From the other side of psychological safety, the fact that he was so direct about it made another group of people feel uncomfortable. Then we had the other conversation of how would you do this in a way which was inclusive for the whole team and allowed them to grow from the experience. Everybody won apart from my ego, which I'm still not over.

Prioritization with Eisenhower's Matrix

This is a life changing piece of magic. For the last year of my life, I've spent a lot of time coaching people at director or soon to be director level. One of the common threads which runs through their existence is there are not enough hours in the day to get stuff done. The more senior you get, the more demands on your time grows. In fact, it grows exponentially. This is Eisenhower's matrix. You write things by how important they are and what urgency they are. If you want to understand how broken your life is, you can get a team to write down all of the tasks and responsibilities they have, and put it in one of these quadrants. Depending on which quadrants they're in, you can tell them fairly quickly where the problem lies. First of all, anything in the top right corner, if it's urgent and important, it's a crisis. If all of your things are in crisis mode, people are going to burn out pretty quickly. If things are urgent, but not important, they are a distraction. The problem is we tend to work on the things where people are noisiest. In a situation where people have got lots of low important high urgency requests, where they just are impatient for answers, typically, what happens is we do the things which are in distraction before the important things which are not urgent. Then what happens is the important things which are not urgent, become urgent. Now rather than working on the things which are highest importance to us in a deliberate and controlled manner, we are now doing them from a reactionary panicked manner, which means the quality of work is going to be less. Understand where things sit on these quadrants. Ignore the trivia. Admittedly, if you're just ignoring something someone's asked you to do, you should probably tell them about it as a courtesy, but you shouldn't be working on these things. You should only be working on the things which bring the most value at any point in time. High performing teams know, what are the most important tasks they could be working on?

Understanding Value and Cost

The way teams know, what is important? What problem are you working on? If you want to find out quickly, whether an organization is aligned around what they're trying to achieve, you ask them, what problem were you trying to solve here? When you get n different answers, you know that nothing's going to get done because you're all going to be pulling in different directions. What is the value of doing this? It might be fascinating to build a machine learning model to determine the correct temperature of coffee in the micro-kitchen at all times based upon flow and the number of people who are going to need coffee. Whether that is aligned with what the company needs to achieve is highly debatable. Lastly, who do you need to do this task with? Who are the people you have to align with and work with to get things done? Because this is the overhead on how much context sharing and how much communication you're going to have to do.

Context Overhead

In fact, the context overhead of communication is another cost in terms of time. If you have 8 people in a team, so a 6-person squad, engineering manager, product manager, 36 connections between them. The overhead of keeping all of those people in sync across all things at all times is astronomical. The perfect unit of work, in terms of context sharing, probably about three people, no less than two. Because anyone working on their own is a fragility in the system which doesn't survive the first holiday, or worst case scenario, bursts it, and that has also happened. Any more than four and the cost of them interoperating is also going to be too high. What happens in a team which is struggling is you wind up with the paralysis anti-pattern of everybody is involved in every single meeting and every single decision. Getting eight people to agree on anything is difficult. You may not want to pay that cost. Get people to talk about what the ideal unit of work and collection of people is going to be. It doesn't matter if you break up your team to do it. In fact, you're likely to be a member of multiple teams, anyway, within your organization, because you might be part of a guild. You might be part of an initiative, which spans a number of teams. You might be part of a tribe. You might be an engineering manager, and you have your engineering peer group, and also another team that you're part of. You want to minimize the size of those teams, because if you're spending all of your time sharing context, you wind up coming up with increasingly convoluted and painful ways of trying to make sure everybody has all context at all time. Because the cost of missing context is very high in some cases. You wind up spending all of your time sharing information rather than getting things done. You want to keep your process and overhead to a minimum so that you can be making progress with the most time as possible.

There's also the difference between deliberate use of time in terms of sharing context and serendipitous. Back at Google, the famously free food is given out to people. Actually, the value to Google of those meals is beyond any number they could spend on actually giving people food because teams go to lunch together. You have a group of engineers in a room, they talk shop. This is the reason why NASA stipulate in their contract, because they make duplicate systems of everything, that not only do they choose companies from different sides of the country, so they're less likely to talk to each other. Part of the contract is that you can't talk to the other company working on the other component. Because what happened is, they used to take people from the East Coast and West Coast, and there was an aeronautics conference. Two people working on the same guidance system met in the hotel bar. They started talking shop. They were both wrong in the same way. They went off and built the same systems. The rocket took off, the first system started failing. Switch over to the backup system. Backup system continued failing, rocket turned into a big pile of debris falling from the heavens.

You want to make sure that people are talking shop because this is where you find out that somebody in another team is working on the same thing as you, as early as possible. This is where you find out that the problem you're running into, somebody has solved before and can short circuit the solution for you. This cheapens what you're doing. Having a way of having serendipitous conversations which stimulate people coming together, not necessarily with a definite purpose, is worth the investment. If you're only working on deliberate plan things you miss out on this opportunity. The larger your company gets, the more that is going to hurt you. I have another example of two teams at Google who were working on the same problem. They found they're working on the same problem. They used to go to each other's launch review meetings to torpedo each other's launch so they could be the first person to launch that feature. Not necessarily the place you want to get to.

Minimize Waste

Good teams minimize waste. You can ask the question, what are we doing to fail quickly? If people can't answer that question, they're probably coming up with waterfall plans where it's just assumed everything is going to work. Do not underestimate the cost of change, both in terms of time and emotion to people. Another team I inherited. I inherited them, and from the previous two years, they'd had their goal cancelled and changed every six months. One of the first acts I had as their manager was to give them a new goal. I was not the most popular person in that team. Actually, seeing the effect that had on them was astonishing. First of all, when they had been told to cancel previous goals, they hadn't been allowed to delete the code from the code base. They were still on the hook for supporting services that they weren't allowed to go and spend time fixing as the infrastructure changed underneath them. This was taking about two person days a week of effort just to keep the lights on, on these things. Second of all, if you think that your work is going to be thrown away in six months' time, or just stopped, you have no incentive. You're not committed to getting things done. You're not committed to high quality. You don't really care because it doesn't matter. It took a while to work through the implications of that. In fact, the promise I made to them upon the fifth change was, first of all, you're going to work on the goal that I am most excited about. You have the most high profile thing I have, which also means you deal with me a lot. There are downsides to this.

Second of all, if they change your goal in six months' time, I'm just going to quit on the spot, because this can't happen again. Even then, it took a year for any trust to regrow in that relationship. It's incredibly painful because when you change it's not just a case of, "Tomorrow we're working on this." You have to disentangle yourself from the previous situation. People might have careers which are based upon a feature. They won't get promoted unless something's delivered. Their personal interest is not aligned with what's happening. If you've done nothing for six months, we'd still be in the same position except worse because you have to support what you wrote and you can't make it better. Also, think about the skills that you need in order to cut down on waste of time. Most companies have 360 feedback, and promo processes. Every 6 to 12 months, everything stops for a month, while everyone tries to figure out how to do that in a way which isn't going to offend their colleagues. We're crap at giving feedback. If you're spending two weeks of your life writing feedback, because you're not sure how to give it effectively, that's not a good use of time. You could spend the day learning how to give feedback effectively and get everything done in an afternoon. Surely, that's a good investment of time. Writing technical design documents, also, we're not great at. Writing emails. Have you ever written an email which is 5 pages long and you've polished it to the point where it gleams in the sun making your point? Then no one actually opened and read it? People don't read email longer than about two paragraphs. How do we allow people to write more effectively so that the people reading it can make a decision sooner rather than having to consume more information? We are constantly beset with too much information in our day jobs. If we're better at sending it in condensed and useful form for each other, we save everybody time.

Being ruthless with time is about working on the highest value things at any point in time. It's about being willing to say this brings no value, and to invest your time in something which is going to bring you value. It's about keeping something small. It's about not having everybody in every single situation even though that feels like the inclusive things to do. It's about communicating directly with people so that you're not having multiple context hops. Or, you need a decision, you talk to your manager, they talk to their manager, they talk to their manager. Then they talk back down. A week later you hear what the decision is without any of the context associated with it. Those things are crippling to the productivity, happiness, and effectiveness of teams.

Anticipate Problems

Lastly, great teams anticipate problems. They are able to deal with ambiguity in a way which seems almost magical. We know that the cost of resolving a problem versus the time required to detect the problem rises exponentially, and yet we still build these massive waterfall charts where we do the easy things first. Then the hard things we defer until the end of our project. We still plan for the golden path where everything works out fine, even though history tells us that every time we do this, we have a really bad time. We still spend the first three months of a six month project, blissfully happy that everything is going well. Then like somebody trying to hand in their university homework, cram it into the last few nights and burn ourselves out. We still do this. In fact, part of the problem is plans. This is a great quote, "Your plan is wrong." I can say that with a high degree of confidence without even looking at it, because no plan of any complexity can possibly account for all of the things which are going to go wrong along the way. People will get sick. You'll be adopting a new technology which you haven't necessarily understood all of the implications of. Requirements will change. The law will change in some cases. The reality is the act of planning to understand the shape of what you're trying to achieve is an incredibly powerful activity because it gives you a rough feeling of the shape of what you're trying to achieve. In its worst situation, a plan is deeply disempowering for a team.

Example Plans

I'm giving to give you a couple of examples, one which went really badly, and one, which went well. Another team I had, they were working on a large scale migration from one system to another. They had a multi-hundred line spreadsheet of all of the tasks, which were required to get from A to B. Against each task, they had a percentage done. Every week, 15 people for an hour and a half got in a room, and they were asked individually, what percentage are you through this? Eighty-three percent, that's good. That's great. The next one. It was a month before the project was supposed to be shipped, everything was on track. Three months later, the project hadn't been shipped, because they weren't talking about the outcomes they were trying to achieve. The project plan had become the outcome. It had become about showing that the plan was green and on track, as the thing they were trying to achieve rather than focusing on the actual problem they were trying to solve. For the people working on this, this prevented them from actually coming up with more intelligent solutions to the problems in front of them, because they needed to fit them to the actual plan of delivery that they were working against, rather than trying to understand the problem and the context they were operating against. When we run the retro for that project, people had PTSD from filling in this spreadsheet. It was like, "I never want to go back to this place. Please don't make me go there." Like, "It's working out. Everything's fine."

While planning is great, understand that your plan is subject to change. The more complicated your plan, the greater the amount of time you're going to spend correcting it when it does change. Because a plan which you make six months ago, and has changed, you don't update, is equally harmful. Therefore, if you're thinking about the time you're investing in keeping your plan up to date, this is also time you could be spending on something else. A good rule of thumb is use the smallest amount of process possible in order to be effective. Anything more than that is just vanity for the people running the processes. This is about, the plan is a tool to solve a problem. It is not the solution in and of itself.

The other plan is, somehow I volunteered to run the GDPR response at Google for a fairly large product. At the start of this project, we all got in a room. This is a problem. This is part of Google Maps. To give you an idea of the complexity here, Google Maps is built up of maybe several billion entities each comprising of up to 1000, or several thousand data points gathered from about 100 different sources, none of which are actually authoritative. Some of which Google doesn't actually have the permission to use past a certain point or for certain purposes, but given by lots of different people. It is a privacy nightmare understanding what data you own, what you have the ability to access, and what people should have control over. In fact, we triggered a large number of gray areas in the GDPR regulation where our lawyers just went, "I don't know. Just do what you feel is the right thing." As long as we've documented it, we can show good intent. This was the situation. The timescale was non-negotiable. Being an employee of Google meant we were pretty much guaranteed that one of the first companies who were going to be knocked on the door of by the European Union who do like fining Google, was going to be us. There was no real flex in getting things done.

Our plan was, everything we're doing should be on the assumption that we're going to finish this three months early. We're going to work on the assumption it's all going to go wrong. Rather than trying to plan all of these things out in advance, we're just going to accept this whole thing is broken. Along the way, we're going to have to ask all of the hard questions upfront, because it might take weeks in some cases to get an answer through lawyers, or through the EU councils just to have a sense of what we're doing here. It wound up being delivered about a month early. If we had planned this the normal way, there would have been a potential for a fairly large fine along the way here. When you are planning towards a non-negotiable deadline, work from the basis that everything is going to fail.

Rules for Planning

In fact, some rules for planning. If your plan does not include the ability to cope with your inevitable failure, it is wrong. How do you plan to fail as cheaply as possible, and as early in the process as possible so you have the opportunity to solve things? One of the conversations you never want to have as a software engineer with your management or the CEO of the company is, "We were going to launch today. We're actually not, and we don't know when we're going to be ready to launch." Those are not enjoyable conversations to have. The sooner you understand that your plan is wrong, the sooner you're able to align your stakeholders with that and have an adult conversation about what you drop in terms of scope if the deadline is non-negotiable. Or, how you change the team dynamics to actually deliver on things.

Your plan is not free to maintain. Make it as cheap as possible. Make it as meaningful as possible to maintain that plan. When you're talking about delivery of tasks or milestones. What are the things preventing us getting a stand is a much more empowering conversation than what percentage are we through this? That might be something you ask as a sanity check. If it's the only question you ask, bad things are going to happen. Your plan will become the outcome in that situation. People are very good at delivering outcomes. It does not lead to the delivery of high quality software.

Finally, and this is to reinforce the "Accelerate" book, how quickly you can recover from failure also determines the level of risk you're willing to take on in your plan. Because if it takes you a month to change something in production, after an error has been detected, you probably want to catch things earlier in the process and invest in that rather than assuming you can just fix things on the fly. If you're developing an operating system for a nuclear submarine, for example, where it may not surface for six months to get your software update over the air. You are going to be much more defensive in your approach to detecting problems early.


The thought I would like to leave you with is from Marcus Aurelius. Time is the most precious thing that we have. We should be savoring it. We should be endeavoring to be our best selves both individually and collectively at all time. If we are not making the best use of that we are not fulfilling our potential as human beings. The way we use our own time and other people's time is either empowering or limiting on our ability to fulfill that potential.


See more presentations with transcripts


Recorded at:

Jul 07, 2020