Twice a year Innovation Leader publishes a selection of the most useful and compelling expert advice into Pointers, a downloadable e-book in PDF form. This edition features our CEO Patti Mikula and her piece “Don’t be Dramatic – Hackathons aren’t Innovation Theatre”!
Download your copy of the Innovation Leaders: Pointers fall edition, or continue reading below for our featured article!
Don’t be Dramatic – Hackathons aren’t Innovation Theatre
People love to write off hackathons as innovation theater. They’re not. They are no more “theater” than any other program framework. If done well, you will get results. If done poorly, you won’t.
Not long ago I got a call from the VP of Innovation at a large financial services company. She had asked their Big Four Consultants to design and execute a hackathon for her company. She was surprised by the response. They mocked her, saying she was just chasing the next shiny thing and engaging in “innovation theater.” Undaunted, she called around to a few of her peers and was put in touch with me. She asked me outright if hackathons were innovation theater, or if they could deliver real value. I gave her my honest opinion: If you have clear, actionable objectives, then a hackathon can help you achieve them. If you are doing a hackathon to have the appearance of being innovative, you are engaging in theatrics. But in my view, the same criticism can be levelled against any tactic – particularly cutting-edge ones. If you are creating a TikTok account to go viral, you won’t. But if you want to reach a hard-to-impress demographic, then hop on your skateboard and grab your bottle of Ocean Spray and have at it. (Spoiler Alert, the VP of Innovation hired us to design a hackathon program for them. It met their objectives and they became a return client for us.)
Here is my list of things not to do when planning a hackathon.
The Devil is in the Details, But Don’t Start There. When you are planning a hackathon, there is a temptation to start with the fun bits. Maybe you have a venue in mind, or want a giant donut wall. Those things can go a long way to enhance the participant experience, but that’s not where you should start. Always start with articulating your objectives. What do you want to achieve with your hackathon? I list some good objectives:
- To find great talent that otherwise may not consider working for your company
- To explore how new technologies could impact your product or services
- To solve a big, hairy problem that your company is grappling with
- To teach important innovation skills and confidence to your workforce
- To engage an external developer community to test or adopt your software, API, or tech
- To find startups that are making waves in your industry to hire, acquire, or fund
Put Your Needs Above Those of Your Participants. Now that you understand the value to you and your organization, you need to understand the value to the participants as well. At the end of the hackathon, you want everyone to walk away feeling like they had a great experience. We’ve heard lots of bad reasons to host a hackathon; while many may meet the objective of the host, they fail to ensure that the participant experience is equally valuable. Here are some signs you may be prioritizing your needs over your participants:
- You are looking for ideas on how to improve your product or service. If your participants are your employees, this is great! If your participants are from outside of your company, this is tricky. The IP from a public hackathon belongs to the participants. If you want to incorporate the tech or ideas into your roadmap, you will need to compensate the participants appropriately.
- You are looking for the one solution to rule them all! A great hackathon will generate some great solutions to whatever challenge you put to the participants, but it’s important that even those that don’t win have a viable market path. Make sure your challenge is broad enough to sustain multiple solutions.
- Your company needs a new website. NOPE, hackathons aren’t free labor.
Don’t Assume Your Participants Have All the Knowledge to Solve the Problem. One of the criticisms of hackathons is that participants don’t have the “big picture,” so they are pitching ideas that have already been tossed aside as impractical or things that are already in the pipeline. But this isn’t a flaw in the framework. It’s a flaw in the data. Hackathons, especially internal ones, are great opportunities for education. If you don’t want your participants to come up with ideas you already have in your pipeline, make sure you share the pipeline! If your hackathons keep surfacing the same ideas that have been deemed impractical or undesirable, then share those ideas with participants. If your participants are designing solutions that don’t take “x” into consideration, then make cross-functional teams so the solutions they design have a broader perspective taken into consideration.
Trust me, your participants don’t want to serve up the same ideas that have ended up in the innovation lab trash bin any more than you do. But they can’t pivot if they don’t know what has been explored already. And if people keep suggesting the same idea, that has been tossed aside each time for some reason or another, maybe the idea isn’t the issue.
How many times do you think someone sat in a boardroom and suggested that we should be able to deposit checks by taking a photo of it through an app? Certainly, more than once. And every time it was tossed aside for a variety of reasons: security, regulatory, etc. Until 2009 when Element Federal Credit Union decided the reward outweighed the risk and rolled out the feature. They fought the good fight with the regulators. They designed a UX that would make customers feel comfortable and secure. Instead of bowing to all of the reasons not to do it, they tackled them. They were the innovation leader that countless others have followed since.
Don’t Forget the Follow-Through. Right up there with understanding what you want to achieve with your hackathon is understanding HOW you will achieve it. Don’t let great solutions die after the hackathon ends. If your objective is to identify great talent (externally or internally), then have your HR team on board to pick up where the hackathon ends off and get those individuals into the right pipelines. If your objective is to solve a problem and build IP, then have engineering resources set aside to work with the winning team(s) to continue the prototyping process, get it built and into production. If your objectives are more about the journey than the destination – you want your participants to learn, to build innovation competency and confidence – make sure you have a way of continuing to nurture these innovation champions.
In conclusion, if someone tells you hackathons are just innovation theater, don’t believe them. When done correctly, they can build strong teams and cutting-edge solutions, and can be a key tool in the innovation leader’s toolkit.