Some thoughts on running successful teams at Google
A few strategies from a long-time Google engineer and manager.
Over my eight-plus years at Google, leading a fairly large and successful team, I’ve developed a set of principles that are core to my own approach to management. Since I’m about to leave Google for a startup, I thought now would be a good time to capture and share these ideas more broadly. The following notes are a slightly modified version of a doc that I shared within Google a while back.
(For context, I was the founding member and engineering director for the Chrome Mobile teams in Seattle and Kirkland, spanning four sub-teams in Chrome, with an emphasis on making the web great for the next billion users. The team consists of around 40 engineers, in addition to a number of PMs, test engineers, UX designers, researchers, and others. We built a lot of features in Chrome that are used by more than a billion people.)
I cannot claim to be some kind of management theory guru. I have found that the following principles have worked well for me, and the teams I have led. Caveat emptor.
Ownership: I think it’s important for a team to have clear ownership of its project, vision, and destiny. Not all teams have this freedom, especially if they are a small remote team connected to a much larger one. My teams were all based in Seattle, and given that Google’s headquarters is in Mountain View, this challenge is fairly acute. My teams have been fortunate to completely own their mission and technology, and to be able to make key decisions on their own. They have the flexibility to start up new efforts and invest in new directions (more on this below). I often see teams — especially remote ones — that are subordinate to another, larger team, and this rarely works well. A team needs to be in control of its destiny.
Having a clear (and flexible) mission: A team should have a clear mission, and that mission should be broad enough to encompass a range of approaches to solving some problem, rather than being narrowly focused on some specific technology. As an example, one of my teams at Google focused on making Chrome work well in offline and intermittently connected networks. Their first project was to build offline page support for Chrome, but the broader mission statement (of making the web work well in poorly-connected settings) goes well beyond that specific project and the code they produced. They went on to do many other things to make web pages load more reliably on poor networks, and that flexibility is key to sustaining the team identity over time. I think it’s important to define a team not by the artifacts it produces, but by the problem it is solving. All too often, I see teams whose identity is to build or maintain some software system. While building software is obviously a pretty important part of a team’s job, sometimes teams get overly focused on the software as an end in itself.
Accountability: I strive to foster a culture of quality and accountability on my teams. Quality is a big deal and we don’t let ourselves off the hook when something goes wrong. For example, bug priorities should actually mean something — P0 bugs should be fixed within a couple of days, P1 bugs within a week or two. That sounds obvious, but it’s surprising to me how many teams (even at Google) take a lackadaisical approach to this. I also take OKRs very seriously. Like most teams at Google, we write down OKRs every quarter, and score the previous quarter’s OKRs to reflect on ways we could have done better. One thing I am a huge fan of is doing a mid-quarter check-in on OKR progress. This gives us the opportunity to identify any course corrections before it’s too late. (You’d be surprised how often someone forgets to get started on an OKR, and the mid-quarter checkin gives them the kick in the rear.) I also feel that it’s not acceptable to repeatedly fail to make progress on an important OKR, or to keep kicking the can down the road quarter over quarter on some project. When this happens it suggests that the OKRs have stopped having any meaning.
Setting priorities effectively: I do not believe in committing to something that you don’t have the time or skills to do well. OKRs are assigned priorities, and I tend to use the following definitions. P0 means “we need to get this fully done this quarter or we’re toast”, P1 means “we should strive to get at least 70% of this done this quarter”, and P2 means “we should make non-negligible progress on this task this quarter.” Some teams also have P3 or even P4 OKRs, especially for things like stretch goals and side projects. I don’t mind the occasional P3 OKR for, say, doing some exploratory work on a new effort, but I often see teams use P3 and P4 for things they don’t really intend to make much (if any) progress on. Putting those things on the OKRs can make you feel good about listing them out, but if you know you’re going to get a low score on them, you should just drop them and focus your attention on the more important things.
Investing in the future: As an exception to my “no P3s” rule, I strongly believe in investing about 20% of a teams’ total time on exploratory and research work. At any given time, some number of engineers on my team are either spending all or part of their time on various exploratory efforts. Some of these are research projects, such as investigating a new technology or gathering data to support a new effort. Others are focused on building a prototype or demo of a new idea to get feedback. Some folks spend 100% of their time on research, but most folks spend somewhere between 0% and 20%.
Of course, not everyone can be working on the far-out, exploratory stuff. And some quarters we just have to hunker down and focus on more pressing needs and put the research work on the back burner. But keeping the innovation pipeline going is essential. It’s way too easy to allow a team to get bogged down by the routines of fixing bugs, cranking out new features, putting out fires. If you don’t protect some people’s time to figure out what’s out beyond the horizon, you run the risk of stagnating. I like to say that it’s not somebody else’s job to innovate — it’s our job.
Communication: I make sure that my team’s projects are well-communicated and easy to find within the company. Our team’s Google-internal website has a summary of all of our projects with links to more information on each one. It’s amazing to me how many team leads at Google fail to do this — it makes it impossible to tell what the team is really doing from afar. I think this is fine if you only care about interacting with your immediate team. Not so great if you want to help others in the company know what you do, or have the opportunity to spark cross-team collaborations. I’ve lost count of the number of times someone has stumbled across my team’s web page and reached out with an interest in collaborating. It’s worth it.
Being inclusive: I wish I had something pithy or unique to share when it comes to diversity and inclusion, but I there’s little I can say that others have not said more eloquently. It seems obvious to me that a team should be supportive of everyone on it and create the conditions where everyone on the team can thrive. I’ll admit that I have not always been great at this. Coming from an academic background, where a great deal of discourse is centered on challenging one another’s ideas, it took me time to recognize that not everyone responds well to a certain style of feedback. I’m a strong believer in Radical Candor, but it is not a universal approach.
