From zero to demo: Lessons learned from MediaMath’s first hackathon
First, a little background on the engineering teams at MediaMath. In December 2012 and January 2013, we acquired two engineering companies – Chicago-based Tap.Me and Cambridge-based Akamai Advertising Decision Solutions (ADS). These acquisitions nearly doubled our engineering headcount, and officially expanded our engineering presence beyond our NYC headquarters.
January 2014 marked the one-year anniversary of these acquisitions, and we wanted to kick off the year with our first-ever employee hackathon. We consider the event a tremendous success. We had 75-85% participation from our technology org, created 11 hacks, and even had one hack that may make into production. And while we (perhaps excessively) researched “how to host a hackathon” (like here, here, and here) we still ended the event with some things we’d do differently next time.
Here’s what we learned from the event:
- Invite the whole company to hack.
Secret techies and would-be techies lurk in every corner of the company. Next time, we’ll consider inviting everyone to participate.
- Test your tools.
For the people’s choice award, I hastily used a service (Poll Everywhere) that only let 50 votes come in before requiring an account upgrade. I put out this fire by quickly creating a Google form, but wish I’d known beforehand, so that I wouldn’t have had to scramble at the last minute.
Also, make sure folks know how to project their demo so they’re not fussing with a system they’ve never used before. Command + F1 is your friend for mirroring on a Mac.
- Focus on fun.
The underlying goal of our hackathon was to have fun and let folks get to know each other. Make sure that’s your goal, too. Don’t use a hackathon to address technical debt or prototype new products (although that may happen).
- Prioritize the event’s timing.
In the spirit of all-night jam sessions, we opted for an after-hours hack during our two-day Engineering All Hands. Not everyone was keen on late night cramming, so we may change it to a daytime event in the future.
- Consider when you post the award categories.
Truthfully, we didn’t want to force people to build towards a prize, so we purposefully set the awards after seeing the demos. We wanted the teams to have the freedom to work on whatever they wanted. However, we’ve gotten mixed feedback from participants about whether we should have posted the categories earlier. A question for us to ponder – would that have changed the dynamics or creativity of the event?
- Share a backlog / forum of ideas.
There are always things that folks talk about building if they “just had the time.” While we posted these in a shared and editable place, in the future, we’ll push the forum even more widely in order to generate more interest – especially cross-office and cross-departmental.
- Provide opportunities for teams to form and socialize ahead of time.
We did a decent job of encouraging teams and projects to form ahead of time, but we’ve gotten feedback that a few organized “mingle days” – even a night or two before the hackathon – would be welcome for encouraging cross-functional projects.
Commemorate the event with a nice piece of swag or other prize for everyone who hacks, in addition to whatever awards you give the winners (we gave Amazon gift cards to the winners). Next time we’ll do something for everyone.
Should you do a hackathon? I’d have to say yes, but don’t underestimate the need to rally the troops and build buzz. Momentum will take over at some point, they’re engineers after all, but the pre-planning needs to be done to ensure a solid event.