What I Learned Rolling Out AI to 900+ Engineers

Lessons from leading AI adoption across 900+ engineers inside a $2bn+ company.

I was hired to lead the AI rollout for 900+ engineers at a $2bn+ sports betting company. Sports betting is an older industry, and older industries tend to have a larger gap to close when technology moves quickly.

You cannot drag everyone across that gap yourself. The only way to push AI adoption at that scale is to create internal sustained motion inside the company so people can keep moving without you. AI adoption is change management, and people change, in disguise. That makes it incredibly hard, but also valuable.

I cannot claim to have done this alone. I was sponsored by and partnered closely with a VP of Engineering, but I was the de facto lead, with a virtual team in place for over a year.

I have worked on a lot of technical change management in the past, and those lessons applied to AI adoption as well. However, if I did it again, I wish I knew a few things up front. I have done my best to write them down here before I forget them.

AI is already here

Almost everyone I meet is using AI in some way today. That was not true a year ago, but something shifted around December 2025. You may believe your company has not truly started adopting AI yet, but your people are almost certainly already using it in some form. MIT Sloan calls this bring your own AI.

Marketing teams are already using image generation services. Engineers are already using ChatGPT or Claude, either on the free tier or a personal subscription. They may not be talking about it because it is just another tool that helps them do their job.

Rolling out AI today is not about convincing people to use it. It is about providing a paved path that lets them use AI in the most sustainable and effective way inside your company.

Managing expectations

Leaders sometimes get AI-pilled. Statements such as “why can’t we do this in a weekend?” or “come on, I can get Claude to do it for me easily” are not rare. When this happens, you have to pull the conversation back to realistic examples, constraints, and the places where AI still needs human judgment.

The opposite also happens. Some leaders do not believe AI is already in use because they cannot see it in official tooling or procurement data. In that case, make it visible through measurement or show-and-tell sessions.

Because AI is already here, rolling it out usually ends up being about bridging expectations. If you are responsible for rolling out AI, your job is to keep that bridge intact long enough for momentum to build.

The hype has poisoned the well

Everyone has seen the same ridiculous LinkedIn posts and VC threads. Developers are obsolete. Tiny teams will replace entire departments. The next model will make software engineering unrecognisable.

People do not hear “we want to improve productivity” in a vacuum. They hear the public story that AI is coming for their jobs. Leaders hear the public story that everything should suddenly move 10x faster.

You have to acknowledge this directly and head-on. If you do not, people tend to get defensive, rightfully so, because they see you as a threat when you are there to help them out. In workshops and one-on-ones, I found it useful to say the hype is inflated, often wrong, and not the frame we should use for the tools available to us.

Then move towards concrete usage: where AI removes grunt work, where it helps with creative exploration, where it produces junk, and where it makes review harder.

One of my favourite examples was Jira. I hate Jira. I do not want to spend my life clicking around tickets, updating fields, or translating between documents and boards. Claude can manage a lot of that for me much better, so I do not have to. That is awesome. The same applies when AI helps someone understand an unfamiliar codebase, interrogate logs, or try an approach that would have been too tedious to explore manually.

Creative usage is the main lever for business impact

The most business impact came from using AI creatively, by people who had enough domain expertise and judgment to do so.

  • Building a vendor integration by joining information spread across many Jira tickets, reverse-engineering vendor callbacks with ngrok, and using an example application for inspiration, moving meaningful work in hours instead of months.
  • Running incident investigations against old knowledge in Slack, Notion, and Jira, then combining it with live monitoring in Grafana.
  • Putting together several marketing campaigns by generating content and copy, then A/B testing them against a small audience segment pulled from Snowflake data.

The vendor integration example is the one I keep coming back to. AI was not doing magic. It was joining scattered internal context with real technical exploration: tickets, callbacks, ngrok, an existing example application, and enough domain knowledge from the people in the room to know what mattered.

It is easy to fall into the trap of defining AI workflows for other people. I saw this a lot in commercial domains like marketing, where technical teams often build systems for domain experts. Engineering teams default to this too. We build solutions for others. With AI, that can become a bottleneck because the best uses often come from the people with the most domain knowledge trying things we would not have prescribed centrally.

Creativity is easiest to come by when people close to a real problem see what worked in adjacent domains, then get time to try it against the problem in front of them.

Show, don’t tell

You cannot drop tools into people’s laps and expect them to change how they have worked for years or decades. Most people I encountered saw AI as one thing: a text generation tool. Text in, text out. Maybe code generation if they were using Cursor or Copilot, but still fundamentally the same mental model.

We ran several workshops where we focused on anything besides code or text generation to break that mental model. Coordinating tickets, epics, a Kanban board in Jira, and Notion documents. Letting AI test a new feature end to end in Android or iOS on a simulator. Building visualisations and dashboards directly in Grafana. Running an entire incident investigation end to end.

The best format was demo, then breakout sessions. Show something real, then force people to try shit out while the idea was still fresh. If people were expected to experiment by themselves later, they usually prioritised the work they already had pressure to finish. That is normal. Learning a new ambiguous tool loses to delivery pressure every time.

Everything is amplified by AI

AI amplifies everything you use it for. Good review habits, clear ownership, and decent quality checks become more valuable because people can move faster without losing judgment. Weak review habits, unclear ownership, and handing over output you do not understand get worse because AI makes it easier to produce more than the team can absorb.

This can surface as bad quality output because the safeguards were not good enough. More work starts arriving for review that looks plausible but is not understood well enough by the person submitting it. The bottleneck moves from producing work to judging work.

It is tempting to reach for a hammer and say “ban AI use for this” when that happens. People will still use AI, you just lose visibility. It is much better to look at the process around it: unclear ownership, weak review habits, missing quality checks, bad handoffs. AI did not create those problems. It made them harder to ignore.

TLDR

AI adoption is much less about tooling than people want it to be. At scale, you need to give people space to experiment, keep the hype in check, and keep judgment in the loop.

  • AI is already here, so most companies are not starting from zero. They are shaping usage that already exists.
  • Managing expectations matters because people and leaders can end up with completely different stories about what AI means.
  • The hype has poisoned the well, so you have to acknowledge it directly or people will treat AI adoption as a threat.
  • Creative usage is the main lever for business impact because the best uses come from people close to real problems trying things you would not have defined centrally.
  • Show, don’t tell because demos and protected time changed behaviour more than telling people to experiment on their own.
  • Everything is amplified by AI, good and bad, so weak processes become visible faster.

AI can create real leverage, but only when the company stays honest about where it helps, where it breaks, and what it amplifies.

In my case, AI usage in the Engineering organisation reached 98% within months, then spread organically into commercial functions across the company. The companies that do this well will stay grounded while everyone else gets pulled into hype, fear, or shallow metrics.