I’m sure many of you have heard of the famous Google 20%. This is the concept that Google engineers are allowed to spend 20% of their time on whatever they want. The idea is that many of the company’s most innovative and disruptive initiatives come from such a policy, and it also helps with employee morale and creativity and so forth.

I think this is a great idea, in theory, but I wonder whether it would work in practice.

Allow me to present some anecdotes, as I am wont to do. I was working on a large project once, with a team of maybe 100 engineers. The project way way behind schedule and in jeopardy, and the response by the PM was to institute a mandatory 10% overtime. You were expected to put in 44 hours a week, or basically a 9-hour day Monday through Thursday. Or another time I was working for an organization that instituted the 9/80 work schedule, which means if you worked a 9-hour day Monday through Thursday you automatically got a 3-day weekend every other week.

Both of these ideas sounded great, again in theory, but the reality? I think if you ask most people to work an extra hour a day they will just fill up an hour with email, chatting, “research” on the web, and so forth. I bet that productivity and output barely increased, if at all, in both of these cases.

So many progressive management and leadership techniques such as the Google 20% are predicated upon an enormous assumption: your organization has recruited and retained the top 10% of talent and your culture and morale is so strong and positive that people love to work and will happily invest their time on side projects that are beneficial to the company.

Seriously? Many people I see aren’t even putting in a solid 8 hour day, and yet you are asking them to stay at the office longer in the misguided idea that they will put in more work? This might work at Google where they have the leverage to recruit the top 10% of the available talent. But not everyone is Google.

So does that mean that, as a manager, you should never allow research time? Engineers need to be nose-to-the-grindstone 8 hours a day? That’s not going to work either. No one can focus straight for 8 hours a day and be productive. In fact I suspect you will start to introduce more errors and bugs if you make people work that long consistently.

There has to be a middle ground, so I tend to follow a couple of guidelines.

1. Measure output based on goals, not hours spent at the desk

This, to be blunt, is really hard, because you have to spend a lot of time defining objectives and then measuring success. For more senior staff this usually turns into strategic goal setting (“Product X needs to have Feature Y done by date Z”). For more junior staff this can easily be tracked via Scrum/Sprint (which is why I’m a proponent of Sprints, but only if you have a full-time Scrum Master managing it). But it still requires a lot of time-consuming tracking and management by a Project Manager or Scrum Master.

Also, depending on your corporate culture, this can be hard because many companies track the workday by hours spent at a desk. Even if you’re a salaried employee, you still fill out an hourly-type timecard showing you spent 8 hours a day at work.

2. Understand that people need mental breaks and there are limits to productive hours in a day

I’m not a stickler for extraneous web surfing or chatting, because I know that I certainly need breaks from time to time. Some days I can be in the zone and super productive, but there’s other days that I have an “off day” and just can’t seem to get focused. And for deep technical or creative work, I certainly recognize that you can usually only get 4-6 good hours of coding in on any given day. There are exceptions, of course, with both certain people and certain days. But there’s a reason that good Sprint planning only plans for 6 hours a day.

3. Pure research time is needed, to “Sharpen the Saw”

As in, the Google 20%.

In Stephen Covey’s “Seven Habits of Highly Effective People”, one of the titular seven habits is “Sharpen the Saw”. I spend a lot of time reading relevant material, both books and websites, and I credit this to a lot of the knowledge that I have in my brain, knowledge which is used in my day-to-day work life as well as my personal life. Taking time to read, not just latest trends and so forth, but also insight and ideas from other people, can help make someone a better engineer and a better person.

Also, sometimes the engineering “play time” is useful for both existing projects and future projects. I tend to be hyper-focused on minimum-viable-product and engineering tasks that are tightly tied to milestones and features. But being too focused on the narrow beam of the project in front of you doesn’t allow for any disruption, or those amazing leaps of improvement that come from trying something new.

This last one can be really, really hard in a lot of organizations. Many companies I’ve worked for bill their hours directly to their customers so there is a strong pressure for all the work being done to be directly tied and traceable to a specific project and even a requirement. Any “playground” research is considered wasteful of the customer’s money. Think of the movie Ratatouille,

“It’s the chef’s job to invent new things, it’s ours to just follow the recipe.”

I certainly understand the position that the company is in, but not only does this actually hurt your ability to deliver value to you customer, it also is a huge blow to your employee morale.

I strongly encourage you to either figure out how to get some overhead time available to your engineers for these types of research tasks, or negotiate a small percentage of allowable research time from your customer. If tracked properly you can still trace how that spent time beings value to your customer…show how that research can lead to process improvement ideas or new features for their products and services.  And thus the “Google 20%” can be beneficial to both your business and your customers.