Research in the Wild: Making Research Work in Industry

My immediate reaction is that the 20% time (40% is more my preference, but the same principles are at play even if there are disagreements about the actual threshold value) is a fine way to go.

But I've heard from multiple friends that often -- again to use your Google example -- if you actually want to use that 20% time you have to work 120% time to do it.

So just like there is a struggle to get Bell Labs-style (traditional ivory tower) research out into the rest of the company, there is also a struggle to keep product pressures and Q3 deadlines from impinging on 20% time.

Perhaps that's why I would argue in favor of 40% time, or even 50% time. Because when your product manager pushes back against you, and demands more of your time because you need to ship by Tuesday, it's more difficult to take all 40-50% away from you.. you might actually end up with that full 20% as a compromise.

Research as a process and a profession and as a mindset is quite different than product-making. Pushing the two too close together or expecting people to be good at both may not always be optimal. See Research as product on the FXPAL Blog.

Rather than worry about what percentage of time researchers allocate to product teams, I think it's more important to align the goals of the research and product organizations.

When I ran a research group in my previous gig, the question I'd ask product management before starting any project was this: if we solve this problem, how much will you care?

If the answer wasn't enthusiastic, then I knew that my team was taking a real gamble to invest in the project. A positive answer at least reduced the risks to feasibility, execution, and the possibility that product management would change its mind by the time we had a solution. The last was a serious risk for a large project--which led us to favor projects with iterative deliverables that we could demonstrate to product management.

Every organization finds its own way. But I'm a fan of models that keep research and product playing for the same team. Even better if researchers and developers work closely together -- and blur the difference between the two roles.