Internal company hack days (or hack weeks) are a common thing in tech companies, but not universal. They should be universal, though. Hackdays help you get great new ideas that are both impactful and feasible. They're probably the best thing you can do to improve your product and reshape your roadmap.

Bold claim, so let's unpack it.

Hackdays, for the unfamiliar, are a day (or two, or week) where you pause most normal work and instead build new things. The engineering team (and product, and design) are free to build whatever they want. During the course of the hackday¹, the goal is to build something new and impactful (usually just a proof of concept). There aren't a lot of constraints, but there is usually some structure. You'll usually have an event at the beginning to help people find ideas and teams to work with. And you usually have an event at the end for people to show off their work.

This is a stark contrast to the way that work is usually structured. In agile² teams, you have short sprints, but you usually have a reasonably long-horizon roadmap. Things generally get onto the roadmap from product managers, and they're addressing a long term vision of where the product is going. The features on the roadmap are typically rather vanilla: they will be good, they're needed, but they're not spicy. It's hard to get truly unexpected things into a roadmap, because you have to prioritize more concrete things if you want to actually write a roadmap since roadmaps are concrete.

Hackdays give a way of proving out ideas that are in some way unfit for the usual roadmap. And those turn out to be the best ideas, and hackdays give a way to give them the light of day.

The hackday process is unique because it provides three crucial ingredients for creative, impactful ideas:

• Working in groups with new people
• A strong time constraint
• The desire to show off

Working with new people is the first key ingredient. When you work with new people, perspectives mix in a great way for creativity. You end up combining insights you could not have gotten with your usual team. This is also why diverse teams win over homogenous teams: you have more perspectives to build off of, and you see a broader solution space and detect problems earlier.

Strong time constraints are also crucial. It's well-known that constraints are a key aspect of a creative process. In this case, we want things which are feasible to implement with the limited resources of a team. Having a time constraint means that we have to be creative in finding a short path to solve a big problem.

And that leads to the desire to show off. There are a lot of ways this manifests, and I don't mean people want to brag. But people generally want to show something cool to their coworkers. When you get to the end of hackday, all your coworkers will have something cool to show; don't you want to do that, too? This leads people to picking ideas which they think will be most impressive or most appreciated.

These ingredients come together into a great combination. You work with people you don't normally, so you get a lot of new insights. And then you work together to create something incredibly impressive on a short timeline. At the end, you come out with really cool proofs-of-concept which show that something highly impactful can be done quickly. Unsurprisingly, these ideas often find their way onto the roadmap, since they now fit the criteria!

I've just come off an internal hackday at my job. It was an incredible experience, with the presentations being hit after hit after hit. The presentations reminded me that my coworkers are so good at their jobs, and that we have such cool stuff to build. That stuff is making its way onto the roadmap sooner than anyone thought it could a week ago.

If you're in an engineering or product organization and you don't have hackdays yet, go get one started. It pays off almost immediately. And it's a lot of fun.

Happy hacking!