We’ve all seen the headlines. "AI will replace the junior engineer”. "The 10x engineer is now a 100x engineer." In leadership meetings almost every conversation comes back to velocity and how we could unlock efficiency with AI.
But when you talk with the team the reality can be different. Your most senior engineers - the ones who built the core of your system - are looking at Copilot or Cursor with a squint. Some see it as a toy; others see it as a threat to the craft; a few see it as a glorified Clippy that hallucinates half-baked solutions into their carefully maintained repos.
As Engineering Managers and Directors, we are currently in a delicate spot. We are being asked by the business to "leverage AI," but we are being told by some of our best people that it’s "not quite there yet".
How do we advocate for AI without sounding like a marketing brochure? How do we move the skeptics without losing their trust?
1. Validate the Skepticism (Because it's often right)
The quickest way to lose a senior engineer is to pretend AI is a silver bullet. It isn't. It produces technical debt at scale if unmonitored. It struggles with complex, cross-service architectural nuances.
When a skeptic says, "It doesn't understand our legacy monolith," don't disagree. Instead, pivot. Your job isn't to convince them it’s perfect; it’s to help them find where it’s useful. You need to think about this in the long term - if they can start to integrate AI into their workflow now it means that as AI gets better they’ll be ready to really use it - if they just get no value they could give up and not catch the wave when it really is ready for them. Good entry ways for engineers can be as simple as just asking questions about the code base or rubber ducking ideas. You should also highlight that keeping up with advancements is part of the job and “career insurance” - just like they keep up with new programming languages or features, they need to keep up to date with AI. This is a good long term investment all round.
Also it’s your job to take the feedback of the team back to leadership - you need to set expectations on where the technology can help now and where it can’t. This of course can be tricky depending on how close the leadership team is to the technology - a founder who wrote a lot of the code may get that quickly, whereas someone from a non-technical background might need this explained in other ways. That’s probably a blog for another day.
2. Move from "Productivity" to "Cognitive Load"
"Productivity" is a dirty word to many engineers. It implies a treadmill - if they code 20% faster, we’ll just give them 20% more tickets.
Shift the conversation to Cognitive Load. Every engineer has a finite amount of "thinking energy" per day. If AI can handle the "janitorial work" of engineering - formatting, boilerplate, regex, SQL migrations - it leaves more room for the high-level system design they actually enjoy.
Advocate for AI as a tool to reduce the boring, not just to increase the output. In fact, don’t focus on the increase of input at all - that should come as a result (we hope - let’s put a pin on that and see if it’s true in 6 months). If you already survey the team to measure developer satisfaction or on-call stress, highlight that you’ll be interested to see if AI can help improve these things too. These are things that will resonate better with your engineers.
3. Identify the Champions
I can’t be the one pushing the tool - I’m not writing code day to day. If I was to interview for a role as an engineer on our team, I wouldn’t pass the test any more. Identify the engineers on your team who are getting benefits from AI, and who carry influence within your team, and ask them to advocate for it and highlight their wins within the team. That can be demos in your team meetings, or as simple as a quick slack message highlighting a quick win. You’ll find other engineers who look up to those engineers will quickly try emulate what they are doing.
If the Director or VP says "Use AI" it’s a mandate. If the influential engineer on the team says, "Actually, I used Claude to refactor that gnarly Python script in five minutes", the rest of the team listens. Your job is to create the space for those internal "wins" to be shared without it feeling like a forced demo.
4. Highlight you expect a short term productivity drop
We need to encourage our teams to use the tools, but adopting new tools takes time. I think about it like switching an IDE - it takes time to get used to it. Your workflow changes. You might need to build new tooling to make yourself productive. Just the setup and learning takes time, and that’s going to slow down the projects you are working on. If you can, talk openly about that and say that for a quarter we know we may slow down a bit in order to get the team onboard with the tools. Giving the team space to learn will be appreciated, and it's necessary. My experience is with even a small bit of time (e.g. a week) things can accelerate very quickly as momentum and familiarity with tools increase. Try a hack week or something similar to give people a safe space to experiment.
Wrapping up
We need to prompt our organizations to evolve. And that evolution won't happen through mandates alone. It happens through empathy, technical honesty, and a relentless focus on making the engineer’s life better - not just making the burndown chart steeper.
How are you shielding your teams from 'AI Hype' while still moving the needle?
Comments
Post a Comment