5 min read
What is a senior engineer?
A senior engineer is someone whose judgment expands what a team can deliver. The title should mean people can rely on that judgment when the system is unfamiliar, the stakes are real, or the obvious solution is wrong. Plenty of organizations hand out the title without ever agreeing on what it requires.
Wilford called me while I was driving back from the gym. He was driving to the office. We talk often about leading organizations through AI adoption. I change names, of course. This week, he told me he had spent more on AI than the rest of his organization combined. He also had senior engineers doing work that did not need to be done. The busywork kept them from slowing down the rest of the team, and it was easier than phasing them out.
That is a strange way to run an organization. The company was spending heavily on a new way to produce software while paying experienced engineers to produce work nobody needed. The AI bill showed up in one place. The cost of the busywork hid in salaries, delays, and the valuable work those people could not do instead.
This is the part AI has exposed. A model can search a codebase, trace dependencies, write tests, and produce a change quickly. It cannot decide whether the change matters to a customer, whether the system can safely absorb it, or whether the result works in production. Those are engineering judgments. A senior engineer is supposed to bring them.
Senior engineer acceptance criteria
If I were defining the senior engineer role today, I would make the expectations clear enough to assess. A senior engineer should meet these criteria:
Most readers also read: The Engineers Who Can’t Use AI Agents Don’t Have a Tools Problem
-
Understand the customer and the value of the work. Know who the customer is, what problem they need solved, and what should improve when the work reaches them. Use that to decide whether the problem is worth solving before the team spends time on it.
-
Understand the value stream. Follow the path from customer need through product decisions, engineering, review, release, and support to customer value. Know which teams and decisions affect that path, where work waits, and how a change in one place affects delivery elsewhere.
-
Make tradeoffs and risk decisions explicit. Compare the available approaches in terms of cost, delivery time, quality, security, and customer impact. Identify which risks can be reduced, which are being accepted, who owns them, and what evidence would make the team pause or recover. Help the team make a sound decision when priorities pull in different directions.
-
Use AI to ship working product. At this point in the job, using AI should not be a mystery. Choose and direct the tools to deliver software that solves the stated problem.
-
Understand the AI tool ecosystem. Know the models, agents, context, permissions, and supporting systems in use. Understand where they are useful, where they fail, and what kinds of mistakes they make. “The agent gave me bad code” is not a diagnosis. It is the first clue.
-
Build ways to verify the change. Define the expected behavior, inspect the work, and use meaningful automated tests. Improve the checks the team relies on so changes can be released and recovered safely. Senior engineers should help build these practices, and leaders must give them the authority and support to do it. Asking an agent whether its own code looks good is not quality control. It is asking the defendant to run the trial.
-
Teach the team. Help other engineers use AI effectively, make sound engineering decisions, and get working product into customers’ hands. The knowledge should spread beyond one person.
-
Explain the economics in plain business language and influence decisions. Show leaders what delay costs, what risk a change reduces, what value it could create, and what the organization keeps paying if it does nothing. When weighing AI spending, compare the AI bill with engineering time, review, rework, release delay, and customer impact. A lower AI bill does not make unneeded work valuable. State the assumptions, use a credible range when precision is impossible, and give leaders a way to check the result without relying on technical terms.
Here is the uncomfortable possibility: some people reached senior roles by getting changes through a slow system without learning how to engineer software well. They copied the local pattern, patched the next ticket, and kept going. When tests were thin and releases were rare, a steady stream of completed tickets could look like sound judgment. AI makes the gap harder to hide. Now someone has to explain the system, direct the work, and show that the result is correct. Some people with senior titles have never had to do all three.
That is not a reason to assume every struggling engineer is unqualified. A team may be stuck with unclear ownership, compliance work that arrives late, or release decisions controlled by another group. A new AI tool also takes time to learn. Leaders need to hear from the engineers and inspect the conditions around the work before deciding whether the problem is skill, process, or both.
Wilford’s choice to keep people busy kept them out of the team’s way and postponed a hard staffing decision. It also postponed the more useful question: could those engineers do work the organization actually needed without slowing down the people around them? Busywork lets a leader call a backlog a plan. It does not make the work valuable, and it does not tell anyone what the team can do.
Organizations helped create this problem. They often treated tenure as proof of judgment, rewarded people for moving tickets through a bottleneck, and made it uncomfortable to question senior decisions. People respond to the system around them. If leaders want a different standard, they have to state it, make room to develop the skills, and let teams point out where the system prevents good work.
Use these criteria to discuss several real changes, not to fill out another competency scorecard. Ask the senior engineer to explain the customer outcome, the proposed approach, the risks, and the cost of waiting. Invite the team to challenge the assumptions and explain what gets in their way. Then look at the results over time: did the changes reach customers safely, did they help, and can the team handle the next ones with less uncertainty?
That is a standard executives can use. A senior engineer should help the organization choose valuable work, use AI to deliver it, build the engineering practices that verify it, explain the economics, and teach the team. If someone cannot do those things today, find out what is in the way and give them a fair chance to learn. If the organization keeps assigning work nobody needs because making a decision feels awkward, the title is not the only thing that needs attention.
Companion
