There’s nothing like a couple workdays to put aside your regular work and do whatever you want. No regular meetings, no pings. You can work alone or on a team. What you do is up to you. Maybe you want to make something, fix something, or learn something (Bill Gates “Think Week” style).

Hack Days are about giving people that autonomy and freedom. It’s like a hackathon, codefest, etc., except it’s not limited to creating software.

My primary experience with Hack Days comes from Shopify, although I had a similar opportunity at my previous job. I’ve seen a lot of great things come from Hack Days at Shopify:

• The team I joined was the result of a Hack Days project my hiring manager led the year before. When I was interviewing, this was a great sign to me that the company valued innovation.
• The last Hack Days team I worked on prototyped a feature, and our demo has gotten some attention. We’ve talked with a couple senior engineering leaders to sketch the remaining work and it looks like a team might take it to production.

I don’t mean to suggest that every project should spawn a team, but I wanted to highlight that projects can lead to that. I think there’s a lot of reasons why companies should organize regular Hack Days, including:

• Hack Days unleash creativity and ownership: Work on whatever you want.
• Hack Days break down silos: People who don’t normally work together, work together.
• Hack Days encourage learning: Stepping away from your regular context is a perfect way to discover new problem domains, new technologies, new skills. Those new learnings can suggest paradigms and analogies that can fuel other work.
• Hack Days lead to breakthroughs: There is “activation energy” required for innovation. With the right ingredients, Hack Days can provide that activation energy for some ideas.

I’ve seen these things in my experience. I’ve always gotten a lot of energy from the creativity, I’ve always met new people across the organization, I’ve always learned something, and I’ve always had some breakthroughs on ideas I wanted to work on but hadn’t had the time for.

Essential ingredients

Hack Days probably means different things to different people. Here’s what I think are the essential ingredients:

• Leadership support: Hack Days have leadership support so that folks participating can focus on the event, instead of being interrupted by non-urgent tasks from their regular work.
• Organic organization: Hack Days teams are organic. Anyone can create a team, and participants can join whatever team(s) they like. There should be some roster of teams to facilitate this organic organization — could be as simple as a Google Sheet.
• Multidisciplinary: Hack Days are for everyone, not just for engineers. The projects don’t need to be technical — and for projects that are, there are certainly non-technical roles.
• Demo: Teams demo what they learned or built with a short video (have a time limit!), and the demos are easily accessible for folks to watch and react to — e.g., by voting. This makes it easy to continue the conversation about projects.
• Enough time: Hack Days are long enough for teams to decide what they’re doing, do it, and demo it. Two days feels like a minimum to me. Shopify does three days, and that seems to work well.

Give it a try

If your organization doesn’t do Hack Days, I hope you’ll try it. It seems like a win-win to me: folks who want to participate enjoy the autonomy and creativity, and the organization gets benefits from that too — the connections, the learnings, the breakthroughs, etc.

If you already do Hack Days, I’d be curious to hear about what works and doesn’t work for you.

And finally, if you liked this post and want to hear more of my thoughts on software and work, including Hack Days projects I can talk about in public, you can follow me on Twitter.