The Elusive 20% Time

The 20% time has become popular in the software industry in recent years. Even though most programmers don’t work at companies that have 20% time, most have heard or know someone who works at a place like Google, where programmers spend 80% of their hours working on what the company requires them to do and 20% on their own projects. Or so we have been told.

A shop across town is doing it and now we want to do it too. Many programmers have tried to introduce 20% time in their workplaces and that proved to be very difficult. So, how can we do it? What are the dos and don’ts? Is there some theory behind this practice? I want to summarize answers to these questions in this post and hope programmers find it useful.

queue size as a function of utilization - rapid rise after 0.8

The main reason for 20% time is to keep capacity utilization at 80% rather than at 100%.

Amazon book cover

You can think of a software development organization as a system that turns feature requests into developed features. You can model its behaviour using queueing theory. Using queueing theory to understand how responsiveness of a software organization depends on its utilization is presented thoroughly in the Chapter 3 of Donald Reinertsen’s 2009 book, The Principles of Product Development Flow. The same logic can also be found in the popular 2006 book by Mary and Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash. It has an example of how Google achieves greater effectiveness by avoiding 100% utilization. I recall having a discussion with a colleague after reading that book – Google’s effectiveness could also be due to the fact that all Googlers we both knew seemed to spend all their waking hours inside Google. We were not 100% sure about the utilization argument. But I read Reinertsen’s book later and it became abundantly clear.

So, programmers thinking of establishing 20% time need to understand the theory behind it.


If requests arrive faster than the system can service them, they queue up. When arrivals are slower, the queue size decreases. Because the arrival and service processes are random, the queue size changes randomly with time. The mathematically inclined can ask about this randomness: there must be some probability distribution, so what will the queue size be on average? Math (queueing theory) has an answer to that: if both arrival and service processes are Markov, then:


where the Greek letter rho is the utilization coefficient equal to the ratio of service and arrival rates. If the processes are non-Markov, the math is more complicated, but doesn’t change the conclusions.

If you plot this function, you can see that the average queue length remains low while utilization is up to 0.8, then rises sharply and goes to infinity. You can understand this intuitively by thinking about your computer’s CPU: when its utilization approaches 100%, the computer becomes unresponsive.


The economics of software development is such that software companies incur big costs when their queues are in high-queue states. This includes missed market opportunities, obsolete products, late projects, and waste caused by building features in anticipation of demand. The 20% time is thus the scientific answer to the problem of optimizing economic outcomes: avoid high-queue states by avoiding utilization ratios causing them. It is essentially the slack that keeps the system responsive.

Several practical conclusions follow immediately:

  • if you’re considering 20% time and doing cost accounting (developers’ time costs X, but/and the company can/cannot afford it), you’re doing it wrong. If a company can give its programmers 20% time on the basis of cost, it can afford to give them a 25% across-the-board raise. It may have some explaining to do as to why it has been underpaying them so much for so long.
  • if you’re allocating 20% to a Friday every week, you’re doing it wrong
  • if you’re setting up a 20% time project proposal submission/review/approval system, you’re doing it wrong
  • if you’re filling out timesheets, you’re doing it wrong
  • if you’re using innovation as a motivator for 20% time, you’re doing it wrong. While new products have come out of 20% projects, they were not the point. If your company cannot innovate during its core hours, that’s a problem!
  • The 20% time is not about creativity. Don’t say you’ll unleash your creativity with 20% time, ask why you’re not creative enough already during your core hours.

Those Are All Don’ts, Where Are the Dos?

You may ask now, you’ve told us all these ways to do it wrong, what about doing it right? Let me answer with the best question I’ve heard while discussing this subject: “If 20% of your capacity is mandated to be filled with non-queue items, then you’ve just shrunk your capacity to 80%, and 80% is your new 100%. Right?”

Yes, “80 is the new 100” highlights the main problem with the attempts to adopt the 20% time without understanding the theory. You need to escape the utilization trap, not to stay in the trap and allocate the 100% differently! You cannot mandate the 20% time, because you cannot choose your utilization percentage, because it’s an output variable. It is a ratio of characteristics of two processes, so it is what it is because the processes are the way they are. So you can only do it the hard way – by changing the processes: the arrival process (demand) and the service process (capability). Balancing capability and demand – we’re basically talking about a lean transformation here or building your company lean from the start. As your lean initiative progresses, slack emerges. But if try to mandate 20% time, you end up in the same utilization trap with less capacity.

This entry was posted in hands-on. Bookmark the permalink.

21 Responses to The Elusive 20% Time

  1. Pingback: The Best of 2012 | Learning Agile and Lean

  2. Christian says:

    Great post. I’ve never thought of 20% as reducing the utilisation, in fact I’ve seen it as the opposite. I’ve often pointed out, based on Don’s work, how 20% time in various forms such as allocating Fridays is flawed. Thanks for the different perspective.

  3. javierart says:

    I loved how simply you linked the 80% utilization golden spot to the 20% time policy. After (not before) reading your post I thought it was obvious. You’ve made me connecting the dots. Thanks.

  4. javierart says:

    Reblogged this on Leannovation and commented:
    Great post on the relationship between utilization golden spot at 80% and the 20% free choice time in companies like Google.

    • azheglov says:

      Note that 20% is not exactly a policy, but a consequence of policies and ongoing system capability improvement. Doing it by allocation is a trap.

      • javierart says:

        I got it. It’s clearly stated on your post. It’s a consequence of improving your system to be working around the 80% utilization golden spot on core projects than people may have 20% to work on personal projects. Thanks.

  5. joejv says:

    Nice Post! I also addressed similar ways to get the 20% time on my blog, but never though to employ Queueing Theory:

    • azheglov says:

      Your post mistakes hack-a-thons and time allocation policies for innovation.

      • joejv says:

        Not really. Most companies in the tech industry have heard about the Google 20% time and some want to emulate it. The question is how. My post talks about ideas to get there within the Scrum/Agile framework. Hack-a-thons, as I stated, are not always for entrepreneurship, sometimes they can be used for refactoring, research, etc. That is simply one option to get to spend time on personal projects. In reality, even companies that implement a 20% time policy, don’t expect their workers to be idle. They are working, just not on project or company specific tasks. Again, good post.

  6. azheglov says:

    Joe, you ask the question “how” in your latest comment and also refer to the 20% as a policy. To answer the “how” question, the first step is to realize that implementing 20% as a policy is a trap. I also didn’t say that the workers are supposed to be idle for a percentage of their time. The intention is to maintain some low-cost-of-delay activities in progress, which can be preempted by higher-cost-of-delay work when it arrives at a faster rate. You also referred to 20% or 8% as an innovation benchmark. Innovation has to occur during the other 80% – the 20% is there to bring the results of the 80% to the market in a reasonable time.

  7. Pingback: Estimations done right - lastzero's software engineering blog

  8. Pingback: The Best of 2013 | Learning Agile and Lean

  9. Jasmine says:

    Hey very nice web site!! Man .. Excellent .. Superb
    .. I’ll bookmark your blog and take the feeds also? I’m glad to seek out numerous useful info right here within the
    put up, we want work out more techniques on this regard,
    thank you for sharing. . . . . .

  10. Very nice post. I just stumbled upon your weblog and wished to say that I’ve really enjoyed surfing around your blog posts.

    In any case I’ll be subscribing to your rss feed and I hope you write again soon!

  11. Hello, I would like to subscribe for this weblog to obtain latest updates, thus where can i do
    it please help.

  12. Pingback: The Still Elusive 20% Time | Connected Knowledge

  13. Awesome site you have here but I was curious about if
    you knew of any community forums that cover the same
    topics discussed here? I’d really like to be a part of group
    where I can get suggestions from other experienced people that share the same interest.
    If you have any recommendations, please let me know.
    Thanks a lot!

  14. Pingback: The Best of 2014 | Connected Knowledge

  15. Pingback: More Agile Testing > Introduction – Test Retreat

  16. Pingback: Os ilusórios 20% de tempo – TALKING ABOUT TESTING

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s