After blogging about my past insights at hackathons I’ve come up with my own ideal hackathon. I’m sure it has flaws, but here is how it stands right now…
Why do a hackathon
My ideal purpose for doing a hackathon is to support solving problems for the business that do not have a clear commercial value or that have a lot of uncertainty?
Personally I think collaboration across teams and developer happiness can be handled in other forums. And I have never worked for companies that suffer from FOMO so I’m not motivated by that. I also think that learning new technologies should be part of your normal day job, so dedicating a hackathon to this seems a little pointless.
As a side note, developers who get to work on well thought our ideas that push boundaries are generally happy developers - so if you get your hackathon right you may be solving developer happiness indirectly. That said, for me it is not the primary goal of the hackathon - it’s a side effect.
I’ve broken my hackathon into 4 stages:
- Ideation as a separate flow based activity
- Pitching your idea to the hackers
- Hacker selection
- The actual hackathon
- Feedback after the hackathon
- Where to from here
1. Ideation as a separate flow based activity
I think ideation should be given more airtime and potentially done by a smaller group than the people who make the thing with flow in mind.
Who should be involved?
Firstly, ideation does not have to have all the people involved that you will have involved at the actual hackathon. Ideation is just for the people that want to come up with a new idea. Some people like doing this, other people just want to make things and don’t care what. If you like ideation be there, if you just want to make something it’s best you wait till the actual hackathon.
So how long should ideation take?
I propose ideation over a one and a half day period. That means one and a half days to come up with a really good idea.
One and a half days you say - that seems like a really long time just for the idea?
Let me explain why I motivate this length.
Day one you form your ideation group. That means you have to go through tuckmans stages, present different ideas, fight, disagree, fork, branch and reform groups etc. That’s going to take you a while.
The aim is by the end of day one you should have put together some sort of idea on what the thing is going to look like. Have some sort of high level pitch on what you are going to solve, how it will kind of work and why. No coding!
The second day is important, because ideas need to settle. Going home and sleeping on it and them coming back the next day once the idea has settled but still taking your attention is going to give you some critical insights you did not have the day before. It also gives you a bit of time to tweak your idea and your pitch.
2. Pitching your idea to the hackers
Once ideation is finished you pitch your idea.
How long is a picth?
Picthes should be time capped. 5 minutes a pitch with 5 minutes of questions afterwards. Pitches paint a conceptual view, they should not go in to how the sausage is made.
Who do you pitch to?
The hackers.
Different hackers might want to be involved for different reasons. Some may like the idea, others may think it will expose them to a technology stack they want to try. Regardless, the purpose of the pitch is to attract people who want to be involved. Just because someone wants to be involved doesn’t mean they have to be. This is where selection kicks in.
3. Hacker selection
Selection on who is actually going to make the thing is done as follows. Each hacker selects three ideas they would like to spend their hackathon on. They interview at their top project - those already in that team get to interview the applicant and choose if they want that person or not.
- If they get picked, they then are involved in selecting the remainder of the team.
- If not they move to their second selected project and repeat the process.
- If they don’t get selected for anything, they can choose to do their own thing on the day or just do normal work.
3. The actual hackathon
The actual hackathon should be a little down the road. Good hackers need time to think about tech stack, learn fundamentals, etc. I would do a hackathon a month or so after ideation and team selection is completed. This gives time for people to tinker, play around with ideas etc.
On the actual hackathon day(s) it’s about making the thing. You have only x hours to finish your proof of concept. Hack hack hack.
It’s important to remind people that you want a working proof of concept. They should focus on the core unique feature - the problem their thing solves. Settings screen, etc can be done later. Those we know we can solve. Focus on the unique thing you are trying to demonstrate.
4. Feedback after the hackathon
To close the loop, when the hackathon ends there needs to be some feedback.
I’ve seen feedback best done in a bazaar style where people walk from table to table to see demonstrations.
A bazaar style session with token based voting system
Everyone is given tokens. Different people are given different amounts of tokens based on their role in an organization. Normal people are given two or three token, top execs given ten or fifteen, or some sort of ratio - the tokens need to look identical so that you don’t know who gave you a token after the fact.
People go from team to team to get a demonstration of their project. If someone thinks their project is a good idea they give some of their tokens to that team.
Token’s should be anonymous
For me it’s important that the payment of tokens is done concealed so that the team doesn’t know who is giving them the tokens or who has given them the tokens. I’ve seen a token based voting system before, but it was done in front of the team which kicked in all sorts of social pressures on when tokens were given - you got to work with these people tomorrow in your day job or one of the members was your line manager and you felt compelled to be nice.
For me the ideal should be that you can lie if you want and say, hey nice idea - I’m going to give yo a token, and then not actually have to give them one if you don’t really want to. I would recommend not lying, but you want to door open for people who do lie to be able to.
The question people should be answering when paying tokens is,
Would you like to see this project given more airtime to be further explored
If you think there is a really good idea, give it a token. If you think it is a brilliant idea, give it all your tokens.
At the end of the bazaar a prizes are handed out and the token tally is done. Prizes are not linked to token allocation. Everyone should get some sort of prize if they contributed, but it should not be linked to the number of tokens they gained.
5. Where to from here…
At the end of the day, the purpose of the hackathon was to support solving problems for the business that do not have a clear commercial value or that have a lot of uncertainty?.
If there is a great idea that surfaces from a hackathon it will get picked up. I would not make any promises to any team on the top idea being given airtime down the road - because the top idea may still really suck.
Good ideas with a solid demonstration will get picked up naturally - no need to promise this before the event just in case the ideas suck
At the end of the feedback thanks should be given to all those that participated and then call it a day.
