An AI transformation hackathon exists for one reason above the others: AI got rolled out, and the behavior did not change. People have access to the tools, and most are not using them, or not using them in ways that matter. A hackathon fixes that by giving people a real problem and room to solve it, instead of another training and another announcement.
The deeper subject is still the organization, not the tool. Run well, the hackathon compresses AI transformation into a few intense days: find where AI can create real value, redesign the work around it, and build the judgment the organization needs to keep using it after the room empties. But it starts with the adoption gap, because that is usually the real reason it is being planned.
The first question is not "what can we automate." It is "why is no one using this, and what has to change for them to."
Not an engineering event
Most hackathons are engineering events. The room fills with people who can build, everyone else watches from the sidelines, and the work is judged on code. An AI transformation hackathon has to break that pattern, because what it is solving is not a build problem. It is a work problem, and the people affected by the work are rarely all engineers.
This hackathon is for everyone who wants the quality of their work life to improve, whether they write code or not. Finance, support, operations, people, compliance, and the customer-facing teams all belong in the room, because they are the ones whose work is changing. The people closest to the workflow are the design team, not the audience. If the room looks like a product and engineering meeting, the problem was picked for the builders, not for the people who will actually live with the change.
The adoption problem this solves
When people are not using AI, the gap usually sits in one of five places:
- Educate. People do not yet see what AI means for their job. They are unfamiliar, skeptical, or worried about their job.
- Enable. They want to use it, but they lack the skill, the access, or the support.
- Engage. They understand it, but they have not taken a first step.
- Empower. They can follow a prompt or a template, but they do not apply it on their own.
- Transform. They use it, but the workflow itself never changed, so the business result did not either.
A transformation hackathon addresses all five at once, which is why it does the job training keeps missing. The room is the education: people learn by solving their own problem instead of sitting through a demo. The shared problem is the engagement: it gives a hesitant person a real reason to try. Doing the work is the enablement and the empowerment: people build the skill and the confidence by using AI against work they care about, with people beside them. And the redesigned workflow is the transform: the work changes, not just the tool wrapped around it. I have written separately about the case for giving people a problem instead of a directive; this format is that argument at full scale.
This is who it is for. The leader whose rollout stalled, with AI-curious people who never crossed over. The one who needs understanding to spread through trusted internal voices rather than a slide deck from outside. The one whose people follow templates but do not think for themselves, or whose tools sit unused while everyone quietly keeps the old way. If any of that sounds familiar, a transformation hackathon is a better lever than another announcement or another course.
What it is for
A transformation hackathon does two jobs at once. One is visible, one is deeper, and both are about the organization, not the tool.
- Adoption. People become users by solving a problem they care about, alongside people whose work they understand. The people closest to the workflow stop being the audience and become the design team.
- Organizational judgment. The room is a live sample of how the operation actually runs. You learn where the work bends, where it breaks, where judgment is real and where it is missing, and who your champions are.
Treat it as an instrument, not a party. You are running it to learn something and to move people, in that order.
Choosing a workflow worth a room
The subject is the workflow, not an idea about the tool. Choose that first.
A good choice has four properties:
- Real and painful. A process pulled from actual work, where people feel the cost, not something invented to show off.
- Cross-functional. Everyone whose work is changing has a stake, not just the people who can build, so the room has to talk to itself.
- Bounded enough to move, big enough to breathe. Progress possible in the time you have, more than one plausible answer.
- Unsolved. If the answer is already known, it is not a transformation, it is a task.
Start with diagnosis, not a solution. Before anyone picks a tool, the team has to be able to answer how the work actually happens today: which steps are judgment, and which are searching, copying, routing, comparing, or updating. A quick selection test is whether a small team can describe the value of changing this workflow in one sentence to someone outside the organization. If not, the room will drift.
Setting parameters, not a task list
Parameters keep people pointed at value without telling them the answer. Fix these up front:
- The workflow to redesign, and the problem statement, one paragraph, agreed by a sponsor who can unblock if needed.
- The timebox. A day is different from a week; both work if the problem is picked to match.
- Scope. Name what is off limits, such as real customer data or production systems.
- A loose definition of done: what you would need to see to believe the work is actually redesigned, not how to get there.
Leave open on purpose: how they divide the work, which of the approved tools they reach for, and what the answer looks like. If you already know the shape of the answer, you handed them a task list.
The tools in the room
For a room open to everyone, the right set is a small handful of human-facing tools, not the engineering stack. Four tests decide whether something earns a spot:
- A person can use it in minutes, with no code, no API keys, no CLI.
- It shows visible value in one session, not after a sprint.
- It is safe by default: it works on the person's own content and takes no consequential action on systems of record.
- It meets people where they already work.
What belongs:
- Everyday assistant, one is enough. ChatGPT or Claude, whichever the org already approves. This is where people learn to research, draft, analyze, and brainstorm safely.
- Where the work already lives. Google Workspace with Gemini, or Microsoft 365 Copilot if the org is Microsoft-based. This is the highest-leverage choice in the set, because the AI appears inside the surfaces people use all day and every output is easy to review in a familiar place. If you fix one tool, fix this one to match the actual suite.
- Shared knowledge. Notion with Notion AI, so teams consolidate scattered notes, ask questions against their own workspace, and learn grounding and citations without a retrieval platform.
- Coordination. Slack with AI and workflow features, for meeting summaries, capturing a decision, and structured input in a channel people already watch. It is the front door, not the system of record, so it is safe.
- Light automation. Make, or Zapier for the gentler on-ramp. A visual builder lets non-technical people automate the copy-paste-and-route drudgery between the SaaS apps they already use, which is the exact quality-of-work-life win most participants are chasing.
- Optional showpiece. Lovable or v0, so a non-coder can turn plain language into a working prototype. This is the single most energizing moment in the room. Keep it optional so it does not turn the event back into a build contest.
Keep out of the room: everything in the models and agent layer, workflow and orchestration, data and build tiers, and evaluation and observability tooling. Those need engineering ownership, credentials, and production governance, so they belong to a separate, engineering-led track, not this one. Also leave out the governance platforms and the operating-model artifacts like NIST AI RMF and ISO 42001. Those are what happens after the room, not what people open during it.
One strategic note. The biggest adoption lever is matching the set to the suite the org already runs: a Google shop centers Workspace and Gemini, a Microsoft shop centers 365 Copilot, an Atlassian shop considers Jira and Confluence with Rovo. Pick five or six tools, pin each to a quality-of-work-life benefit, and hand every team a sandbox with sanitized examples, never live production data.
Running the room
The leader's job is small and specific: frame the work, set the boundary, hold the space, get out of the way.
What helps in practice:
- Frame it once at the start: the workflow, the problem, and what you will be watching for.
- Defend the time out loud. Cancel the competing meetings. Busy teams trade experimentation time away the moment the calendar tightens.
- Check in once or twice, not constantly. Ask "what is stuck," not "give me a status report."
- Let people struggle a little. The moment they want to quit and ask for a template is often the exact moment the learning would have happened.
Treat concern as information, not resistance. If someone is uncomfortable handing part of the workflow to AI, there is usually a reason: an undocumented exception, a customer impact, an output they cannot verify. That concern is part of the design, not an obstacle to it.
Work through the phases, and watch the communication
A transformation hackathon produces adoption and judgment only when teams work through a set of phases, and at each phase they answer two questions, not one. How does the work change? And how does the way we communicate about it change?
The second question is the one most teams skip, and it is where the value leaks. The change is not finished when a team builds something. It is finished when the people who have to act on it understand what it means for their work. When everyone can ship, that is the part that has to scale too.
A hackathon compresses these phases into the room. Here is what to consider at each.
Discover
Find the real problem, size what it costs, and decide whether it is worth solving before anything gets built.
- How the work changes. Teams stop building something impressive and start naming the problem and proving it is real.
- How communication changes. The problem is written in one sentence a stranger could repeat, and that sentence becomes the shared anchor. A short decision record captures why this problem, now.
Design
Agree what the solution will do, who will use it, and how you will know it worked.
- How the work changes. Product, design, engineering, and the people who do the work decide roles and decision rights before code. Who decides what, and who can say no.
- How communication changes. The design is written with its reasoning, so someone who was not in the room can defend or adjust it. Handoffs become explicit instead of implied.
Transform
Change the workflow itself, not just the tool wrapped around it.
- How the work changes. The team decides what a person does, what AI handles, and where a person reviews and decides. The oversight is designed, not left as a vague "keep a human in the loop."
- How communication changes. Changes to roles and responsibilities are communicated as decisions with owners. Left unspoken, people quietly revert to the old way.
Prove
Test the assumption most likely to sink the idea, with success criteria set before the test runs.
- How the work changes. Teams shift from "does the demo run" to "did the risky assumption hold," and they set the baseline first.
- How communication changes. Findings are recorded, including the failures. An honest no is a result, and it is written down so it does not disappear after the demo.
Build
Turn the design into something working, with safeguards in place.
- How the work changes. People pair across functions. Everyone writes or reviews, so no one becomes a spectator.
- How communication changes. The why of key decisions is captured as you go. The changelog is written for the people who explain the work, not the people who built it.
Observe
Measure whether it is working in the real world, not whether it looked good in the room.
- How the work changes. Instrumentation and evaluation become a habit, not a one-time project.
- How communication changes. Shared dashboards replace opinions. Findings turn into decisions someone owns, on a schedule.
Notice the pattern. At every phase there is a version of the same move: write down the why, name the owner, and explain the change to the people who have to act on it, in terms of their work. That is the difference between a hackathon that produces demos and one that produces a shared understanding.
Judging without a demo contest
A demo contest measures presentation, not transformation. It rewards whoever makes the tool look best, and it quietly teaches everyone else that the point is to look good in the room.
Judge the work along three lines instead:
- Did they redesign the workflow, or just speed up a weak one the way it already runs?
- What did they learn about where judgment is real, and where the tool failed against real work?
- What carries forward, and who owns it?
The third line matters most. A redesign with no owner evaporates, and the old process quietly returns. Name the owner before the room ends.
What the room teaches you
This is where organizational judgment gets built, and it is the part most people skip. Watch the room as data:
- Where people stall. When a team gets stuck, or quietly abandons the tool and switches back to the old way, that is usually a real workflow barrier, not a skill gap. It points at a process that has not changed, which is a different job than training, and worth more than any demo.
- Where judgment is missing. Who accepts an output they should have checked, or rejects one they should have kept. That tells you where people are confidently wrong, which is where oversight is under-designed.
- Who steps up. The people who explain the tool to their neighbor, or who stay late to ask about the next problem, are your champions.
- What repeats. If three teams independently hit the same wall, you have found a workflow worth redesigning, not a coincidence.
Write these down the same day. The insight decays fast.
These become the start of a transformation roadmap, because they are findings about how the organization actually works, gathered in a controlled setting, rather than opinions from a survey. Each one is a small deposit into the judgment the organization will lean on long after the tools change.
Measuring adoption, not applause
The measure is not the quality of the demos. It is what changed in the same five gaps you diagnosed at the start.
- Engage. Did a hesitant person take a first step?
- Enable. Did someone who lacked the skill leave able to use the tool on their own?
- Empower. Did a template-follower start solving their own problem?
- Transform. Did any redesigned workflow survive into real use, with a named owner and a way to see whether it is working?
- Educate. Do people now ask better questions, about their workflow rather than which model to use?
If the answer to all five is no, the problem was wrong or the time was not protected. If even one is yes, you have the beginning of an adoption story you can show a skeptic, and evidence worth handing to leadership. The work does not end at the event, or at launch. It ends when the feedback loop is running and people keep using AI because the work got better, not because they were told to.
The short version
Pick one real, cross-functional, unsolved workflow. Diagnose why people are not using AI first: do they not understand, not have the skill or access, not care to try, not trust themselves to go further, or is the workflow unchanged. Then find how the work actually happens today. Fix the parameters and leave the answer open. Protect the time. Work the phases, and at each one ask two questions: how does the work change, and how does the communication change. Judge the redesign, name the owner, and read the room for where the operation gets stuck. Then watch who asks for AI next.
That is a hackathon doing the real job of an AI transformation: moving people from curious to user, and building the organizational judgment that outlasts the event.