Hack Days, 20% Time and Kaizen Events

The 20%Doctrine How Tinkering, Goofing Off, and Breaking the Rules at Work Drive Success in Business by Ryan Tate introduces the concept of “hack days” popularized by software development teams within companies such as Google and Yahoo! During hack days, also called 20% time at Google, people are allowed to work on their own projects or on cross-functional projects, throwing off the constraints of their functional silo. This allows their creativity to wander into peripheral areas or to work in a flow on a project with other coders work for different managers.

Hacking, 20% time and kaizen events strike me as instances of creative problem solving. Some similarities noted in the book:

• Hack days and kaizen events leverage creativity of individuals
• Both feature working in cross-functional teams
• Both are orchestrated / explicitly enabled by management
• Programmers / kaizen team members become better at presenting and communicating
• Both promote yokoten, e.g. sharing software functionality and APIs to each other

People in all types of organizations need some of hack days or 20% time to be able to reflect upon and redesign their processes. People often have a keen awareness of problems and ideas for countermeasures to these problems, but are held back by formal structures functional silos that do not enable rapid change and experimentation. There is so much opportunity to improve that the 20% time will come back as saved time. In some cases these improvements could be more than problem solving but innovative new services that delight customers and drive revenue growth.

Here are some questions to ponder:

• What things within your organization are “hackable”?
• What processes, systems or product designs can be tinkered with, changed or tested, while maintaining integrity of the current operation?
• What percentage of hack time is sustainable?
• How could your organization get started with a 20% time or hack day experiment?

In a repetitive production process, customer-facing service process such as healthcare or retail, or any high-paced work in which output is closely measured, it is not practical to spend 20% of such customer-facing time hacking our work. We could not satisfy our customers. We are not all developers. But we could be, if we look closely at what can and should be hacked, and dedicated a week, a day an hour towards creating more time and space to do kaizen.

---