Five Engineering Leadership Skills That Matter When AI Writes the Code

Which habit is behind this for you? The free 3-minute assessment names it and links the playbooks that fix it. Take the assessment →

A recent LeadDev feature by Lucy Adams asked three practitioners - Matt Vassar, who teaches technical communication at Stanford's School of Engineering; Tiffany Jachja, formerly a senior engineering manager at Yahoo; and Sreenivasa Reddy, a staff software engineer at BNSF Railway - which leadership skills are worth building now that writing code costs so little. Below is our summary of the five areas they point to, in our own words, with the practical conversation each one turns into. The original article is on LeadDev.

1. Judgment: decide what is worth shipping

An agent can offer several workable approaches to a problem in seconds. Picking one still requires knowing the customer, the security posture and, in regulated industries, the compliance rules the code has to live under. That weighing is where a leader adds the most value, and it is the part of the job that has not become cheaper.

• Make validation visible. Note the reviews, rejections and "not this approach" calls you and your team make. They are real output, and they belong in 1:1s and promotion cases alongside shipped features.
• Ask the production question early. "What does this cost us if it is wrong in production?" is a better filter than "does it work on my branch?"

2. Mentoring: hand juniors the verification loop

Much of the work junior engineers used to learn from is now done by agents, which risks thinning the pipeline from junior to senior. Vassar likens it to surgical training in which the trainee, instead of assisting a senior surgeon, ends up observing a machine perform the operation. In his view the tool cannot replace what mentorship teaches.

His suggestion is practical: let juniors own verification. They write the tests and acceptance criteria an agent has to satisfy, so they still practise on genuine production problems. Jachja adds that as code becomes abundant, the valuable work shifts to the boundaries: understanding where agents tend to fail, and being able to explain those limits to a team. As product managers and other colleagues start generating code too, that judgment matters more, not less.

• Review the criteria, not only the diff. A junior's acceptance criteria show how they think about failure. That is the thing to mentor.
• Ask "what would make this wrong?" It trains the habit of looking for the case the agent did not consider.

3. Delegation: stop being the blocker

Leadership scope keeps growing. In LeadDev's 2026 Engineering Leadership Report, 37% of engineering leaders said they are doing more hands-on technical work than a year earlier, and 45% said they are working more hours. Under that pressure, the reflex to jump in and fix things yourself gets stronger - and it is the reflex that keeps a team dependent on you.

Jachja's rule is never to be the blocker. When she feels the urge to speed something up by doing it herself, she asks what opportunity she would be taking from someone else. Reddy frames the same shift as going from being the one with the fix to being the one who sets others up to find it. He uses three questions:

• What does this engineer not know yet that they need? Often the gap is information, not ability.
• What could I ask that lets them work it out? A good question transfers more than a finished answer.
• Where is it worth letting them struggle? Some difficulty is the point. Removing all of it removes the learning.

4. Translation: explain decisions as consequences

The more senior the role, the more of it happens outside engineering - budgets, headcount and roadmap tradeoffs negotiated with people who do not share your technical context. Reddy's approach is to turn technical decisions into consequences, expressed in measures the audience already tracks, such as lead time, change failure rate and time to restore service, rather than in architecture vocabulary.

He is careful not to equate this with simplifying. The aim is selection: out of all the complexity involved, surface the piece that bears on this particular decision-maker's choice. Jachja works on the reverse problem: how to convey, in a single line, the real effort behind a request that looks trivial from the outside.

• Instead of "we need to decouple billing from checkout", try "today one billing bug can take checkout down; after this change it cannot, and recovery drops from hours to minutes."
• Instead of "we have a lot of tech debt in the deploy pipeline", try "one release in five needs a rollback; this work halves that."
• Instead of "it's just a config change", try "the change is one line; proving it is safe for every customer is three days."

5. Managing uncertainty: share the plan you have

Nobody knows what engineering teams will look like in five years, and pretending otherwise costs trust. Jachja recommends listening before presenting a plan, because reactions to AI vary widely within one team and a plan lands only once you understand where each person is coming from. Vassar suggests admitting you do not have every answer and then reading the room: calm a team that is anxious, raise the energy of one that is drifting. He also notes that earlier waves of automation often changed jobs for the better.

Why these are conversation skills

Read the five again and notice where each one actually happens. Judgment is exercised in a design review. Mentoring happens in a pairing session or a 1:1. Delegation is a conversation where you hand over something you could do faster yourself. Translation is a budget or roadmap meeting. Uncertainty is managed in front of the team. The leaders who handle AI well are unlikely to be the ones who prompt best - they are the ones who are good at these conversations, and like any skill, those improve with deliberate practice before the moment counts.

Source: summarised and paraphrased from "5 skills that make you a better engineering leader" by Lucy Adams, LeadDev, 2 November 2026. Views are attributed to the people quoted there; the examples and practical notes are DrillUp's.