Steven LafortuneAI shows up in almost every conversation these days. At Devolutions, we decided early that talk alone wasn’t enough: people needed permission, time, and a bit of structure to make it useful.
We’re roughly 200 to 250 people. Some of us ship product code all day. Others work in legal, marketing, finance, HR, and support. Across all of those roles, the goal is the same: put AI into the work people already do, so it saves time instead of sitting unused.
Here’s how that plays out for us day to day, and what you might try in your own team.
Encouragement is not enough: build the operating system
Permission alone does not create habits. People need time, training, tools, and someone to ask when they get stuck. That is why we treat AI like an internal capability to grow, not a fad to tolerate.
Our CTO, Marc-André Moreau, answered community questions on security, cost, and culture. The short version for day-to-day work is simple: leadership backs AI, teams still own quality and judgment, and we invest so people can get faster without flying blind.
AI hackathons: a full day to build something useful
One of the most visible rituals is the AI hackathon: a full day people can use to work on AI projects for their own job, their team, or a workflow that still eats too much manual time.
We ran the first AI-focused hackathon last year with our technical teams. Developers and other technical roles used the day to prototype automations, skills, and tools they could bring back into product and engineering work.
We also run the same idea for non-technical departments: legal, marketing, HR, and other teams that do not live in a codebase. The goal is the same: stop doing everything by hand when a well-scoped AI workflow can take the repetitive load, so people can focus on judgment, relationships, and the work that still needs a human in the loop.
Mindstone training for technical and non-technical paths
We’re continuing our investment in training with Mindstone, a third-party firm focused on practical AI skills. Technical and non-technical people, including colleagues in HR, are going through it, with tracks adapted to how each group actually works.
That mattered. A developer and a marketer do not need the same first day with AI. Shared vocabulary helps; identical exercises usually do not. If you are rolling out AI in a mixed org, split the paths early and keep the outcomes concrete: a workflow improved, a draft accelerated, a report assembled faster, a review checklist that no longer starts from a blank page.
Tools, experiments, and a little productive chaos
We also give people room to try more than one stack. Internally you will hear Claude, ChatGPT, Cursor, and other tools show up depending on the job. We sometimes joke that it is IT chaos in the best sense: people can experiment, build automations and skills, share what works with other teams, and figure out what fits their role.
That is intentional. Locking everyone into a single tool too early can freeze learning. Letting people compare approaches, then converge on what is useful, tends to produce better defaults over time. For security and IT leaders reading this: the point is not uncontrolled sprawl. It is guided experimentation with support nearby (more on that next).
The AI enablement team: five to six people who unblock projects
To keep experiments from dying in someone’s browser tabs, we put together an AI enablement team of about five to six people. They follow projects across the company, help teams design automations, and especially support colleagues who are newer to AI tools and do not yet know how to build skills or where to start.
If someone in a non-technical role has an idea but no playbook, enablement is the bridge. That is the difference between “AI is encouraged” as a slogan and “AI is usable” as a practice.
AI champions in every team, meeting monthly
We also named AI champions inside teams across Devolutions. They meet once a month with the AI enablement group to share projects in flight, patterns that worked, and ideas other teams can adapt.
Champions are not a second IT department. They are peers who notice what is working locally and make it visible. For an MSP or mid-size IT org, a lightweight version of this (one champion per squad, a recurring 30-minute sync) is often enough to stop good ideas from staying siloed.
What you can borrow this month
You do not need our exact headcount or tool list to use the same shape:
- Say the policy out loud. Encourage AI on purpose, with clear expectations on quality, privacy, and review.
- Give people a day. A hackathon (technical or non-technical) beats endless “we should try AI someday” meetings.
- Train for the audience. Separate technical and non-technical tracks; measure outcomes, not attendance alone.
- Allow a small set of tools, then share winners. Experimentation without a feedback loop is just noise.
- Staff enablement, even lightly. One or two people who unblock others will move more work than another tool license alone.
- Name champions and meet monthly. Make reuse the default.
Looking ahead: progress now, ambition for the next few years
We are proud of the progress: hackathons for more than developers, company-wide training, an enablement team, and champions who keep learning visible. We are also clear that this is not a finished program. AI at Devolutions is something we intend to push further over the next few years, in how we work internally and in how our products help IT teams operate with more automation and less busywork.
If your organization is still deciding whether AI is “allowed,” start with culture and structure, not only with a model pick. If you are already experimenting, borrow the pieces that fit: time on the calendar, training that matches the job, people whose role is to help, and a rhythm for sharing what works.
Curious how others in the community are organizing AI? Tell us in the comments, or continue the conversation on the Devolutions Forum.
