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?

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.
If this question can be reworded to fit the rules in the help center, please edit the question.

@Dan theregister.co.uk/1999/10/27/what_the_hell ;) It's a term used to describe "un-planned, developer initiated work" at a company. Typically part-time. Some companies allow their staff to spend a percentage of their time working on anything they like - sometimes that work turns into work the company can use, or a product to release.
–
dannywartnabyOct 7 '10 at 12:56

2

@danny That's not at all how I understand the term: you're describing Google's "20% time". I rather doubt that Lockheed's Skunk Works do anything unplanned. Rather, it's "a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects". (Quote from WP's Skunk Works page)
–
Frank SheararOct 7 '10 at 13:36

1

@SteveBennett: The extreme logical opposite of 20% time is 100% utilization, working in functional silos, high degree of specialization, accounting for time spent in each function, and lots, lots, and lots of waste.
–
azheglovDec 16 '11 at 1:10

5 Answers
5

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).)

Woah, nice answer. I had never considered that - always viewed it as a cultural thing. +1
–
Kim BurgessDec 15 '11 at 23:35

VERY interesting... One thing that I don't grok, though: Why the queue stays small up to 80% is because there's free capacity up to that point. 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?
–
Dan RayDec 16 '11 at 14:14

@KimBurgess: I added a comment to your comment to the Q&A at the end of the answer.
–
azheglovDec 19 '11 at 21:31

@DanRay: You got that right! I added Q&A at the end of the answer.
–
azheglovDec 19 '11 at 21:32

Thanks for your response. I guess it has to be a culture - you can't force staff to invent things. Also agreed that it can't be instituted by a committee of developers - my experiences certainly align with that, so I guess the question becomes where does this culture come from? Atlassian trialled this, so it must have been a management decision. Do you think this something that can only work if it's at the heart of a company's culture from it's inception?
–
dannywartnabyOct 8 '10 at 10:27

In case of Atlassian, the decision did come from the top, but I guess they had the right kind of employees, the developers who were ready for it. Still, this blog post: blogs.atlassian.com/developer/2009/02/… reports quite a few problems with their implementation and even though they said they'd continue their experiment, they haven't updated the public in more than a year and a half. I'm staying tuned.
–
azheglovOct 8 '10 at 17:52

"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.

Why was it a problem that they were digging more into their main expertise? It sounds like they were happy to implement stuff that (presumably) needed to be getting done, but wasn't. Not everyone will be passionate about trying new and innovative things all the time, and I think it would be a mistake to force that attitude.
–
Matt OlenikOct 7 '10 at 20:06

I wouldn't say it was a problem, exactly. I just think they worked on the product because they were reticent to pick something off-limits. This was partly because I didn't adequately explain that the eligible problem domain was everything.
–
John DiblingOct 7 '10 at 21:03

Really useful answer John, thanks. It's interesting that you found that the lack of direction and the relative freedom to invent work was a contributing factor to the 20% time not working for some developers, as it's at the heart of the concept. I guess some developers just need to be given a clear target in order to get the best out of them. I guess the culture could be "spend 20% of your time creating something, but if you can't, that's OK, maybe use the time to make something better - it doesn't have to be your current project".. ?.
–
dannywartnabyOct 8 '10 at 10:34

That's odd, I've first encountered the term "skunk works" in a book that described a high-value but low-cost project that started out as a secret pet project for one developer and later turned out to change the organization's direction completely.
–
SpoikeFeb 9 '11 at 7:10

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.

I think that's true to most organisations - i've certainly experienced in that past that showing cool stuff to management/marketing opens certain opportunities and creates new projects - yet any attempt and making this time 'officially' available for the pursuit of new and forward thinking ideas falls very flat, very quickly. You mentioned "spare time" - is this time outside of your working ours, or within? Also, may I ask, how big is your department? (how many devs, and how many get involved with this?)
–
dannywartnabyOct 8 '10 at 10:30

These projects are usually started in between chartered projects. Our team is a small team (3-7 developers). And it depends on the project who gets involved in it. Sometimes I do these things at home for fun if I want to learn a new technology, other times if its something I can prototype fairly quickyl without working most of the details out I will do just that.
–
ChrisOct 8 '10 at 10:43

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.

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.