Planning Harry’s 2019 Hackathon

In December of 2019 Harry’s held its annual Hackathon. The two-day event has become a much-adored tradition that enables us to live some of Harry’s values including Look Left to Find Right, Improve Always, and All In All Together. As a new Harry’s employee and first time Hackathon coordinator (at any company) I was determined to make it a fun event. Here is how I went about it and what I learned from hosting it.

Preparation

Planning a Hackathon, even for a relatively small team, is not a one-person job. While it’s not a full-time job, there’s enough things to do that I had to recruit some trusted colleagues to help. Our planning team ultimately consisted of four members. Our mission was to organize an event everyone would enjoy in about five weeks. Our list of things to concentrate on included the budget, theme, schedule, marketing, judging, and demos.

Budget

The first challenge we encountered in estimating the budget is that we weren’t sure how many people would actually participate. We intended to invite 40–45 people but wouldn’t turn away anyone that heard about the event via word-of-mouth. We also weren’t sure how many invitees would participate. Using some back-of-the-napkin math we estimated 25–35 people would take part and we’d create a registration sheet to help firm this number up as the Hackathon approached.

With that number in mind we listed the expenses we had to have and the ones we’d like to have. Had-to-haves included lunches, stickers, and prizes. Nice-to-haves included additional swag, booz for the demos, and breakfasts.

Budgeting for most of these expenses was pretty easy except for prizes. The x-factor in budgeting prizes is that we didn’t know how large the winning teams would be. More on that later.

In the end we budgeted $1500 for two lunches, stickers, and prizes. All the nice-to-haves were dropped. About 30 people participated.

The Theme

What makes a good theme? Is a theme even necessary? Would a theme encourage participation or discourage participation? We debated several ideas for a theme. Should the focus be something technical like bots? Should it be tied to a business endeavor or a company value? We decided we didn’t want a technical theme so that designers, product managers, and other non-technical staff would be comfortable participating. We also wanted the theme to be broad, so all sorts of ideas felt at home. Eventually we settled on Communication, since communication could refer to communication between systems, with each other, or with customers. The word “communication” felt pretty bland so we ultimately chose “Let’s Talk” as a more colloquial way to refer to communication.

Scheduling

The day, week, or month of year to hold your event depends on your company’s rhythms. Ours landed in December. More importantly we decided to make it a two-day event with the demos at the end of day two. This would give teams about 14 business hours to work on their projects. Holding an “Ideas” meeting about a week before the event was very helpful in building excitement and confirming the approximate number of participants we would have.

Marketing the Event

With the date and theme decided, we could finally announce the Hackathon. We shared via Slack, mentioned it in monthly staff meetings, and posted fliers around the office. A lesson learned here is that you can’t market the event enough. Despite what we thought was a good effort, a number of people approached us after the event, disappointed they hadn’t heard about it in time to participate.

Judging

Judging turned out to be a more challenging problem than we anticipated. We had to figure out who would judge, how to judge, and what characteristics would be judged.

The who. We felt 3–5 judges was appropriate. In our company there was a yearning to have the founders and other C level employees be the judges. These schedules can be difficult to coordinate so we cast a wide net in order to recruit them. We reached out to nearly a dozen executives and had some accept our invitation only to decline later and vice versa. In the end we had four judges but were scrambling to confirm that until the day of the Hackathon.

The how. In the beginning we had a vigorous debate about how to pick the winners. Most Original, Best Idea, and Top Implementation were all considered but we ultimately settled on First, Second, Third, and People’s Choice. We then spent time creating a detailed scorecard that each judge would use to rate the teams from 0–3 in four categories. We also created a simple Google Form to judge the People’s Choice winner.

The Main Event

Finally, the big day arrived. We reserved our companies big, common space and arranged for the teams to be able to present via video conference which was broadcast on a large screen in the room and available remotely. The demos were scheduled for one hour and we had eight teams on the docket. We gave each team six minutes for the demo assuming there would be some set up and tear down time between each demo. Only twice did we need to alert teams they were approaching time and several teams were under time thus an hour was just right. At the conclusion of the demos the judges announced the winners and we encouraged everyone to vote for the People’s Choice winner.

In Retrospect

First and foremost, we received enough positive feedback to feel we met our primary goal of having a fun event. Despite that, there are a number of ways we can Improve Always next time. We’re thinking about team prizes rather than individual prizes. The schedule is likely shift to avoid the Holiday crunch, while being mindful of other key dates on the calendar, and we’ll ask our C level execs for their availability before scheduling the next Hackathon.