How to Plan a Good Hackathon

Over the past decade, I've hosted a lot of hackathons.

Agency-side at Mutual Mobile | A Grid Dynamics Company we shut down the agency for Blend Day, an all hands experience where 100+ engineers tackled innovation prototypes that led to winning new clients. At Rithmio we employed mini hackathons to develop prototypes that demonstrated the potential for gesture-based products powered by our wearable tech platform. At 嘉吉 , our internal software product team sourced future features, moonshot ideas ideas for incremental enhancements from Enterprise-based product owners to fuel our 3-day innovation exercises.

No matter whether you're an event planner or the VP of Innovation, effective hackathons drive impact to retain accounts, land new clients, drive PR exposure in industry, retain and develop top tier talent, and even entice talent to join your company. To do it well requires a keen ability to stay laser-focused on each audience segment's needs, ensure strategic alignment with the company and follow through on pre, during and post event activities.

Audience Needs

A hackathon is nothing without people to plan it, participate in it and champion next steps. Lean into your marketing 101 skills to clearly define the audiences that the hackathon will need to serve, do some discovery to better understand their needs, and assess how your hackathon will create value for them.

Let's take employee participants. Early career or new employees will feel rather stressed out participating, as they perceive there are high stakes to demonstrate their worth and match outputs with more senior staffers. Consider striking a balance of seasoned or newcomer talent across your hackathon teams to ensure the team culture is supportive and safe. Or, perhaps release the teams pre-event, so that more junior personnel can have time to build and build rapport pre-event.

Or consider more senior employees. They have aggressive deadlines, scrum coaches on their case, demanding clients breathing down their necks. You'll need to plan well in advance to ensure their calendar is adequately blocked out and the project management organization has visibility to the blackout dates to inform roadmap adjustments on their project plans.

Or even take different functions of employees participating. Product coaches or business people participating in the experience will feel anxious, "how can I participate? I'm not an engineer!" Find ways pre-event to hight examples of how non-designers and non-engineers will add meaningful value. You may also consider training business people on tools such as Figma, UX research techniques, how to build an effective pitch to how to lead market analysis for startups. These toolkits will help them feel more comfortable as to how to collaborate within a fast-paced innovation team.

Strategic Alignment

Before you start planning any hackathon, it is essential to build an event plan, define how value will be created and ensure it aligns back with business objectives. Also, all outcomes can't be equal. They need to be prioritized.

At Mutual Mobile, our primary objective with Hackathons was to retain and develop talent. Also, we wanted to use hackathons as a way to showcase work we do that is not under an NDA, so we could attain awareness benefits to court talent (and also win new clients). We prioritized the employee experience pre, during and post event. We also identified that publicity and portfolio-building activities were important to our employees, so we invested in those areas. For example, we even invested in a video crew to follow along throughout the experience (thank you, Johnny Bones ) to invest in assets that matched the energy of the event. We also developed public-facing blog posts and case studies to showcase the prototypes built, so employees could put their work out in the world.

Maybe your event's return on investment has to do with helping the entire company navigate a new market or industry shift. I once hosted a hackathon focused on sensor kits powered by Texas Instruments (now 10+ years ago). The dev boards gave software engineers a friendly starting point to explore hardware without having a specialized background. SDKs were marketed as ready to go for engineers of all levels. Just to be sure, I brought in senior engineers from our agency to explore the sensor kits and SDKs. We quickly realized the marketing messages didn't match the engineer experience. Our senior engineers had to incur several cycles to expand upon the code to make the IoT kits friendlier and more usable for our team. In doing so, they were also able to draft better technical documentation, which helped our actual event take place much smoother. Test out any tech that will be a required building block well before your event, as there are bound to be "gotchas".

Pre, During and Post-Event

Hackathons require more scope than you may anticipate. I strongly suggest you approach a Hackathon like a major event that has components pre, during and post event.

Pre Event

The planning of your Hackathon should start months, yes months, before your target event date. During this time period, you're responsible for defining target outcomes, gaining buy-in from the executive team and functional managers, and assessing the group of people that will be required to fulfill the experience. Stay objective and pay close attention to the risks. For example, what if you're at a company that stinks at brainstorming and innovation exercises? To address this gap, you may need to assign facilitators and improve their ideation techniques and skills pre-event.

Pre-event you'll also need to decide what type of ideas your event will support. Will your event be narrow, and you'll be responsible for sourcing prompts from business stakeholders? Will your event have a theme such as sustainability + tech + food, to create thematic guardrails for participants? Or, will your event be wide open, which means pre or during the event your participants will incur time to come up with their own ideas to pursue? Each format has its own risks and benefits. I prefer more narrow structured hackathons where we have tight themes + 3-4 key concepts for teams to draw from. Or, I usually see the strongest ROI when I approach existing business and product leaders for prompts, develop the prompts to be right-sized for a hackathon, and give participants an option to sign up for the prompt of their 1st, 2nd or 3rd preference.

Finally, this is an experience. How can you get the word out? How can you drive buzz? How can you proactively address your target audiences' questions and concerns? How can you get sign ups early? What % of your audience has done a hackathon before, and what are their perceptions? Also, what's in it for them? Will there be prizes, bragging rights, executive-level visibility? Define the perks to support the awareness campaign and drive participation.

During the Event

There is no partial participation in hackathons. I will repeat... there is no partial participations in hackathon. And if you have leaders claiming to participate, but in effect they're actually stepping in and out to do business calls - ask them to step back as it drags down the rest of the team. All participants are fully allocated and their time out from the daily grind needs to be budgeted for and protected.

You'll need to host a kickoff. Bring your best energy. Pick a likable host with good charisma. Get people excited, motivated and in a different mindset. During this part of the experience, you're energizing your participants, explaining why we're doing a hackathon, providing guidance on how to operate, walking people through the prompts and breaking people out into teams.

Your top or most senior teammates will be instrumental when coaching across multiple groups. Consider allocating a senior engineer across 2-3 prompts, so that they can help quickly unblock issues. You may also consider formalizing a help desk chat thread or literal desk, so as people get stuck they know where to go in order to receive help.

Access to clients or subject matter experts during the event is another consideration. If you're sourcing prompts from your clients, in a good brief and input materials you may be able to capture the key insights. However, in a best case scenario, you've identified subject matter experts for each prompt and booked out workshop time with them and the hackathon team to ideate together. This way the experience is more immersive, the end client participates in the solution-shaping (thus is more likely to steward it moving forward), and it helps your employees expand their network.

I also find it useful to have a plan for hackathon operations. Which repo should devs use? Do you have a section on Figma to aggregate all hackathon design concepts? Where should pitch decks go on the server? These details matter, as they improve the target outcomes. Sadly, I've seen hackathon planners not anticipate the operations aspect, which ultimately leads to lost files and wasted time and effort.

Don't also forget about human needs. To help keep people focused, think of this like a high-touch conference. Breakfast should be provided, a snack cart should be wheeled around, bring in good coffee, provide lunch and have grab n' go snacks. If you're asking your employees to incur the stress of fast-paced innovation, address their human needs to help keep them on track.

Also, hackathons have a horrible history of asking people to give up their lives around the clock to innovate. Set boundaries up front, so people know what they're in for. It is inexcusable to package up a hackathon as a perk or fun experience, and then turn it into an employee abuse situation where you're asking employees to work 24-7 in the name of innovation. Your employees are smart, and they'll see right through this. Make the experience fair, and address this negative aspect of hackathon history upfront by encouraging employees to only hack between working hours.

Post Event

I think of post event in several phases. First, is the internal-only demo. As implied in the name, this ritual is intended to be a closing exercise for participants only to showcase what they accomplished under a time constraint to each other. It is a safe environment to pitch, without having to stress about executives or clients listening in. Also, decoupling an internal demo from a public demo gives team leads time to coach participants on how to improve their pitches to drive greater impact with execs.

The next step is to promote the public demo. This calendar invite should have been booked out well in advance, but now is your opportunity to market it and drive buzz. Tease out what the teams worked on. Ensure VIPs from related domains are invited. Or, consider even doing unique demo days for various audiences, thus the demos will have a common theme.

Speaking of demos, something engineer leaders usually fight me on is the length of demos. In today's short attention span culture, no one wants to hear your hackathon demo if it takes longer than 5 minutes. I strictly enforce this constraint, as it drives a better experience for your audience listening to the demo. It also will help hackathon participants develop the skill of selling their idea in a short time period. We give 1 min and 30 second warnings, and will unmute and cut off a presentation when the time runs out.

Public demos should take place about a week, max 2 weeks, after the actual hackathon. You want to maximize the window of time for teams improving their pitches, catching any final bugs in their prototypes and presenting in a charismatic way. However, if you push the public demos out too far, your team will forget what they build and you increase your risk that demo files will get broken or lost. Public demos should be hosted and provide a professional event experience for the audience. I discourage Q&A, as usually the questions aren't meaty or the audience feels bad if a presenter receives no questions.

Following public demos, you should do a marketing push. This is part of your promise to hackathon participants. Market their work. Put it in the spotlight. Help them grow their professional brand within your company. Invest in video demos, case study blog posts or posts highlighting the innovation process as a whole. This is important to do, as it shows employees their work and effort mattered, and is of high value to the company. It instills pride.

Another best practice is to regroup with the clients and SMEs that submitted prompts. Re-demo the hackathon concept to them, solicit feedback and assess how to proceed. Often good hackathon concepts can lead to discovery engagements or spark other ideas of initiatives worth pursing.

And finally, it is retrospective time. Send out feedback surveys to your hackathon participants. Request feedback from your senior staffers that helped plan and host the event. Request feedback from clients that submitted prompts. Request feedback from management. Compile the results, publish them and build out a checklist to address areas to improve the next time you host a hackathon event. Also, stay close to any new business opportunities or client projects that were influenced by the hackathon, as connecting the dots between revenue generated tied back to hackathon event is an important metric to package up for management.

Closing

There are nuances to every hackathon, and what works within one team or company may not translate well to other settings. I hope some of the best practices I've noted above may help your team incrementally improve an upcoming hackathon you have planned, or perhaps inspire you to break free from the daily grind and help your team co-innovate.

Photo Credit: https://www.shopify.com/stock-photos/photos/business-pug-working-on-laptop