Last week, we officially kicked off the second ever Stormpath company hackathon: StormHack 0x01. Our first StormHack event took place a little over two years ago (wow, the time really flies!) and was a huge success: our team built quite a few high-value projects, everyone had fun, and it was a huge morale booster for the team.
This time around, we had similar results. StormHack was incredibly productive, valuable, and most of all: fun.
In the spirit of openness, I thought I’d continue the tradition of sharing what worked, what didn’t, and what I learned throughout the hackathon, to give you a better idea of how you might want to run your own hackathon at your company >:)
If you work at a company where a hackathon has never been done before, you might run into trouble selling the idea to your leadership. While I didn’t have this problem at Stormpath (we have great executives, what can I say?), there are definitely some things I’d recommend when trying to sell the idea of an internal hackathon to your boss(es).
Evangelism is not only about reaching out to developers external to your company, but also being able to bridge gaps internally as well.
By understanding both the pros and cons of running an internal hackathon, you can more likely convince your company leadership that it’s a good idea.
The largest problem people tend to have about hosting an internal hackathon is that it will directly take away engineering time.
At small tech companies, engineering time is usually the single largest constraint. Taking time away from core engineering is usually not something you want to do, as it slows down product momentum, causes timelines to slip, and may negatively impact customers.
Furthermore, if you pull your DevOps / ops / systems team off infrastructure for a few days, and your systems are not 100% reliable, then you run the risk of having public outages and all other sorts of problems.
There’s also the big issue of cost. Getting everyone together for a few days to work on creative projects can potentially cost a lot of money.
On the opposite side of the spectrum, running an internal hackathon can be great for a lot of reasons.
Team bonding. Regardless of how you run your hackathon, one of the guaranteed side-effects is that your teams will have time to bond. By getting everyone together and reserving time to work on creative endeavors, you foster an ideal environment for people to hang out, collaborate with others they may not normally work with, and generally have fun.
There’s also something about a slightly competitive atmosphere that brings out the best in people, and gets them to more closely bond with their teammates. Working hard towards a single goal with a small group of people gives everyone a chance to really get to know their co-workers.
Exercising the Product. When you’re constantly working hard to improve a product, one of the things you frequently forget to do is take a step back and evaluate your product from a new perspective.
Taking some time to work on creative projects for a few days gives everyone the chance to work with the product in a way they may not normally experience. Having the ability work on something new often provides a fresh perspective on what things need to be fixed, improved, and (maybe even?) removed in the future.
Creating Valuable Things. One of the best sells to executives is the fact that during an internal hackathon, all employees are working on new, creative ways to improve the product in some way.
At StormHack, for instance, we had teams build new (and very complex!) core API features, marketing materials, and user onboarding tools. These projects have contributed a significant amount of value to the company in a very short amount of time, all without any sort of management overhead / process in the way.
Keeping your company thinking about new ways to expand and improve your business is incredibly important in ensuring that your company continues to innovate. Hosting an internal hackathon is quite possibly the best way to accomplish this in a short period of time, with minimal investment.
Reducing Technical Debt. Another popular reason to throw an internal hackathon is to eradicate technical debt. While this isn’t one of the reasons we threw StormHack, it’s still a great reason to have a hackathon.
As a product grows and matures, maintaining a balance between shipping features and keeping a sane amount of technical debt becomes more and more challenging. Giving everyone on your team time to reduce technical debt without any other pressures can do wonders for engineering morale, product stability, and maintainability as a whole.
When organizing a hackathon (or any event, really), the first thing you should do is draw up a schedule so you have some definitive boundaries to work within.
The StormHack schedule looked like this:
June 15 (Wednesday)
- 12pm -> 1pm: Idea pitches (during lunch)
- 3pm -> 6pm: Finish idea pitches, break into teams, and plan out projects (no coding)
- 6pm: Dinner
June 16 (Thursday)
- 8am: Breakfast
- 9am -> 12pm: Hacking
- 12pm: Lunch / hacking
- 12pm -> 6pm: Hacking
- 6pm: Dinner / hacking
- 7pm: Coding stops
June 17 (Friday)
- 8am: Breakfast
- 9am -> 12pm: Hacking
- 12pm: Lunch / hacking
- 12pm -> 4pm: Hacking
- 4pm -> 6pm: Demos
- 6pm: Awards / dinner
When I ran the last StormHack a little over two years ago, one of the main bits of feedback I got from the team was that a decent number of people wanted to continue working on their projects after work hours.
Although it was tempting to give people unrestricted project time during the event this time around, I decided not to, as it wouldn’t be fair to people at Stormpath who have families, outside commitments, etc. Depending on your company culture, you might want to tweak this to what works best for you.
Now that we’ve covered the schedule, let’s talk about how the hackathon event actually works.
The goal on Day 1 is to give everyone a chance to pitch their ideas to the rest of the team, recruit team members, and plan out their projects.
In my opinion, Day 1 is the most important part of the event. It’s really important to let everyone know upfront how the teams and idea pitching works so there isn’t a lot of confusion. If you do a bad job of getting everyone to pitch their ideas and break into teams on Day 1, the rest of the event won’t work very well.
The way we handled idea pitching at StormHack worked really well. A few weeks before the event, I sent everyone on the team an email with a link to a Google Sheet that had a couple columns:
- Submitted By
I encouraged everyone to start thinking of potential hackathon ideas that would be useful to Stormpath in some way, and to add them to the list. This way, everyone on the team could get a sense for what sort of ideas people had, and start to think about what they want to work on in advance.
When the actual day of the event came, we got everyone together in the Stormpath dining hall, and I invited everyone who had an idea to pitch that idea to the rest of the team. This way, everyone who had an idea they wanted to work on would have a chance to get other people interested in the idea, and recruit people for their team.
Each of the pitches included:
- A description of the idea.
- A little bit about why the idea is awesome.
- A list of people needed to complete the project. This part is particularly important in companies where not everyone is technical. Having people explain what non-technical help they need on their team is really valuable, as it makes everyone feel included and important.
While this was going on, I was taking note of each idea, and the person who submitted it in a new Google Sheet.
After everyone had an opportunity to pitch their ideas, I then read through the list and had everyone vote for their favorite 3 ideas (by raising their hands). I tallied up the results, and we used this to narrow the list of many ideas down to just 10.
The reason we did this was because we wanted to encourage people to work together in teams, and to not have a lot of teams with just one person on them (that wouldn’t be very fun for team bonding!).
Afterward, we then used hand raising to go through the list of the top 10 ideas and assign people into teams.
Before the event started, we decided that teams must have 2 <= n <= 5 members in order to encourage both collaboration and diversity of ideas. While it wouldn’t be fun to have a lot of 1 person teams, it also wouldn’t be fun to have a single team with 20 people on it, going against another team with only 2 people.
NOTE: In the event that more than 5 people wanted to work on a single team, we would have let the person who pitched the idea pick which people got in. Luckily, however, this didn’t happen =)
After all the teams had been formally decided, we then broke up into our newly formed teams, and went off to plan our projects.
Project planning is incredibly important, especially when you only have a short amount of time to build a project, and you’re working with people you may not work with often.
The idea here is that when each team goes off to plan, they should:
- Figure out exactly what they’re building.
- Sketch out any mockups they need.
- Assign tasks to each person on the team.
- Make a realistic timeline for each part of the project.
- Figure out how they want to do their demos at the end of the hackathon.
- Do any necessary research.
This way, once Day 1 is over, every team will be 100% ready to come in the next day and immediately start building things!
The goal on Day 2 is to build things as fast and furiously as possible =) Other than breaks for eating, the goal of Day 2 should be to do a majority of the project work.
The goal on Day 3 is to finish up the projects, prepare a small demo, and pitch what your team built to the rest of the company so voting can take place.
At StormHack, I basically called up each team in random order and gave them 10 minutes to present. This took a little over an hour and a half.
Depending on how big your company is, you may want to reserve more (or less) time for project presentations.
NOTE: One thing I should have done better was to let each team know how long they had to present in advance. Several teams ended up going over their allotted presentation time, and had to be cut off early 🙁 Next time, I’ll be sure to explicitly write it out, and remind teams during the event how long they have to present, so they can prepare accordingly.
Once the presentations are done, it’s time to vote!
The way we handled voting was pretty good, I think:
- We got paper bowls and attached a Post-it note to each bowl with the team’s idea / name.
- We then gave each person in the room 3 paper voting slips.
- We told everyone to go up and place one voting slip into 3 separate team bowls (to vote for the top 3 teams).
The rules were that:
- Each person could only put one vote into a team bowl. This means you had to vote for 3 teams.
- You could not vote for your own team.
Once we tallied up all the results, we found the top 3 teams (by votes), and called them up to front to receive their hackathon trophies =)
We decided against doing expensive cash prizes and the like because that might cause ultra-competitive behavior (which we didn’t want). We instead opted to give the top 3 teams custom StormHack trophies.
After all the awards had been handed out, Brian started playing the Star Wars Imperial March music, at which point I pulled out the participation prize for everyone: custom ordered StormHack medallions:
Everyone then came up one at a time, and I placed the medal around their neck. It was a really fun way to end the event, and made sure that everyone felt they won something for their hard work. It was a really good time all around.
Finally, after the medals had been given out, everyone hung out for a bit before heading home to catch up on some much-needed sleep =)
On the logistical side of things, here’s what we did at StormHack. When running an event like this yourself, you might find some of these considerations useful.
A week prior to the event, I sent everyone an email with a link to a shared Spotify Playlist I had created. I told people to add their favorite music to the list, and that whatever was there would be played throughout the office on shuffle during the event.
This worked out fairly well (we only had speakers in our main open space), because people could go into conference rooms and shut the door for privacy / quiet, as well as put on headphones and ignore it if they wanted to.
I’m still not sure if this is the best solution, as people have such widely different taste in music. But, I can most definitely say that music is needed during this sort of event to create a good atmosphere! So, at the bare minimum, you should have speakers around that you can use!
Total Cost: $0
If you’re going to run an internal hackathon, you might as well get some good video / photos out of it! During StormHack, we had Lindsay take pictures, record video, and even setup a reality TV-style camera booth.
The camera booth was really fun: we setup a GoPro camera in an empty conference room, and told people they could go into the room and record whatever they wanted for future usage. We had people tell hilarious stories, do crazy stuff, and just overall have a lot of fun.
We’re going to eventually edit these videos together into a Stormpath recruiting video of some sort, or maybe just play it at future company BBQs and laugh =)
Total Cost: $0
When running an internal event like a hackathon, making everyone feel like part of the group is really important, especially when one of your main goals is team bonding.
What we did to help with this was generate a custom StormHack 0x01 t-shirt design from CustomInk, and then send out a Google Form to everyone on the team two weeks in advance asking for each person’s t-shirt size.
On the first day of the hackathon, we gave the shirts out to everyone to wear and took advantage of this on day #2 in order to get a big team picture together.
Overall: the t-shirts went over really well — people loved them and felt like it made the event better!
Total Cost: $836.51
As I mentioned earlier, we decided to give out custom trophies to the top 3 teams, as well as custom medallions to everyone who participated. We ended up ordering the medallions through TrophyDepot.
The trophies were purchased by our office manager, Sarah, and the custom Stormtrooper figurines were purchased at the Disney Store nearby. =)
Total Cost: $482.96
At Stormpath, we have catered lunch every day in the office. We use ZeroCater for this. They’re a catering startup that handles all of the food creation, pickup, and delivery for companies.
What’s nice about ZeroCater is that they let you specify food allergies, etc., and have a nice schedule that everyone can see for each week. So, if I’m curious about what food will be served for lunch this upcoming Friday, I can take a look at ZeroCater’s website and know. =)
For StormHack, we basically let ZeroCater know that we’ll also need them to cater breakfast and dinner each day, gave them the times, and that was it! They handled the rest.
We also ordered lots of additional sodas, energy drinks (my personal favorite, mmm), and various beers and liquors which we had delivered directly to our office.
Total Cost: $6,118.16
Without question, the most expensive part of StormHack for us was travel costs. We have quite a few remote employees, and flying them into the area, and taking care of things like transportation, lodging, etc., was a large expense.
For companies where everyone is local (or everyone is remote!), this won’t be an issue.
In total, we flew in 6 people (7 if you count me) for the entire week of fun / activities.
Total Cost: $9,410.06
With everything included, StormHack cost us roughly $16,847.69 (for a team of 37 people).
If you take the amount of direct project value, team bonding, overall fun that was had at the event into consideration, I think you’d agree that overall, $16,847.69 was a small price to pay for such a valuable experience.
Since we’ve now discussed all of the hackathon scheduling and rules, let’s talk about how StormHack actually turned out!
Overall: things went very well. In terms of value: out of our 10 teams, each team delivered an incredibly valuable project for the company. Some of the teams have already made their projects publicly available to the world (which we’ll be talking about in later articles), and some will be released in the coming weeks.
In terms of a sprint, StormHack yielded some of the coolest and most useful new product ideas we’ve ever had. For a small 2.5 day break from normal work, this output far exceeded any expectations we had going in.
When the event was over, I sent out a simple Google Form questionnaire to everyone that asked 5 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 really liked about StormHack?
- What would you like to improve about StormHack in the future?
For #1, the average person rated StormHack as a 8.9/10. That’s a pretty high average score, meaning that most people really had a good time!
For #2, every single person (except one) said they would like to participate in another StormHack event in the future.
For #3, we got several interesting answers regarding things people did not like:
- People wanted to keep working after hours and not be required to stop
- People wanted to repeat the event more frequently =)
- People got annoyed with the music (everyone got to put their favorite songs into a shared Spotify playlist that was blasted on speakers around the office)
For #4, we got lots of good feedback on things people really loved:
- People really enjoyed working with different groups!
- People really enjoyed the atmosphere, drinking (we had beer out through the duration of the event), and the music being blasted around the office (even if they didn’t necessarily like the song selections)
- People liked working on new projects for a change
- People liked demoing their projects in front of everyone
Finally, for #5, we got great feedback on what people would like to improve:
- People wanted the event to last for a full week instead of just 2.5 days
- People wanted more balanced teams that had a good mix of new / experienced Storm Troopers
- People wanted the voting system to be more automatic. Maybe next time we’ll build an app or something to make the voting process simpler / easier
- People wanted to see more of the company involved (this time around our ops team declined to participate, in order to help keep the infrastructure alive)
- People wanted the event to take place much more often
Overall? The event was a great success! People had fun. Valuable projects were built. And much team bonding was had.
Running a company hackathon can be an incredibly rewarding experience for everyone involved. I know that for me, personally, the past two StormHack events have been some of the highlights of my career.
The ability to hack on creative projects, get everyone involved, and take a break from normal work to focus on outside-the-box things is fun, exciting, and incredibly valuable.
If you decide to run your own company hackathon, please email me or leave a comment below! I’d love to hear how it goes, and I hope you have as much fun as I have.
Finally: I wanted to give a huge shoutout to Tom for reading and reviewing this for me when he was already super busy, as well as Sarah for doing a killer job with all the logistics, keeping everything running smoothly, and handling everyone’s last minute problems =)
Team Stormpath, out.