Ode to 20% Time
The perk of a healthier organization
20% time, the idea that every engineer gets one day a week to do whatever they want, is one of the most enduring, albeit often misunderstood, cultural cornerstones of Google. The practice has been hailed as the origin story of many successful products nearly as often as it has been called a myth or a long-lost perk. In my corner of the organization at least, it is very much alive, and I encourage taking advantage of it every chance I get. 20% time occupies a strange niche in the realm of the company’s corporate practices: it’s never been enshrined or codified, it just is. This also means that I, and every other leader in the organization, are its stewards, responsible for making sure it endures.
The way I like to explain 20% time to my teammates is: here is one day a week (it can be claimed in bigger chunks too) that you may use on things that interest you. Make sure you use it beneficially: it’s not vacation time, hobby time, or family time; it’s work time, but time that your manager has, by design, no oversight on. In my view, that is the most important aspect of 20% time: you may use it to do things that may have nothing to do with your day job. Your manager will not tell you what to do, but they also implicitly make the commitment that the contribution will not be ignored if something positive comes out of it.
I have worked on many 20% over the course of my career. I once noticed that many library maintainers had a difficult time getting their users to move off of deprecated interfaces as their libraries evolved. I decided to organize a company-wide ‘deprecation fix-it:’ a week-long event that introduced new tooling to flag deprecations, a leaderboard, war rooms and prizes. It was a great geek-fest, which turned into an interesting lesson in reward engineering: the event caused many library maintainers to accelerate the deprecation of interfaces they wanted users to migrate away from, which resulted in the total count of call sites to deprecated methods to actually increase, not decrease, over the course of the event. Lots of lessons learned, and for a Noogler like me, a chance to rub elbows with many of the amazing engineers that built and maintained the core of our infrastructure and tooling.
Another time, about a decade ago, I became frustrated trying to find the toll-free number for a company on their website. I realized that there were little incentives for a company to loudly advertise their customer service lines if they were a net cost to them. So I wondered if I could surface them directly in Google search. I sourced some toll-free number listings, set them up on a periodic ingest pipeline, built an index for them, a scoring function to match them up with queries, and a web frontend. Unfortunately, it never got past the stage of a demo because I lacked the time and expertise to get it to the next stage of integration. This is in fact one of the failure modes of 20% time: it’s often easy to get some of the way to a goal, but the last mile takes much more time, commitment and dedication.
My most recent 20% projects were to put together a deep learning lecture on Udacity, create a new Conference on Robot Learning, and work on protein crystallography. Time well spent.
But why would any leader actually want to commit to a practice that nominally could cut off 20% of their team’s bandwidth? Critically, not everyone wants to do 20% projects, and many of those who do are, well … 120% kind of people. So the math isn’t as bad as the naive calculation suggests, even if you believe the fallacy of measuring software productivity in people-hours. The value of everyone knowing that they may use that time is enormous however: knowledge that if for any reason, at any time, you have an escape hatch from your day job does wonders to psychological safety. A desire to escape your day job may not mean you hate it, it may just mean you seek a balance that the strict necessities of the task at hand can’t provide. For me, whose job would easily veer into spending 100% of my time in meetings, knowing that I can carve out significant non-interactive time during my week is almost a mental health necessity, and one that I can channel entirely into 20% projects without guilt.
For managers, 20%’s are a great way to take the pulse of your team. It is very difficult, once someone is locked into a particular role or function, to evaluate both their abilities and aspirations in other roles: do they love writing? Or tinkering with hardware? It’s also a useful early warning that something may be missing in their day job, or something may be going wrong. Choosing to do a 20% in itself is not a signal that something is amiss, but it can trigger a fruitful conversation about what opportunities are untapped in their current role. In fact, when a 20% becomes a 40% or a 60%, it’s a conversation you can no longer afford not having, because that’s when you know there may definitely be a problem.
As a recruiting device, having someone do a 20% on your team is a fantastic opportunity to vet a potential transfer. I try to have that conversation early on, because it helps set expectations in the right place. Looking at 20% contributions is a unique opportunity to look at someone’s ability to execute in the context of your own line of work: I have had several people transfer into my team who were on paper terrible performers, chiefly because they were in the wrong team or role in the first place, and turned around completely once they were in the right environment. Enabling this kind of mobility should be encouraged by organizations, because it opens up growth opportunities that would not exist otherwise.
For an organization, it is a subtle but meaningful way to keep management on their toes. Here is a permanent pool of one fifth of the company’s energy that can self-organize in any creative direction at any time. Knowing that every employee can vote with their feet, albeit in a controlled fashion, and direct a part of their energy where nobody can claim strong oversight means micromanagers can’t smother energy and ambition for long. It’s also a great way to unearth sources of frustration that it’s nominally nobody’s job to fix: for instance, our agitating to create a deprecation fix-it shed some spotlight on how difficult it was to keep pace in a forever changing software environment, and forced some policy changes, especially in regards to communication around these software API updates.
Bringing 20% contributors into a project is not always straightforward. The hosting team needs to go into the relationship with the right set of expectations: about half of the 20% engagements I’ve been involved in lead nowhere, often because people’s ‘real job’ comes calling. As a consequence, it’s important to make sure not to put 20%ers in the critical path of one’s work. But as a way to open up new frontiers, involving someone who wants to learn, bring a new perspective, and whose performance review isn’t on the line, can be a wonderful way to explore uncharted territory — or add that nice feature you’ve always dreamed of but never got around to implementing.
It takes a certain boldness to be willing to inject this much ‘unsupervised time’ into an organization, but that display of trust is also a powerful signal in and of itself that people’s interests and engagement in the company’s success are valued. High-performers in particular hate to be boxed-in, and when given the opportunity, will happily channel their energy to productive uses — albeit not necessarily the ones you’d expect. Providing a lightweight framework for these ‘side jobs’ is a great way to channel people’s creative impulses without sacrificing a team’s focus and overall direction. A lot of that time typically gets redirected to learning and personal development as well, fulfilling individuals’ need for growth and improving the team’s skill set at the same time. Important-but-not-urgent things, those with a knack for never landing on anyone’s quarterly objectives like code health and improved tooling, are also provided room to happen organically.
The overall benefit is a much healthier, self-regulating organization, one that has exploration and experimentation built into its fabric and cultivated as a productive and valued habit.
