Introduction
AI Adoption Is More About Culture Than Tools
A few weeks ago, we sat down with a potential client for a project kickoff conversation. The goal was to find out how we could help them integrate AI into their company. Their whole team joined the call, about 15 people, and within the first ten minutes, it was clear everyone had a different idea of what “using AI” meant to them.
One person wanted an easier way to schedule meetings. Another wanted AI to summarize call notes. A few wanted to search through years of client history. Some of what people described, honestly, was closer to plain automation than a need for artificial intelligence. More than a few people in the room were hesitant to bring AI anywhere near client data.
We see versions of this conversation often. Getting a small team to actually use AI well has less to do with picking the right tool and more to do with getting everyone talking about it the same way, and rolling it out based on collective priorities. In this article, we’ll look at what actually gets in the way of AI adoption, and what it takes to get everyone on the same page.
Adoption Rarely Follows a Clean Plan
We too are a small company, and when ChatGPT first became available, people on our team started experimenting with it individually, mostly for writing emails, Slack messages, and other everyday communication. Some team members also found it especially useful for polishing blog posts before publishing. It wasn’t long before our Operations team confirmed that using AI to help write blog posts was an approved use case, as long as it was being used responsibly. That became one of our first shared, agreed-upon use cases for AI.
Around that time, I was pairing with our founder while he was doing quality assurance on blog posts, and I noticed he was using AI a little differently. He wasn’t using it to generate a draft, but to review one from a few different angles before it went out. It was a small moment, but it stuck with me. There were more interesting ways to use AI than what most of us were doing, and at that point they weren’t something the rest of the team really knew about. I realized that while it may seem obvious to the person who is using AI in that way, it may not be obvious to everyone else. From then on I was always thinking about how knowledge sharing would be one of our greatest tools for incorporating AI.
On the engineering side, adoption moved on its own track. A few engineers asked for GitHub Copilot, while others kept writing code the way they always had. As tools like Claude Code showed up, a handful of people started experimenting with those too, on their own schedule.
I gave an internal presentation around this time on using AI responsibly, mostly focused on avoiding sharing sensitive client data, but I also mentioned some of the ways I had seen our team using it during various pair sessions. The discussion that followed surfaced a handful of practices and considerations that a lot of us, myself included, hadn’t heard yet. The landscape was moving fast enough that even people paying close attention were catching up in real time.
From there, more people started weaving AI into their day to day work, each in their own way. We eventually settled on a smaller set of approved tools, company managed OpenAI and Claude accounts, with clear guidance that client work needed to stay inside those approved accounts. Often we don’t use AI at all when it comes to client projects. It depends on our agreements with each client. We also started building AI into our own internal tools, and not long after, into projects for clients directly.
One thing that stuck with me from a client meeting was hearing our founder describe our approach to accidental AI mistakes, like someone unintentionally sharing information they shouldn’t have, as “tell, don’t blame.” The point wasn’t to pretend mistakes wouldn’t happen. It was to make sure people felt safe enough to flag them the moment they did, so that we could prevent any further damage if necessary.
As our AI work matured, we started taking on client projects focused specifically on building AI solutions. And even with all of that progress, our team still spans a real range. Some engineers use AI constantly, some are much more cautious about it or opt out entirely, and plenty of people fall somewhere in between.
Building Alignment on Purpose
There isn’t a single clean framework that gets a team from “everyone has a different idea of what AI means” to “the whole team is using it exactly the same.” Treating alignment as something you build on purpose, rather than something that happens automatically once you pick a tool, seems to matter more than the tool itself.
A few things make that process go more smoothly, based on what we’ve seen work both internally and with clients.
Start by getting people to describe what “using AI” means to them before you talk about specific tools. In that meeting with fifteen people, nobody had actually said out loud what they meant by “using AI,” and that gap is what created the disagreement. A short conversation early on can surface those differences before they turn into confusion later. Of course it is possible that different members of the team use it for different use cases, but it’s important that everyone has the shared knowledge of what’s going on.
Make room for people to ask questions and admit mistakes without getting defensive about it. Our “tell, don’t blame” approach to accidental AI mishaps exists because people are much more likely to flag a problem, like an AI tool touching data it shouldn’t have, if they aren’t worried about getting in trouble for it.
Give people a shared vocabulary and a couple of sanctioned starting points. Blog writing became one of our first agreed-upon use cases for AI because it was clear, low risk, and something people could point to. Having somewhere concrete to start made individual experimentation easier to build on, instead of leaving everyone to figure things out entirely on their own.
Alignment also means talking honestly about what AI shouldn’t do to the way people show up at work. If someone drafts a client email with AI, we expect it to still sound like the person sending it, and like the company as a whole. We try to hold each other accountable for that, catching it when something feels flattened or off voice, the same way we’d catch a typo.
That kind of accountability only works if people feel safe raising harder questions too, like whether AI is going to change what their job looks like, or replace parts of it outright. We don’t have a tidy answer to that. What we do have is a habit of talking about it directly instead of letting the question sit unspoken in the room.
Treat AI as a Team Capability
One of the biggest differences we’ve noticed between teams that successfully adopt AI and those that struggle is that the successful teams don’t leave it entirely up to individuals to figure things out.
One engineering team we work with introduced AI gradually, one workflow at a time. They didn’t expect everyone to suddenly change how they worked overnight. Instead, they rolled out new practices deliberately, made sure everyone understood how to use them, talked openly about where AI was helpful and where it wasn’t, and reinforced that AI suggestions still required human judgment.
Just as importantly, everyone was expected to use the same process. There wasn’t one developer embracing AI while another ignored it entirely. By making AI part of the team’s workflow instead of an individual preference, they created consistency. That consistency made it easier to share what was working, improve their processes over time, and establish common expectations around quality.
What stood out wasn’t the specific AI tools they were using. It was the culture they built around them. AI wasn’t treated as a shortcut. It was treated as another skill the team was developing together.
Start Building Organizational Knowledge Early
Another pattern we’ve noticed is that the earlier a team starts building shared AI knowledge, the more valuable that knowledge becomes over time.
Many people think about AI adoption as choosing the right model or purchasing the right subscription. In reality, a large part of the value comes from everything your team learns after that decision. Prompts get refined, workflows improve, and internal documentation grows as people share what they’ve learned. People discover better ways to solve problems and share those discoveries with one another.
Over time, that knowledge becomes part of the organization itself. New employees can build on it instead of starting from scratch. Teams begin improving existing workflows instead of reinventing them.
The longer a team waits to start that process, the wider the gap becomes. It isn’t just a gap in familiarity with AI tools. It’s a gap in organizational knowledge. Teams that start earlier have had more time to develop shared practices, build internal context, and improve the systems that support their work.
That doesn’t mean every company needs to move as quickly as possible or adopt every new AI tool that comes along. It does mean there is value in starting small, learning together, and letting that knowledge compound over time.
Conclusion
One thing we’ve learned over the past few years is that AI adoption is never really finished.
Even after we settled on a smaller set of approved tools, new practices and considerations keep surfacing. The tools continue to evolve, new capabilities appear every few months, and teams continue discovering better ways to use them.
The small companies getting the most value from AI aren’t necessarily the ones using the newest models or the most sophisticated tools. They’re the ones creating shared expectations, documenting what works, improving their processes together, and treating AI as something the organization learns, not just something individual employees experiment with.
Think back to that fifteen-person kickoff call. The disagreement in the room wasn’t really about AI at all. It was a team that had never stopped to build the shared vocabulary and expectations we’ve been describing throughout this article. That’s the gap worth closing before you pick a single tool. And once that tool or set of tools is picked, make sure that everyone on the team knows how to knowledge share and is onboard with where you are going.
None of this replaces the work of figuring out which AI problems are actually worth solving for your business. We’ve written about that separately . But it’s hard to get any use case off the ground if your team isn’t talking about AI the same way to begin with.
The tools will keep changing. The teams that build a culture of learning, knowledge sharing, and thoughtful experimentation will be in the best position to adapt right alongside them.
Have you started introducing AI into your organization, or are you still figuring out where to begin? If you need help, let’s talk .