Scaling AI adoption in engineering beyond one team

Stefan-Iulian Tesoi · 26 October 2026 · 6 min read

Copy the conditions that made the first team work, not its configuration. The pilot team usually had an audited backlog, a reviewer with time and someone who owned the result. The second team inherits the agent settings and none of those, which is why second rollouts underperform pilots even when the tooling is identical.

Scaling AI adoption is therefore mostly a question of which of those conditions can be transferred, and how fast.

Why does the second team underperform the pilot?

Because the pilot team was selected and the second team was assigned. Pilot teams are chosen for a lead who volunteered, a clean repository and a backlog someone had already tidied. They get attention for a month. The second team gets a rollout announcement and a copy of the pilot's configuration.

Nothing in that table is a tool setting. Second team AI adoption fails on those rows, and the post-mortem blames the agent, because the agent is the only thing that visibly changed.

There is a timing effect on top. A pilot's first month spends a backlog written over the previous year, and adoption stalls after the first month when that stock runs out. If the second team starts during the pilot's good month, the decision to expand rests on a number that was about to fall.

Conditions, not configuration

The pilot's real output is a list of conditions, and the configuration is the least valuable part of it. A CLAUDE.md file, a set of MCP servers and a permission policy can be copied in an afternoon. The conditions that produced the pilot's result cannot:

• A measured backlog. A count of how many items an agent could execute from the text alone, taken before the agents arrived.
• A named owner who answers "is this item ready" and can say no.
• Review capacity, in hours per week, protected from the rest of the sprint.
• A test suite that runs green, so the evidence an agent hands back means something.
• A baseline, such as the two numbers the first two weeks of an agent pilot should count.

DORA's research points the same way. Its AI Capabilities Model, published in September 2025, names seven capabilities that amplify the benefits of AI: a clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, a user-centric focus and quality internal platforms. At most one of the seven is something a tool installs. DORA also reports that without a user-centric focus, AI adoption can hurt team performance:

"When users aren't the focus, AI-assisted development teams may just be moving quickly in the wrong direction."

What should be shared across teams, and what stays local?

Share the guardrails and the measurement; keep the rules and the backlog local. The split follows who has the knowledge.

Shared, usually owned by a platform team: the approved coding agents and MCP servers, permission defaults, how credentials are issued, audit logging, a starter rules template, and the method for counting backlog readiness. These need to be consistent, and a security review only has to happen once.

Local, owned by each team: the project rules for its repositories, its backlog and its owner, its acceptance-criteria conventions, its review rotation and its pace. A payments service and a marketing site need different instructions, and a single rules file trying to cover both is generic for each.

A shared backlog across teams is the one thing worth resisting. One queue for several teams' agents hides who owns readiness, and the item nobody owns is the one an agent executes badly.

Laimonade keeps this split by design. Each project holds its own rule files, the CLAUDE.md, AGENTS.md and .cursor/rules its team wrote, and any agent connected to that project reads them through one tool. Connections are granted per project, so the second team's agents see the second team's backlog and nothing else. The team's conventions travel with its backlog rather than with whoever configured a laptop.

Scaling AI adoption one team at a time

Add one team at a time, and start the next only when the previous one is past its first month. An organisation with eight teams adding one a month is done in eight months with eight readable results. Adding four at once is done in one month with four results nobody can compare, because nothing was held constant.

For each new team, the sequence that held up in the pilot still applies, with one step added:

1. Audit twenty items from the top of its backlog and count how many an agent could execute.
2. Name the backlog owner and the reviewer, and agree the review hours.
3. Borrow a pilot engineer for two weeks, sitting in planning and review.
4. Measure the same two numbers the pilot measured, from the same starting point.
5. Expand only when month two holds, not when month one looks good.

An AI rollout across teams at that pace looks slow on a roadmap. It is faster than an enterprise AI coding rollout that has to be restarted after a quarter because four teams stalled at once and nobody could say why. The single-team plan behind each step is in the coding agent rollout plan for one team, and the leadership view is on the page for engineering leaders.

Which signs say a team is not ready yet?

Five, and each is cheaper to fix before the agents arrive than after:

• Fewer than a third of sampled items pass the readiness check.
• Nobody can name the backlog owner without a pause.
• The test suite is red, or takes longer than half an hour.
• Review is already the bottleneck, with pull requests waiting days for a first look.
• The team was told rather than asked, and treats the rollout as someone else's project.

A team showing two or more of these is a team whose first month will be spent discovering them. Fixing them first is the rollout.

Frequently asked questions

Should a central platform team own the agent setup?

It should own the guardrails, not the work. A platform team is the right home for approved tools, credentials, permission defaults and audit logs, because those must be consistent across teams. It is the wrong home for backlog readiness and project rules, which depend on knowledge only the product team has. A platform team that writes every team's rules file produces generic files nobody updates.

Can the pilot team coach the next one?

Yes, for a bounded time, and it is the cheapest transfer of tacit knowledge available. One pilot engineer joining the next team's planning and review for two weeks carries habits a document misses: how small an item should be, and what a checkable criterion looks like. Much longer than that and the pilot team's own throughput drops.

Do shared project rules help or get in the way?

A shared base helps; a single shared file gets in the way. Rules on commits, secrets and testing belong in a template every team starts from. Rules for a specific repository belong in that team's own file, because a long file covering every service is mostly noise for each of them, and nobody owns keeping it current.