Are hackathons worth it?
7shifts has had internal hackathons for 2 years now. We initially launched them as a perk for the engineering team; a small learning opportunity: 2 days every 2 months.
Looking back, the first iteration of our hackathon format was quite limiting. We were 13 people across our various development teams. The thought of losing 2 days of product work every 2 months was a huge concern for us. This led us to constrain the hackathons with harsh rules like “it’s got to ship” or “focus on customer value”. In essence it was a normal sprint continued, with developers either wrapping up their features, or working on low hanging fruit they could ship quickly. Very little research or learning was done.
During one of these early hackathons, some of the developers started working on automating the more arduous tasks they might encounter during a sprint. Tasks that would allow them to focus on more impactful work in the long-term.
This lead us to relax the requirements around “focus on customer value” and “ship it” for the next iteration of our hackathon format. I had some reservations that developers would gravitate to something not “valuable” from a business/product perspective, or irrelevant given our technical direction. I was quite wrong — and gladly so.
We started seeing vast improvements to our build pipelines and our internal admin panel. People were paying down annoying debt items, creating stricter boundaries between our domains.
My concerns of irrelevant tech, or lack of value were completely unfounded. We work hard to hire the right people. In turn, we trust these people to do the right thing (One of our core values is “Act like an owner”). Developers started flocking towards “what if” questions. If we could do [X] again, if the performance of [X] was better, if, if, if… These became foundations for experiments and proof-of-concepts.
Today, we have lifted all restrictions on hackathons and increased their length to 3 days every quarter. Our most recent hackathon followed this format. The team gave great feedback, and the projects that came from it are incredibly exciting.
While not everything is immediately shippable, everything is relevant, actionable, and valuable.
Why 3 days? A side-effect of three days, we think, is the ability for people to band together and plan their idea in its entirety. A full end-to-end mini sprint. Planning and executing on their project in a short amount of time is a valuable lesson, especially for our junior developers. While they’re exposed to regular tech planning on their teams, this gives them the ability to do it on their own: drive their own project, have the self-discipline to finish projects.
I strongly believe our hackathons are valuable, not only for individual learning, but for the organization. Here are a few of the projects our teams worked on last hackathon:
- GraphQL: Could we improve our mobile team’s development process? How can our mobile app load faster if it weren’t limited by our REST API’s chattiness?
- Dibbs: Written entirely by new members of our Engineering team, this deployment coordination slack bot allows people to mark themselves next in line for deployments. Planned, developed, adopted in 3 days.
- Domain Events, Web Sockets: Could we improve our front-end user experience by sending domain events over web sockets instead of polling for results. Can we improve our messaging experience?
- Improvements to automate our localization support
- Many improvements to our internal admin panel. Faster issue resolution = happy customers.
How do we ensure hackathon success?
Track & Organize: We organize hackathons like miniature sprints. Hackathon ideas are tracked long before the hackathon starts. We collect ideas in a Jira project. Developers can rally around these ideas and pair up with others, or work on their own.
Stay away: Seriously, stay out of it. Managers in particular. Do an offsite — use this opportunity to work on those tasks you’ve been putting off for a while. Leave the developers to the hackathon without interruption. Obviously outages and “code reds” are an exception.
Demos: Hold people accountable to their learnings and progress. This can be as simple as a blog post, a short description of the work, a 2–3 minute demo of what happened.
Follow up & collaborate: Coordinate with your product team on next steps. Hackathon ideas that are actionable, or have obvious customer value can be slotted into upcoming sprints and potentially advance your roadmap faster than expected. Some hackathon projects might just be experiments for a better understanding of a problem set, the project itself might not be shippable, but the learning is highly valuable for the future.
We’re hiring!
Like learning at a fast pace? Like shipping value to customers continually? See what open positions we have on our careers page.
