Here at Stormpath, we just finished our very first internal hackathon (StormHack 0x00). It was a lot of fun. In this article I’ll walk you through what we did — what worked, what didn’t, and most importantly: how everything went!
For a while, we had wanted to throw an internal hackathon to work on fun projects, but because of startup time constraints, we just never got around to it. After deciding on a date, however, it was easy to organize with only about two weeks advance notice. In the end, everyone had a blast, and we made a lot of progress!
Before you start planning, it’s a good idea to sit down and think about what you want to accomplish with your hackathon. Pretty common reasons for internal hackathons seem to be:
- Give engineers time to refactor code and reduce technical debt.
- Build fun projects and compete against your co-workers (similar to public hackathons).
- Give your teams unstructured free time to hack on whatever they want (in a non-competitive way).
- Team bonding.
- Exercise your product (if you’re a tech company, forcing your team to build projects that use your service is a great way to find issues and get a better perspective on your users’ experience).
At Stormpath, we wanted the hackathon to get everyone together for bonding, as well as get everyone more familiar with using our API. When you’re constantly working ON your product, but not using it every day, it’s easy to forget about the user experience.
Be sure to keep the purpose of your hackathon in mind as you go through the planning stages, and try to align the activities with your goals so there’s no mismatch.
Once you’ve got your purpose decided, you’ll want to calendar out a few days of time, and develop a hard schedule. While this is fairly obvious, it’s incredibly important! By laying out a timetable early on, the rest of your planning will be much easier.
In our case, we decided to make the hackathon a two day event, with a kickoff/planning event the night prior . Then Tom and I sat down for an hour and drew up a preliminary schedule of events. It ended up looking like this:
Wednesday, Feb 26
- 4pm –> End of Day: Pitch ideas, break into teams, brainstorm. NO CODING!
Thursday, Feb 27
- 9am –> 10am: Breakfast. Coding begins.
- 10am –> 1pm: HACK!
- 1pm –> 2pm: Lunch.
- 2pm –> 6pm: Caffeine and HACKING!
- 6pm –> 7pm: Dinner.
- 7pm – Pencils Down
Friday, Feb 28
- 9am –> 10am: Breakfast. Coding begins.
- 10am –> 1pm: HACK!
- 1pm –> 2pm: Lunch.
- 2pm –> 4pm: Coding. Demo prep.
- 4pm –> 7pm: Demos. Awards. Dinner. Hanging out.
We also decided to have hard start and stop times for the coding portion of the event. Since we have a pretty diverse group of employees (some people have kids, long commutes, etc.), we decided to NOT allow coding after hours — this way everyone would have an equal chance to participate and win the event.
Once you’ve got a rough schedule, you’ll want to decide on the official ‘rules’ of the hackathon.
First decide how you’ll handle ‘winning’. As I’m sure many of you know, most public hackathons have prizes (cash, iPads, etc.). We thought about this a lot, and decided AGAINST traditional prizes.
Instead of paying the winners, we decided to go with a trophy approach. The winning team will get a trophy that they can keep on their desks, along with bragging rights until the next hackathon takes place >:)
This aligned a lot better with what we’re trying to accomplish: bonding and getting everyone to exercise our product. It wouldn’t really make sense for us to host a competitive hackathon where winning is the utmost goal, since that could negatively affect our team bonding.
In the end, we settled on the following rule list:
- Coding must take place during designated programming hours. No outside work allowed.
- Each team gets 20 minutes to present their project (max).
- Each project must use the Stormpath API in some way.
- Teams must be two or more people.
- When voting occurs, each team must cast votes for ANOTHER team. No self-voting allowed!
The last two rules were meant to encourage team bonding / friendliness during the competition, and generally make things more ‘fun’ 🙂
NOTE: We didn’t include any judging criteria here. Some hackathons lay out judging criteria (points for creativity, etc.) — we decided against this to make things generally more open / fun. If you do plan on having judging criteria, now would be a good time to lay out those rules.
The next thing we did was decide how to reward people for participating.
First, we catered in all meals / drinks through the event. This makes it convenient for everyone involved, since they don’t have to worry about leaving to grab food. Also, people are generally happy with free food.
We also wanted to give everyone a prize for participating — something that would be fun and memorable. After a bit of thinking, we decided on custom t-shirts. Tom designed this cool t-shirt. Why the Stormtrooper? Almost everyone at Stormpath is a Star Wars nerd, and it’s our company’s unofficial mascot. 🙂
Our amazing office manager Kelsey collected everyone’s t-shirt size, and ordered enough t-shirts for everyone! (It’s good to do this as soon as possible, since t-shirts often take about a week to get approved / printed.)
Once you’ve gotten everything planned and organized, the last big then you need to do is get food / drinks / snacks ready.
The first thing you’ll likely need to do is decide upon a budget for the event. In our case, we were authorized to spend roughly $2,000 for the event (for food, prizes, etc.). Stormpath has about 15 employees, so you can probably use that number as a rough cost figure if you’re planning on providing food, snacks, etc., for your teams.
Kelsey made a Costco run the morning of the event, and got a ton of snacks (chips, salsa, coke, Red Bull (sugar free!), beer, and a few other things). We put out food throughout the hackathon so hungry hackers could much on whatever they wanted.
Kelsey also reached out to local restaurants and placed orders for breakfast, lunch, and dinner. You should probably give restaurants a few days of advanced notice, especially if you’re going to be catering in food for more than a few people.
I think it’s safe to say that the logistics part is most definitely the trickiest part of the planning process. Without someone to actually call all the restaurants, make food runs, etc., you’ll need to put in a lot more effort (thanks Kelsey!).
In the end, we spent exactly $970.69 on the event, and 8.5 hours of logistics work — not too bad, I think!
On the day(s) of your event, there are a few things you’ll want to do:
- Set up some loud speakers in the office area.
- Have a designated DJ (in this case, I DJ’d).
- If you’re going to do voting at the end of the event, print up voting slips (or something similar).
- Make the environment fun — decorate if you can (we didn’t do this, but it would have been nice), open up any offices / closed spaces and allow people to use them for collaboration. Go around and talk with everyone about their projects to make sure people are having fun and enjoying themselves.
For music, I basically DJ’d whatever music I was feeling — but told everyone that they could GChat me any requests — this worked pretty well. We had tons of music requests throughout the event, which made things a lot more fun.
It would also be cool to have an automated DJ, where people can queue up music to play — and it just plays. Maybe next time!
When you reach the end of your hackathon, and it’s time for demos — you’ll want to make sure you have a few things:
- An open space where everyone can fit. Pull up chairs and make sure nobody is left out!
- A projector and laptop cords, so people can hook up to demo their project
- Snacks / beer — this encourages a more relaxing / fun environment! Make it casual!
- Give each team a set amount of time to present their projects. We ended up with 5 teams, and we allowed 20 minutes each. But you might want to do shorter demos if you have more groups.
- Get everyone asking questions about projects, and encourage comments and feedback. This gets everyone talking about their projects in more depth, and keeps everyone engaged.
- Make sure you clap after each team presents. It makes everyone feel all warm and fuzzy. 🙂
And once the demos are done, you should immediately start voting (if you’re going to do it). In our case, we gave each person 3 voting slips and created one bowl for each team. We then let everyone allocate their voting slips amongst the teams – but not their own team.
We then counted everything up, and handed out awards and t-shirts!
We had a tie for first place, so the two winning teams decided to share their trophy with the office. The other teams each got smaller trophies (everyone got one), in addition to the custom t-shirts for participation.
After that, everyone had snacks and beer together, and hung out for a while before going home.
Overall, I’d call our first hackathon a huge success!
After the event was over, I emailed out a Google Form to everyone, which asked several questions:
- On a scale of 1 to 10, how much did you enjoy StormHack?
- Would you like to participate in another StormHack in the future?
- Is there anything you didn’t like about StormHack?
- Is there anything you liked about StormHack?
- What would you like to improve about StormHack in the future?
Every single person gave StormHack a rating of 8 or above, which leads me to believe everyone had a good time.
I also got a lot of feedback saying that it was really nice to take a break from normal work, and hack for a while. Several people said they learned new skills, and thought it was a productive use of time. One person even said the worst part about StormHack was that “it had to end”, heh.
Lastly, I got several comments saying people enjoyed the DJ’ing, so I guess my taste in music isn’t that horrible after all!
Regardless of how you choose to run your hackathon, sending out a Google Form after the event will definitely give you some insight into what you can do better next time. I’d highly recommend it.
In the Google Form feedback, I got some feedback on things that didn’t work so well.
First, it seems like almost everyone wanted to continue working outside of core hackathon hours.. I’m still not totally sure what to think about this one — on one hand, it would be fun to be able to hack at home when the office is closed — but on the other hand, enforcing strict work hours made the event accessible to people who had other commitments outside work.
Secondly, we had several requests to offer healthier food choices during the event. For breakfast on both days we had relatively unhealthy stuff: bagels and muffins one day, and donuts the next.
There were also two other things that got brought up separately:
- Including non-Stormpath employees (turn it into a public hackathon), to make things more fun.
- More planning around incorporating non-technical people into the groups.
During the hackathon, we had non-technical team members join up with engineers and hack on projects alongside the programmers.
StormHack 0x00 was a resounding success!
Through the event, we had everyone team up, spend a lot of quality time hacking on code and building new integrations with our API, as well as some API endpoints, and everyone enjoyed themselves! Some of the projects will actually make it into the product as features in the near future.
In the next week or so we’ll be writing follow up articles about each project that was made during the hackathon, and showing off some of the neat stuff that was developed! We ended up building several very neat projects including a Bitcoin investment platform, an authentication load balancer and proxy, a suspicious activity detector (to detect when a user logs into their account in a suspicious manner), really beautiful website templates, and more!
If you’re thinking of throwing your own internal hackathon, and have any questions at all, please hit me up: [email protected] — I’d be more than happy to give you any additional information you might want!
Lastly, here are some photos from the event – as you can see, we all had a lot of fun 🙂