How I Encouraged the Team to Adopt AI Dev Tools

When AI coding tools started getting good, I had a problem that a lot of engineering managers had: I could see that something important was happening, but I couldn’t credibly push my team toward it. You can’t advocate for a tool you don’t understand, and you definitely can’t lead a team through a shift you haven’t been through yourself.

So I’m going to write down what actually worked for me, because it wasn’t a mandate, a training budget, or a top-down rollout. It was slower and quieter than that, and I think that’s exactly why it stuck.

It started with a demo from our CTO

I’d like to say this was all my idea, but it wasn’t. What really got the ball rolling was watching our CTO start getting genuinely good results with Claude Code — fixing several bugs at the same time, in a fraction of the time it used to take. Then the CTO ran a demo for the rest of us, showing exactly how he was doing it.

That demo was a real eye-opener, and it’s the thing that got me to start taking this seriously. I walked out of it needing to understand how he was pulling it off, and how I could do the same.

That’s when I stopped using Cursor and committed to learning Claude Code properly. It didn’t take long to work out a setup that clicked for me: using git worktrees so I could have Claude fixing more than one bug at a time, and building a personal flow around iTerm2 with different-colored tabs for the different contexts I had running at once. Once that workflow fell into place, the multiple-bugs-at-once results the CTO had shown stopped feeling like magic and started feeling like something I could do.

Then I put it to work on my own job

After the CTO’s demo, but before I dived into a personal project, I tried pointing Claude Code at something closer to home: my Obsidian vault. I keep all of my management work there as markdown — notes from every one-on-one, notes from meetings, notes about goals and thoughts and what we should do next — all in a private git repository under my control. I handed that vault to Claude Code and let it figure things out for me, to save myself time.

The first thing I used it for was prepping for one-on-ones. Before each one, Claude Code would read back through my previous notes on that person and pull in context from GitHub and our ticket-tracking system to understand what they were actually working on. Instead of scrambling to remember where we’d left off, I’d walk in with a clear picture already in hand.

Later I folded in Gemini’s notes from our stand-up meetings, so Claude Code could use them to summarize each person’s current work. That made it much easier to follow what everyone was doing from week to week.

Then I went deep on a personal project

Getting fluent in the day-to-day workflow was one thing, but I wanted to know what Claude Code could really do when I let it loose on something big. I’d been using it for our actual work and bug fixing, but always in small, bounded ways. So I spent my weekends learning the technology on a personal project. I picked something with no stakes and no deadline — an old game I wanted to revive — precisely because it gave me complete freedom to use Claude Code however I wanted. No production system to break, no review process to satisfy, nobody watching. Just me, a side project, and the tool.

That freedom turned out to be the whole point. I wasn’t trying to ship anything. I was trying to find out what was actually possible. And the answer surprised me. I watched Claude Code read 35-year-old C source, understand it, and rewrite whole subsystems correctly on the first try. I learned where it was strong, where it needed a tight leash, and what a good working rhythm with it felt like.

When I brought this back to my work, I wasn’t speculating about AI tools. I had opinions, I had scars, and I had a real sense of what these tools could and couldn’t do. That credibility is something you cannot fake in front of good engineers, and you can’t get it from a webinar. You have to use the thing.

If you’re a manager reading this: this is the step you can’t skip. Pick a personal project, give yourself a couple of weekends, and actually build something. Everything else I did only worked because I’d done this first. In my experience it takes something like 20 to 30 hours of actually using Claude Code before you’re competent enough with it to understand what it can do and to speak about it credibly — so budget for that, and don’t expect a single afternoon to get you there.

It helped enormously to have pioneers

I’ve already talked about the CTO’s demo, but the influence of our most senior engineers went well beyond that one session. Both our CTO and our principal engineer kept leading the way technically — continuously learning, picking up new skills, and openly talking about their techniques. Having senior, respected people out in front really helps.

That’s the thing I’d encourage any manager to cultivate deliberately. You want pioneers on the team — people who are genuinely excited to push the technology forward and, just as importantly, who narrate what they’re finding so others can follow. When your most technical people are visibly drawn to a tool and talking about it in the open, everyone else leans in to see what they’re seeing.

Then, the one-on-ones did the real work

The demos created interest, but the one-on-ones are where adoption actually took root. I used my regular one-on-ones in three deliberate ways.

I taught. I’d tell each person what I’d been learning about Claude Code, and show them — concretely — how it was changing my own work and making me faster. Not “you should try this,” but “here’s a thing I did yesterday that would have taken me an afternoon, and here’s how.” Sharing my own experience, including the parts where I’d stumbled, made it safe for them to experiment without feeling like they were behind.

I asked. Every week, in every one-on-one, I asked two questions: What AI tools are you using? and What have you learned? I cannot overstate how much these two questions did. They sent a clear, repeated signal that this was something I cared about and expected people to be exploring. They surfaced tips that I could then carry to the next person. And — gently, without anyone being put on the spot in a group — they created a small, recurring moment of accountability.

I listened. People told me what was working and what was frustrating. Some were enthusiastic early adopters; some were skeptical; some just hadn’t gotten around to it. All of that was fine. The point of asking every week wasn’t to push, it was to keep the door open and keep the conversation alive.

What happened over time

None of this was a big bang. There was no launch date. But week over week, the answers to “what have you learned?” got richer. People who’d been quiet started showing up to demos with their own things to share. The early adopters pulled the curious along, and the curious pulled the skeptics. Adoption grew, steadily, and it grew because people chose it — not because anyone told them to.

One of the most fun parts of this was watching the moment it clicked for each developer. One week we’d be talking, a little abstractly, about what might even be possible with these tools. A couple of weeks later that same person would show up to our one-on-one and excitedly announce that they hadn’t written any code by hand in two weeks, because they’d figured out how to get Claude to write all of it. You could see the switch flip in real time, person by person, and it never stopped being satisfying to watch.

Looking back, the pattern is pretty clear:

• Earn credibility by using the tools yourself, on something low-stakes where you have total freedom to explore.
• Make the value visible. A live demo from a respected engineer — fixing several bugs at once — beats any productivity slide.
• Cultivate pioneers. Senior, respected engineers who push the technology and narrate their results — in Slack, in the open — pull everyone else along.
• Use your one-on-ones to teach, ask, and listen — every single week, consistently.
• Be patient. Adoption is a curve, not a switch. Your job is to keep the slope positive.

The technology is moving fast, and it’s tempting to try to force the pace with mandates. In my experience, the durable way to lead a team through a shift like this is to go through it yourself first, then make it easy, visible, and safe for everyone else to follow.

At a startup you often feel like everything has to happen in a hurry — like these changes shouldn’t be taking this long. When that pressure hits, it’s worth reminding yourself, as a manager, that your team isn’t competing against some idea of what perfection should look like. Your team is competing against other teams of human beings who are wrestling with the very same problems and challenges, trying to work their way through it just like you are. As long as your team keeps executing, keeps adopting new things, and keeps learning, they’re going to do well. When it comes to leading people, go slow to go fast.