How to Organise an Enterprise Hackathon (Step-by-Step Playbook)

Two weeks ago, shortly after publishing my article about our AI hackathon, I was having lunch with a customer.

He told me he’d read the article and immediately wondered how he could bring the same approach to his small team. “This is really cool. How could I apply something like this to my team?”

He leads a small department that was recently created to introduce AI into the engineering organisation of a large industrial company. The team is still at the beginning. They need to define their purpose, explain how they will support the wider business, decide which services they will offer, and create a practical plan for getting started.

In other words, they don’t need months of philosophical discussions and endless PowerPoint decks.

They need to build something together.

And that is exactly where an enterprise hackathon can be powerful.

What is a hackathon in a company context?

A hackathon is a short, intense event — usually one or two days — where small teams work on a clear challenge and build a first working version of a solution. The word comes from software (“hack” + “marathon”), where developers would code through the night to ship a prototype.

An enterprise hackathon keeps the spirit and changes the participants. It’s not only for programmers. Engineers, sales people, HR, operations and leaders work side by side on real business problems: a new service, a broken process, a customer journey, an AI use case.

What makes it different from a normal workshop is the output. A workshop often ends with sticky notes and ideas. A good hackathon ends with something you can see, click or test — and a decision about what happens next.

The problem: new teams overthink. Enterprise hackathons accelerate alignment.

When a new team is created, especially around a topic as broad as AI, there are usually more questions than answers.

• What is our role?
• Which problems should we solve?
• How are we different from IT, digitalisation, data, or innovation teams?
• What should people come to us for?
• Which services should we offer?
• How will we make decisions?

These questions matter. But they can also lead to endless meetings, presentations, and philosophical discussions.

Everyone shares opinions, but nothing tangible exists at the end.

An enterprise hackathon changes the dynamic. Instead of only talking about the future, the team starts creating it. They work in small groups, make decisions, build first versions, and put something visible on the table.

During our lunch, we discussed seven questions that can help structure this type of hackathon.

1. Purpose: Why are we running the hackathon?

The first question is simple:

Why are we doing this, and what do we want to achieve?

In this case, the purpose is to bring the new AI engineering team together and accelerate the setup of the department.

The hackathon is not primarily about testing a new AI tool or creating a technical prototype. It is about helping the team define itself.

By the end of the day, they want to have greater clarity about their vision, their role in the organisation, the services they will offer, and the first actions they will take.

There is also a human purpose.

The team members need to get to know each other, build trust, and feel that they are creating something together rather than simply receiving instructions from above.

A good enterprise hackathon should therefore define both a business outcome and a human outcome.

What should exist at the end?

And how should people feel?

2. Challenge: What are we actually working on?

A hackathon needs a specific challenge.

“Let’s work on AI” is not a challenge.

It is too broad, and every participant will interpret it differently.

For this team, the challenge is:

How might we define the vision, operating model, services, and first internal presence of the new AI engineering department?

This challenge is concrete enough to guide the day, but broad enough to allow several teams to contribute.

Everyone will first work together on the overall vision:

Why does this department exist?

How can it help the engineering organisation?

What value should it create?

After that, the team will split into smaller groups to work on different parts of the setup.

One group will focus on governance.

One will work on the plan and roadmap.

One will build the first version of the communication strategy.

This means the hackathon will produce connected outputs that support the same larger goal.

3. Participants: Who needs to be in the room?

The next question is:

Who should participate to bring the right knowledge, skills, and perspectives?

For an enterprise hackathon, more people are not always better.

What matters is having the right mix.

In this case, the core department will participate. Depending on the size of the team, it may also be useful to include one or two people from engineering, IT, digitalisation, or internal communications.

However, the team should stay small enough to work quickly.

Groups of around three people are often ideal. They are large enough to combine different perspectives, but small enough for everyone to contribute.

The teams can also be designed intentionally.

For example, avoid placing all technical people in one group and all communication-oriented people in another. Mixing skills usually produces stronger results.

4. Roles: Who does what during the day?

Even an informal hackathon needs clear roles.

Someone needs to facilitate the process, manage the time, explain the exercises, and keep the energy moving.

Someone needs to act as the challenge owner and answer questions about the department’s context.

I also like to appoint a “stream lead” for each little group. They shall be part of the planning, and on the day of the hackathon, lead the group. They shall also decide who will document decisions and who will present the result. And they will make final decisions when the group does not agree. A hackathon can create a lot of ideas, but the team still needs a way to move forward.

Without clear roles, sometimes people wait for direction and nothing happens. With a simple structure, people can focus on contributing.

5. Format: Where and for how long?

This team is based in Germany, and the company is not doing particularly well at the moment.

It would not feel appropriate to organise an expensive off-site event or fly everyone to another country.

But they do have a small travel budget.

So the my customers wants to book a cabin not far from the office where the team can spend one full day together.

I think this is a smart choice.

An enterprise hackathon does not need to be expensive. It does not require a luxury hotel, a big stage, or an elaborate event setup.

But changing the environment matters.

Moving away from meeting rooms, email, and daily interruptions creates space for different conversations and fresh ideas. Even a simple cabin near the office can signal that this is not a normal working day.

It is a day to think, build, and start something new.

6. Experience: How will the day feel?

The agenda should create a rhythm between alignment, focused work, interaction, and recovery.

The day could begin with a short check-in and a discussion about the purpose of the department.

The team can then work together on the vision and the value they want to bring to the organisation.

After that, they can divide into teams of three.

Each group works independently on its topic: governance, plan, or comms.

The day should include short checkpoints where teams share progress, ask for feedback, and ensure that the different outputs still fit together.

Breaks are also important.

People cannot be creative for six hours without pause.

A walk, good food, coffee outside, or an informal conversation can generate as much value as a structured workshop exercise.

In this case, the team will finish with dinner and a barbecue. That may sound like a small detail, but it is part of the experience.

People remember how a day felt.

The informal moments are often where trust is built.

7. Outcomes: What should exist at the end?

The final question is:

What should teams deliver, and how should people feel when the hackathon ends?

For this enterprise hackathon, the tangible outputs could include:

A first department vision.

A description of how the team will help the organisation.

An initial service offering.

A governance model.

A 90-day action plan.

A first version of the Comms plan.

These do not need to be finished products.

They need to be strong enough to continue developing after the hackathon.

The emotional outcome matters too.

People should leave with clarity, ownership, energy, and a sense that the department is becoming real.

That is the real power of an enterprise hackathon.

It turns an abstract idea into something a team can see, shape, and own.

A ready-to-use one-day agenda

Steal this schedule for your first enterprise hackathon. It works for 10–40 people, in person or remote.

Time	Block	What happens
09:00	Kick-off	Sponsor states the purpose and the challenge in plain words (15 min, no slides marathon).
09:30	Team formation	Mixed teams of 4–6, each with a decider, a maker and a customer voice.
10:00	Sprint 1 — Understand	Teams map the problem, interview the customer voice, pick one sharp question.
11:30	Sprint 2 — Create	Divergent ideas first, then each team commits to one concept.
13:00	Lunch	Away from screens. This is where cross-team ideas actually spread.
14:00	Sprint 3 — Build	Prototype: a mock-up, a demo, a storyboard — anything testable.
16:00	Test	Teams swap and stress-test each other’s prototypes for 30 minutes.
16:45	Demos	5 minutes per team: problem, prototype, what they’d do next.
17:30	Commitments	Sponsor picks what continues, names an owner and a date. This is the step most hackathons skip.

Running an AI-focused edition? I wrote about that separately in AI Hackathons, Kids, and the New Era of Empowerment — and if you want help designing yours, that’s exactly what I do in my coaching and workshops.

Enterprise hackathon FAQ

How long should an enterprise hackathon be?

One full day is enough for most teams. Two days work well when the challenge is bigger or when people travel to be together. Shorter than half a day rarely produces anything tangible.

Do participants need to be technical?

No. With today’s AI and no-code tools, non-technical people can build surprisingly real prototypes. Mixed teams of technical and business people usually produce the best results.

What happens after the hackathon?

This is where most hackathons fail. Before the event, agree that the sponsor will pick what continues, name an owner and set a date. Without that commitment, even great prototypes disappear.

The takeaway

Hackathons are not only for coding.

They are useful whenever a team needs to solve a specific problem, create something tangible, and build momentum quickly.

A well-designed enterprise hackathon can help launch a department, shape a service offering, define a new operating model, redesign a process, or turn an AI ambition into a practical starting point.

You do not need a big budget.

You need a meaningful challenge, the right people, a clear structure, and enough space to work differently.

If you’re looking for a place to do exactly that, that’s what we’re building at Share The Nest in southern Spain—an all-inclusive space where teams can disconnect from the daily routine, run focused enterprise hackathons, and leave with tangible results.

Sometimes, changing the environment is what unlocks the breakthrough.

Related reading: How to write a Manifesto with AI and design thinking · The 7 Hard Truths I Learned About Making Projects Actually Work