December 5, 2013
Occasionally I like to yield my "bully pulpit" to folks on our team that I collaborate with on joint research projects – and today is just such an occasion. Over the past few months I've been working on research with Vivian Brown on the in's and out's of public and private hackathons. It was interesting when we started this research – we got more than a few puzzled looks and questions like "why would developers want to spend their own personal time writing code?" and "hackathons might be great for start-ups and Valley companies, but will they play in Peoria?". My own personal response to these questions was to refer folks back to a stream of research I wrote in 2010 on building high-performance development teams. In my opinion a well-run hackathon is the developer equivalent of a musicians' jam session. At their core the best developers are makers – creatives who are intrinsically motivated to create and get a charge out of learning something new or building out someone else's inspiration. It's one expression of a building wave of "Social Development" that is changing the way development works, and how firms relate to developers and vice versa.
But enough rambling. I'll turn things over to Viv. Right before Thanksgiving, Salesforce hosted a well publicized "Million Dollar Hackathon" – and the results were a bit mixed. Viv's thoughts on it below:
Make Hackathons a Win-Win
Last week, Salesforce.com hosted a million dollar hackathon. The motivation was clear: a million dollar prize generates a ton of media coverage and jump-starts third-party development on their new mobile platform. Unfortunately, the results were less than stellar. The rules stated that participants had to submit a new mobile app built solely for the event, but the winning application was a modification of an app that had already been demonstrated weeks before the contest began. On top of that, one of the winners was a former Salesforce employee, inviting accusations of favoritism. Meanwhile, some participants found that their code hadn’t even been run during the judging round. What Salesforce hoped would impress potential developers backfired into a storm of bad press, leading Salesforce to name a second winner (and hand out a second million dollar prize).
Developers’ time is valuable. If you use hackathons as a source of low-cost labor, participants will walk away feeling taken advantage of. To get hackathons right, hosts need to make sure that the event is a win for everyone involved – including those who leave without a prize. To make sure the event is beneficial for everyone, think about what contests hope to get out of it.
First, hackathons attract intrinsically motivated developers who love to compete. Hosts should make sure the atmosphere is competitive and fun, which plenty of entertainment and opportunities to socialize. Great prizes up the stakes, adding to the excitement to the competition. The chance to learn cutting-edge technologies can also be a draw. On the other hand, nothing spoils a competition like hints of unfair play. Hosts should provide clear guidelines at the beginning of the event and then stick to the rules laid out. Judging needs to be open and transparent, considering all entrees. That way, participants will feel that their competitive energy was well-spent.
Entrepreneurial developers also go to hackathons to promote their own ideas. Give developers a platform to show off what they’ve built – to other developers at the event, to judges, and in media coverage after the event. For hackathon participants with a start-up idea, a write-up in TechCrunch can be just as valuable as a cash prize.
Finally, hosts should be clear about what happens after the hackathon. Who owns the ideas that were generated? How will they be put into use? If any ideas get picked up for development, follow up with developers to let them know what became of their designs.
To learn how to make enterprise hackathons work for your organization check out our report, “Energize Your Developers With A Hackathon”