Hackathon Innovation Ritual: How we grow our best ideas

Explore

Hackathon Ideas: 12 Tips To Grow Ideas Into Solutions

Hackathon is one of our most sacred rituals at Coda, and we’re excited to give you a behind-the-scenes look, plus a template so you can run your own Hackathon.

Introduction from Oliver

From 20% time to Hackathons.

“Creativity loves constraints, but they must be balanced with a healthy disregard for the impossible.” — Sergey Brin & Marissa Mayer (not sure who said it first)

One of the things that drew me to Google over 15 years ago was their 20% time perk — where employees had permission to spend 20% of their time working on whatever they thought would most benefit Google. This was meant to increase employee satisfaction and drive bottoms-up innovation. Quickly I noticed that across the board everyone was struggling to make the best use out of 20% time and come up with really innovative ideas. The most successful projects almost always require significant coordinated contributions from diverse cross-functional groups (e.g. designers, product managers, engineers, computer programmers), and people felt shy asking their mentors and colleagues for help.

My teams in Zürich decided to start coordinating our 20% time, so everyone could collaborate on each other’s innovations at the same time. We called it Innovation Week. That helped. So we took it a step further: We asked people to demo their 20% work at the end of the week, which got more people interested in joining the next one- but not all of them had an idea to work on. So we created a structure to support pitching ideas. Some ideas required certain skills so we ended up helping with finding team members as well (hint: UI designers and engineers are always in short supply).

Eventually we created a framework that encouraged bottoms-up innovation from ideation through execution to presentation, a.k.a. a hackathon. And like any good idea we were not the only teams in the company experimenting with hackathon project ideas.

“3 out of 4 of our best ideas have come from Hackathon” — Shishir Mehrotra

Here at Coda, we celebrate maker culture — Hackathons are very central to our Culture. We are running a Hackathon every quarter. Many of our most successful features came out of Hackathons - for example Coda Packs, Charts, Reactions, and Dark Mode.

This doc is meant to both show you why running hackathons is such an important ritual, but also give you a template to run your very first hackathon. If you and your team are beginners and are about to run your very first hackathon, just copy this doc, then check out the 12 lessons I’ve learned from 15 years of running hackathons.

⁠

Copy doc

⁠

12 lessons from 15 years of running Hackathons

1. Hackathons are for everybody, not just for engineers!

I have heard many excuses for not participating or running Hackathons, many of them based on the assumption that one needs to be an engineer or designer to participate. That is not true. First it is called Hackathon for a reason, the main goal is rapid exploration of an idea using any form of shortcut available. The goal is not to engineer a production quality solution to the problem. Take shortcuts!

I have seen successful projects hack together a Chrome extension that hacked their feature into Gmail instead of dealing with the Gmail codebase. Some teams might build a demo in a rapid prototyping tool completely outside the codebase. Some team’s demo consisted of slide decks or Figma mocks (and they were awesome!) - zero coding or software development skills required. I have seen teams write the documentation and press release of a non-existing feature as their output. One of the projects in our last Hackathon event here at Coda produced music (jingles!) as their output.

2. Be clear about the type of ideas to generate.

There is a natural tension between working on features that can be shipped relatively soon after the event and great big further out ideas that can be explored during the Hackathon. At Coda, we have a rule that nothing ships as part of Hackathon (we use a related but different ritual called Shipathon for the first type of projects and use Hackathons for longer-term bigger ambitious ideas and hence have the rule that nothing ships as part of Hackathon. That said, you can easily take our Hackathon template and adjust it to run an event focused on shorter-term closer-to-shippable projects.

3. Pick a theme.

My first Hackathons we left completely open to all ideas with no filter - in the end the thought was to gather the best ideas from across all teams and to work on them. Ironically that led to less creative ideas and more stress on the team during ideation than when we asked teams to work on something that relates to a certain topic or theme. A theme/topic provides a source of inspiration but also an artificial constraints - and that helps the brain in producing ideas. (And, it is fun). I found that broad widely interpretable themes (”Music”) or abstract themes (”Black and White”) work best, and that narrow highly product related themes (”reinvent feature Y”) worst.

During our last Coda Hackathon, when we were brainstorming ideas for a theme and someone mentioned the popular TV series Schitt’s Creek. The energy in the room immediately went up as everybody remembered their favorite moments and character. Once we noticed we could spell it Sheet’s Creek plus that it triggered a whole bunch of ideas for the organizer, it was clear that it worked as a source of inspiration - so it worked as a theme for us.

4. Very important: If a team has an idea they are very excited about, they should pursue it, if it relates to the theme or not.

The goal of the hackathon theme is to inspire and help, not to obstruct. Everybody needs to be able to freely pick what they work on (within legal constraints obviously). This includes not participating, even though as an organizer I would always try hard to encourage and help people to participate.

⁠

5. Team sizes of 5-7 seems to be the sweet spot.

We have nudged (but never forced) much larger teams to split into multiple teams. As organizers, we always work hard to have all 1 person “teams” find some more team members.

6. Hackathon duration - compressed, not a slog.

For the actual hacking, one day (and one long night) is on the short side, a full week for hacking on the very long side. At Coda we take 2 days of time for Hacking and Demoing, and a few hours the days before for Ideation and Team Formation.

7. Ideas are never the problem.

In my time as Google Zürich Site Lead I gave probably about 40-50 talks to C-level executives from all over Europe about how to build an innovation culture, and most of the time someone in the audience raised their concern about employees not coming up with enough ideas. My response is always that that is the wrong thing to worry about, in any organization there are way more ideas in the heads of the employees than can reasonably be implemented. “Ideas are cheap and plentiful, implementation is king”. A Hackathon is a great way to surface these ideas and have people vote with their feet (with their Hackathon time) on which ones to explore further. That said, it is important to have an open enough environment so employees can propose their ideas and freely pick what they get to spend their time on.

At our last Coda Hackathon, we had a 100 person org propose 69 ideas (and IMO every single one of them worth exploring) out of which 14 were being actively worked on during the hackathon event. We spent only 1h on pitching those ideas, but our team members had of course days to think about which idea they want to propose.

(If for some reason you need to generate more ideas, check out our gallery

here⁠

⁠

8. Ideas change - embrace it.

Often during the Hackathon ideas change as teams start to work on them- this is a sign of progress, not failure. As a result, teams often change their name half-way through the Hackathon to reflect the new refined direction they are pursuing.

9. Good ideas come up again and again and again

This is what Keith Coleman, when he ran Gmail, used to say to me as an excuse for not keeping notes... 😉 That means some ideas will get worked on by multiple teams in the same or across different Hackathons. That is great, and the sign of either a great idea that is really missing from your product or the sign that there is some gold hidden in the idea that has not been found yet. You will typically be surprised how different implementations of the same idea can be if worked on by different teams.

⁠

9. Hackathons are an important team building exercise.

Approach hackathons as an opportunity for people that have different day jobs to work together and learn from each other. This is why we have the entire company do the Hackathon together at Coda, rather than individual teams by themselves. If you can bring people together in the same location (post-pandemic) that is recommended, if not, virtual hackathon is a great alternative, too.

10. Hackathon is not a competition — but will still feel competitive.

The main goal of Hackathon is to give space to new ideas and some will turn out better than others. Some might get funded, built, and shipped, and others will not. The decision which ideas make it onto the roadmap of the company and which ones do not is a complex one factoring in resources and costs, legal implications, broader strategy, etc. and not just the quality of the work of the Hackathon team - and it is important to be transparent and upfront about this.

The main goal is to allow the rapid exploration of ideas. Any team spending a great time working on a big bold idea should leave it with the feeling of a win. When we run a Hackathon at Coda, we gather feedback about how excited our teams are about the different projects, but we have a larger number of categories we ask them to vote on (see People’s Choice Award). Last Hackathon we voted in 5 categories for 14 projects.

It is perfectly fine to not have any voting or awards and just have people participate for the fun of working on fresh ideas and working with people they might otherwise not work with - you adjust this part of the process to your team.

12. I almost forgot the single most important aspect of Hackathon: Schwag.

I have no scientific explanation for this, but you need to have hackathon theme-related t-shirts for your hackers or some other schwag, it is really really important, trust me.

⁠

The rules of Coda hackathons

Finally, it’s important to lay some ground rules at the beginning of the hackathon. At Coda, we have 3 rules for our Hackathons:

1. First of all, everyone hacks.

There’s often a perception that hackathons are just for engineers. At Coda, everyone is a maker. People demo everything from docs to figma designs to pieces of code. Everyone hacks.

2. And, nothing ships as part of Hackathon.

At Coda, we want to encourage teams to use the Hackathon to explore bigger ideas and further out features and not to use the time to finish their current project. Therefore we have the rule that nothing ships as part of Hackathon.

3. Final rule: Passion rules.

If someone is really passionate about doing something during Hackathon, they should do it.

⁠

Ready to run your own hackathon?

Head to

Tactical Guide: How to run a Hackathon in your company⁠

⁠

Hackathon Ideas FAQs

What is a hackathon?

Hackathon is an event that gathers company employees to collaborate on a project. Hackathons can be a competition-style events where teams are instructed to ideate a solution and complete a task in a defined time frame.

What is the purpose of a hackathon?

Most broadly speaking, the purpose of a hackathon event is to create or improve a piece of hardware or software. Both startups and established companies tend to look at hackathon events as an opportunity to improve their products/services by giving their employees a chance to contribute with unique ideas.

What are the best hackathon ideas for beginners?

Whether an activity is a good idea for your hackathon event depends on the line of work you are in, products you are building, and specific skill set of hackathon participants, but some of the most common hackathon activities include:

Building a website in Java, CSS, HTML

Creating a new PC or mobile game

Developing a new mobile app or mobile app features

Developing new product features

Listing ways to improve user experience for a product (hardware, software, or any physical product)

Creating data visualizations with Python

Leveraging IoT, machine learning (ML), big data, or artificial intelligence (AI)to develop new industry-related solutions

⁠

A few of the 25,000+ teams that 🏃‍♀️ on Coda.

⁠

a77eed08d9f915aabec0346b67a40b7ec93457a9864e51bde1e9239fad175c59624ad1bd252ec5041198bc8e9a52ce31b441ab4767fbb714b9172474278d0b29434f118c46abc5c7a7377f4ad1ea733677ca74d97bc8661e4bbfde8d9cdafabc285f5616.jpeg

⁠

Coda is an all-in-one doc for your team’s unique processes — the rituals that help you succeed. Teams that use Coda get rid of hundreds of documents, spreadsheets, and even bespoke apps, to work quickly and clearly in one place. This template is a Coda doc. Click around to explore.

Find out how to Coda-fy your rituals.

⁠

Connect with a Rituals Architect

⁠

Gallery

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.