 |
| Credit: spydergrrl |
Them: "We're going to run a hackathon."
Me: "Why?"
Them: "What do you mean, why?"
Me: "What are your goals? Who are you inviting? What kind of experience would you like them to have? What outcomes are you looking for? When you award a prize, what happens to the rest of the solutions the other participants created? What happens post-event?"
And then I usually get un-invited from future meetings.
True story. And more than once.
After having run several design jams, mentored and supported a number of hackathons, designed and led countless workshops over the years, I think that these events generally have a design problem.
In that they often don't get designed.
People quickly put a hackathon together using guides they find online, throw out invitations to random people, get a space and mentors and hope for the best. At the end, they award a single winner and send everyone back to their lives. Six months later, nothing comes out of it. Because a hackathon is a sterile environment where "the problem" being defined and addressed doesn't necessarily (usually) reflect the realities of everyday life: that is, real users, real circumstances, and real pressures.
So no matter who wins, the solution isn't necessarily transferable back into the organization without a significant amount of investment or rework. The ideas aren't built for sustainability and re-use; they're built for and in the vacuum of the hackathon. But someone somewhere considers themselves cool for having done something innovative in their organization even though no one really benefited in the end.
Ugh.
Initiatives of any kind tend to fail when they don't have clear goals and don't produce tangible results. Hackathons are no different. Usually, a hackathon is being bandied about as an idea for all the wrong reasons:
- It's a "quick innovative win".
- It will help engage, entice and/or recruit the younger demographic.
- It is a low-cost way to generate ideas and crowd-source solutions.
- and so on...
If the answer to either of those questions is "No", they shouldn't be doing a hackathon. To be honest, I think the hackathon format best suited to one of two things:
- Encouraging entrepreneurship: Events like Startup Weekend evaluate participants on both their business plan and minimum viable product, which provides them with a well-rounded experience beyond just focusing on the technology.
- Solving a specific problem with technology: Events like Hacking Health which have a long lead time during which teams can explore problems, meet regularly to learn skills, conduct research, and eventually culminate in an app challenge. The entire user experience can last months prior to the actual hackathon, providing a solid foundation before the participants get down to work at the event.
You can probably think of other specific situations where hackathons work well, but in my opinion, those are the best two I've seen.
So if a hackathon isn't the solution, what is? That depends on what your organization needs. Here are some questions to help you figure that out:
- First of all, start with the question: What do we want to do the day after the event? What outcome/ information/ solution do we need to move forward?
- What was the catalyst for the event? Audience engagement? Recruitment? PR? Brainstorming? Sustained idea generation? A new approach to an old problem?
- What will we do with the outputs of the event? As in, ALL of the outcomes? Will we support ideas beyond the event? Will we incubate a number of good ones? Will we offer support to participants to maintain momentum? Are we committing funds to this? How will people find the time to work on it in order to make their ideas a reality? If we have no intention of fostering the ideas post-event, then...
- What experience do we want for our participants? Who should we invite? Do they need a particular set of skills to participate? What happens if we end up with a widely varied audience; will they be able to generate the outcomes we are seeking? How will they feel if they produce a solution that goes nowhere? What would we like them to gain from this experience? Do we want to teach them anything or help build specific skills?
- Is this event a one-off or is this a program? Will we run more events? Are our mentors available for ongoing consultation? Do we want to build a community so they can support one another? Do we want to tap into this audience on an ongoing basis for new ideas? Do we intend to tie events together to help grow ideas?
Once you consider these questions and consider your constraints (time, people, budget, facilities), your event style will likely emerge on its own.
- If you want to recruit/ teach/ engage people, some combination of skills development and co-design would allow participants to both learn and contribute.
- If you want to generate new ideas for existing problems, a facilitated working session between actual clients and participants would foster co-design, allowing clients to validate the participant ideas against their real-world experience.
- And so forth...
More often than not, the answer is some sort of collaborative working session that combines facilitated work with co-design, whether it's a design jam, a workshop, facilitator-led working sessions, an incubator model or even short-term pilot projects...
So, next time someone says "Hackathon," don't automatically assume that's the right answer. Ask questions, define the desired outcomes for both the organization and the participants. And then design a session that will benefit everyone involved and be more likely to generate those outcomes. And those are measurable expectations that you can use to define whether or not the event was a success.
Who knows, maybe you'll throw a hackathon anyway, but at least you'll know why you did and what you planned to get out of it. And that is a win regardless.*
_____
*But don't be offended if they don't invite you back to their planning meetings once you start asking questions. Not everyone likes to design fit for purpose. Keep trying! Can't win them all, but you can win some. ;)
Thanks to @sagecram and @lovelace for their support on this piece.