Somewhere in the last two years, the expectations placed on engineers changed without anyone writing it down.
Ship faster. Use the tools. Do more with a smaller team. Absorb the review burden of code you didn't write. Learn a new way of working while the roadmap stays exactly as full as it was before.
Most engineers I know have accepted this. What they notice, and rarely say out loud, is that the expectations placed on leadership didn't change at all.
The asymmetry
Accountability in most organizations flows in one direction. Engineers have sprint commitments, delivery metrics, performance reviews, and a manager asking why something slipped. The machinery for holding them to account is well built and constantly running.
Now ask the mirror question. When a team misses a quarter because they waited five weeks for a decision on which of two systems was the system of record, who is accountable for those five weeks? When engineers spend a third of their time on integration work that exists only because two leaders couldn't agree on ownership, whose number goes red?
Usually nobody's. The delay gets absorbed into the team's velocity and shows up as an engineering problem.
That asymmetry was survivable when execution was the constraint. It isn't anymore. When a meaningful share of the building gets faster, everything that isn't building becomes the bottleneck: prioritization, decision latency, unclear ownership, shifting direction. Those are leadership outputs. AI has quietly promoted them into the critical path, and the people responsible for them are often the least measured people in the organization.
If the constraint has moved from how fast engineers build to how fast the organization decides, then leadership belongs on the same scoreboard we've always given engineering.
What we are actually asking for
Be honest about the size of the ask. Adopting AI properly is not "use the assistant." It's asking engineers to:
- Review more code than they write, including code with no author to ask.
- Develop judgment about when a plausible-looking answer is wrong, which is harder and more tiring than writing the thing yourself.
- Carry the same production accountability for output they generated in a fraction of the time.
- Change a craft they have spent a decade getting good at, in public, while still hitting dates.
That is a substantial, genuinely difficult professional shift. It is reasonable to ask for it. It is not reasonable to ask for it while offering nothing in return and calling the result a productivity gain.
The other half of the contract
If you're going to hold engineers accountable for delivering more, here is what you owe them. Not as a perk, as the reciprocal obligation that makes the ask legitimate.
- Time blocked, counted from the team's side. Not "how quickly did leadership decide," which just invites fast, hollow decisions to beat a clock. Measure how long teams sat waiting, reported by the people who did the waiting. Treat a two-week block the way you'd treat a two-week build failure.
- Pivots that arrive with a name and a reason. The goal isn't a frozen roadmap; in this market that would be its own kind of failure. The goal is that a change in direction is attributed and explained, rather than appearing in the backlog overnight as though it had always been there. Faster execution makes the explanation worth more, not less.
- Claims calibrated to the evidence you actually have. Isolating AI's effect on defect rates, amid turnover and tech debt and two new product lines, is genuinely hard. That difficulty is not a reason to build a telemetry programme before you can say anything. It's a reason to stop announcing the 30% gain. If you can't separate the signal, lower the claim. Leaders who report only the numerator aren't measuring, they're marketing.
- Capacity that reflects the new work. Review, validation, and judgment are real work. If they aren't in the plan, you haven't redistributed the effort, you've hidden it.
- Owning the outcome you asked for. If the AI initiative you sponsored doesn't produce value, that is a leadership result, not a team result. Say so in the same forum where you announced it.
None of these require a tool. All of them require a leader willing to be measured on something uncomfortable.
"But won't they just game it?"
Some will. Any number attached to a person's standing gets managed: decisions closed without being resolved, pivots justified in language that explains nothing.
It's worth noticing what we usually do with that objection, though. We have never once treated it as disqualifying for engineering. Velocity is among the most gamed numbers our industry has ever produced and we kept it for a decade. The risk of gaming is real in both directions; only one direction has ever been excused because of it.
The protection isn't a cleverer dashboard. It's who holds the instrument. When the number comes from the teams living with the constraint rather than from the people being assessed, gaming it requires a blocked team to agree they weren't blocked. That is a much harder lie to tell, and it's the reason to measure this from the bottom up.
With one dependency that isn't small: none of this works unless it's safe to file the report. A team that expects "we waited two weeks on you" to be heard as an accusation will quietly absorb the delay and work the weekend instead, and your numbers will look excellent right up until the people producing them leave. So safety isn't an adjacent virtue here, it's a precondition of the instrument working at all. You will find out where you actually stand the first time a reported block points at someone senior, and what happens in the ten minutes after that will tell your organization more than any dashboard.
Making it symmetric
The practical move is small and slightly painful: for every expectation you raise on the engineering side, write down the corresponding commitment on yours, with a name and a number attached.
You asked for 20% more throughput? Then commit to a ceiling on how long any team sits blocked, let the teams themselves report the breaches, and put that number in front of the same audience that sees the delivery dashboard. You asked teams to adopt a new workflow? Then commit to removing two approval steps this quarter, and be specific about which.
The moment leadership commitments have owners and dates, something shifts. The conversation stops being "why is engineering slow" and becomes "where is this system slow," which is a question the whole organization can actually answer.
The part that builds trust
Engineers are not cynical about AI. In my experience they are more curious about it than most executives are. What they are cynical about is being asked to change how they work by people who won't change how they work.
Accountability that only points downward isn't accountability. It's just pressure, and pressure without reciprocity is how you lose the people you most need for the transition.
The organizations that come out of this era ahead won't be the ones that demanded the most from their engineers. They'll be the ones where the demand ran in both directions, and everyone could see it.