Over the past three years, hackathons at uShip have grown from an idea to a tradition. Ideally, we want each event to feel almost effortless in their planning and execution. While we’ve experienced many successes, we’ve also learned a lot of lessons along the way.
Below are some of the takeaways from our team of 40 developers who have participated in a dozen or so hackathons to this point.
Preparation is key
Throwing together a hackathon at the last minute can work, but only if you have folks who already have ideas queued up and ready to execute. Otherwise, you’re looking at a complete crapshoot. If you’re going to want people to spend part of a weekend at work, no matter the reason, you’d better give them notice.
This is where building a hack-centric culture is invaluable, as it becomes something people want to do naturally (more on that later). Try to create a buzz about the event organically. Use the weeks leading up to the event to build anticipation. Getting developers excited about the hackathon can be trying at times, but it’s extremely important.
Involve non-technical staff, when possible
We now hold Engineering Department hackathons once or twice per quarter. At least once a year, however, we have a company-wide hackathon as one of our monthly “First Friday” events. During the larger events, Developers learn about pain points in user experience from our sales, business development, and customer operations teams.
Encourage your non-technical staff to submit projects, recruit a team, act as a QA and SME, or even get their hands dirty in development. Help them cultivate their idea from a problem-solving approach rather than a solutions-first one. An example might be, “I can’t search for a shipment by location,” vs. “Build a new shipment reporting screen”.
This way, your entire staff gets exposure to an outside-the-box line of thinking. By opening things up to members outside the dev team, we’ve discovered employees who were interested in development then later went through our internship program and eventually became full-time developers.
Facilitating connections is more important than organizing
If you’re the organizer or part of an organizing committee, you don’t need to manage this event. Put people in the best position to learn about proposed projects, and they will naturally self organize. For internal events, you don’t need to overthink structure nor apply a theme.
At the event, the location where folks do the hacking is much more important than it may seem. Are people sequestered in far away rooms? If so, they might be more productive, but it can feel like work. We prefer getting as many people together as possible in a big room, with plentiful beverages and some music.
Timing can be challenging
Avoid scheduling hackathons on days where people tend to be out, like holidays or popular festivals. Low participation can kill the morale of those who attend. It’s also pretty uncommon that somebody wants to work a full week and then spend an additional day or two at the office,even if it’s on a project of their choosing. Cutting into normal work hours will probably not affect sprint commitments that much, but it will prove to developers that management truly believes in the value of hackathons.
Multiple days > 24 hours
To expand on the last point, the best hackathon projects we’ve produced have come from multi-day hackathons. Recently, we reserved the 3 days before Thanksgiving and gave our Engineering team that time to work on whatever their hearts desired. Typically, a high percentage of the team would take one or more days of PTO that week to get an early start on holiday travel anyway, so those who remained were able to plan and execute over multiple days on projects with a significant scope. Given that amount of time, people were able to give their projects more polish and solve some of the nagging issues that we typically ignore during a more rushed timeframe.
A hackathon isn’t just a weekend event. Once the novelty wears off (after one or two events), developers may justifiably begin to question why they should continue to participate if nothing is done with any of the projects. Generally speaking, the purpose of a hackathon is to quickly produce a piece or proof of concept of a potentially big idea. If people don’t believe the leadership will champion the most promising ideas across the company, they’ll stop building them and, god forbid, become less inclined to generate big ideas altogether.
We’ve pushed for buy-in from technical and product leadership to see that, where applicable, pieces or sometimes entire hackathon projects are put into the development pipeline. The code gets cleaned up/re-architected, sent through QA and integrated into the platform. From the image upload in our mobile apps to an improved cancellation experience, we’ve had multiple projects see their way to production.
Also, ending the event in a formal way is important — we make it a point to reserve the following week’s Engineering Team Meeting for presentations so that people have a chance to show off their work. While creating something that nobody sees can still be a valuable exercise or learning experience, recognition from your coworkers can make the whole thing feel worth it.
[BONUS] Quick tips:
- It’s pricey, but people love quality catered food. East Side Pies pizza and Gus’ Fried Chicken (local favorites) have been much appreciated by attendees. They also love prizes and fun t-shirts. You don’t have to do this for smaller, impromptu hackathons, but the big “official” ones greatly benefit from more ceremony.
- One of the best things we ever did for hackathons was to create a custom trophy for the crowd-voted winner.
It’s a semi-realistic looking stuffed bear mounted on a giant base with a custom plaque. Did I mention it has chainsaws for hands and its eyes flicker red when a switch is turned on?Words can’t do him justice. The winning team shares custody, so this magnificent thing goes on a victory tour through the office.
- Play the movie Hackers in the background somewhere, at least once. (Warning: movie contains nudity)
- People have obligations that require them to leave — family and pets are important, too. Encourage people to come and go as they need to. It’s better than them not attending at all.
(Thanks to Brent Lewis for his contributions to this post)