In the last two years I have attended 2 hackathons from two different companies. Both have been great experiences that I have been grateful to attend.
While I have walked away from these events with what I personally wanted to achieve, I’ve also come away with one big question…
Why is the company doing this? What are they wanting to get out of this?
The answer of course depends on the company, it could be any of the following…
- We are trying to increase developer moral?
- We are trying to encourage collaboration between people that do not normally work together?
- We are trying to get people to look at technologies they would not normally play with?
- We are trying to support solving problems that support the business that do not have a clear commercial value?
- We are trying to foster better ideation processes?
- We are doing this because other companies do this but for no other reason?
What I have learnt so far…
Below are a few insights that I have gained from my experiences of hackathons…
Beware of tuckman stages of group development
If you don’t know tuckmans stages of group development - it’s worth a read. In essence whenever forming a team or a group, you see forming, storming, norming, performing stages.
If in your hackathons you are going to form groups of people that do not normally work together, you are going to see these stages manifest themselves during the hackathon. If the objective of the hackathon is to produce something, you may want to adjust how you form your teams. Let me explain…
Because hackathons are generally time boxed events of a day or two you don’t have enough time to get to the performing stage if you are in a newly formed team. This means that if your intent was to ‘produce’ something, by forming new teams that have not worked together just before starting you are hindering the ability for the team to make something useful.
I would suggest keep teams small, ideally people in the teams should have worked together before the day in some way.
On the counter to this, if your objective is to get people to form relationships with people they have never or infrequently worked with before quickly, giving them a ‘hard’ or ‘impossible’ time frame to work under is a great way to accelerate people bonding. Nothing better than being in an impossible task with other people to accelerate progression through tuckmans four stages.
Be mindful of the technology stack
You are on a really tight timeline. You have got 12, 24 or 48 hours to produce something. Do you really think you can code something in that time frame while learning a totally new technology stack at the same time?
My experience is you are going to be able to do one of the two, but not both.
From a learning perspective, I learn the fundamentals best on my own. This gives me time to google, do tutorials, and let the knowledge seep in. Once I have passed the fundamentals, my learning is accelerated by learning in groups.
If I’m at a hackathon and everyone in the group is learning a totally new technology stack it’s a smell. I want at least one person there to have a good understanding of the tech stack before we start. What I’ve found is if nobody has a good understanding of the tech stack there is quite a strong social pressure to learn together as a team. Learning something totally new as a team has not worked well for me.
Make sure you have the fundamentals covered before the hackathon, or stay with a tech stack that most people are comfortable with.
Separate ideation from hacking
Getting everyone on the same page for a great idea is hard. Coming up with a great idea is extremely hard. You face all the challenges during the ideation stage that you face during the make it stage.
In the hackathons that I have been to, I’ve seen ideation been done badly. It’s either been tackled as part of the hackathon, or it has been handled in a set of brainstorming sessions before the hackathon. Neither has felt ideal.
Ideation as part of the hackathon
You take a bunch of people, all with different skills and expertise, give them a fixed short period of time in a newly formed team and then say GO.
Well, guess what happens, the coders want to code, the analysts want to analyze and the testers (if they are traditional testers) don’t know what to do.
Having ideation as part of the hackathon has not been a good idea. There is a lot of storming. My observation is you end up with low impact ideas.
Avoid ideation as part of the hackathon
Ideation as a set of brainstorming sessions
So, you have decided to separate the hackathon from the ideation. Great idea. You set up a series of one hour meetings for a month or so before the hackathon for ‘ideation’. Chaos ensues…
Ideation is hard. Having one hour sessions to come up with a really good idea doesn’t feel like the best way to tackle things. It’s like trying to cook a really good meal but you can only add a new ingredient to the mix once a week.
Ideation as a set of context switched brainstorming activities does not flow enough for my liking. I want a block of continuous time to come up with a really good idea.
I’m sure there is more…
So, these are the things I have learnt from attending past hackathons. I’m sure there are a bunch of learnings that you have had if you have attended a hackathon before. If so, I would appreciate your insights in the comments section. Happy hacking!
