Here are my 5 principles of good internal hackathons
On last week’s Commit podcast, Neal asked me about how organizations should run their internal hackathons. Most of the tips are in the first 5 minutes, but I wanted to expand on them.
This is the number one mistake companies make when they organize hackathons. Promise me you won’t do it, OK?
The cold truth is that a company hackathon isn’t really suited for developing your core product or generating IP that will increase your market cap. Forget what you’ve read about the Amazing Breakthroughs™, all that stuff comes later.
Instead, focus on experimenting at the edges of your product and user experience. This is the area where your best people want to play. Set the stage for your team to make new things and have fun solving problems that have always annoyed them.
2. Be open.
Many companies claim to be open. However, the real test is whether you’re willing to be open about things aren’t perfect.
I appreciate that you might not want your competition to know when they are working on. Or to share incomplete features? Would Apple do that? Of course not, but you likely aren’t Apple. So why not show the world what you’re working on?
Users and customers will be happy to see the ideas and tests you are running. It’s entirely possible that they might provide helpful feedback or suggestions — the very feedback you’ll need to determine if these projects should continue into more ‘serious’ development.
3. Press pause on work.
This should be obvious, but no one leaves the hackathon for a meeting, or to take a work call, or to catch up some emails. Set your hackathon date far in advance and tell everyone to clear their calendar. One of the joys of the hackathon experience is extreme focus, so use it.
"If your business dies because you spend 12 hours away from it, then it probably wasn’t that good in the first place."
4. Focus on learning & experimentation.
The advice we always give to hackers attending hackathons is to optimize the experience for their own learning. The approach shouldn’t be any different for internal hackathons.
5. The best ideas not hacks into production.
Fact: not all internal company hackathon projects will make it to production. Unless hackathons are a regular part of your development process, it’s likely that the number of projects that get deployed will be quite low. And that’s fine, remember #1?
A better goal, is for participants to get their idea into the product rather than their hacky code.
For example at one Devpost hackathon a team member created an ‘import from GitHub’ feature for creating a Devpost project page. This feature is now a popular one in our product. However, we didn’t deploy the hackathon version — nope, the feature demonstrated that day simply helped the team understand that is was both possible and worthwhile. That enabled the development team to invest the time necessary to create a version that was up to our product standards.
We applied all of these tips to our own company hackathon and you can see all of our projects here.
For more hackathon tips make sure you subscribe to the Commit either on iTunes or YouTube.
If you have any questions about getting your company hackathon right, post a response here or reach out to me directly: richardsmmurby@gmail.com
Happy Hacking!
Richard