Excellent write-up. Thanks, Elizabeth.
I'm a software engineer at a company that implements a "20%". Every couple of months, we have a one (sometimes two) week sprint for the 20%. As you've pointed out, it works out to be less than 20%, and many engineers choose to keep working on their primary projects to catch up on delivery dates.
In the weeks leading up to the 20% sprint, we create a collaborative table in which engineers propose ideas and pitch those ideas in a meeting on the Monday morning of the sprint. Proposals fall into two categories:
I find the 20% sprints very valuable. A lot of the time, there is work I would like to be done that doesn't fit well within "normal" priorities. I believe such work to be valuable based on my experience and knowledge. However, it doesn't have sufficient visibility from the perspectives of the higher levels. Therefore, this sort of work would never make its way into our everyday work without the 20% sprint.
Ironically, it seems to me that "agile" development took autonomy away from software developers, and "20%" gives it partially back.
- The gain in autonomy generally causes the improvements in morale and thus productivity that you’d expect (unless it backfires), but no one has quantified them.
My guess is that in cases where this is the case it can also carry over to employees who don't take the 20% time. Merely having the option to do so may increase morale.
Thank you for taking the time to publish this. It's kind of sad to see companies painting a picture of some kind of internal intellectual vibrancy or freedom or something when in fact it's more of a recruiting or morale gimmick, or is just dominated in practice by performance demands. I have the sense that utilization numbers are low because it's actually quite hard to formulate something compelling to work on for oneself, even absent any demands for justification or approval, and one of the reasons that people work at companies is to be given something compelling to work on (though this often isn't what actually happens).
Your post triggered the following thoughts in me:
At best you might hope that 20% time would harvest insights from "line-level" employees about (1) what tools could be built to improve their own productivity, (2) what features customers would like (especially when the line-level employees are a representative sample of customer base itself), and (3) what super cool things could be built that are just hard to understand unless you've pondered it over and over for years. Companies attempt to harvest and filter such insights (to whatever extent they really exist) through the ordinary reporting structure, but there are going to be some such insights that good but systematically fail to make it through, especially in category (3).
So we have employees who are doing a job that gives them, as a byproduct, some kind of insight that we want to get access to. This is really a lot like the problem of eliciting latent knowledge, in which we have some powerful machine learning system that has demonstrated competence in some domain (e.g. predicting the sensor-visible consequences of plans) and due to its competence in that domain we suspect that it has an internal understanding of something that would be useful to us (e.g. knowing whether its own sensors have been tampered with). This really seems like a non-vacuous connection to me. Interesting.
Interesting.
This doesn't cover my major issues with 20% time:
20% time when well-implemented can be decent. Having the ability for someone to go "nope, I know you keep pushing off the debug documentation for module X in favor of putting out fires because we can't debug module X, but I'm going to put my 20% time into fixing this module up into a coherent whole" is great, and often under-appreciated. Having that then shot down because we're currently too busy putting out fires because we can't debug module X rather defeats the point. Having that shot down after 5 days, meaning that instead of a single coherent debug document written by one person in a year of 20% time we have a Frankenstein mess put together by ten people each of which gets pulled off in five days because, again, the debug documentation isn't seen as important? Again, rather defeats the point.
My company wouldnt consider 20% time, but we do have a mechanism for new ideas. There is a fund of set size that you can apply to if you think you have an innovative idea worth exploring. Process is simple and structure of proposal needs to be "fast-fail" - it expects initial proposal will be focussed on feasibily and proof-of-value. Of course it is always over-subscribed but at least many things get to be tried. If first phase comes up promising you can get a lot more than 20% of time funded.
This is very interesting, thank you for sharing it.
I find the 5 day limits (without approval) quite insane. Even assuming that means 5 actual days (and not 20% of 5 days = 1 full day). Lets say you have an employee who has now put 5 days into their preferred passion project. You end it. They then put 5 says into their second-favourite passion project. The end result is an annoyed employee who has half-finished a train of side-projects and is still putting 20% of their time to one side from core duties.
My current work (university) is thankfully very flexible, so maybe I am seeing things from the wrong perspective.
- 20% or even 120% time has outsized returns for industries that have very high capital costs but minimal marginal costs, such that employees couldn’t do them at home. This was a big deal at 3M (a chemical company) and, for the right kind of nerd, big data.
May I ask for more detail on what this means? All I got from this is that since employees couldn't work from home (on weekends, say, as one might do in a software role), the net effect of 20% was that 3M got 20% overtime from employees for free. And that the returns on the 20% time were very significant because process improvement/intensification (a primary enjoyable skill of of 3M engg talent) has very high RoI in general.
I was approached by a client to research the concept of 20% time for engineers, and they graciously agreed to let me share my results. Because this work was tailored to the needs of a specific client, it may have gaps or assumptions that make it a bad 101 post, but in the expectation that it is more useful than not publishing at all, I would like to share it (with client permission).
Side project time, popularized as 20% time at Google, is a policy that allows employees to spend a set percentage of their time on a project of their choice, rather than one directed by management. In practice this can mean a lot of different things, ranging from “spend 20% of your time on whatever you want” to “sure, spend all the free time you want generating more IP for us, as long as your main project is completely unaffected” (often referred to as 120% time) to “theoretically you’re free to do whatever, but we’ve imposed so many restrictions that this means nothing”. I did a 4-hour survey to get a sense of what implementations were available and how they felt for workers.
A frustration here is that almost all of what I could find via Google searches were puff-pieces, anti-puff-pieces, and employees complaining on social media (and one academic article). The single best article I found came not through a Google search, but because I played D&D with the author 15 years ago and she saw me talking about this on Facebook. She can’t be the only one writing about 20% time in a thoughtful way and I’m mad that that writing has been crowded out by work that is, at best, repetitive, and at worst actively misleading.
There are enough anecdotal reports that I believe 20% time exists and is used to good effect by some employees at some companies (including Google) some of the time. The dearth of easily findable information on specific implementations, managerial approaches, trade-offs, etc, makes me downgrade my estimate of how often that happens, vs 20% time being a legible signal of an underlying attitude towards autonomy, or a dubious recruitment tool. I see a real market gap for someone to explain how to do 20% time well at companies of different sizes and product types.
But in the meantime, here’s the summary I gave my client. Reminder: this was originally intended for a high-context conversation with someone who was paying me by the hour, and as such is choppier, less nuanced, and has different emphases than ideal for a public blog post.
My full notes are available here.
Thanks to the anonymous client for commissioning this research and allowing me to share it, and my Patreon patrons for funding my writing it up for public consumption.