Authored By
Matt Katz
As Arcesium's Field CTO, Matt leads Arcesium's Forward Deployed Software Engineering and Client Success teams. His work to empower clients and simplify technical challenges stems from a 25-year career in financial technology working with clients and software. Outside work, he enjoys books, bikes, and boards.
Share This post
Hackathons pull in people who like to solve hard problems, fit tight constraints, and do slightly unreasonable things with people they respect. The same traits that lead us to train for triathlons or crawl through mud and under wires for a Tough Mudder drive us to happily stay up late wrestling an impossible bug “for fun.”
But the mistake leaders make is letting hackathons fall into “one-off” territory instead of using them to define how your culture learns, experiments, and improves. Done correctly, they give people room to fix how they work, try new product ideas, and build tighter connections across the company.
Once upon a time, hackathons were scrappy, amateur, and fun in the best possible way. But then they transformed into marketing vehicles and recruiting funnels in disguise, and they lost something essential. They stopped inspiring people to cross boundaries and develop relationships.
To bring that energy back, tech leaders must do two things: keep appealing to the obstacle-course instinct, but, at the same time, design the challenge to make culture happen.
The “do anything, blue sky” hackathon without constraints seems like a way to offer total freedom for innovation. In practice, however, it paralyzes people. It’s like saying, “Go write a novel,” and then walking away. But if you say, “Go write a novel about a camping trip,” ideas start to show up. Constraints spur creativity.
Hackathons work the same way. Use a clear scope that aligns with something important in your company:
Pick a theme and let real strategic priorities be the fuel. People value autonomy, mastery, and growth more than branded hoodies or pizza. This mindset comes when your teams:
That’s how hackathons help discover and unlock hidden value. They shine a light on all the “this drives me crazy” ideas that never make it into a quarterly OKR but matter a lot to how work gets done.
Getting meaningful cultural outcomes from hackathons starts with good orchestration. Once you know the challenge you want people to run, you must build a runnable course and plan for what happens at the end. This is where many internal hackathons fall flat.
Overnight coding sessions are exhilarating but have a downside. They end up excluding anyone with a family, significant responsibilities, or a senior role. And that sends an unintentional message about who you value in your organization.
Another approach is to stretch the event over a few days within normal working rhythms. Have managers agree in advance that participants can carve out real time from their regular responsibilities to make it clear that this is legitimate work.
In addition, every team needs at least one person who’s not part of the core engineering group for that product. Pulling in operations, product, client service, sales, or anyone with deep domain knowledge helps you break silos on purpose instead of only showcasing engineering hot shots. For example, non-engineers can contribute by:
When you do that, two things happen. First, your ideas get better because they’re grounded in actual workflows, not just what’s technically cool. Hackers sometimes fixate on using the latest tool, but that can be channeled to be used on real problems. Second, you create relationships that outlast the event. The next time someone in ops has a problem, they already know an engineer who cares about that space. That’s culture change.
Finally, treat logistics like you’re running a televised event. You’d be surprised how many hackathons get started only to find that people don’t know where to run their code, how to access the necessary environments and APIs, or how to submit their project. These logistics aren’t glamorous, but if you skip them, everyone wastes time debugging infrastructure instead of exploring ideas.
The same level of planning should go into incentives. You can certainly order pizza and put out snacks to set a hackathon apart from just another meeting. But if the main story is, “We bought food,” people will treat it like free food with some coding attached. The motivation has to come from that combination of challenge, incentives, and cultural capital.
The more important piece, though, is what happens after the demo. A hackathon creates POCs that management can react to. Someone who has been quietly frustrated with a process for years can show their fix working. Suddenly, the conversation shifts from paper to having a POC that proves the point. Getting senior eyes on your great idea is a real reward in a healthy culture.
The final layer of impact accumulates over time. You start to build some organizational muscle. People figure out how to form balanced teams and become less shy about poking at a new data platform or API because they’ve already kicked the tires once. They get direct attention from senior company leaders. Over time, they turn into internal experts.
Some of them will keep entering and winning. At some point, it makes sense to tap those folks as judges or mentors, which sends a clear message about the way you value innovation as a company. When hackathons are more than a fun side quest, it’s one of the ways you influence the direction of the company.
When you put clear themes, sane time commitments, cross-functional teams, thought-through logistics, meaningful incentives, and real follow-through together, you build a culture machine that people want to run. It taps into the fundamentals of autonomy, mastery, and growth, giving each team member a real shot at changing how your company works.
