August 2, 2012
When you're hired at Google, you only have to do the job you were hired for 80% of the time. The other 20% of the time, you can work on whatever you like – provided it advances Google in some way. At least, that's the theory.
Google's 20 percent time policy is well known in software engineering circles by now. What's not as well known is that this concept dates all the way back to 1948 at 3M.
In 1974, 3M scientist Art Fry came up with a clever invention. He thought if he could apply an adhesive (dreamed up by colleague Spencer Silver several years earlier) to the back of a piece of paper, he could create the perfect bookmark, one that kept place in his church hymnal. He called it the Post-It Note. Fry came up with the now iconic product (he talks to the Smithsonian about it here) during his "15 percent time," a program at 3M that allows employees to use a portion of their paid time to chase rainbows and hatch their own ideas. It might seem like a squishy employee benefit. But the time has actually produced many of the company's best-selling products and has set a precedent for some of the top technology companies of the day, like Google and Hewlett-Packard.
There's not much documentation on HP's version of this; when I do find mentions of it, it's always referred to as a "convention", not an explicit policy. Robert X. Cringely provides more detail:
Google didn’t invent that: HP did. And the way the process was instituted at HP was quite formal in that the 10 percent time was after lunch on Fridays. Imagine what it must have been like on Friday afternoons in Palo Alto with every engineer working on some wild-ass idea. And the other part of the system was that those engineers had access to what they called “lab stores” — anything needed to do the job, whether it was a microscope or a magnetron or a barrel of acetone could be taken without question on Friday afternoons from the HP warehouses. This enabled a flurry of innovation that produced some of HP’s greatest products including those printers.
Maybe HP did invent this, since they've been around since 1939. Dave Raggett, for example, apparently played a major role in inventing HTML on his 10% time at HP.
Although the concept predates Google, they've done more to validate it as an actual strategy and popularize it in tech circles than anyone else. Oddly enough, I can't find any mention of the 20% time benefit listed on the current Google jobs page, but it's an integral part of Google's culture. And for good reason: notable 20 percent projects include GMail, Google News, Google Talk, and AdSense. According to ex-employee Marissa Meyer, as many as half of Google's products originated from that 20% time.
At Hewlett-Packard, 3M, and Google, "many" of their best and most popular products come from the thin sliver of time they granted employees to work on whatever they wanted to. What does this mean? Should we all be goofing off more at work and experimenting with our own ideas? That's what the book The 20% Doctrine explores.
Closely related to 20% time is the Hack Day. Hack Days carve out a specific 24 hour timeframe from the schedule, encouraging large groups to come together to work collaboratively (or in friendly competition) during that period. Chad Dickerson instituted one of the first at Yahoo in 2005.
The Friday before, I had organized the first internal Hack Day at Yahoo! with the help of a loosely-organized band of people around the company. The “hack” designation for the day was a tip of the hat to hacker culture, but also a nod to the fact that we were trying to fix a system that didn’t work particularly well. The idea was really simple: all the engineers in our division were given the day off to build anything they wanted to build. The only rules were to build something in 24 hours and then show it at the end of the period. The basic structure of the event itself was inspired by what we had seen at small startups, but no one had attempted such an event at a large scale at an established company.
The first Yahoo! Hack Day was clearly a success. In a company that was struggling to innovate, about seventy prototypes appeared out of nowhere in a single 24-hour period and they were presented in a joyfully enthusiastic environment where people whooped and yelled and cheered. Sleep-deprived, t-shirt-clad developers stayed late at work on a Friday night to show prototypes they had built for no other reason than they wanted to build something. In his seminal book about open source software, The Cathedral and the Bazaar, Eric Raymond wrote: “Every good work of software starts by scratching a developer’s personal itch.” There clearly had been a lot of developer itching around Yahoo! but it took Hack Day to let them issue a collective cathartic scratch.
Atlassian's version, a quarterly ShipIt Day, also dates back to 2005. Interestingly, they also attempted to emulate Google's 20% time policy with mixed results.
Far and away, the biggest problem was scheduling time for 20% work. As one person put it, “Getting 20% time is incredibly difficult amongst all the pressure to deliver new features and bug fixes.” Atlassian has frequent product releases, so it is very hard for teams to schedule ‘down time’. Small teams in particular found it hard to afford time away from core product development. This wasn’t due to Team Leaders being harsh. It was often due to developers not wanting to increase the workload on their peers while they did 20% work. They like the products they are developing and are proud of their efforts. However, they don’t want to be seen as enjoying a privilege while others carry the workload.
I think there's enough of a track record of documented success that it's worth lobbying for something like Hack Days or 20% time wherever you work. But before you do, consider if you and your company are ready:
- Is there adequate slack in the schedule?
You can't realistically achieve 20% time, or even a single measly hack day, if there's absolutely zero slack in the schedule. If everyone around you is working full-tilt boogie as hard as they can, all the time, that's … probably not healthy. Sure, everyone has crunch times now and then, but if your work environment feels like constant crunch time, you'll need to deal with that first. For ammunition, try Tom Demarco's book Slack.
- Does daydreaming time matter?
If anyone gets flak for not "looking busy", your company's work culture may not be able to support an initiative like this. There has to be buy-in at the pointy-haired-boss level that time spent thinking and daydreaming is a valid part of work. Daydreaming is not the antithesis of work; on the contrary, creative problem solving requires it.
- Is failure accepted?
When given the freedom to "work on whatever you want", the powers that be have to really mean it for the work to matter. Mostly that means providing employees the unfettered freedom to fail miserably at their skunkworks projects, sans repercussion or judgment. Without failure, and lots of the stuff, there can be no innovation, or true experimentation. The value of (quickly!) learning from failures and moving on is enormous.
- Is individual experimentation respected?
If there isn't a healthy respect for individual experimentation versus the neverending pursuit of the Next Thing on the collective project task list, these initiatives are destined to fail. You have to truly believe, as a company, and as peers, that crucial innovations and improvements can come from everyone at the company at any time, in bottom-up fashion – they aren't delivered from on high at scheduled release intervals in the almighty Master Plan.
Having some official acknowledgement that time spent working on whatever you think will make things better around these here parts is not just tolerated – but encouraged – might go a long way towards making work feel a lot less like work.
[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.
Posted by Jeff Atwood
What about Valve? Their official company policy is not 20% time for personal projects, but 100%. It is still fascinating to me that with that and their flat company structure* they still manage to ship so many great products (not just single game projects, but things like Steam).
*: "...we don’t have any management, and nobody “reports
to” anybody else. We do have a founder/president, but
even he isn’t your manager." - Valve: Handbook for new employees
My experience with this idea is that it doesn't work unless you have good people who are actually -capable- of using their creative brains and doing things with their own initiative.
I offered this to my software team, but am yet to see them actually doing anything with their time. I have to really push them to make them use it. I guess it's my fault for hiring them, but still, it bugs me.
I have to agree with cbp. I think the ability to get something good out of these initiatives depends on the people that you have to work with.
You really need people who are passionate about creating new things. Some developers at my current company seem to only focus on the job in hand, and don't provide input into future products or experimentation. Maybe we've got the wrong people here and maybe that's a reflection on our hiring process.
I really agree with that philosophy; working on or with something you really want is always going to be more productive and motivating than anything else.
Then again people must share the enthusiasm, and not least also understand it, for this idea to be succesful. I wish my company had this policy.. :)
Yesterday at work we formed our new product team, part of this was me giving a quick presentation on our vision for the year, vision for our main product, goals for Q1 and I highlighted that I was implementing a sacred 20% policy. I'm very excited to see what it will enable, and I think we've got the right mix of people to create some really great products.
What timing - the company where I work is doing its very first ever "Innovation Days," modeled after Atlassian's ShipIt Days, today. I'm skeptical that it will bear fruit given the culture at this company, but hey, I'm open to being surprised.
We've just started doing 10% time. In terms of scheduling, we're doing it on a Friday afternoon for the whole company. I'm hoping that this will make it easier for teams to find time for doing it because it'll be more of a "hey it's Friday afternoon, time for 10% time" rather than "I'll try and do some 10% time tomorrow afternoon if I manage to finish this feature".
It'll also make it easier to for people from different teams to work together if they want to.
Thanks for posting about this!
When I emailed you on the matter the last thing I expected was a whole blog post to read about.
I'll be sure to forward this to my boss, and again; thanks a bunch!
20% at Atlassian is actually going pretty strong. Every team in the company does it slightly differently—some teams schedule a day a week, others set aside a "20% week" between releases—but it's much rarer these days that you hear complaints that developers don’t get the opportunity to exercise their time.
It took a while, and I think part of that process was proving that the programme actually produces results sufficient to justify its existence. These days it’s rare that we have a release of our products where one of the marquee features isn’t something that came out of a 20% project or ShipIt competition.
There's another angle to this as well, that no one seems to have considered:
Some of us love experimentation and creating stuff - but hate having to present it, or restrict it to something useful to the company. So we avoid taking advantage of this time, and wait until we have full freedom at home.
My company (a small real estate brokerage with a few developers) had a hackfest and it was great! I wrote up my experiences here: http://www.mooreds.com/wordpress/archives/768
So, don't limit this type of free thinking work just to development staff--some great ideas came from people who couldn't code. One difficulty is the deliverable--instead of running code, powerpoints or presentations were given.
I see two main benefits of hackfest (or 20% time, etc).
* new ideas that come from the time spent, even if they take some time to be fully incorporated
* a culture of innovation and respect for ideas from anyone
The second benefit is a concept that is not revolutionary at small tech companies, but for lots of other organizations it is.
We'll be doing another hackfest this year--I'd like to ramp it up to at least twice a year.
Almost a month ago I started a thread at Real World Technologies (http://www.realworldtech.com/forum?threadid=123828&curpostid=123828 ) asking about the origin of 20% time. Responses there pointed to Valve and HP but did not mention 3M. (In my post I pointed to a vaguely similar concept presented in A Canticle for Liebowitz, where monks were allowed to work on side projects after their copying quota was met.)
It was nice to read about more examples.
We have a similar policy where I work. The only problem is I don't think anyone has ever taken the time because they already have more work than they can handle. The few people that have come up with major innovations have done it in addition to their existing overtime.
It'd be great to have time to work on new and innovative ideas. Though I think a lot of companies struggle at giving employees enough time to do innovative or even adequate work on what they are already required to do.
"Oddly enough, I can't find any mention of the 20% time benefit listed on the current Google jobs page, but it's an integral part of Google's culture."
I don't find this odd at all. They're downplaying it, and I wouldn't be surprised if they're phasing it out entirely. All the Google people I know barely have time for it any more. They call it "120% time" -- what you do after you work a full week, if you want to stay late. I don't know of anyone who's spent a full day a week on a personal project, even once, in the past 5 years. While we were watching, Google became a Big Company, with all the good and bad that comes with that.
Due to mergers and splits, "HP" today isn't the same company as "HP" in 1939, but I'd be surprised if either HP or Agilent still had something similar.
I think 10%/15%/20%/hack time is very important for new ideas, but it seems that the ingredients you identify as crucial for its success are fundamentally incompatible with Big Company culture.
I think people are missing the biggest problem with these 'work on whatever you want programs'. And that's *ownership*.
Let's say I have a great idea. Great ideas are cheap. But it's still *my* idea. Someone else might have came up with his own, identical or similar idea, and that's his idea. But *my* idea is my own. And maybe it's the next Facebook or Twitter. Maybe it will change the world. Probably not - but maybe.
If I use my spare time and turn my idea into a reality - it might make me a millionare. It might lead to my own company. It might make me famous. Because it's *mine* I can use my idea to explore all of the possibilities.
But what happens when you use work time and resources to work on your idea? Who owns it now? *THEY* do. Not you. Will you be rewarded for it? *Maybe*. Will you have control over it *No*.
Maybe you get paid well enough that you don't care. But when I look at hourly rates people get as contractors and consultants - that's what you can earn PER HOUR doing assigned work. I'd need to make a lot more to hand over every awesome idea I may or may not have that may or may not be profitable, in addition to the regular work I do.
Some notes about 3M:
• All employees must prove that they have spent the appropriate amount of time working on their own projects. If, during their performance review, they can't prove it, they are immediately suspended from their regular duties until they make up the time.
• All managers are chemical engineers. Not only that, every one has developed and sold a product of their own invention.
• The president is the manager who sells the most products. If some young engineer develops a product that out-sells the president's products, guess who becomes the new president next quarter.
Some notes about HP (when Packard and Hewlett were running it):
• All engineers must has an electronic gizmo of their own creation on their desk at all times. This is in case Hewlett or Packard stopped by to visit; they should have something to play with while they're there.
• HP developed Management by Walking Around. This was because Hewlett and Packard loved to talk about hardware and wandered around talking to their engineers. (Sadly, other companies which try to implement this don't realize it does not work if employees cannot talk about their work. Just walking around and handing out dictates does not work.)
• All HP engineers had to spend two weeks in sales talking directly to customers. Most computers firms won't let their developers so much as smile at customers.
Commonly heard joke:
Most companies have the equivalent of Google's 20% day, they call it "Saturday".
Definitely one of the elements to account for is the human element.
Big companies like Google and HP can have 20% time be good for the company in the long run because they seek to hire top-quality developers.
If instead your company consists of mostly developers who are just there for a paycheck, 20% time just means 20% less work.
@Rob Paulson If you have a personal idea that you think could start your own company, you are free to keep it to yourself and use the 20% time for some other idea that maybe isn't so grand.
I feel like more companies should do this 20% time policy, it gives developers a feeling of satisfaction when they get to build an app that they can brainstorm up and develop from the ground up rather than working on client projects all the time. Sometimes we all need a break from the normal grind to work on hobby projects.
That's nothing - those people who work for government (city, state, federal) work 50% of the time every day
Tom DeMarco has a great book on this subject: _Slack_ (NADA.) It's thin -- 200 pages-ish -- and I typically keep a few copies around to give to people who "need" them. I'd offer you one, but you strike me as the kind of guy who might do the same thing.
Still, ping me if you want me to send you one. :)
@Shawn H Corey - I've never heard the 1st and 3rd things at 3M. AFAIK, 15% time is not required. As for the 2nd, we do have 3 software groups our manager is a software guy, but the director is a chemical engineer.
HP stopped that long time ago.
This died when Carly Fiorina was CEO and never came back.
And I can't imagine it will ever come back, the HP Labs have funds reduced and HP is not too much into innovation anymore.
@cbp - I agree with you that it takes a motivated person or team. As far as I know, I'm the only one out of my team that has the desire and motivation to take on 'skunkworks projects' ... two of which have now turned into major initiatives for our department or company and we're spending hundreds of thousands of dollars on hardware for them.
But I've got a personal history of running skunkworks projects that turn into big deals; I did it at every job I've had except the one where I worked at a major university in an overemployed-by-regulation department. There I slept in my chair most of the afternoon....
It's not an official company policy at my current company to allow this kind of project/work. I simply take the time; in the context of the "120%" concept from Google. Since good things come out of it and I keep getting awarded for it the second I show progress on something useful, I suppose I'll keep doing it.
I do take exception with those that say that this time is only for coming up with ideas. I think it's also for scratching itches that management won't allow you to scratch on official time. For instance, we've got (at last count) 6,882 Nagios checks across less than 150 servers. We collect performance data with a different platform, collect logfiles with another completely different platform and parse a very small amount of them in any usable way, and we don't have anything in place for tracking actual application performance except 'gut feel' and some basic statistics. Nagios works in the sense that it alerts us when stuff breaks; it's just crude and scratchy and ill-fitting. That last problem has been identified by management and someone's working on it part time, but I stole some hardware resources and am now working with that person on finding one solution that will do all four things we need.
I'm a peon at a university, and I would say the rule is reversed there for most people. Everyone has things they have to do, but getting them done takes no more than 20% of the time. The rest of the time you are supposed to be doing your own thing: your research, your grant writing, etc. For faculty, that's the whole point. For some of the staff, like me and I guess the guy in the previous comment, there's this twilight zone where you are not sure if you're supposed to be doing something on your own initiative or just standing by for when you are needed. Of course, some of the staff are expected to always be busy with not-their-own-thing. If there is "overemployed-by-regulation" it's because of an essential trust that people working there are already motivated to pursue their own interests which are also the interests of the university. Sure, there are slackers, but it's better to have a creative culture that allows that than to stifle both the slack and the creativity.
I think many of us are in companies that are still very much led in the classic command-and-control style. Top heavy management layers, program management, project management, task management, a multitude of roles and processes.
All of this is created on the assumption that employees are dumb, lazy slackers that need to be told precisely what to do when, in a standardized way. Some say such organizations attract people with limited innovative capabilities, you could also argue that such organizations create people that way.
Some organizations even dare to constrain "innovation" in such rigid processes. Sure, feel free to come up with awesome ideas from the bottom. All you have to do is swim upstream, find sponsors, submit a business case analysis, etc. It's discouraging, more a process for anti-innovation.
The 20% time, when done properly, lets go of that rigid structure, and all the successes it has delivered are great proof that people want to make great contributions when given the freedom and trust. Sure, a minority will misuse the time just like a minority misuses working from home, but the general improvement for society is more important.
I have implemented my own 20% time, unfortunately self-funded as my company does not have it. Still, it sky rocketed my personal development, balanced my work and private life, and allowed me to build a cool website that is the marriage of two of my hobbies. I won't abuse this blog by plugging it. I will even take things further to opt for all of society to aim for a 4 day work week.
Great, after reading that Valve handbook I might not be happy at any other place I work... might have to move and apply :P
Creative types will almost always be able to find the'20%' time, regardless of policy. Having such a policy, official or otherwise simply allows slackers to slack even more, and the creators will continue to do what they have been doing all along.
While there's a certain amount of trust/responsibility required from Da Management, this is where good immediate-supervisors (aka. middle management) actually have jobs: protect your underlings from the boring drudgery of policy and give them the tools to get things done, which may mean turning a blind eye when they are working on a project which doesn't seem to have a direct bearing on the current schedule of tasks.
Great stuff! I stumbled upon this article while writing the evaluation of my software sabbatical - http://www.erisc.se/software/2012/08/14/software_sabbatical_evaluation/
I think one approach worth looking into is to spend this "goofing off" on longer periods of time instead of just chunks here and there, just to get some distance from the drudgery mentality of bug fixes, deadlines and release schedules. I've experimented with this a bit, and even if I haven't found anything revolutionary I definitely feel there's something to it.
I think one thing that is needed to make such a thing work at any given company is a culture where new ideas are accepted and welcomed.
List of Programming activities
1. Problem statement: To develop a program that calculates a customer’s charges and total bill at the gasoline pump. It involves collection of information needed for the program like the current prices of gasoline, labor availability and charges.
2. Program specification: This program will request for the customer to state what type of gasoline they want. For instance, Regular or Premium, and state or enter the amount of gasoline they require. The program will then automatically calculate the price of the gas and calculate the federal tax. It will then prompt the user to state what kind of sale they want and calculate the service charge and state sales taxes according to the service provided. The program will then give the total bill he/she is supposed to pay
Something like this does really depend on the embedded culture of the company and the people in it. It's really hard to *force* it to work no matter how great it could be.
I worked at a large scale company and we implemented a HackDay event from the bottom up, modeled after what Yahoo and Altassian did. We simply just did it, grassroots style.
While management buy in can make it be better, it's not as necessary as employee buy in. If people are motivated enough, they will find the time to make it happen. Whether that's formal 20% time, a slow Friday, 120% time or just lunchtime, it will really come down to attitude and motivation.
Luckily I was in an enormous company at the time so the likelihood of finding compatible people was a lot higher. But it still took a lot of will power and effort to get it going. I've since parted ways with the company, but currently they're running their 10th event, so it's managed to stick and continues to grow each year.
Sometimes, these sorts of things, you just have to throw caution to the wind and just do it. Reduce the hurdles, bend the rules and make it work for your group. If it means taking a few days instead of one, or just shortening it to an afternoon of idea brainstorming, there's lots of ways to get people engaged. The important part isn't so much what actually gets done on a HackDay or how, the fun part is to get things started. Once the ball gets rolling, that's when you start to see the interesting things happen, and that will end up lasting far longer than any HackDay can.
I've seen our HackDays produce everything from personal learning experiences to website redesigns to online tools to new prototypes that actually went on to become products in the company's inventory. Undoubtedly something of value, yet the concept itself was still run adhoc by a core group of employees that believed in the concept.
Anyway, I have a little more about my thoughts on HackDay here: http://goo.gl/xNofr
And I figured I may as well, so here's to actually running a HackDay: http://goo.gl/zV8Wz
I know, cheap plug. :)
anything needed to do the job, whether it was a microscope or a magnetron or a barrel of acetone could be taken without question on Friday afternoons from the HP warehouses. This enabled a flurry of innovation that produced some of HP’s greatest products including those printers. serviced apartments london
But my point is that high spending and low (financial) saving does not necessarily mean that people aren't preparing for the future. Our well-being today isn't increased merely by our past saving, but sometimes by our past spending. chino hills plumber