The DRI Problem: Why Most Claude Code Rollouts Plateau

Here's a question I've asked at every enterprise engineering org I've worked with over the last six months: who owns your Claude Code configuration?

The most common answer is: "Uh, a few of us play with it." A handful of names. A Slack channel. No one with the authority to make a decision and have it stick.

That answer is the entire problem. And Anthropic's Applied AI team just named it, in the most operationally specific language I've seen them use:

"The minimum viable version is a DRI: one person with ownership over the Claude Code configuration, the authority to make calls on settings, permissions policy, the plugin marketplace, and CLAUDE.md conventions, and the responsibility to keep them current."

DRI — directly responsible individual. The Apple term for "who do I go to when this breaks." It's a load-bearing word in that sentence because of what's missing in most orgs: not enthusiasm, not budget, but a name on the wall.

The Two Adoption Patterns That Actually Work

The Applied AI team describes two configurations that drove fast rollouts:

"At one company, a couple of engineers built a suite of plugins and MCPs that were available on day one. At another, an entire team focused on managing AI coding tools had the infrastructure in place before the rollout began."

Notice what's identical between the two: infrastructure existed before broad access.

The team can be one person or a department, but the timing is the same — somebody wired up the harness, package, and conventions before developers got their hands on it. The Applied AI team's framing of this is sharp:

"In both cases, developers' first experience was productive rather than frustrating, and adoption spread from there."

The implicit alternative — the rollout pattern where developers got Claude Code first and the configuration came later — produces the opposite curve. First experience: friction. First impression: "this thing doesn't know our codebase." Sticky impression: "this thing is for greenfield work, not our codebase." That impression is what kills adoption around 30%, because it leaves the harder half of the team unconvinced.

What "Bottoms-Up" Actually Buys And Doesn't

Bottoms-up adoption — engineers discover Claude Code, start using it, evangelize internally — is excellent at one thing: generating enthusiasm. It's terrible at one thing: generating consistency.

The Applied AI team is direct about the failure mode:

"Bottoms-up adoption generates enthusiasm but can fragment without someone to centralize what works."

What "fragment" looks like in practice:

• Three different teams write three different CLAUDE.md conventions for the same monorepo.
• Two engineers each build an internal-analytics MCP, slightly differently, both half-finished.
• A great deploy skill on the payments team never reaches the platform team because no one packaged it.
• New hires get random advice from random teammates about how to set Claude Code up.

None of these are tragic on their own. Together, they are why adoption plateaus. The team has reinvented the wheel four times. Each version is 60% as good as it could be. Nobody is responsible for making any of them 100%.

The DRI exists to make that responsibility legible. That person assembles, that person evangelizes, that person deprecates the dead stuff.

The Emerging Role: Agent Manager

The Applied AI piece names something new:

"Agent manager — a hybrid PM/engineer function dedicated to managing the Claude Code ecosystem."

This is the first time I've seen this title in print at Anthropic. It's worth taking seriously.

The role is hybrid because the work is hybrid:

• PM-shaped work: deciding which skills go in the official marketplace, sequencing the rollout, defining the governance for who can publish what, handling cross-functional alignment with security and legal.
• Engineering-shaped work: writing the org-wide CLAUDE.md hierarchy, packaging skills into plugins, building the MCP servers that connect Claude to internal tools, instrumenting the rollout to know what's working.

In organizations that have made Claude Code work at scale, this role exists explicitly. In organizations that haven't, the work is happening implicitly — usually by an exhausted staff engineer who's doing it on top of their day job.

Some predictions about the next 12 months:

1. "Agent Manager" will become a published job title at companies with >500 engineers. We're already seeing it in early job postings under labels like "Developer AI Lead" and "AI Tooling Engineer."
2. The role will report into Developer Experience or Platform Engineering, per the Applied AI team's explicit recommendation: "typically the function responsible for onboarding new engineers and building developer tooling."
3. Smaller orgs will run a part-time DRI instead of a dedicated role — but the DRI's existence is the load-bearing variable, not the headcount budget.

The Governance Question

The Applied AI piece raises three questions specifically for regulated industries:

"Who controls which skills and plugins are available, how do you prevent thousands of engineers from independently rebuilding the same thing, how do you make sure AI-generated code goes through the same review process as human-generated code?"

These are not abstract concerns. Each one has a wrong answer that creates real damage:

• No control over skills/plugins → security incidents. Random skills that exfiltrate code to third-party services are a real category of risk. Without a curated marketplace, you can't tell which skills are safe.
• No prevention of duplicated work → wasted engineering hours. Three teams independently building the same MCP isn't speculative; it's the modal failure I see.
• No review process for AI-generated code → quality regressions. Code review exists for a reason. AI-generated code is not exempt.

The Applied AI team's recommended approach is conservative and clearly tested:

"Start with a defined set of approved skills, required code review processes, and limited initial access, and expand as confidence builds."

That's the answer for highly regulated industries (finance, healthcare, defense). For less regulated ones, you can move faster, but the shape of the governance is the same: someone owns the rollout, someone owns the curated set, someone owns the review process.

The DRI is the entity those sentences point at.

Cross-Functional Working Groups

There's one more pattern in the article that's worth surfacing:

"We've observed the smoothest deployments at organizations that establish cross-functional working groups early by bringing together engineering, information security, and governance representatives to define requirements together and build a rollout roadmap."

The pattern here: pull the people who will eventually object into the room before there's a reason to object. Security finds out about Claude Code rollouts late more often than they find out early. By the time they find out late, there's already a half-finished MCP that exfiltrates code to an external API, and the conversation is adversarial. By the time they find out early, they're co-authors of the rollout plan, and the conversation is collaborative.

This is unglamorous PM work. It's also the work that makes the difference between a fast rollout and a stalled one.

The Single Question To Answer

If your organization is rolling out Claude Code and you take one thing from this post:

Who is your DRI?

If the answer is "nobody, but everyone," that's the same answer as nobody. Pick a person. Give them authority over settings, the plugin marketplace, the CLAUDE.md hierarchy, and the conventions. Make it 30% of their job. Watch what changes.

Bottoms-up gets you to 30%. The DRI gets you to 80%.

---

Part of the Claude Code at Scale series. Previous: LSP — the highest-ROI investment most teams skip. Series start: The harness, not the model.