You already know how to do this: why AI adoption is a people problem, not a knowledge problem
A project showed me that stalled AI adoption is usually an incentives problem, engineers protecting themselves from expanding expectations, not a skills gap.
I kicked this off at the start of the year, which may as well be years ago given the AI release cycle. Models have shipped, tools have changed, and half the advice from January is already old news. I want to be upfront about that, because what follows isn’t about specific tools/models/whathaveyous, it’s about the conditions that let a team actually learn and grow. Those have held up. 5-6 months later my team is running their own AI improvement process without me in the room, building agentic workflows off their own initiative, and enjoying the ride. I’ll get to that. First, let me tell you what I got wrong before I got it right.
The wrong diagnosis
When AI adoption stalls on an engineering team, the instinct in the industry seems to be to treat it as a knowledge problem. People don’t know how to use the tools well enough! You run a workshop, share some resources, drop it into goals, go to conferences. Maybe you nudge a little harder, make the goals broader, anything to get those usage numbers up and hope the knowledge comes with submersion.
I don’t think that’s usually the actual problem.
What I was watching from my team wasn’t based in ignorance, it was a kind of careful distance. I started hearing things like “Haha, hallucinations”, “I guess it’s not there yet” and “silly AI”; all conversation enders. There was vague agreement that AI was probably useful for some things. A conspicuous absence of anyone documenting what they’d actually tried and what had happened.
For a while I read that as scepticism, or maybe fatigue? But I listened and watched and over time I realised I was misreading the room entirely.
The thing nobody says out loud
Let me say the quiet part loud, because I think it’s the most important thing in this post.
Engineers are smart people who have watched the tech industry go through repeated cycles of “do more with less.” They’ve seen tools get introduced with enthusiasm by leaders, followed by expectations quietly ramping up, followed by someone pointing at a dashboard, or deadline they invented, and asking why velocity isn’t higher. The job security conversation is real, everyone in tech knows it and nobody wants to be the one to bring it up, and it sits underneath every conversation about AI productivity whether we name it or not.
So here’s what I think was actually happening on my team: if you admit AI is working, you’ve just signed yourself up for more tickets. If you say the output is good, the bar moves. The rational response, if you’re an engineer who’s been around long enough to know how this goes, is to stay vague. Let the hype cycle do its thing. Keep your head down. “Haha, hallucinations” is actually a very efficient way to end that conversation without committing to anything. My engineers are smart people, and I don’t believe any of this was deliberate, but it’s a subconscious coping mechanism to quell the pressure of the overarching story outside of our team.
That’s not laziness or resistance. That’s self-preservation. And honestly? I don’t blame anyone for it.
But here’s what it means for a manager trying to drive adoption and run a high performing team: the problem isn’t knowledge. It’s incentives. Your team isn’t failing to engage, they’re rationally declining to engage with a system where honesty gets punished.
In general, what engineers want is to solve interesting problems. They want to get better at their craft, to be ahead of the curve rather than behind it. To have genuine job security, not because they were compliant, but because they’re genuinely good at what they do. The opportunity with AI, if you frame it right, speaks to all of those things. The threat framing speaks to none of them. (The psychology of how engineers, in particular, respond to new tool mandates is something I keep thinking about — probably worth its own post.)
You already know how to do this
Once I felt that I knew the blocker to adoption better, I tried to reflect on what the “knowledge”, or the skills, needed were. Effectively working with AI requires skills that every engineer on my team already had. The problem wasn’t a skills gap, it was how the problem was being framed.
Think about what happens when a new engineer joins the team. You don’t hand them a ticket and disappear. You think about what context they need, provide docs to domain knowledge and system structure. You scope work that matches where they are right now. You set clear expectations about what done looks like and provide a way to confirm those expectations are met. You check in at sensible intervals. You make it safe to say “I’m stuck” or “this approach isn’t working.”
None of that is new. It’s just good engineering practice applied to onboarding.
The mistake many people make with AI is treating it like a search engine that sometimes lies, something you query and evaluate, with no obvious lever between a good result and a bad one. When it fails, the conclusion is that the tool is bad. The idea that you might be responsible for the quality of the output, that your job is to set it up to succeed the same way you’d set up a new teammate, hadn’t clicked.
That’s the reframe. Not “here’s how to provide context to an LLM”, that conversation is happening publicly and constantly. It’s: this person is new, show them the ropes. The skills were already in the room. They just needed a different problem to point at.
Enter Eli
So we ran Project Eli. (ELI5 — Explain Like I’m 5 — get it? Not to be confused with Deloitte’s Eli, an agentic AI system they named independently — which I genuinely didn’t know about until much later!)
Each member of my engineering team was “paired” with Eli for a week at a time. They were responsible for Eli’s output and they were to treat Eli like a new engineer on the team.
In practice, that meant applying engineering process that already existed: scoping work appropriately, bringing relevant context, setting clear expectations, checking in where it made sense. Not because AI requires these things in some novel way, it’s because good work always requires these things. The framing was a shortcut to instincts the team already had.
At the end of each week there was a showcase of what Eli had completed, plus a separate retrospective focused specifically on workflow to learn as a team. Not just “did it produce good output?” but “what did you learn about how to work with it better?”
But first: I lowered the bar
Before any of that could work, I had to change the incentive structure.
I told my team explicitly that I am not expecting more output. In fact, and this might stress some out, I expect less during this experiment. The goal isn’t to learn AI tools and keep pace (or god forbid increase it). The goal is to learn the tools so we can go faster later.
This sounds minor, but have you ever tried to learn something while also going faster?
Once that was clear, once the team knew that admitting something wasn’t working wouldn’t be treated as falling behind, and that honest feedback wouldn’t trigger a productivity conversation, the quality of what came out of the retrospectives changed completely.
Instead of “it’s pretty good for some things, but bad at others” we started getting specifics: what didn’t work, what they’d tried, what might change the result. We now had evidence that we could do something with as a team.
It also freed people up to engage with the interesting questions — not “should I use this?” but “how do I use this well?” That’s a much better place for a team to be. An engineering craft question, not just compliance for the sake of it.
What actually went wrong (the good stuff)
I want to pause here because the failures were some of the most valuable parts of the whole experiment.
The “it’s a person” framing broke down almost immediately. By week two, people were relating to Eli in ways that didn’t quite match the mental model I’d set up. Some were treating it more like a very fast search engine. Some were confused between what made the work Eli’s and what made it theirs. In some cases trying to treat Eli like a literal person made the whole thing more confusing!
But that confusion itself was revealing. When people got tangled up in what it meant to mentor/onboard an AI, they were wrestling with a genuinely useful question — what is the right relationship to have with Eli? (There’s actually some really interesting recent research on whether anthropomorphising AI helps or hurts — and my experience both validates and complicates it. A rabbit hole for another day.)
Nobody agreed on what “use AI” actually meant. This was a big one. When I said I wanted the team using AI on their work, I had underappreciated how many ways that could be interpreted. I thought being open meant everyone could enter at their own comfort level, that progress could be relative.
Some engineers were thinking sidecar: AI running alongside them, suggesting, autocompleting, helping them move a bit faster at what they were already doing. Others were thinking more ambitiously with agentic workflows, AI handling whole tasks end-to-end with oversight at key checkpoints. These are genuinely different things with different risk profiles, different quality considerations, and different implications for how you structure work. (The sidecar vs. agentic distinction deserves a proper exploration — it’s become one of the most useful frameworks in how we talk about AI work on the team.)
Even when we as a group said we want to get to agentic workflows, there was still a spectrum of interpretations. However, rather than that being a problem, this turned into some of the best conversations of the whole experiment. Getting alignment on what “using AI” actually meant — what was in scope, what good looked like, where the guardrails should be — surfaced assumptions I didn’t know anyone was making, gave quieter team members a genuine reason to contribute, and developed a team that valued discussion about AI approaches.
If you run something like this, don’t assume you’re all talking about the same thing. Surface it early. The conversation is worth more than you’d expect.
Tech debt showed up uninvited. Once people started working with AI on real tasks, the inconsistencies in our system design became harder to ignore. An AI working with a well-structured, consistent codebase gets much further than one working with accumulated debt and workarounds. Seeing it in practice, and having the team identify it themselves rather than being told, turned an abstract technical debt conversation into a concrete, motivated one. That was an unexpected bonus.
Some work was just the wrong starting point. A few engineers picked tasks that were genuinely hard to do well with AI for where we were at, not because of capability limits, but because the feedback loops were too slow, the success criteria too fuzzy, or the blast radius of a mistake too high to learn comfortably. Working out which tasks to start with took a couple of rounds. That’s okay, it’s the kind of thing you can only really learn by trying, and we were now trying!
Where we ended up
I want to be careful here not to make this sound like I ran a clever experiment and my team were the lucky recipients of my insight. That’s not what happened.
What actually happened is that I created some conditions and got out of the way — and my team figured it out. They ran with the retrospectives, built frameworks, started identifying problems before I’d noticed them, and pushed each other to go further. I guided early, contributed on direction, and increasingly just showed up to listen. As a leader who aims for maximum autonomy and creating leaders not followers, it felt very satisfying.
At risk of being cheesy, the thing I’m proudest of isn’t the adoption rate or the agentic workflows, though genuinely those are great, it’s that the team did this together. The learning was collective. When something didn’t work, people brought it to the group as a puzzle to solve, not a complaint to escalate or a reason to give up. That shift from individual frustration to collective problem-solving was the real outcome. The team has taken these learnings and also applied them to their tech debt planning process and we keep finding more and more wins in how we work and collaborate, well outside of the AI adoption topic.
What I actually believe about all of this
I should say where I’m coming from on the general AI discussion, because I think it matters. As we’ve learned, context context context!
I’m a believer. I use AI every day and enjoy doing so. I think the tools are remarkable and the trajectory is steep. But I also know my enthusiasm doesn’t get to override the experience of the people closest to the work.
Scepticism, when it’s well-evidenced, is genuinely useful. It’s how you find the edges of what the tools can actually do. The goal of Project Eli was never to get everyone to agree with me, it was to create conditions where people could form honest views and share them without fear. Diversity of thought, including the uncomfortable kind, is how you make better decisions and grow.
One thing I’d push back on gently: the dystopian framing that sometimes surrounds this conversation — “adopt or be replaced.” Fear is a terrible motivator for innovation. It’s a terrible motivator for anything, honestly. If your team is going to get genuinely good at working with AI, it’ll be because they found it interesting, because it made them better at something they cared about, because it solved a real problem. Not because they were scared of the alternative.
The job security angle is real, affecting many people’s lives right now, and I’m not going to pretend otherwise. But the answer isn’t fear, it’s capability. Teams that are genuinely curious and skilled will find navigating these times easier. Building that curiosity requires safety, not pressure.
The thing worth taking with you
If your team is hesitant, or stuck in vague non-committal territory about AI, ask yourself: have you actually made it safe to be honest? Not safe in a policy sense, safe in a what happens when I tell you the truth sense.
The engineering instinct to protect yourself from expanding expectations is rational and understandable. You’re not going to talk your way past it with better demos and workshops. You need to change the framing and highlight the interesting problem to solve.
Remove the productivity expectation, even temporarily. Make the goal learning. Name the thing people are afraid of, that doing this well might mean they just get more work, and explicitly take it off the table.
And then treat the whole thing like what it is: onboarding someone new. Not because AI is a person. But because you already know how to do that, and those instincts are the right ones to activate.