The meeting that didn’t work.
The sprint review should have been a celebration. The engineering team had adopted an AI coding assistant three months earlier. Velocity numbers were up. PRs were merging faster than anyone had seen. The CTO had shared the dashboard in the all-hands and called it a turning point.
Then the product manager spoke. She had written fourteen user stories in the last sprint. Eleven of them had come back from engineering with clarifying questions — scope ambiguity, edge cases not covered, acceptance criteria too vague for the agent to work from. Each one added a day. A few added three.
The QA lead went next. His team was now reviewing pull requests that were, on average, twice the size they had been six months ago. Same team. Same capacity. The test suite was growing faster than his engineers could validate it. He had raised a headcount request. It was under review.
The designer said nothing. She had started using a generative UI tool on her own, without a structured path or training budget. She was three weeks ahead of the process. Nobody had told her how to constrain its output for the design system.
The engineering team had been enabled. Everyone else in that room had not. And the bottleneck, as predicted, had simply moved.
To see how AI shifts bottlenecks instead of removing them, read the previous article in this AI Enablement series, The Bottleneck Just Moved.
The number that should change the conversation.
In September 2025, DORA and Google Cloud published their State of AI-Assisted Software Development Report, alongside an AI Capabilities Model — seven foundational capabilities that determine whether AI productivity gains actually reach an organization’s bottom line.
Two of those seven are not engineering capabilities.
They are: user-centric focus — the ability to decompose work into small, user-validated slices — and working in small batches — the practice of limiting work in progress and releasing frequently. Both are product and delivery capabilities. Both are owned primarily by product managers, designers, and delivery leads, not by the engineers writing the code.
DORA’s research found that user-centric focus directly moderates AI’s impact on team performance. Teams with low user-centricity that adopt AI don’t simply fail to improve — their performance decreases.
As DORA put it: a team with poor user focus that adopts AI is likely to be propelled even further in the wrong direction. Only at high levels of user-centricity do teams see performance increase with AI adoption.
Working in small batches carries its own dynamic: without it, AI’s tendency to generate large, unstable changes goes unchecked — speed accumulates without translating to product performance. Neither capability is owned by engineering. Both belong to the roles this article is about.
This is not an edge case. It is the default state of most AI rollouts today.
Diagram 1: DORA’s AI Capabilities Model (2025). Two of seven foundational capabilities are product and delivery capabilities not owned by engineering. Low user-centricity with AI adoption leads to decreased team performance.
Where the enablement budget actually goes Picture the typical rollout. Seat licenses are procured for every developer. Onboarding sessions run for two weeks. A prompt engineering workshop is added to the calendar. A Slack channel is created — #ai-tools — and a PDF guide is pinned to it.
Six months later, the program manager reports that developer adoption is at 74%. The CTO calls it a success.
The seat-license spend goes to engineering. The transformation budget does not exist.
Meanwhile, the product manager is still writing requirements in the same prose format she used five years ago. No one told her that AI agents work from structured, machine-readable specifications. The QA engineer has no structured path for directing test-generation agents. The security engineer is still retrofitting reviews after merge. The SRE team is managing a CI pipeline that was designed for a world of human-paced commits.
Diagram 2. The enablement gap in a typical AI rollout. Developer roles receive comprehensive structured investment; non-developer roles in the same delivery chain share a Slack channel and a PDF.
What changes for each role
The three transformations described in the first article in the series, The Bottleneck Just Moved — practice, organization, and developer — are not sequential. They are simultaneous. But the organization transformation has specific and learnable shape for every non-engineering role in the delivery chain.
Diagram 3. The full delivery circle. Every feature passes through eight functions before reaching a user. AI currently amplifies one — Engineering.
Product managers: from prose to precision
The PM’s job has always been to translate intent into something a team can build. In an AI-augmented world, that translation needs to go one level further — into something an agent can consume directly.
This requires learning to write specifications in structured formats — EARS notation, Given/When/Then acceptance criteria, DORA-aligned story decomposition — that AI agents can validate against during construction. It means developing a feel for which ambiguities will cause the agent to hallucinate a direction versus pause for clarification. It means learning to use tools like Kiro to turn high-level intent into a steering file before engineering begins.
The PM who makes this shift does not just write better requirements. She reduces rework at the point where it is most expensive: after the code is written and the PR is large.
QA engineers: from test writers to quality architects
Before AI, the QA engineer’s leverage was in writing thorough tests. After AI, writing tests is something the agent does. The QA engineer’s leverage shifts to two different places: specifying what to test before construction begins, and reviewing and directing AI-generated test suites at scale.
Quality gates move forward. The QA engineer co-authors acceptance criteria during spec review, not after code review. She defines edge cases, failure modes, and coverage targets as part of the steering context. Reviewing a test suite produced by an agent at scale requires different techniques — knowing where agents over-generate (happy-path coverage) and where they reliably miss (error states, boundary conditions, integration points).
Designers: from deliverables to constraints
Designers face a particular version of this challenge. Generative UI tools are powerful and fast. They are also entirely unaware of your design system, accessibility requirements, brand constraints, or the reasoning behind every component decision your team has spent years encoding. Without structured enablement, designers go one of two ways: they avoid the tools entirely, or they use them personally and unsanctioned — producing output that engineering then has to reconcile with the design system. The DX 2025 Impact Report found shadow AI to be near-universal. The shift required is from designing deliverables to designing constraints. A design system that is machine-readable becomes an active participant in the generation process, not a guide someone ignores.
Security engineers: from gatekeepers to co-authors
The first article made the point plainly: a clear AI policy eliminates ambiguity. Shadow AI — engineers using personal tools because no approved option exists, or the approved tool is worse — is now ubiquitous. It is also a security problem that scales with code velocity. The security engineer’s role in an AI-augmented organization is to move earlier and become embedded. This means learning to author security policies as machine-readable steering files that travel with the agent’s context through construction. It means understanding where AI-generated code creates supply chain exposure, and designing the review process for AI’s patterns of error rather than a human’s. Security teams that make this shift transform from a gate into a design function.
SRE and platform teams: from operators to throughput architects
The platform is the constraint nobody talks about in AI enablement conversations. CircleCI’s analysis of AI-driven development found that static CI pipelines cannot keep pace with the volume AI generates. If your pipeline takes 45 minutes to run and your engineers are now producing three times the commits per day, you have a new bottleneck that will eventually show up as an incident. SRE teams need to be enabled to think about platform capacity in terms of AI throughput — understanding where pipeline bottlenecks will form, how to design test parallelization and caching for AI-augmented volume, and how to evaluate infrastructure implications of agent-driven deployments before the velocity increase makes those implications visible in production.
What funded enablement actually looks like
There is a version of this that costs almost nothing and delivers almost nothing. A Slack channel. A PDF. An invitation to use the same developer-facing tool with no role-specific guidance. A lunch-and-learn. And there is a version that takes the organization transformation seriously.
Diagram 4. Cross-role enablement: what usually happens versus what actually works. The most revealing metric — lead time at handoffs between roles — is rarely measured in either scenario.
Funded enablement looks like a structured curriculum with role-specific learning paths — not generic AI literacy, but PM-specific, QA-specific, security-specific skill development with clear outcomes. It looks like practice rituals that change how the team actually works together. And it looks like measurement: not whether people attended the training, but whether lead time for changes moved, and where the variability came from.
DORA’s findings point in the same direction. The organizations that saw AI gains reach the bottom line did not simply have better tools. They had the product and delivery capabilities — user-centric focus, working in small batches — that let AI’s output actually move through the system. Those capabilities are not engineering capabilities. They belong to the roles this article is about.
A practical sequence for leaders
01 — Map who touches every feature, not just who builds it. List the roles that a user story moves through from idea to production. For most organizations, this is eight to twelve functions. Note which ones have a structured AI enablement path. For most organizations, the answer is one.
02 — Prioritize the bottleneck. Where is work queuing right now? If QA is the constraint, enable QA first. If spec ambiguity is generating the most rework, enable PMs first. The transformation budget should follow the bottleneck, not the organizational chart.
03 — Fund it at the same level you fund developer licensing. The seat-license cost is procurement. The enablement cost is learning and development. Most organizations separate them. The ones seeing system-level gains treat them as a single investment with a single return.
04 — Build practice into the ritual, not just the curriculum. Training that is not reinforced by changed working practices decays within weeks. The rituals — Mob Elaboration, specification review, forward quality gates — are where the learning becomes durable.
05 — Measure what changes at the seam. The most revealing metric is not within a role — it is between roles. How long does a feature sit between PM sign-off and engineering picking it up? How long between code complete and QA sign-off? Lead time lives at the handoffs. So does the value of cross-role enablement.
The circle is the system
The first article in this series, The Bottleneck Just Moved, ended with a line worth restating: the limit on what your organization can deliver with AI is no longer set by the tool. It is set by the system the tool lands in. That system is every role that a feature touches. The PM who writes the first brief. The designer who shapes the experience. The QA engineer who validates the behavior. The security engineer who authors the constraints.
The SRE who scales the platform. The developer who orchestrates it all. Enabling the developer without enabling the room is faster typing in the same bottleneck.
Widen the circle. The productivity gains everyone has been promised are on the other side of it.
What is your organization’s enablement ratio — for every dollar spent enabling developers with AI, how much reaches the other roles in the delivery chain? I would be genuinely interested to hear where teams are landing on this. Contact us to start the conversation.
Sources
Ascendient Learning Offers Live AI and Agentic AI Training
Browse Courses
Cloud Computing is a cornerstone topic in the IT industry with big players like Amazon, Microsoft, Google, and others providing cloud services offerings. These are the top 30 cloud computing terms you should be familiar with if you want to pursue a career in the cloud.
Cloud security should be at the forefront of every IT decision you make. Learn how to achieve this in our blog.
With emerging technologies and evolving customer expectations, the future of banking is set to change. Learn about the future and trends of cloud banking here.
Ascendient Learning is the coming together of three highly respected brands; Accelebrate, ExitCertified, and Web Age Solutions - renowned for their training expertise - to form one company committed to providing excellence in outcomes-based technical training.
With our winning team, we provide a full suite of customizable training to help organizations and teams upskill, reskill, and meet the growing demand for technical development because we believe that when talent meets drive, individuals rise, and businesses thrive.
