The Secret Weapon For Aligning Everyone in the Company— Internal Hackathons
Over the years I’ve seen hackathons from all kinds of angles — I’ve participated in them (and won one of them), I’ve helped to organize some and been a mentor in others.
Some of them have been open to everyone while others have been internal (i.e. for company employees only).
Most have been held in physical locations but some have also been virtual (one with over 12,000+ participants from all over the world).
Now, after leaving Pipedrive (and Pipedrive becoming an unicorn), I’ve had some time to reflect on what makes for an effective internal hackathon and what they can be used for.
By the way, Martin Henk (one of the co-founders of Pipedrive) has written a bit about using hackathons in the early days of Pipedrive.
However, I think there are quite big differences between a team of 10 and a team of 100. So, I’m going write from the perspective of using hackathons within a company that has hundreds (if not thousands) of employees.
Why Organize Internal Hackathons?
Harness the creativity of all the people in your company
Sometimes the best ideas come from a place you least expect. I saw it again and again in Pipedrive. Engineers, engineering managers, support folks, salespeople — they all had solid ideas and picked up top prizes.
The bigger the company, the more some roles move away from customer contact. Suddenly you’ve got all this data coming in from analytics tools that is cool to look at. However, genuine insights rarely come from quantitative data. Insights come from doing the legwork — from talking with customers.
So, it’s especially important to get people from support and sales to participate and test out their ideas — they are the ones who have direct contacts with customers every single day.
Even though you might have a process already in place to harness “the voice of the customer”, with hackathons you’re essentially shortening the feedback loop. It’s what innovation is all about.
The same goes for other roles that might not be too included in the product management process as such — your engineers, engineering managers, the people who work on the knowledge base, customer success managers etc. The more, the merrier.
As a side-effect, you will also be cutting down the amount of criticism around feature prioritization. You know, stuff like “why haven’t they fixed it? we’ve been telling product managers for two years to build this.”
Now it’s their chance to try fixing it themselves or finding out why it’s not a good idea.
Rally the entire company behind company objectives
Internal hackathons are the under-used secret weapon for aligning people on company objectives.
It’s not rare that after the objectives get set, people get busy with details and at some point don’t remember the big picture anymore.
Or maybe the big picture wasn’t communicated to everyone properly in the first place. Communication is hard when you’ve got hundreds or thousands of people to keep in sync.
The people who participate in hackathons that are set around company goals will internalize those goals. And they will be able to explain them to others as well. As participants are from every department, it’s hard to overestimate the effect this will have in terms of aligning the company around common goals.
Take a break from “serious” work
Let’s face it. Most people just want a break and have some fun. And it’s totally fine. From the company’s perspective, it’s the most productive fun time you could imagine.
Preconditions — Things You Must Do Before Organizing An Internal Hackathon
Set clear company objectives
As I said earlier — internal hackathons are a great way to rally people around common objectives.
However, this only works if you actually have proper objectives. And by that I mean you probably should be using some kind of framework to set the objectives.
I personally am a believer in OKRs. Meaning you set Objectives on a leadership level that have to be inspiring. And together with those who have to deliver the objective, you’ll set Key Results.
The Beginner’s Guide to OKR by Felipe Castro (free) is a great place where to start with OKRs.
Another good thing about the OKRs is that it’s recommended to only have a 2–3 of them. Which means it also matches with the frequency of hackathons — twice or thrice a year.
Hard commit resources for the winning ideas beforehand
You absolutely have to commit resources before you run a hackathon. It’s the only way to ensure that all the great ideas will actually get implemented.
Maybe, at first, you want to only commit to implementing the winning idea (not the top 3). And cap the development time to one team and two months, for example.
But you have to do it and be transparent about it. This is also to ensure that you won’t get disgruntled participants.
Something foggy like “we will find the resources and get it done at some point” is not the way to go here. As soon as the hackathon is over, you will run into prioritization problems immediately.
By the way — the implementation part can also be the prize itself. For example, you could send the winning team to somewhere warm or cool where they can work on shipping it while taking surfing lessons or doing snowboarding. It’s a win-swim situation for everyone.🏄
How to Run Internal Hackathons
Set clear rules for evaluating ideas
You will always have participants who will be saying “I think there were much better ideas.”
But you can cut down that number dramatically by making the evaluation criteria known in advance.
Make sure the jury knows how to evaluate the ideas
Isn’t that the same thing as the previous tip? It’s not. Let me explain.
When you run hackathons around a specific company goal (or a sub-goal, even), you can have several criteria for evaluation. Typically you’d have something like “progress made”, “presentation skills”, “potential” etc.
But how do you evaluate “potential”?
If you run a hackathon around building growth loops, then how do you evaluate growth loops?
Not everyone in your company is a specialist in a given area (even if they are a C-level exec).
So, you might want to do some education among the jury beforehand. You won’t have much time for choosing the winners. Maybe only a half an hour where the teams can have a break for food (after demos and before the announcement). Make that time count.
Create a separate Slack channel for all the comms
You should do that already before the hackathon. It’s a good way to build awareness plus you’ll avoid answering the same question several times.
After the hackathon, you can use the channel to update everyone on the progress.
Make sure everyone who wants to, can actually participate
As a rule, it’s better to run hackathons during workdays (or at least partly during workdays). People will be in town and they are more likely to spend their work time rather than their spare time at the event.
However, departments are different. Support reps might have to be online during certain hours. Salespeople might have to take or make calls to fill the quota. Engineers might have to be on call during the hackathon.
So, discuss with different departments heads how to solve those situations. For example, you should make sure that if a salesperson participates, then they won’t be punished for missing their sales quota because of the hackathon.
Let participants submit their ideas beforehand
Seeing the first ideas will inspire others to submit their ideas.
There’s not much more to say about it except the next point.
Discuss the ideas through before the hackathon with participants
Sometimes the topic of the hackathon is very simple. At least you think it is. But you will discover that not everyone understands things the same way as you.
You will have ideas that are totally unrelated to the hackathon topic. And you will have ideas that are related but are presented in such a confusing way that it’s hard to see how exactly they are related.
So, each time someone submits an idea, sit down with that person, and discuss it through quickly. You will improve the quality of ideas and the outcome of the hackathon that way.
Prepare a basic template for pitching
You probably don’t want to limit the creativity too much. But you should at least make sure that a couple of essential pieces are communicated out during the pitch. Things like problem statement, solution, etc.
Split big groups apart and merge the soloists
The goal of hackathons is to test out as many good ideas as possible.
Sometimes, a couple of ideas seem so good, that everyone wants to be part of those teams. Often, though, those won’t actually be the winning teams. The most obvious ideas aren’t necessarily the most insightful ones.
So, if a big group emerges, split it apart. Set an upper limit to group size and make sure you communicate this rule beforehand.
If you have got people who can’t find teammates (and you’ve got no big groups to split either), then merge those people together. They will work out themselves which idea to go with.
Let area mentors give advice separately (not in a group)
First, make sure you have mentors for different areas to start with. For design, for engineering, for presentation/pitching, etc.
After you have area mentors, make sure that they either advise teams separately (i.e. one mentor at a time) or that you group mentors for the same area together (engineering mentors only, for example).
It will be hard for the teams to take in 10 different pieces of advice from 4 different areas at the same time. Keep focus during reviews and give them time to digest the feedback by area.
If you run the hackathon over many physical locations, you need to make sure that each location has someone dedicated to that location alone.
Set attractive prizes
That’s a big part of why people participate. So which prizes should you have?
You can just ask the participants — what do they think are attractive prizes?
I’ve found that stuff related to work productivity is actually the best of both worlds. Things like noise-canceling headphones, extra money for training (trips), etc.
Prepare thoroughly technically
There are usually a lot of technical details to work out. Especially when you’re trying to bring several locations together virtually but you have a physical auditorium as well.
It’s not unusual to have some of the demos fail for technical reasons. So, do a thorough run through.
Pro-tip for virtual hackathons
Trying to organize people into teams is way harder virtually. And the bigger the number of participants the harder it gets.
It might be a good idea to also list the skills of participants and keep a live list of who is taken and who is not. And in general use proper software to manage the hackathon.
Tools like Notion and Coda work great for that purpose and don’t cost anything or cost very little depending on your exact needs. They are way more flexible compared to, for example, Google Docs or Confluence.
The idea is to put team listings, voting (private), prize listings, participate lists etc all in one place and link them together.
Or you can go pro and try something like MuchSkills (this specific feature of MuchSkills was born during and because of a hackathon) or Eventornado (where, perhaps not surprisingly in retrospect, Martin Henk is a co-founder) to manage hundreds or even thousands of participants.
