Great internal hackathons

Most corporate hackathons produce a graveyard of demos that don't stick. Having run several internal hackathons for both engineering and GTM teams in my current company, Keysight, I've put together a rough manual on how to break that pattern and host winning hackathons.

The baseline

An internal hackathon, run well, brings you ideas, cross-team trust, and hands-on time with new tools. Run poorly, you burn a week of goodwill with leadership.

Only a minority of hackathons start with a defined objective and a way to measure it. The bottleneck isn't the weekend itself, but rather the planning before and the follow-through afterwards.

Scoping around a goal

Tech Twitter's latest craze is around loops and /goals.

To scope your event, decide why you're running this before you pick a date, time, or venue. From there, you can figure out who's invited, how long it runs, what gets judged, and how you'll know it served its purpose.

You might want product ideas, higher engagement, fewer data silos, hands-on time with a new tool, hidden talent surfaced, new or improved internal tooling, or a signal for experimentation. Narrowing down is the hard part.

Make it falsifiable

It helps to use Charlie Munger's inversion principle when choosing a goal.

Write the goal so you could be wrong.

You can have an event that's an innovation engine, a recruiting stunt, a team offsite, or a marketing moment. It can't be all four. Pick one, have one or two others be side benefits, and design around your primary outcome.

Saying your goal with the hackathon is to "increase engagement" is not measurable, but something like "At least 60% of the org participates, and three projects enter a real backlog within 30 days"

is more viable to work with.

What you're really moving: skill, not output

Post-2023, AI and automation hackathons have unlocked non-technical teammates' ability to compete more seriously.

The real output of internal hackathons can be measured by people's ability to climb a capability curve. The payoff shows up months later when more people can clear the next step easily.

I like Ramp's model for how they describe the tiers of their internal adoption. It goes something like this:

• L0 - Occasional chat user: Pastes the odd question into ChatGPT. No workflow has actually changed.
• L1 - Dabbler: Has tried custom GPTs, assistants, or a coding agent. Sees the possibility but hasn't compounded it into anything repeatable.
• L2 - Workflow automator: Has built an app, script, or agent that automates part of their own job with a real trigger, input, and human checkpoint.
• L3 - Systems builder: Builds the connectors, skills, and templates that raise everyone else's ceiling. A force multiplier, not just personally productive.

With an internal hackathon, design for moving the broad middle from L1 to L2: one person, one repeatable workflow.

Don't optimize the weekend to try and mint a few L3 platform builders.

Timeline, roles, and access

End-to-end, a single hackathon typically takes 30-40 days to organize.

Responsibilities break down into three categories:

• Secure sponsorship
• Lock in logistics
• Promote, promote, promote

Starting off, it helps to start small: one team or org. Loop in IT, HR, Legal, and Comms early on to help amplify your abilities.

Ownership is critical, too!

Name a single owner for communications, and explicit owners for registration, mentoring, judging, prizes, logistics, and infrastructure. Diffuse ownership is how details will fall through otherwise.

There's also another landmine in enterprise to watch out for:

Access.

In a governed company, live demos will usually die on access rather than on code. It can take weeks to get SSO app registration, data permissions, and model licensing cleared. The depth of your hackathon improves greatly when demos are built on approved data rather than a hand-exported CSV file.

Format and duration

There's no one-size-fits-all for every org. Adjust the length and shape of your event to the goal and who you need in the room.

Some common formats:

• Classic sprint: 24-48 hours of high energy and focus. Tradeoff: all-nighter culture excludes parents, caregivers, and anyone who does better work rested.
• Hack week: 5 days, 9-5 (or 9-9 if you prefer). More inclusive, less burnout, deeper builds. Tradeoff: competes with the day job.
• Company-wide: 1-2 days. There's less disruption across sites if everyone's focused on this. Tradeoff: you get less depth per project.
• Virtual/hybrid: Flexible dates means you can reach distributed teams. Tradeoff: you need deliberate pacing and async tooling, or the energy flatlines.

The sweet spot is typically 48 hours across three calendar days.

For example: kick off Wednesday afternoon, checkpoint on Thursday, and present and judge on Friday afternoon.

Cap demos at 5-10 minutes (if including presentation slides) plus a few minutes for questions. Shorter slots force clarity on what's being communicated.

Also note: Programs that still glorify sleep deprivation get a loud weekend but a narrow crowd. If you want broad participation for your hackathon, do not require overnight work.

Themes and problem statements

A workable theme will name a real pain, is tight enough to focus the room, and still leaves room for solutions that you didn't predict.

"Innovate!" sounds great... but it's too vague.

So, not great.

A pre-written spec is too tight.

Also not great.

Frame challenges as business problems over technical homework. "Build a RAG pipeline" will pull in an army of engineers, but engineers are rarely where the unresolved pain lives. "Cut prep time before a customer meeting" will pull in finance, ops, support, and marketing alongside engineering.

AI hackathons, in particular, should bias towards internal tooling and knowledge-worker friction. This could be repetitive lookups, manual reports, or meeting notes that nobody trusts. Aim to unlock territories less crowded than R&D demos and attract sharp non-engineering demos that show where the next themes should come from.

You can run open "build anything" tracks alongside themed tracks (where it's easier to judge and follow-up) to kick off. In mature programs, two themed challenges + a wildcard category is a winning formula.

Team formation: the curious & the capable

Mixed functions beat monoculture.

Teams that can blend engineering with product, ops, marketing, or finance tend to ship more useful work than all-engineer or all-PM groups.

At least one person should care about the problem domain so the result is useful, not just clever.

For AI hackathons, assign coaches/mentors explicitly.

Pair non-technical builders with a smaller set of AI-fluent engineers who will unblock rather than take over the keyboard. Your mentors are there to help a peer reach "shipped" instead of stalling on setup.

In practice, you can go run a skill-matching channel for folks without teams. The consensus sweet spot for team sizes is 3-4 people. Smaller teams typically lack bandwidth; larger ones spend time coordinating rather than building.

For first events, also consider seeding a few cross-functional teams so others can see the pattern you want.

Running the days

Over-communicate, then communicate again.

State the goal when you announce the event, restate it at kickoff, and post it where people are working.

The most common day-one surprise is discovering that your hackers have no idea what the hackathon is actually for.

Manage the rest of the business in advance, too!

The first reaction from other leaders is, "So all development stops for three days?"

Email them early explaining what the event is, why it matters, and which requests (i.e., genuine emergencies) still get attention vs. which wait (everything else). Get their buy-in before the event, not during it.

A few other tips:

• Run a pre-event idea session a week or two ahead so people block time and arrive with a sketch.
• Hold a midway check-in during the hackathon so mentors can catch teams that wandered while there's still time.
• Schedule breaks, feed people well, and set a clear end time. Breaks work better as milestones than as guilt.
• Keep swag modest! Stickers beat custom tees for a first run.
• Don't let logistics eat up the week. :)

Judging and prizes

Publish judging criteria before teams start.

Opaque scoring is the fastest way to lose trust.

Typical dimensions:

• Innovation
• Feasibility
• Impact
• Execution
• Fit to theme

Adding in several small categories, e.g. "most valuable to customers" and "most valuable to employees", can also help spread recognition and cut the winner-takes-all resentment.

For AI hackathons, score whether the build changed real work and if someone else can reuse it.

Ask what existed before the event versus what was built during it, especially when teams extend internal projects.

For choosing judges, mix in senior leaders, domain experts, and peers as judges, and send out the rubric early.

Prizes, too, should matter without overshadowing the work. Time with leadership or a conference ticket travels well. So does good hardware. (Few truly know that the difference between a good keyboard and a great one can be life-changing.)

The real prize that people remember, though, is rarer: budget and a roadmap slot to keep building.

The 5% problem: life after the demo

Most hackathons' demos will die after that Awards slide.

Winners will be announced, inboxes will refill, and within a quarter most of your entire projects lineup is dead. About 5% of them, at best, will last more than five months.

Treat continuation as a system you design:

• Record demos, write up projects, and keep the contact list ASAP.
• Define how a promising build gets a sponsor, some engineering help, and a real slot in the backlog.
• Publish reusable workflows in a shared library.
• Schedule 30-, 60-, and 90-day check-ins so blockers surface while you can still help.

Measure what worked

There's three types of indicators:

• Leading - Participation rate and diversity across functions; number & quality of ideas; pre vs. post confidence with the tools.
• Lagging - Projects that continue and ship; documented time saved or cost avoided; participant retention; movement on capability ladder (see above).
• Qualitative - Talent surfaced; cross-silo relationships; visible appetite for experimentation.

Similar to how engineering orgs track internal tooling, you can borrow these metrics too:

• Active usage
• Sessions per user
• Share of work that's AI-assisted
• Reusable skills published
• Adoption by others

How these things go wrong

• Themes are vague.
• Stakeholders add requirements the week before.
• No mentors, so non-technical teams stall on setup while engineers race ahead.
• No afterlife - winners are announced and then silence.
• The event is built for coders only.
• Overnight work is treated as a virtue to shrink who can participate.
• Demos only run on someone's laptop.
• Too many goals at once.
• Your published challenge was never trial-built, so nobody can finish in time.

How these things go right

• Leadership treats hackathons as a way of working, not an annual party.
• Start before the perfect budget.
• Raise the floor before the ceiling.
• Provide builders a channel, office hours, and airtime at the next all-hands.
• Clear, precise, well-scoped goal.
• Explicit owners for comms, judging, mentoring, logistics, & infra.
• Route promising projects onto a funded roadmap path.

Ball's in your court now.

Hit me up on X, LinkedIn, or via email with your learnings.