The long-time readers of my blog may remember this old post: The Elusive 20% Time. It turned out to be quite popular as people revisited it, tweeted it and struck conversations about it for a long time after I posted it. Its text will soon appear as my contribution to the upcoming book by Lisa Crispin and Janet Gregory, More Agile Testing: Learning Journeys for the Whole Team. For the new readers, here is the updated text (that will be included in the book), shortened, cleaned up by copyediting and less software-centric.
The topic of 20% time has become popular in creative industries in recent years. Many have heard of companies that have 20% time or know someone who works there. One example is Google, where engineers 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. Those who have tried to introduce 20% time in their workplaces found it surprisingly difficult. So, how can we do it? What are the dos and don’ts? Is there some theory behind this practice?
The main reason for 20% time is to keep the average capacity utilization at 80% rather than at 100% to build in slack time. We can think of a knowledge-work organization as a system that turns requests into delivered products and services. We can then model its behaviour using queuing theory.
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. But, on average, the queue size looks like this:
The average queue size remains low while utilization is up to 0.8, then rises sharply and goes to infinity. We can understand this intuitively by thinking about our computer’s CPU: when its utilization is low, it responds instantly to our inputs, but when a background task pushes its utilization close to 100%, the computer becomes frustratingly slow to respond to every click.
The slack – the gap between the utilized and full capacity — keeps the system responsive. So, for those who want to have it in their organization, several practical conclusions follow immediately – and they are about what not to do:
- Cost accounting (engineers’ time costs X, but the company may not be able to afford it). The economic benefit comes from reducing the cost of delay.
- Setting up a 20% time project proposal submission-review-approval system
- Tracking the 20% time by filling out timesheets
- Using innovation as a motivator for the 20% time. 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!
- Relying on the 20% time to encourage creativity. Saying you’ll unleash your creativity with 20% time begs the question why you’re not creative enough already during your core hours.
- Allocating the 20% time to a Friday every week…
Those are All Don’ts, Where Are the Dos?
OK, what about doing it right? Let’s answer with the best question heard while discussing this subject with practitioners: “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?” Right, “80 is the new 100″ highlights the main problem with the attempts to mandate the 20% time without understanding the theory. You want to escape the utilization trap, not to stay in the trap and allocate time differently. Utilization depends on two processes: the arrival process (demand) and the service process (capability). You can’t really choose your utilization. It is what it is because the processes are what they are. You can, however, work on the processes by improving your organization’s delivery capability and shaping the demand. As you make progress, slack will emerge.
Maybe I’m dense, but I missed the actionable advice in this pair of articles. Both have a long list of Don’ts. But, when the Do sections came around, they were still 80% “here’s a common trap”. I.e Don’ts.
Finally, both finish with a single sentence of positive advice. This first says “you need to change your process.” For example…? The second advises “improving your organization’s delivery capability and shaping the demand”. That’s a start at least.
I think you have something interesting and valuable to say on this topic. But, I have only read these two articles on your site. So, if the positive advice I’m looking for is elsewhere, I’d appreciate a link. Otherwise, I hope to hear about a third article in this series where you get around to spelling out the Do’s of 20% time.
Cory, sorry for the long delay with response – I kind of neglected the blog in the last couple of months.
All “don’ts” are actionable guidance, just like a dead-end sign at an intersection.
In most service businesses, there are basically two competing forces. One is your set of capabilities to deliver to your customers and meet their expectations. The other is the demand placed upon your organization from the market. And yes, if your business is a company developing some kind of technological solution, then the process of developing and delivering a stream of features is a service. And yes, even if your delivery process delivers only to the internal customers within a company, it can still be modeled the same way.
In order to succeed, you have to work on improvements from both sides. One one side, continuously improve delivery capabilities. On the other side, shape the demand. If you can deliver somewhat faster than the market demand, you will realize some amount of idle time. And if your situation is the opposite, demand overwhelms capability, then your system is unsustainable and collapses eventually.
Improving capability and shaping demand is hard work. You have to think in your context. Simply cutting your productive hours by 20% will not do the trick.
To look for examples, start with an independent coffee shop in your town that somehow survives in business, even though it has to compete with Starbucks. Small businesses like that can illustrate the concepts I just commented on, yet give you no temptation to copy any practices.
Pingback: The Best of 2014 | Connected Knowledge
Thankss for posting this