Hacking success: Lessons learned from our Seattle hackathon

During our quarterly team offsite in Seattle a few weeks ago, we dedicated one day to a hackathon. Running a hackathon during a tech startup’s offsite is hardly an original idea, but we left feeling great about this one and I wanted to share a few things we did that I think helped make it unusually memorable for us and our customers.

Lessons for running an impactful hackathon

When done right, hackathons give everyone on the team an opportunity to bond, come up with out-of-the-box and high-impact projects for customers, and have lots of fun.

When done incorrectly, they can feel like frustrating mandatory fun that just creates more work in an already crowded production pipeline. While executives are off doing who knows what, engineers huddle around quiet tables building on their own. Not ideal!

We, obviously, hoped for the former when planning out our hackathon. Much like our overall offsite goals, we wanted to give the team a chance to get to know each other better and create unexpected momentum around our shared product vision. Though as usual, we also just wanted to build some cool stuff that’s been on our minds!

Here are a couple of the things we did and what we learned.

1. Don’t stress the prep

In the past, I would tacitly support the idea of pre-planning or even hacking itself before the hackathon formally started. Not this time.

We wanted to make sure we didn’t encourage additional pre- or post-work that would interfere with day-to-day priorities or personal lives. So, we kept all hackathon activity constrained to:

• One event the day before where folks pitched their ideas
• The actual day of the hackathon
• One event the day after for demos and the award ceremony

This was a huge equalizer for the team. These constraints leveled the playing field and ensured everyone could focus on their work and family before the hackathon without feeling like they were behind before we even started.

We all certainly thought about what we’d work on ahead of time, and brainstormed collectively as a team, which helped reinforce excitement about ideas that would ultimately have the biggest impact. +1’s from everyone on the team, including founders, in these discussions turned the hackathon into a shared team activity before it even started and built a great foundation and alignment for the event itself.

2. Involve everyone

We’re an 11-person startup with nearly everyone in engineering, so “involve everyone” is easy for us to say. But a stated goal of ours was to involve the whole company – even founders. We’re saying no to PD hackathons!

Having everyone involved in the hackathon, including the founders, demonstrates the importance of the event. It creates a sense of equality and, most of all, creates hustle, drive, and determination as everyone bands together to build things. We wanted folks to feel like this was important and that we could ship real customer value in a short amount of time. Nothing says that better than walking the walk.

This time around, one of our co-founders Austin (who is not a classically-trained engineer and is most well known for being our in-house SME on revenue technology) not only participated, but won an award for Biggest Customer Delighter after building our first Chrome extension. The team’s help, including our unofficial teammate ChatGPT, was a powerful catalyst to help us make one of our customers’ major wishlist items a reality.

While everyone on the team may not be able ultimately assemble and ship code, there’s so much non-engineers can contribute to help teams win, including designing the user experience, testing and integrating, organizing the work, and preparing for the big show. If you want more info on how to run (and win) great hackathons, our own Sam Larsen-Disney, the author of the Hackathon Survival Guide, is a wealth of knowledge.‍

3. Dedicate the very next week to productizing

Knowing hackathon projects won’t die a slow death in branch purgatory, as most often do, is an incredible motivator. It’s also an important part of making sure hackathons continue to be meaningful in the future. It’s very unlikely that one day, or even multiple days depending on the complexity of a project, is enough to get code to the level of quality and functional completeness required to merge. That shouldn’t even be the goal, anyway.

Instead, the goal of our hackathon was to take an incredibly exciting idea and cobble together a proof of concept to show what’s possible to the team. Nothing more, nothing less. We knew going in that the task of turning that code into something that meets our team’s engineering standards was separate and would come later. This is also why we’ll never have a hackathon award category for “Fastest to Ship”. 🐢

The key is that “later” has to come right away. A team’s already in the zone, switched in, and excited about their projects. There’s no better time to productize the POC, put it behind a feature flag, and deploy to production. Whether or not the feature ultimately GAs is another question, and we’ve found teams with a strong sense of ownership and customer obsession who decide to take a hackathon project to production will act as good stewards of it and its future.

For example, the week after our hackathon, Sam published his Popovers feature to prod, Austin published his Chrome extension to the store, and Andrew pushed his Raycast extension live for customer use.

We’re also learning this practice helps us create hackathon projects that aren’t completely out there in a fantasy land of ideas, unlikely to ever ship. Knowing that productizing projects is an intentional, if still optional, part of the process leads to work that’s more grounded, realistic, and ultimately able to be converted best to customer value.

4. Skip the cash prizes

We considered cash prizes but quickly dismissed them because we’ve found they don’t motivate our team as much (and they don’t align with our company’s value of cash conservation anyway).

What did we go with instead? Simple, elegant trophies that matched our design language and look great on our desks. Now everyone wants more than one, too!

Also, shout out to the EngravedDesign team on Etsy, who were fantastic to work with and produced these beautiful crystal trophies. We bought three small-sized ones at $49.99 and one medium-sized one at $59.99 – evidence you don’t have to break the bank to create memorable prizes that will last with employees.

5. Keep a sharp start time, loose end time

Starting the hackathon on the dot helped build up energy and anticipation, and our 9am kickoff was a blast. Folks knew what they were working on, teams were formed, and everyone hit the ground running with the clock officially ticking.

The day itself was a whirlwind with lots of running around, excitement, teamwork, and furious progress. Being in person was key. While we’re a remote team, an in-person hackathon feels substantially different from remote collaboration.

Most startups have a huge amount of knowledge captured in the heads of their employees. Being live, in person allowed folks to tap into our group knowledge instantly. It also created a strong feeling of camaraderie that normally escapes teams that work only remote.

While we had breaks for lunch and dinner, we didn’t have an official end time. Not every team needed (or wanted) the extra hours in the evening, but quite a few folks ended up hanging out for a little more coding, and it spontaneously turned out to be some of the best bonding time we had. With a mellow intensity, we had some time to just chat and enjoy the company of like-minded engineers working on their passion projects. It was one of our favorite moments.

What did we end up building after all?

I’ve talked a lot about how much fun the hackathon was. This fun, however, is part and parcel to the feeling of pride that we shipped real product features to our customers that are already delivering value.

To anyone who’s planning a hackathon: This is the north star metric. Create an environment where people have fun, ship stuff, and create real value for your customers.

Here’s a breakdown of all the awesome stuff we built. 👇

Chrome Extension (shipped 🚀)

• Save person and company records from LinkedIn
• See existing records in your workspace with a matching LinkedIn URL

Zapier Integration (shipped 🚀)

• Connect Clarify to the thousands of integrations built into Zapier
• Create records, notes, and other objects in Clarify when interesting things happen in other tools
• React to record changes, list membership updates, and other events in Clarify to trigger actions in other tools

‍Raycast Integration (shipped 🚀)

• Search for and quickly open People, Companies, and Deals
• Add new records directly from Raycast without opening Clarify

Dark Mode (shipped 🚀)

• Full support for dark mode ✨

Popovers (shipped 🚀)

• Preview any record at a glance with beautiful popovers that appear when hovered over

‍What’s next: Life after the hackathon

The offsite was all about finding a balance between structured programming and flexibility to find some synchronicity amongst the team, and the hackathon work was a great example of this balance in action.

‍We’re also still working on wrapping up the final projects out of our POC batch, including:

• Customizable cards: Personalize any record with additional context from other systems.
• Dashboards: Create custom dashboards with your most important contacts, deals, and lists.
• AI-assisted import: Import your data and automatically map it to the correct fields.

To get updates on those items, check out our Changelog.

If you want to read about our overall lessons learned from the offsite, check out this retro from Austin. And, if all this teamwork talk sounds exciting, head on over to our company page and take a look at our open roles. 👀