Make Your Job Feel Less Like Work With The 80/20 Rule

When you work at Google, you only have to do the job you were hired for 80 per cent of the time. The other 20 per cent 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 per cent time policy is well known in software engineering circles. What’s not as well known is that this concept dates all the way back to 1948 at 3M.


There’s not much documentation on HP’s version of this. When I do find references to 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 per cent 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 per cent time at HP.

Although the concept predates Google, they’ve done more to validate it as an actual strategy and popularise it in tech circles. Oddly enough, I can’t find any mention of the 20 per cent time benefit listed on the current Google jobs page, but it’s an integral part of Google’s culture for good reason: notable 20 per cent 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 per cent time.

At Hewlett-Packard, 3M and Google, “many” of their best and most popular products come from the thin sliver of time they grant employees to work on whatever they want. 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 per cent 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 organised 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 70 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 per cent 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 per cent time wherever you work. But before you do, consider if you and your company are ready:

1. Is there adequate slack in the schedule?
You can’t realistically achieve 20 per cent 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.

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

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

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


Today is Goof Off at Work Day [Coding Horror]



Trending Stories Right Now