Most MSPs have purchased at least one AI tool in the past year. Fewer have figured out how to make their technicians actually use it. The gap between “we have AI access” and “our team thinks in AI-first terms” is not a technology problem. It is a culture and change management problem, and it will not close on its own.
You do not need a formal training program, an outside consultant, or months of runway to close that gap. What you need is a structured, time-boxed challenge that gives your team permission to experiment, a clear goal to aim at, and a reason to care about winning. An internal AI hackathon does exactly that. Artie, one of the MSP operators we work with closely, ran a four-week employee challenge built around a deceptively simple constraint: build an AI agent that reclaims at least one hour per week. The results were worth examining closely, and the model is repeatable.
Why “One Reclaimed Hour” Is the Right Constraint
Hackathons fail when the goal is too abstract. “Explore AI capabilities” or “get comfortable with the tools” sounds reasonable, but it gives participants no way to know whether they are succeeding. Artie’s team solved this by anchoring the challenge to something every technician already cares about: time.
One reclaimed hour per week is specific enough to be measurable, ambitious enough to feel meaningful, and humble enough that a mid-level tech can actually reach it. It also shifts the framing away from “learn a new tool” and toward “solve a real problem.” That distinction matters. When your team is building toward a tangible outcome, they engage differently than when they are completing training modules.
The constraint also naturally filters toward high-value use cases. To reclaim an hour, participants have to identify where time is actually being lost in their workflows. That discovery process is itself valuable, often producing insights about inefficiencies that have nothing to do with AI. The hackathon becomes a structured audit of how work actually gets done, which is something most MSPs have never formally attempted.
How to Structure Four Weeks Without Losing Momentum
A four-week timeline is long enough to produce real results and short enough to maintain urgency. Here is how Artie structured each phase:
Week one: Problem identification. Each participant documented two or three recurring tasks that consume time without requiring deep judgment. Ticket triage, routine client status updates, documentation drafts, alert categorization. The goal was not to find the perfect use case but to identify any use case worth testing.
Week two: Build the first version. Participants started building or configuring AI agents targeting their identified problem. Artie’s team used a mix of tools depending on the tech’s comfort level, and no one was required to use the same platform. This reduced the anxiety of “learning the tool” and kept focus on the outcome.
Week three: Test and refine. This is where most hackathons stall, because the first version almost never works the way you expect. Build explicit iteration time into the schedule. Artie held a mid-challenge check-in where techs shared what was working and what was not, which created organic peer learning without formal instruction.
Week four: Demo day and vote. Each participant presented their agent to the full team, walked through the problem it solved, and quantified the time reclaimed. The team voted on the best submission. Artie awarded a monetary prize to the winner.
That final vote is not just a nice ending. It creates a social incentive that persists through the harder middle weeks when enthusiasm naturally dips.
The Monetary Prize: Smaller Than You Think, More Effective Than You Expect
You do not need a large prize to make this work. Artie’s prize was meaningful but not extravagant. The psychological effect of a monetary reward is less about the amount and more about what it signals: that leadership takes this seriously enough to put something real on the line.
A gift card or bonus that feels like an afterthought will produce afterthought-level engagement. A prize that requires a team vote to award produces something different. It creates accountability between peers, not just between employees and management. When your techs know their colleagues will evaluate their work, the quality of that work tends to rise.
If budget is genuinely constrained, there are alternatives that carry similar weight: extra PTO, a team outing, public recognition in a company all-hands. The mechanism matters less than the signal. Make it clear that this challenge is a real priority, not an HR initiative to check off.
What You Actually Get at the End of Four Weeks
The obvious output is a set of working AI agents built by your own team. Some will be rough. Some will be genuinely impressive. All of them will reflect real operational knowledge about your specific environment, client base, and workflows, which is something no off-the-shelf tool can replicate.
But the less obvious output is more valuable. By the end of four weeks, you will have identified which technicians have high AI aptitude and want to go deeper. You will have surfaced use cases you had not thought to look for. You will have created a shared vocabulary around AI that did not exist before. And you will have demonstrated to your team that AI fluency is something you build by doing, not by watching videos.
Artie’s team came out of the challenge with three agents that went into regular production use. More importantly, they came out with a different attitude toward the tools. The question shifted from “should I try this?” to “what should I build next?” That shift is the actual goal, and a four-week hackathon is one of the most reliable ways to produce it.
Making It Repeatable: Turning One Hackathon Into a Culture
A single hackathon is a good start. A quarterly cadence is a culture shift. If the first challenge goes reasonably well, resist the temptation to declare victory and move on. Schedule the next one before the momentum from the first one fades.
Each subsequent challenge can raise the bar slightly. The second challenge might target two reclaimed hours instead of one, or require integration across multiple tools, or focus on a specific service line like security operations or project management. You are building a curriculum, even if it does not look like one.
The agents your team builds also become shared assets. Document them. Build a simple internal library where techs can find and adapt each other’s work. Over time, that library becomes one of your most durable operational advantages, a body of IP that reflects your team’s expertise and your clients’ actual needs.
Moving your MSP team from having AI tools to genuinely using them is not a technical challenge. It is a human one. A structured four-week hackathon with a clear constraint, a competitive incentive, and a team vote gives you a repeatable mechanism to drive real adoption without mandating it.
Artie’s model works because it respects how people actually change behavior: through doing, through peer accountability, and through visible recognition that the work matters. You can run this quarter. The version you run six months from now will be better, because your team will be better.
