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:
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:
As far as allocation, we've tried several different things.
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:
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:
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.
Other than that it was very similar to one iteration out of five.
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.
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:
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!"
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.
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%.
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.
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.
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.
