What participants post publicly
No polished testimonial deck, just real posts published right after the hackathons.
The posts are loaded from LinkedIn, which may process data and set cookies of its own. They only load once you request them here.
The adoption gap this closes
Most enablement programmes stop at the certificate, and usage stalls a week later. That drop-off is the adoption gap, and it is a practice problem rather than a knowledge one. People do not keep using a tool because they understood a lecture. They keep using it because they have felt what it does on their own work and there is something running that pulls them back to it. Four forces widen the gap when a programme ends at attendance.
No behaviour change is designed in. A course covers concepts and ends. Nothing about the following Monday is different, so the old workflow reasserts itself.
The pilot has no owner. A tool everyone is invited to use and no one is responsible for quietly falls out of the routine.
There is nothing to return to. Without a running artifact, the reminder to use the tool disappears with the slides.
Adoption is never measured. When no one tracks whether the tool is used, no one notices it has been abandoned, and the next programme repeats the same shape.
Enablement closes the gap by building behaviour, not awareness. A week of shipping real work leaves a habit with something to reinforce it.
Goals of the enablement sprint
The goal is operating capacity, not a warm feeling on Friday. After the sprint your teams should be doing things they could not do the week before, without waiting on a central expert.
Continued use of the tools in the weeks after, because a running artifact keeps pulling people back.
Fewer manual updates, faster replies and better internal search, tied to a workflow your team now owns.
A named owner per artifact with a next step, so the pilot does not evaporate.
A documented AI literacy measure as a building block toward EU AI Act Article 4.
What the programme entails
An enablement hackathon is a guided work sprint for teams who cannot and do not need to code. Participants work with Cursor, Lovable, n8n, Gamma, Figma Make, Claude Code, Custom GPTs and NotebookLM on their own data, and facilitation keeps each team on one tightly framed problem so a usable, ownable result exists at the end. Enablement adds one thing a bootcamp skips, a deliberate handoff so the artifact keeps running and the behaviour keeps happening.
A typical sprint has four interlocking parts:
- Challenge scoping tied to a routine. Each group takes a real, recurring task with a named user and a desired output, so the artifact has a place in the weekly routine from day one.
- Tool workshop. Before building, each group learns exactly the stack its challenge needs, so the tools chosen are the tools that will still be used later.
- Build phase. Teams build with a facilitator beside them, keeping the prototype inside a boundary that can actually be operated after the week.
- Pitch, handoff and an adoption plan. Each team demonstrates its result, names risks, and hands the artifact to an owner with a next step and a simple way to see whether it is still in use.
Deliverables
Pre-scoping with a per-team challenge tied to a real routine.
A curated tool stack per challenge, including access.
A facilitated build sprint with a coach present throughout.
At least one working prototype per team (automation, dashboard, Custom GPT, app prototype or workflow) that an owner can operate.
A handoff document per prototype with owner, access, open risks, acceptance criterion and next step.
A lightweight adoption plan so you can see whether the tool is still in use after 30 days.
Documentation of the AI literacy measure for participants.
Who it fits, and who it does not
Honest fit saves both sides time. Enablement is the stronger lever when these points hold. When they do not, we say so.
| Good fit when | Not a fit when |
|---|---|
| you care about usage in the weeks after, not just the day of | a one-off inspiring session is genuinely all you want |
| a named owner will operate the artifact and watch adoption | no one can take responsibility once the week ends |
| data and tool access can be approved in principle | real data cannot be touched for legal reasons under any circumstances |
| you want operating capacity you can see in the workflow | a certificate on file already satisfies the goal |
Classic training vs enablement hackathon
| Criterion | Classic training or e-learning | AI Hackathons enablement hackathon |
|---|---|---|
| Output | certificate or attendance record | a working prototype your team operates |
| What it changes | knowledge on the day | behaviour in the weeks after |
| Adoption after 30 days | unclear without measurement | designed for and observed via a lightweight plan |
| Ownership afterwards | rarely defined | a named owner with a next step |
| Proof of value | hard to show | a tangible artifact as the starting point for your own measurement |
| Time to first result | weeks to months | ready to start in one week, outcome depends on scope |
The table compares ways of working, not vendors, and deliberately carries no invented percentages. Reliable adoption figures only come from your own measurement over time. A hundred people who can really operate the tools outproduce a thousand who merely sat through a session, which is exactly why enablement measures usage, not attendance.
How the value can add up (a model, not a client number)
An honest view of the payback uses your own figures, not a borrowed case number. The model has three inputs and one formula.
Weekly time a person spends on one recurring task the artifact touches, say answering repetitive customer questions.
The share the tool realistically removes once it is genuinely adopted.
Internal hourly rate times the number of people who keep using it.
Formula: hours saved per week × hourly rate × 45 working weeks × people who keep using it − the one-off cost of the sprint and the follow-through. Put your own numbers in. As an illustrative model only: if repetitive replies cost each person four hours a week and an adopted assistant removes half, that is two hours across, say, twelve people over a year, but only for the people who actually keep using it, which is why adoption is the term that matters most in this formula. We run this in the discovery call with your real numbers, not ours.
Interactive calculator: /tools/ai-enablement-readiness/.
Does this match your goal? Decide with a person, or read first.
The one-week path, as an animated timeline
| # | Step | Owner | Output |
|---|---|---|---|
| 1 | Intro call | AI Hackathons + sponsor | agreed goal, rough scope, date |
| 2 | Tools and challenges call | AI Hackathons + team leads | challenges tied to real routines, tool stack per challenge |
| 3 | Finalise info and data | Client (IT, privacy) | approved data access, documented boundaries |
| 4 | Hackathon prep | AI Hackathons | prepared environments, access, run of show |
| 5 | Tool workshop | AI Hackathons + teams | every participant can operate their stack |
| 6 | Hackathon sprint | Teams (coached) | working prototypes an owner can run |
| 7 | Pitches, handoff and adoption plan | Teams + owner | handoff documents, named owners, a 30-day adoption plan |
Social proof
Teams from Adobe, YOYABA, Onventis and NavVis have worked with us.
See the case studies
Book a discovery call