Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

I've read that Google's 20% rule is about encouraging fun and innovation.

How can my company implemented and manage a program like this?

A good answer to this question should also cover these sub questions:

  • What are the boundaries for that 20% of time?
  • What happens if I have to work 40hours to complete my project on time?
    Would I then expected to put in an additional 10 hours of "Fun" work?
    Can I just spend 16 regular hours the next week? If I miss a week do I just lose the 20% hours?
share|improve this question
4  
Very related: Today is Goof off at work day, a blog article on 20% time by Jeff Atwood. –  Rarity Aug 2 '12 at 13:56
    
Actually Google is moving away from the 20%. If you read their official pitches they don't talk about it any more, and it's not as encouraged as it was. –  DJClayworth Feb 14 '13 at 3:45
1  
Perhaps that is the reason they don't appear as innovative as they once were? –  Simon Apr 4 at 23:36
add comment

7 Answers 7

up vote 26 down vote accepted
+50

I can provide a little information on this based around how my company has implemented it and how we have struggled.

At my company we implemented it as a recruiting tool and as a way to keep engineers skills sharp. There are also some potentially interesting reasons to keep utilization from getting too high to better facilitate context switching. That answer also has several good guidelines around 20% time and some additional references that further support his point.

We are not basing what we do around the points mentioned there, but I do think it is worth reflecting on if you are trying to implement your own 20% time at a company.

We have a few basic guidelines around what people's 20% time can be used for. It should be something that generally contributes to the company (including to the culture we are trying to build) or to your own professional development. So spending time learning a new programming language is awesome, using the time to learn guitar is not.

We also hold regular presentations, and if you are taking the time then you need to also give a presentation as to what you were working on. This keeps the 20% time productive. Some things we have found 20% time especially good for:

  • Prototyping ideas or playing with technologies we aren't yet ready to put into production.
  • Keeping skills sharp.
  • Recruiting great people.
  • Provide an opportunity for engineering to build effective proofs of concept that can get product-level support.

As far as allocation, we've tried several different things.

Time Per Week

The idea here is that 1 day a week is dedicated to side projects. Essentially the "if you're allocating 20% to a Friday every week" approach to the problem. We tried this implementation first, and ran into several immediate problems:

  • Many interesting challenges are not conducive to working on for one day. It takes that long just to familiarize yourself with what you are doing.
  • If you were running even slightly behind on any given task, you didn't take it… which frequently meant that you never took 20% time. Rolling over was problematic, because frankly, if you are tracking it with a time sheet at that level something has gone wrong.
  • Not very predictable from a planning standpoint, because while Fridays were common they weren't universal, and you didn't know who would be taking it or whether they would actually take it.
  • It did help more with planning, because it helped prevent people from putting their personal velocity too high if they put in an automatic 20% buffer.
  • For the most part, it never got used.

One Iteration Out of Five

We worked for a long time off of two week iterations. So the next implementation of the idea was that you would spend one iteration out of every five working on whatever side projects. This worked reasonably well–substantially better than the previous version. Some considerations:

  • This made things very predictable from a product standpoint. You knew exactly what weeks you would lose and could schedule around that accordingly.
  • On the other hand, scheduling conflicts were common because a team would be scheduled for a release the week after and need to get mock deployments or last-minute testing done. So they would frequently find their schedule moving around, and they could easily disrupt someone else's 20% time because of the need for their expertise on the deploy or the code.
  • It didn't really help with the utilization problem.
  • Teams that didn't have perfectly synced iterations (none of us did) couldn't really effectively work together on larger or more interesting projects.

One Week Out of Five

Then we started moving to a kanban system and started thinking in weeks instead of iterations, so we transitioned between 1 iteration out of five to one week out of five.

  • Conflicts with deployments were more common (frequency), but generally generated lower impact since it was easier to block off a week than it was to block off two weeks.
  • Since everyone was working week-by-week, it made it easier to sync up with other teams.

Other than that it was very similar to one iteration out of five.

Time blocks per quarter

This is the current system that we are trying. The idea here is that you set up tasks for yourself on the kanban boards with the amount of time allocated to them that you get for the quarter. Time does not roll between quarters, but you can take it all up front or all at the end, or in smaller chunks as you see fit. This lets individuals and teams figure out what would work best for them based on their release schedule, and also to take time in more or less than a one week increment depending on their schedule, what they are trying to do, etc.

This solves a lot of the problems we encountered before, but it has the disadvantage that time has to be more closely managed and is harder to precisely predict. On the other hand, it can be had at a lower level of disruption.

share|improve this answer
add comment

I have experience working in organizations that implemented something like "20% time" (even if it was just "10% time") and it's something that I am going to be implementing in the company I just joined.

The answer to the question of how is "carefully". That's not meant to be a snarky response, but rather a true one to a broad question in which we don't know the details of your company. By "carefully" I mean:

  • with support from superiors, or at least a tacit understanding of what's going on
  • with consistency (don't implement the program and then take it away immediately)
  • by giving support to those attempting it (don't denigrate the work product, and celebrate the output)
  • with an understanding that in the beginning you might see less direct benefit (or outputs) for the projects to which people are officially assigned

This leads to the question you didn't actually ask, which is why do this in the first place? Understanding the "why" behind this will make these following answers to your sub-questions make more sense.

What are the boundaries for that 20% of time?

Whatever you want, that in some way enhances the company's products or its resources (e.g. you).

What happens if I have to work 40hours to complete my project on time? (etc)

If you don't have time to spend on something extra, don't.

If you look at the first line of the NY Times article to which you linked, it says "Engineers are encouraged to take 20 percent of their time to work on something company-related that interests them personally." Emphasis mine.

Encouraged. Not forced. "20% time" is not about "mandatory fun" or "extra work beyond your actual assignment". It is voluntary, and it's about discovering and encouraging motivation in the workplace.

It's worth noting that it's not something that Google invented -- the sticky note came about in the early 1970s because a 3M employee used his "15% time" to dream it up.

Daniel Pink, author of Drive: The Surprising Truth About What Motivates Us focuses discussion about employee motivation on three factors: the need for autonomy (desire to direct our own lives), mastery (the desire to get better at something that matters), and many examples of "20% time" or Atlassian's FedEx Days, which are 1.5 day events meant to foster creativity, scratch itches, get traction for radical ideas and (in the end) have fun, have at their core the desire to make happier, more motivated, and engaged employees with the understanding that the investment will pay off in better work during the other 80% of the time, if those are the things that work for you.

Back to the original question of "how does a company do this"? I return to my answer of "carefully", but would also add "with gusto!"

share|improve this answer
3  
This is a great answer! –  Rarity Apr 21 '12 at 16:01
add comment

I work in a company that considers itself a 'results oriented workplace', sometimes called 'results oriented environment.'

A ROW team rejects the factory model of employment in which managers and foremen are paid to ride herd on a factory floor of sheep like children who cannot be trusted.

[Aside: In the US defense contractors are pretty much forced into Taylorism by government contract requirements. This may account for the common huge cost overruns and frequent missed delivery dates.]

The factory model work environment is sometimes called 'Taylorism', after Fredrick W Taylor.

A software team working in a Taylor type structure could not implement Google's 20% concept, the time tracking alone would be very expensive and distracting. Since many, probably most, of the 20% projects never result in near term profits a Taylor style company would not continue the experiment for long.

I've never worked at Google, but I suspect they are a ROW type organization. I suspect that Google developers work with their team leaders to lay out a schedule of expected results, which takes in to account the developers 20% projects. I suspect that as long as a developer delivers results more or less according to the agreed on (not imposed on) plan there isn't any worry about how long someone took for lunch or if they spent 9 hours last week on their 20% project.

share|improve this answer
    
Chad - I edited the original question to allow for speculation, since otherwise only Google management could answer it. I hope it seems informed speculation, since my organization, while not having a formal 20% policy, allows employees a great deal of personal freedom to experiment and learn on company time. –  Jim In Texas Apr 17 '12 at 15:19
    
That's fine Chad, but as written the question is unanswerable by anyone other than a Google manager. The question should be worded in such a way as to allow non-Google employees to answer in some way. That means the answers will involve 'speculation', whether we like that word or not. –  Jim In Texas Apr 18 '12 at 16:47
    
"How can this be implemented effectively", when such a plan clearly has been should not be answer with "No you can't do that". –  Rarity Apr 21 '12 at 14:26
    
I am glad you mentioned Taylorism. There is a great documentary on YouTube about it, I will try to find it this evening. –  amphibient Sep 25 '12 at 17:50
add comment

I'm going to attempt to answer the following:

Or how could a software development organization implement a similar '20% project' concept that would be acceptable to management, customers, and employees.

As I see it, implementing such a thing in a workplace would require getting over several roadblocks. You have to realize that this a business decision and thus must be something sellable to senior management in business terms.

First, how is the salary of the developer currently paid for? If, as in the place I work, the majority of the developer time is charged to client specific projects, 20% of the time spent on non-billable work is going to be a tough sell. The money to pay those salaries has to come from somewhere and any proposal to do this will have to specify from where. I see three basic choices: the company takes it from current profits, the company raises the hour rate charged to the clients to be able to pay for it or the company pads the hours changed to the client by 20% (which may or may not be legal). If you do not do client billable work, then the first choice is your only choice. If you do then the second may be viable if (and it's a big if) it is unlikely that you will lose clients when you raise your rates. The third option seems to me to not really be viable and I wouldn't suggest it unless I knew it was legal.

However to sell the proposal, you have to show what they will get for the money. It's simlar to R&D in a pharmaceutical company. It is big risk and a big cost with a potentially huge payoff. But how to determine if it did have a payoff? Well that's where you have to track the personal projects. So if you propose such a thing, make sure to devise a system for personal projects that get implemented to be tracked and cost savings or new profits from them tracked.

You are going to have to quantify the potential benefits in business terms. Talk in terms of ability to attract the best talent, lower costs due to higher employee retention, and of course the potential profits discussed above.

Next you have to show how the hours will be used and how project planning will have to be adjusted to allow for the time. This means that deadlines will move out which again is not an easy sell. I would suggest up to 20% of the hours charged in a month vice a week would make the most sense. And yes if you didn't do it that month you would lose it except under extraordinary circumstances which would be decided one at a time by management. You might also consider slotting some or all of the time in as a rest period between major projects. It's a little easier to tell outside clients that none will be available to work until June 1 and the project will take 40 work days than to tell them it will start May 15 and will take 48 work days. Some of this would have to consider how you currently do business. Teams mostly in maintenance mode would not have that kind of easy to define down time, but with shorter projects, it is probably easier to find the hours on a weekly basis.

You also have to address, Do we buy more people or move deadlines out to account for the extra 20%.

share|improve this answer
add comment

The question can best be answered by a company that has this policy, but I have worked with some organizations that tried, but failed to use it.

  • In a 40 hour work week, 8 hours will be used not to goof off but to productively goof off. In one organization, the amount of documentation required for this 20% meant that 4 hours of it were lost to paperwork.

  • One group expected employees to put in 60 hours a week, therefor nobody knew if it was supposed to be 48 hours of work and 12 hours of experimentation; or 60 hours of work and then experimentation tacked onto the end of the week.

The idea that the company or employee is to track the hours so it can be used to level the workload makes it sound like a administrative nightmare. It also means that the employee knows that management is tracking the time, and that management decides what projects are worth playing with.

If it didn't sound like fun, or at least less stressful compared with the other projects, I would not be interested in it.

share|improve this answer
    
I somehow doubt Google actually kills half of 20% time with paperwork. What company required such a level of documentation and why would it be required? –  Rarity Apr 16 '12 at 15:11
3  
It was required by a group who read an article about the Google policy, but were really micro-managers. –  mhoran_psprep Apr 16 '12 at 15:23
1  
Micromanage != Google. I wouldn't take that as a mark against the 20% rule, just the incompetent company. –  Rarity Apr 16 '12 at 15:37
6  
If a company's goal is to maximize quarterly profits by minimizing labor costs then of course a 20% 'goof off' would be incomprehensible to management or employees. On the other hand, if a company had a policy of designing a work environment that attracted the world's best employees so as to implement long term world domination of their industry, then 20% 'goof off' would seem a small price to pay. –  Jim In Texas Apr 16 '12 at 16:17
2  
-1 because you're explaining how an incompetent company would do this, not how to implement it properly. –  Rarity Apr 21 '12 at 14:23
show 2 more comments

All of the ideas before this one make setting time aside far more complicated than it needs to be. 20% is one day of any week. This way four days are spent working on "normal" projects. One day per week for four weeks are spent on "other" more inspirational work. Try this process on for size.

  1. Sounds like the idea has been sold to the higher-ups. If so, there is no work to do there.
  2. If you want to implement the project, do it on a 20% basis of one day per week.
  3. On the fifth day of the period (4 Fridays in a row, on the 5th Friday) Present the work.
  4. Sixth Friday, select the most awesome project. Add it to a refinement queue.
  5. Next four Fridays work around developing the project, decide if the project has true merit.
  6. If so, add it to the primary work schedule as a project and work toward an alpha version.
  7. Demonstrate the Alpha, and decide if you want to go any further. Keep list of other less worthy projects available for consideration. Likely the runner-up to the chosen project may get the same attention.
  8. If the project is chosen for further development, add it to the development queue. Wait one month for project to stabilize, rinse and repeat
  9. You should be able to do this at least four times a year.
  10. "Failures" meaning projects aside from the first 8 chosen can always be reviewed and revised again later.
share|improve this answer
add comment

I agree with the other comments that one should do so very carefully. I think you should perhaps strive for the following:

1) balanced goals. You want your employees working on projects that can potentially benefit your company, however, you don't necessarily want to take too much control over what they decide to do with this time. If you tell them what they can work on, they will see it as no different than having another project added on their plate.

2) Normal hours. If your 20% rules is correctly implemented chances are your employees will work on it off hours. However, I wouldn't require it. This somewhat coincides with having "balanced goals". If you tell your employees what you want them to work on in their 20% time in addition to their current time they will see passed the fancy lingo and see it as it is forced overtime. It should be made clear, however, that their normal work responsibilities take priority. You will have to work hard to make sure their normal work is throttled such that it doesn't invade their 20% time as much as is realistic. I would further add, if you have trouble with employees putting in just their union 40 when there is still lots of work to be done there is a strong chance you have a morale issue. Happy employees will take the time to get the work done.

3) recognition. You need to recognize the work put in by your employees. Make sure you recognize success, hard work, as well as innovation. Not every idea they have will be a home run. But you need to encourage participation. They need to see that you value their ideas and contributions.

4) Fun. You want your employees to have fun with this. This is a way for them to blow off intellectual steam, speak to other departments and groups they might not normally interact with, and discover problems or ideas that they hadn't known existed. This isn't just an exercise for software engineers, its an exercise for business people too. Often times there is a lack of communication between the software side and the business side. Software people are building solutions that the business doesn't need and the business needs has no idea that there are software solutions to the problems they face every day. Give a chance for both sides to communicate with one another and the gears in their head will start grinding.

5) feedback. As a general rule your mileage may vary. I think ultimately the most important resource to you is your employees themselves. Don't just solicit feedback online from stack. Solicit your employees for their opinions. They will appreciate you asking them and appreciate the chance to find a way of doing things that will work with them. Ultimately the 20% rule in my opinion is a machine for improving morale, generating ideas, and flattening your organization. I think it helps eliminate the bureaucracy that many corporate cultures struggle with. If there are challenges that your company is facing, chances are there is someone who might have a way of solving them. They might not be the person you expect. Listen to your employees and find what works for you.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.