I had a great time visiting the Cinchcast engineering team in Buenos Aires, Argentina a couple of weeks ago.
While I was there, we spent a day on a hackathon building some long awaited features for Blogtalkradio.
This prompted me to think - what are some tips for hosting a successful hackathon in a company.
1. Set expectations.
It's hard to build clever and innovative code within 24 hours. It's even harder to make that piece of code ready for Production within such a short timeframe. It's a job of a CTO (or a hackathon organizer) to manage expectations of the business stakeholders about the results. Explain that the hackathon will improve the team morale, teamwork, and may result in key business features. But be upfront that it's likely the code will need more polishing and prioritization in the backlog before it's released.
2. Choose a good working space.
A good working space for a hackathon is key (and plenty of caffeine). I recommend getting out of the office so the team feels a different vibe. For example, in NYC Cinchcast engineering team often goes to hack in the lobby of the Ace hotel. In Buenos Aires, we rented for a day a conference room in Urban Station in historic neighborhood of San Telmo
3. Ignore complaints.
The engineers usually work hard enough during the week so I don't believe that they should sacrifice their weekend for a hackathon. As a result, no matter which day you pick (during the week), it will never be ideal. There'll be looming deadlines and projects that people need to deliver. Most people will love working on something new, but a minority few will always complain. Ignore the complaints! It's for the greater good. Even though hackathons may disrupt the sprint process, people will collaborate with each other, innovate, and have fun.
4. Split into teams of people who usually don't work together.
It's best to break a group into small teams of 2-3 people each. Not everybody in the team has to be an engineer : QA, Product, or Designers should feel welcome to join in and provide valuable advice. Encourage pair programming between engineers instead of each person in a team working separately.
5. Steer the team to work on useful (fun) projects.
The projects need to be ambitious, interesting, and fun BUT they should not be entirely useless for the business. What I like to do is solicit opinion of everybody in a company, asking them for cool ideas for a hackathon. But in the end, the engineers decide which projects they want to work on themselves. As the groups debate, ask them "How will this be useful for the business?" "How will this project be useful for you?" Steer the groups, but let them make the final choices.
6. Have fun (and take breaks)!
Don't just code - take a lunch break together, talk about life and technology. Everybody will be productive this way.
7. Do demos and review the code at the end.
Finally, at the end - make sure everybody gets to look at the cool projects that people built.