Estimated reading time: 4 minutes
Key takeaways:
- Give juniors the verification loop: let them write the tests and acceptance criteria that agents have to meet.
- Stop being the blocker by asking what context your engineers lack and where they should be allowed to struggle.
- Explain technical decisions as consequences, in metrics your stakeholders already track.
The role of the engineering leader is shifting, and so are the skills required to succeed in the job.
AI has cut the cost of writing code. The harder parts of your job sit around it: deciding what’s worth building, checking what agents produce, growing your team, and explaining technical priorities to people outside engineering.
LeadDev spoke to a Stanford technical communication lecturer, a senior engineering manager, and a staff engineer about the five skills worth investing in now.
Your inbox, upgraded.
Receive weekly engineering insights to level up your leadership approach.
1. Judgment: decide what’s worth shipping
AI can produce multiple different ways to approach a problem in seconds. Someone still has to weigh customer context, security requirements, and, in regulated industries, the compliance environment.
“AI dramatically reduces the cost of producing an answer, but it hasn’t reduced the cost of making the wrong decisions in production,” says Sreenivasa Reddy, staff software engineer at BNSF Railway.
That gap is where human leaders add the most value, he says. Reddy calls the underlying problem the invisible validator: AI lets one person generate far more output, but someone still has to validate it, and that work rarely shows up in metrics that count pull requests and commits.
The validation gap is already here. In Sonar’s State of Code Developer Survey report, 96% of developers said they don’t fully trust AI-generated code to be functionally correct.
2. Mentorship: give juniors the verification work
Junior engineers are losing the work they once used to learn from, and that could thin the pipeline from junior to senior roles.
Matt Vassar, a core lecturer in the Technical Communications Program at the Stanford School of Engineering, compares it to a surgical resident who used to assist an experienced surgeon and now watches a robot do the job instead.
“Sometimes we fool ourselves by thinking AI can train us, but the reality is that your deepest training is through mentorship,” Vassar says.
His advice is to let juniors own the verification loop. They write the tests and acceptance criteria an agent has to satisfy, so that they still get reps on real production problems.
Tiffany Jachja, former senior engineering manager at Yahoo, says that when agents produce code at volume, the scarce work moves to the edges: knowing where AI agents fall short and how to explain that to your team. As product managers and other colleagues start producing code too, that mix of observation and technical understanding matters even more.
3. Delegation: stop being the blocker
Most leaders’ scope is growing. In LeadDev’s 2026 Engineering Leadership Report, 37% of engineering leaders said they are doing more hands-on technical work, and 45% are working more hours than this time last year.
The hardest shift for new managers is getting results through others instead of through your own work, Jachja says. The instinct to jump in and fix a problem works for an individual contributor. As a manager’s default, it keeps the team dependent on you and slows their growth.
Her rule is to never be the blocker. When she feels the urge to go faster, she asks what she’s taking away from someone else, because the work could be their opportunity.
Reddy describes the same shift as moving from the person who solves the problem to the person who creates the conditions for others to solve it. He asks three questions: What context is an engineer missing? What question would help them reason it through? Where should they be allowed to struggle?
More like this
4. Translation: explain decisions as consequences
The more senior you get, the more of your job happens outside engineering. You negotiate budgets, headcount, and roadmap tradeoffs with colleagues who don’t share your technical context.
Reddy turns technical decisions into consequences. He uses metrics his audience already tracks, such as lead time, change failure rate, and time to restore, instead of architecture vocabulary. However, he warns against oversimplifying.
“Good technical communication isn’t removing complexity, it’s identifying which part of complexity matters to the person making that decision at that level,” he says.
Jachja is working on the inverse problem: finding the one sentence that shows a non-technical colleague how much effort sits behind an engineering problem that looks like a two-minute fix.
5. Managing uncertainty: share the plan you have
No one knows what engineering teams will look like in five years, and you shouldn’t pretend to. Jachja recommends listening first, then sharing the plan you do have.
Berlin • November 9 & 10, 2026
LeadDev Berlin is two weeks away. Find what helps stretched teams keep going.
Reactions to AI vary across a team, and you need to understand where each person is coming from before your plans will land, she adds.
Vassar says to admit you don’t have the answers, then read the room. If the team is frantic, be the calming presence. If it’s coasting, raise the energy. He points out that earlier waves of automation often changed jobs for the better.
Reddy finds it useful to explain what’s known, what isn’t, what decision is being made now, and what would cause it to be revisited.
“Clarity is not the same thing as certainty,” he concludes.
