Hack days are an interesting idea based on the 15% time from 3M in 1948. The fundamental goal for hack days is to empower engineers to solve problems that they see however they want to. Without the day-to-day delivery pressure they can solve problems that other people don’t even realize they have or in ways that are incredibly creative.
At Tes, our hack days have delivered:
- Several internal tools for service health, tracking deployments and team status
- A wide array of improvements to our shared tooling and documentation
- Features that have proven themselves extremely valuable six months down the road
- A feature that everybody thought was impossible
- Improved monitoring and knowledge of how to do production alerting
- and the list goes on…
Hack days started in October 2015 at TES. When hack days were introduced, all the engineers were asked whether they would prefer one day every two weeks or one week every 3 months. The benefit of one day is that they happen pretty often and are small. The downside is that between kickoff at 10am (when you guarantee that all the engineers are in the office) and the demos at 4pm (when people might start heading home) you will end up with about 5 hours of hacking. The benefit of a week of hacking is that you can actually get something meaningful done during the time. The vote was split: 40% for one day, 40% for one week and 20% abstaining (suggesting that either they didn’t care or they would not partake in the hack days). Given the even split, a compromise was agreed and we went with the first Thursday and Friday of every month.
We chose these goals, in this order of importance:
- Get some choice in what you work on
- Work with people that you wouldn’t normally work with
- Learn something
- Get ownership of some of our shared tooling
- Provide something of value to TES
With the goals in place, we set out the following rules:
- These are work days so don’t be a muppet - no personal projects or ignoring critical issues.
- These are optional - if you feel that your current project needs your time, don’t feel pressured into missing two days of work.
- Please don’t work from home for these if you can avoid it - the intention is to promote crossteam collaboration, learning and interaction.
- There will be a standup at 10am on Thursday where everybody with an idea can put it forth. Sixty second elevator pitch - we don’t want it to take all day. Once all the ideas are out, teams will form around the ideas.
- There will be beer on Friday at 4:00pm. Each team or individual will have an opportunity to present the work they accomplished to general accolades.
- The team with the most impressive accomplishment will receive a meaningful prize.
The rules have evolved since their inception but the goals have not changed. Specifically, we have become much better at working remotely (#remoteFirst), so rule #3 is no longer appropriate. Rule #4 has changed as we now kick off on Wednesday @ 4pm so we can have one shared meeting across timezones (especially to balance the U.S. and U.K. time difference).
The Anatomy of our Hack Days
Preparations for each set of hack days starts two weeks in advance. We send out 3 reminders for hack days via email and HipChat. (Feedback has consistently indicated that we should remind everybody multiple times before so they are prepared.) The reminders include a link to a Google spreadsheet with ideas for the hack days. Everybody is encouraged to add ideas with the ideas are focused on improvements to the engineering tools or process - ie: “what can you do that will make your life or your team’s life easier”. This has been quite critical to help bring in the people who have been less engaged or who had a negative outlook on the concept originally.
This pre-preperation is very important because it means that people are able to prepare and consider what they might want to work on. On Tuesday evening we stop idea submissions (you can still work on something that isn’t in the spreadsheet, but you don’t get to present it in the kickoff) and create GitHub issues for each of the ideas. We also create a HipChat room for each idea so that remote engineers (or shy engineers) can easily jump into ideas. The value of the GitHub issues is that it allows context to flow from hack day to hack day (there are ideas that span multiple hack days), it allows you to know who is working on which idea (we have recieved feedback that some people don’t care about the idea but rather want to work with specific people) and gives us a system for voting for the winner at the end.
When the kickoff comes around somebody in the office will set up the conference call which we have run successfully via Google Hangouts (you can stream via YouTube for more viewers) and more recently Zoom. During the kickoff each idea will get a 60 second description by whomever suggested the idea originally. The US folks will start immediately, while those closer to the GMT timezone will head home (or finish their work day) and then start hacking first thing in the morning.
The demos happen at 4pm (8am PST) and again follow a similar pattern to the kickoff but generally we’ve found that only 33% - 50% of the ideas actually have had work done on them and therefore we generally give five minutes per idea. This will usually end up running for about an hour and is generally very positive for the team. At the end a ‘winner’ is voted for and gets to bask in the adulation of their peers. The winner or winning team gets a custom-made TES Hackday T-shirt or something similarly meaningful.
Hack days give our engineers a chance to work on new and interesting problems outside the normal roadmapping structure that deliver value for the business. They also add to the team culture by encouraging innovation and creating opportunities for team members to collaborate with people with whom they wouldn’t otherwise have much contact.