Hackathons are those mini focused events where groups of people look at a problem and solve it in a free-to-do-as-you-please manner. Basically, teams hack a problem – i.e. manage to solve a problem, by proposing validated, detailed ideas. Some may involve code/tech, but not necessarily.
Hackathons come in many shapes and sizes. From the large public events where anyone can join, to the closed corporate event where employees can focus on new problems.
Hackathons are great. Not only do they break boundaries and get teams to work together, but results can be meaningful and very real. However, for them to have any impact on real improvements, you need to follow a few key steps. Here are a few things we need to keep in mind when suggesting an internal, corporate hackathon.
Safety – Employees need to feel that if they mess up, they will be fine. Failing is fine. There are no KPIs for hackathon participants under than experiencing and learning. And let’s face it, many failures were successful eventually (for example – bubble wrap was initially designed to be wallpaper!)
Timing is key – Look for that week where teams have more time on their hand. Timing is really everything. Setting up a situation where teams are focusing on a hackathon and yet loads happening at their office will result in greater stress and not much innovation.
Death by Frequency – I love prawns. Love them. Juicy succulent stuff. Give me prawns every day and will hate them very quickly. Hackathons are great but only do them as often as possible, and not more.
Hackathons are not lost development time. Hackathons held monthly may be overkill. Try and look for that balance and start small. Think about each hackathon as a big deal, and avoid letting them become another boring Monday innovaton thing that your staff doesn’t get. Keep them excited!
It is a priority – Let’s face it, if something is not made to be important, than it is likely to never happen. Is there CEO buy-in? Does your staff feel that what is being done is important? Is it appreciated? Is it easy to get out of it? Show that this is not a team building exercise but a strategically important event that aims to change the way you do business. (Yes, it can be that important!)
Give it a theme – Themes are great! It gives some focus. Do not give requirements.
You want to give themes a framework for the event, but you do not want to give teams a list of requirements. Themes allow teams to go down similar paths. Requirements ensures they all end up in the same place. Worse still, requirements lead to manager pointing fingers saying our staff is not innovative!
Winners are important – Let us face it, competition is a great driving force. We all want to win, or at least, no one wants to lose. Therefore have winning teams! Give prizes! Yes, give prizes!
Mentors work – Teams often come together by ideas and energy, rarely by perfectly matching skill sets. Give teams mentors. External mentors may add an extra spin. Give them energy to feed off of. Mentors go a long way!
Make it count – Hackathons need to be part of a process. In isolation they are great, but ideally you need to know what happens next. How do projects come alive? How are they managed? What happens to the employees that thought about the new ideas? How are they treated? How are they involved? How is the new idea reintegrated into the company? How should teams work on the new idea? How are resources going to be allocated? How are road blocker type of people going to conform to change and new ways? How are you going to make good ideas become a reality yet diminish risks?
Have you ever tried an internal hackathon? Was it a success? Would love to hear your comments below if it was grand or ‘meh’!