DEVOPSdigest

The 20% time has an almost mythical status. Popularized by Google, but with its roots actually stretching back to the 1940s(link is external), the basic concept is that 20 percent of an employee's paid time is dedicated to pursuing personal projects. The idea is that it creates a hotbed of innovation which might feed into company work and improve skills.

In software development terms, the products that have their foundations in 20 percent are legendary. Google News, Gmail, AdSense(link is external) — all allegedly came out of Google's own use of the concept, which it talked about in its 2004 founders' letter(link is external): "Google employees have '20 percent time' — effectively one day per week — in which they are free to pursue projects they are passionate about and think will benefit Google."

In theory, it is a great way to stimulate innovation and creativity. Yet how effective is it in practice? It's a question that came up at an Indorse Engineering Leaders panel discussion, highlighting a concern that rather than using 20 percent of their time to focus on personal projects, developers actually end up doing their day-to-day work.

"It is not necessarily a bad thing if your developers are using their 20 percent innovation time to do day-to-day work," said Oswaldo Hernandez Perez, Engineering Manager at Improbable. "It might be a signal for you and your leadership team that you may be putting the team under expectations of delivery that are not correct. Otherwise, why would they use that time to keep working on day-to-day work?"

Quite often, the first challenge can be getting a team to take the time. Once that is accomplished, it can then become an opportunity to see what they actually do with it and use those signals as an indicator of what's going on in the organization.

One of the other panelists, Sarah Vang Nohr, Engineering Manager at Trustpilot asked how managers can get developers that do not think they are creative to use the time effectively. "We have different types of engineers, all the archetypes you could imagine. Some of them want to be creative, while others are more practical and matter-of-fact. It's a matter of engaging each team member and giving them the space to think outside of the box, and become comfortable being uncomfortable."

Sarah's question highlighted a common issue within organizations, and how they perceive creativity as a whole (and not just in the context of development). While many consider it to be something intangible, innovation actually works best when working within defined structures. It's an approach Oswaldo takes with his teams — 20 percent projects are planned ahead of time, discussed in one to ones, and seen as much about personal skills development as they are about improving technical ability or innovating for the sake of it.

"We make sure that they get buy-in from product management, from UX, and they have to work on it with the view to shipping. This ultimately means that they're going to get to a point where they might have to convince other developers and others (e.g. designers, product managers) to give up their 20 percent time to commit to the project — it's an exercise in improving empathy and communication skills."

That structure is critical to the success of the 20 percent time in an organization. Where many businesses go wrong is to automatically assume that if it worked for Google, it will work for them. They then implement it without considering what Google's problem was, and why innovation time was the solution. It is a classic example of solutioneering, where someone comes up with a solution, then has to find a problem it can solve.

What successful teams do is take the concept and see how they can structure it in such a way that it solves a problem for them — in the example above, improving personal leadership skills. By having the 20 percent projects involve other parts of the organization, developers get to learn critical soft skills that they might not get the chance to exercise when working on day-to-day work.

That was something Thomas Dittmer, Group Technology Director at Prestige Worldwide, really valued: "As developers, we ultimately serve the business need, but there's often a disconnect between the way tech talks and the way business talks. Getting developers to think more laterally, to think beyond their immediate work, is critical to improving those relationships, and that's using 20 percent time as a true development tool, in all senses, is so valuable."

To follow that point, Matthew Sinclair, VP at BCG Digital Ventures, also insisted that the 20% innovation time "needs to be coordinated to be effective" — and once it starts, it's a great way to get signals back from your team and all the engineers.

As Matthew summarized, "The signal perspective is great. I'm a big believer in signals and I think one of the real superpowers of a good leader is the ability to know the right signals to look for."

20 percent time clearly has benefits, if deployed in the right way. But its use, and abuse, are tied closely with how the organization in question approaches problem solving and creativity — it is when 20 percent time is expected to exist without guidance that it becomes a burden, rather than a source of innovation.