We’ve been running hackathons at SEP since 2011. Over the years we’ve experimented with the setup. It’s ranged from actual product pitches to technology explorations (and everything in between).
Recent hackathons have settled into a pattern that works well for us. That pattern includes:
- Pitches
- Q & A
- Form teams
- Build
- Demos
Our hackathons run about 48 hours start-to-end. We pitch ideas on Friday afternoon and we demo what we’ve built on Sunday afternoon.
Pitches
The first step in our process is to gather a group of people to listen to pitches of ideas for the weekend. The pitches are well attended. Beyond those participating in the hackathon, we’ll have just as many other people from SEP listening in to the pitches.
Anyone can pitch an idea (or several ideas). The pitches should be relatively short (<5 minutes). We do ask for each pitch to include the following items:
- What technologies are going to be used?
- How many other people are you looking for?
The “what” of the pitch varies wildly. It might involve exploring a new language, playing around with some hardware, trying new frameworks, solving some internal tooling problems, etc. Some recent examples include:
- Building an app with ARKit and SceneKit
- Augented reality interfaces using HoloLens
- Image and face recognition
- Drone control software
- Bluetooth beacons and geofencing
Q & A
After the pitches complete, we move towards some informal Q & A. We all go down to the common area in our building and talk over food and drinks. This is partially a social time but also allows time to get more information about projects you might be interested in. People will mill about and ask pitchers more detailed questions about what they have in mind for their projects. The pitchers might also be using this time to try to recruit people to come work on their idea.
Form teams
Unlike many hackahtons, the teams are not formed going into the hackathon start. Teams are formed out of people interested in working on a project in the moment. People might pick a project because they find the tech interesting, because they have a particular expertise of relevance, or even because it gives them a chance to work with other SEPeers they don’t normally get to work with.
To form teams, we head back into the room where we did the pitches. Then everyone who is sticking around for the weekend writes her or his name up on a sticky note and places it next to a project.
Once everyone has placed themself somewhere, we will go through the projects one at a time and see if that project has enough participants to be viable. If not, we’ll ask which other project they are interested in working on.
When all the teams are formed, the last logistical item is just to figure out where each team is working. Each team will find some place where they can all co-locate to be able to talk easily and grab one another for a pair or to ask questions.
Build
Building is really the heart of the weekend. The teams have through late afternoon on Sunday to build something that they want to demo back out at the end of the weekend.
Most teams will start off using a bit of time for some organizational activities. Depending on what the project is (and who is involved in it) this might involve:
- A domain walkthrough if the subject of the project is technically complex, new to most involved, etc.
- An abbreviated story mapping session to uncover the work
- Using a design studio (or other techniques) to quickly coalesce some ideas about a user interface
Then everyone on a team will grab some of the work and start to build. The “how” of that will vary wildly based on tech stack and team. In general, people will take relatively small pieces of work then merge and push their changes in on a fairly frequent basis.
People will keep building until they decide they’ve had enough for the day and return the next morning. Start and end times for the day vary by person, but pretty much everyone is around between breakfast and lunch and will stay at least a while after dinner.
Throughout the weekend, we break at regular times for food. We have food catered in and will all pause our work for a bit to chat over a meal.
We also use the meal breaks to give a brief update on our projects to everyone else who is around for the weekend. We’ll all go around and share what we’ve been working on since the last update. This is also a time to put out a call for help for anyone stuck on a problem. Given the breadth and depth of experience across everyone at the hackathon, someone will have an answer (or at least some pointers) to any problems brought up.
After lunch on Sunday, teams will start to give more thought to their demo that is coming up in a few hours. They can step back and see how much they were able to accomplish and then prioritize what last few changes they want to get it.
Demos
The last step in our hackathon weekend is a demo. Each team will have time to show off what they built and talk about what they learned during the process. It’s a great opportunity to show off what you built of the weekend and see what other ideas came into fruition.
Some teams will put together presentations / slide decks; others will just talk through their weekend. The narrative part of the demo often involves some lessons learned (especially when things went off the rails during the build portion) and an explanation of what they built.
For the actual demo, the format will vary wildly. If a team built a web application on a new tech stack, the demo could be using the app itself and a walkthrough of their tech stack. A team that built an image recognition framework might setup a camera and have people or objects move across it and watch a piece of software respond. A project controlling hardware might show a laptop hooked up to a hardware rig.
Demos (take two)
The last step in our demos doesn’t actually happen during the hackathon itself. We know that not everyone at SEP can participate in a hackathon. But we know that there are a lot of others at the company who are interested in what their colleagues worked on over a 48 hour span of time. So we provide a way for others to see what was built.
A few days after the hackathon, we’ll setup some tables in our common area. Each time can setup a station and we run a science fair style set of demos. During these sessions, the majority of people at SEP find time to come in, see what was built, and ask questions. Similar to the actual weekend demos, it provides an energizing / fun conclusion to a couple of days of work fun hacking out something interesting.
