Skip to content

Knowledge base

Leading AI Adoption

The levers an engineering leader actually controls when a team adopts agents, and the measurement trap that turns a good adoption into a bad one.

Written by

Updated:

Leadership 2

The gap between organizations is not a tool gap. Google reported roughly 10% gains; METR measured a 19% slowdown on the same class of work; some organizations shipped as much as 50% more defects after adopting AI (Leadership in AI-Assisted Engineering (opens in a new tab), DX). The tools were comparable. The leadership was not.

Distributing licenses is not adoption. “Companies fail at AI adoption because they treat it like installing software when it’s actually rewiring how people work” (AI-Powered Workforce Playbook (opens in a new tab), GitHub).

What a leader actually controls

Permission to experiment. DX counts clear AI policies and time to learn, with space to experiment rather than only materials, among the factors that move adoption most (Leadership in AI-Assisted Engineering (opens in a new tab), DX). This is the cheapest available intervention and most organizations skip it, because “we bought the licenses” reads as encouragement to the person who signed the invoice and as nothing at all to the person being measured on sprint velocity.

Psychological safety. Without it, defects hide, bad decisions go unchallenged, and the team runs on a fiction of consensus. Agentic AI is an amplifier and a mirror: “if your organization is faulty, is broken in some ways, it will mirror that” (The Elastic Loop (opens in a new tab), INNOQ). Adoption does not fix a dysfunctional organization; it makes the dysfunction faster. The mechanism is the one in Transformational Leadership.

Agency, not just autonomy. “Agency is the ability to make use of autonomy. If your people are not agentic, they won’t use your autonomy. You can bury them in autonomy. They won’t embrace it” (The Elastic Loop (opens in a new tab), INNOQ). The great divide in AI outcomes runs along agency, not seniority. Granting freedom to a team that has been trained for a decade to wait for approval changes nothing.

The operating model, not the tooling. Enterprises that changed only their tools plateau at 5-15% productivity gains. Top performers were seven times more likely to have AI-native workflows across the SDLC and six times more likely to have restructured roles; about 70% of surveyed companies had not changed their role definitions at all (Moving Away from Agile). The concrete moves: pods of three to five instead of teams of eight to twelve, continuous planning instead of quarterly, spec-driven work instead of story-driven. The plateau predates generative AI: in Roland Berger’s 2022 survey of 50 board-level executives, more than half had started digital business models or processes and failed to make them scale, and the reason they gave was that agile had begun and ended at team level, with budget processes still demanding precise planning at the start of the year and resisting reprioritization (Roland Berger - The digital dilemma (opens in a new tab), 2022).

A career ladder redrawn for the new unit of work. One engineering team’s account, written while it rewrote its own ladder, argues that a checkbox for AI use misses the change. The old rungs assumed the smallest unit of an engineer’s work was the code behind one ticket that someone else had scoped, shipped and watched in production. At a company reporting about 95% of its backend code as generated, the unit becomes the whole feature: design it, build it, ship it, roll it out and keep it running. Shipping a lot of working code used to stand in for competence, and AI made that stand-in free, so the rungs now ask what the engineer understands and which metric the work moves. Leads are expected to name that number (Integral Engineering - The unit of work for engineers has moved. Did your expectations move with it? (opens in a new tab), August 2026, practitioner account of one company’s ladder).

The ladder also gained a column whose expectations grow with level. Engineers have no hard cap on token spend, but they must know what they spend and be able to justify it, and a task done twice should be automated the third time. Each level owns a part of fighting slop, the plausible, subtly wrong output that is cheap to generate and costly to clean up: an engineer catches it in their own work, a lead stops it for the team, and a manager builds the system that keeps it down. Juniors keep the friction that builds judgment instead of letting AI skip it, under the rule “learn with AI, not around it”, while a lead is expected to build tooling the whole team reuses. The author names the cost: given the choice, a large token budget goes to an experienced engineer, who can tell when the output is wrong. Two structural rules keep the ladder usable. Every skill sits in exactly one place, so a behaviour you cannot find is missing. And the ladder describes the role while a separate review cycle scores the person, so it never becomes a checklist that earns a promotion (Integral Engineering - The unit of work for engineers has moved. Did your expectations move with it? (opens in a new tab), August 2026, practitioner account of one company’s ladder).

Amazon revised its software engineer role guideline in October 2026 and kept it free of named technology, as it had through the cloud, microservices and serverless. Its senior engineers judged AI a faster and deeper change than those, and still wrote the guideline around what does not change, impact on customers, the business and the team, because any definition of good AI practice written now would be outdated within a year. Three expectations sit beside it. An engineer whose work current AI tooling does not help treats that as a finding, not a failing: they document why, share it with peers and raise it with their manager, and explaining where AI does not yet help counts as the judgement the role asks for. A leader’s understanding has a concrete bar: they have used the tools on their own production work, can name one task where the tools helped and one where they did not, and can explain that judgement to their team. And engineers and managers closer to their customers and product get the most out of agentic development, so the guideline asks every level to reconnect with both, with the expected scope growing with seniority (Amazon - An update from Amazon engineering leadership on the role of the developer in the age of AI (opens in a new tab), October 2026, company memo).

A clean codebase. Codebase cleanliness correlates with AI productivity gains (R² 0.40 across 120,000+ engineers) more closely than token spend does (R² 0.20) (AI Productivity Research). Leaders who fund an AI budget but not a cleanup budget have bought the weaker lever.

A relationship boundary. The human-agent boundary should reflect the relationship a customer expects. In an interview on the German podcast {ungeskriptet}, Dominic von Proeck, who runs the AI training company Leaders of AI, describes letting AI do the sales chores, preparing and following up customer conversations and updating the CRM, while no agent writes comments on the platform or answers private messages, and a call through the website always reaches a person. This is a practitioner and training-vendor policy, not comparative evidence, but it makes the boundary explicit before implementation starts ({ungeskriptet} - Was er mir über KI erzählte, hat mich schockiert (opens in a new tab), July 2026).

Written norms for conduct, not a separate AI ethics. Honeycomb published its rules for using AI in business conduct and grounded them in the amplifier point above: no new standard, the existing values at higher stakes. Four of its eight rules travel beyond that company. Generic outreach with a name slotted into a template disrespects the recipient and is now cheap enough to send at scale. Attention is a cost, so the test before sending a long document is whether it is useful and whether you would want to receive it, not whether generating it was cheap. Ownership does not move: if your name is on it, you own it, whatever drafted it. And the set is written to be judged rather than applied, because a rulebook for AI conduct dates faster than the judgment behind it (Honeycomb - AI norms and values, part 1 (opens in a new tab), August 2026, vendor, first of three parts).

Reject unnecessary agents. The team retired a chain of agents that walked a customer through the purchase on the website, from the contract to the course, once a shop where people click through three steps did the job. Its advice is to start from the use case, not the technology: its bookkeeping agent collects, names and files incoming invoices on a very cheap model, nobody on the team checks its work, and the team accepts that risk because the tax advisor complains when a receipt is missing or duplicated ({ungeskriptet} - Was er mir über KI erzählte, hat mich schockiert (opens in a new tab), July 2026, practitioner and training vendor).

A stated human-agent ratio. One report proposes a single metric for a team that runs agents: how many agents a role or process needs, and how many people are required to guide them. It names both failure directions. Too few agents per person leaves capacity unused. Too many overwhelm the human capacity for judgment, which introduces business risk and burnout. The same report argues the functional org chart gives way to a “Work Chart”, where a team forms around an outcome and disbands when it is met, and reports 46% of leaders already using agents to automate a whole workflow or process. Fieldwork ran in February and March 2025 across 31,000 knowledge workers in 31 markets, and the publisher sells the agent tooling the report recommends, so the ratio is a question each organization answers for itself rather than a benchmark to hit (Microsoft - 2025: The year the Frontier Firm is born (opens in a new tab), April 2025, vendor).

The measurement trap

The instinct is to measure activity: PRs merged, tokens spent, seats active. Every one of those goes up under AI adoption whether or not anything improved, and none of them survives a serious question from a CFO.

Three rules keep the dashboard honest.

Never report adoption without outcome. More PRs with a rising change failure rate is a regression that looks like a win. Pair every utilization metric with a quality guardrail. The four KPIs in Measuring Agentic Engineering Impact, DORA, rework rate, use of what ships and cost per change, are the minimum honest set.

Never measure an individual with a survey that feeds a performance review. Developers misjudge their own productivity by an average of 30 percentile points (AI Productivity Research), so self-assessment is a conversation starter, not evidence. Attach it to a review and it stops measuring maturity and starts measuring fear.

A third rule follows from how vendor segments get built. Distrust a segment defined by its own outcome. The Work Trend Index defines a “Frontier Firm” by five traits, among them org-wide AI deployment, current agent use, and a leadership belief that agents are key to AI ROI. It then reports that 71% of leaders at those 844 firms say their company is thriving against 39% globally, and that 55% say they can take on more work against 25% globally. The comparison is correlational and the segment is partly defined by leadership optimism, so it describes who the early adopters are and cannot show that agents produced the result (Microsoft - 2025: The year the Frontier Firm is born (opens in a new tab), April 2025, vendor). Any internal dashboard that compares an AI-enthusiastic pilot group against a company average has the same defect.

The more useful signal is the one nobody counts: unclosed loops. Not how many merge requests were opened, but how many went stale. How many agent sessions were abandoned in frustration. How many agent-opened refactoring PRs nobody ever reviewed (The Elastic Loop (opens in a new tab), INNOQ). Those numbers point at the bottleneck; the vanity metrics point away from it.

  • The studies behind the numbers above: Evidence.

Resources

Leadership and adoption