Introducing "20% time" at a workplace [closed]

Question

20% time it's the culture of an employer allowing it's employees to spend 20% of their time working on projects that they find interesting - it may be inventing a new app, or improving an existing process, etc. Some people may know this as skunk work, however that term may not mean anything (or something entirely different) to you.

There are many documented cases of great products being born out of 20%/skunk work at a company. It seems like a win/win situation; the company potentially gain a great new product or application, and the developer has the opportunity to flex his/her creative muscles and innovate.

I tried on numerous occasions to introduce some form of 20%/Skunk working at my previous employer with no success.

How can I better justify it to management? What's the "right" way to approach this kind of work arrangement?

Answer 1

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

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.

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.

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 N = rho^2 / (1-rho).

(Where 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.

PRACTICE

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 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!
• 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.

ANSWERS TO QUESTIONS IN THE COMMENTS

Dan, you got that right and accurately described the mistake made by many. 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. An organization does have influence over both processes; matching capability and demand is one of the hard problems addressed by the lean software development body of knowledge. Utilization is one of the indicators how well this problem solved in an organization. Slack emerges as your lean initiative progresses and you remove waste from the value stream. But if you mandate 20% time, you end up in the same utilization trap with less available capacity.

Kim, it is still partially a culture thing. The closest cultural reference I can think of is the synergistic level of the so-called Marshall model of organizational change. It emerges at the end of successful lean transformations or is present in organizations built lean from the start. (Here's a link to Bob Marshall's white paper (PDF).)

REFERENCES

The above logic is well supported in the software engineering literature. Mary and Tom Poppendieck hinted at it in their 2006 book Implementing Lean Software Development. Donald Reinertsen in his 2009 book Principles of Product Development Flow (Chapter 3) gives thourough treatment of this subject, with formulas and graphs.

Answer 2

Fourteen months after I wrote this answer, I came up with a much better one.

I haven't worked in a place where such works were officially recognized. But from my conversations and attempts to learn about this practice, I found this - well, mostly what the "20% time" is not:

• it's indeed a culture and not a policy
• it can't be decreed by the senior management
• it can't be instituted by a committee of developers
• it is not 32 hours on this and 8 hours on that

Answer 3

"Skunkworks" isn't the same as 20% time. 20% time is as you said -- time the developer chooses on his own what to work on. Skunkworks is totally different. A skunkworks project is a high-value, high-cost project worked on by a team (often a splinter team of gurus) that is not reported on to upper management, and the team decides on their own how the project should proceed without management direction. These projects are often motivated by a tactical or business need to get something done, but there's no room in the budget for it. If something has to get done, it gets done -- budgets be damned.

I managed a development team where I implemented 20% time. Or tried to, anyway. I had approval of my superiors, so that wasn't an issue. The problem was that the team was too small and too specialized. Whenever problems came up that needed immediate intervention, the 20% time was bumped. This ended up happening very often.

I also found that some of my developer's found my lack of direction unsettling. Even though I said "work on anything you want, so long as it's programming-related," they still had a hard time accepting the "anything" part. They thought that some projects would be better than others, so they inevitably worked on low-level implementation requests in the main product, things like that. I wanted them to branch out and grow, but instead they dug deeper in to their main expertise.

I would do it again, but I would expressly prohibit working on the main product and I might start them off with some ideas to choose from to get started.

Answer 4

I'm working for a start-up that has implemented the 20% policy. This is my first employer to do this, and when he brought it up at the job interview, I was really surprised, as most other employers were trying not to "waste" a single hour.

I joined the start-up when it was formed, and for almost a year I was the only developer. I spent my 20% with basically a couple of things:

• Reporting/fixing bugs in random open source projects – this can be as small as forking an interesting project on Github & fixing a few typos in the docs.
• Writing open-source "stuff" – things like programming challenges, just for fun.
• Going to conferences and sprints – every few moths I'd go to a sprint where I can work on projects (some of which might be used by the main app, others not) and gain some experience. There are a few libraries that are used by our app and by apps developed by other companies who send developers to conferences, so it can be seen as a direct benefit to our company.
• Learning new technologies – this is how I learned Go, even though we don't use it in the company. This is especially encouraged by my employer. Lately I've been following some of the Stanford free on-line classes.

The times are not measured precisely, it's definitely not 32+8 hours, sometimes there are urgent things to do when there's just not enough time to cut off that 20%, other times I have more time to spare.

I'm working remotely, and we use 37signal's Campfire chat to communicate and to loosely track each other's presence, and these hours are tracked as "working" hours, I'm logged on to the chat and available to co-workers, though making it clear that I'm not working on our project right now.

Answer 5

From my small experience, a lot of our projects actually started in this fashion. We had free time and bandwidth to take on new projects, we got together and came up with potential cool/forward thinking ideas for our department. In our spare time we developed a prototype and once it was fairly polished, presented to upper level and usually they see the benefit.

It seems to me that upper level knows what they want if they see it but does not know they need/want it until they see it. Prototyping has allowed us to create our own projects, propose them and then once approved divert more time to them to complete.