Sponsoring AI Adoption (the Right Way)

In this module

Why sponsorship matters more than tool choice
The DRI principle — one accountable owner, not a committee
What to fund — and what to refuse to fund
The org structure question — where does the agent manager live?
Avoiding the Two-Year Curse — pruning the harness configuration
Common sponsorship failure modes
A sponsorship checklist

Why sponsorship matters more than tool choice

Most failed AI adoption efforts in 2024-2026 didn't fail because the tool was wrong. They failed because the sponsorship was wrong.

The pattern: an executive approves a budget for "AI tools." Engineering picks tools. Product picks tools. Sales picks tools. The tools work in isolation. The tools don't work together. Nobody owns the integration. The integration debt grows. Six months later the executive asks "where's the value?" and engineering points to product, product points to engineering, and the actual answer is "no one was responsible for closing the loop, so the loop is still open."

This is not a tool problem. It's a sponsorship problem. The closed-loop pattern requires someone who owns the loop. Not a committee, not "everyone's responsibility" — one person whose job description has the word "loop" in it.

Anthropic's guidance for adopting their tooling — relevant beyond their specific products — names this directly: assign a DRI (directly responsible individual) who owns the AI tooling ecosystem. The DRI is a hybrid PM/engineering role, sometimes called an "agent manager," and they own:

The harness configuration (which tools, in what configuration, with what guardrails)
The skill library (what's documented, what's tested, what's getting deprecated)
The audit hygiene (lifecycle events are wired, gates are configured correctly)
The agent dispatch quality (which work goes to which model tier, which specialist)
The cross-team coaching (training PMs to author good Briefs, training engineers to read agent output critically)

Without a DRI, the harness drifts. CLAUDE.md stops being maintained. Skills get out of date. Lifecycle events fail silently. The closed loop opens back up and nobody notices because everyone's focused on their own surface.

A vocabulary note: Builders and the DRI

The "Builder" vocabulary is now broadly used — Product School's AI Product Builder programs and Meta's "everyone is a Builder" framing both treat Builder as the universal role for anyone shipping through structured interfaces (Briefs, specs, prompts). In a closed-loop org, every role becomes a Builder: the PM files Briefs, the marketer files Briefs, the AE files customer-signal Briefs, the engineer ships code-execution Briefs.

The DRI (or Loop Master, in the PM track's terminology) is a Builder who specializes in orchestration. Same shape as "the Tech Lead is an engineer who also leads the team." The specialization sits on top of the shared Builder foundation, doesn't replace it. This matters for your hiring conversation: you are not hiring a generic platform admin; you are hiring a Builder whose specialty is harness health.

Treating the DRI as a Builder-with-specialization (rather than a separate service role) protects against two failure modes: (a) the role getting mis-cast as "the AI babysitter" or "platform support," and (b) the role being seen as a service to other Builders rather than a peer with focused responsibilities.

The DRI principle

The DRI is one person. Not "one person from each team." Not "a steering committee that meets monthly." One person with a calendar that has time for the work.

This is unusual in large orgs. The instinct in most orgs is to spread responsibility — it feels more inclusive, it surfaces more perspectives. For load-bearing operational systems, distributed ownership is usually a failure mode. The harness ecosystem is load-bearing in the sense that quiet degradation produces silent strategic costs.

A good DRI profile:

5-10 years of engineering or product experience — needs to be technical enough to debug a misconfigured skill, strategic enough to know which Briefs need Opus vs. Haiku
High operational discipline — runbooks, audit trails, incident response patterns; not a person who lives in slides
Strong systems thinking — the harness is a system, not a stack of tools; the DRI sees it as one
Coaching disposition — partly about humans, even if smaller share than a Scrum Master
Healthy AI skepticism — knows when the harness is lying, what to test, what to trust

Common DRI sources:

A senior Scrum Master or Engineering Operations lead who wants to grow into the role
A senior PgM with operational depth
A staff engineer with platform-team experience
Less commonly but possibly: a senior PM with operational discipline (rare; most PMs are wired for customer/strategy, not operations)

The PM track's Module 4 covers the "Loop Master" role evolution in depth. The DRI role at an executive level is the same role, named for the sponsorship context.

What to fund

The investment is concrete:

Fund: a dedicated DRI (1.0 FTE)

Not 0.5 FTE. Not "someone's stretch project." A full role with a manager who owns its performance and a budget line that survives quarterly reprioritization.

If the org is small enough that 1.0 FTE feels heavy, the right answer is usually "the org is too small to need this yet — revisit at next headcount checkpoint." Closing the loop is a multi-year investment; starting it without a DRI is starting it badly.

Fund: harness ecosystem investments

The harness ecosystem — CLAUDE.md, skills, hooks, plugins, MCP servers, subagents — compounds. The investment in writing a good skill returns value every time that skill is used, by anyone in the org. Funding includes:

Engineering time to write and maintain skills (10-20% of the DRI's time + occasional contributions from specialist engineers)
Tooling licenses (Claude API, specialized MCP integrations)
Documentation maintenance (CLAUDE.md hygiene is a real ongoing cost)
Periodic external audit (every 9-12 months, an outside review of the harness configuration)

Fund: integration work

Closed-loop platforms connect to your existing stack — Jira, Linear, GitHub, your data warehouse, your observability stack. Integration is real work and a real failure mode if underfunded. Budget 2-3 engineer-months of dedicated time per major integration, more if your stack is unusual.

Fund: change management

The cultural shift from "ship faster" to "ship more learning per shipped unit" is significant. PMs need to learn Brief authoring. Engineers need to learn agent-friendly architectures. Leadership needs to learn to read OARs. Budget for training, coaching, and the time it takes to develop new habits.

What to refuse to fund

Three things sponsorship gets wrong:

Don't fund vague "AI strategy" consulting

The market is saturated with AI strategy consultants who will produce a slide deck. The strategy is mostly knowable from the research foundation (DORA, McKinsey, Anthropic harness) plus your own organizational context. The expensive work is the execution — which is what the DRI does. If you find yourself spending more on AI strategy consulting than on the DRI's salary, the budget is upside-down.

Don't fund "AI feature racing"

"We need an AI feature in product to compete" is a different conversation from "we need to close the loop on our development process." Conflating them is expensive — the AI features go to the product team, the loop investment goes to internal tooling, and they don't share a roadmap. Sponsor them as separate initiatives with separate budgets and separate success metrics.

Don't fund "AI for everyone" rollouts before the harness is ready

Rolling AI tools out to every PM and engineer simultaneously, before the harness is configured, is a structural recipe for the DORA Vacuum Hypothesis to play out at scale. The 7.2% delivery stability reduction DORA observed comes from this pattern. Start with the harness, then roll out. The DRI manages the rollout cadence.

The org structure question

Where does the DRI live? Three legitimate options:

Option	When it works	When it fails
In engineering (reports to VP Eng)	When the dominant failure mode is harness-config and agent dispatch; eng leadership has bandwidth	When product becomes a second-class citizen — Briefs reflect eng concerns, not strategic objectives
In product (reports to VP Product)	When the dominant failure mode is spec quality and outcome attribution; product leadership has technical depth	When eng resists the patterns because they came from "product's tool"
Shared (reports to whoever owns engineering velocity)	When the org is mature enough to have a "platform" or "developer experience" function with cross-cutting authority	When "shared ownership" means nobody owns it

Recommendation: shared, reporting to whoever owns engineering velocity — usually a VP Engineering or CTO. The "shared" framing means both product and engineering have a stake; the reporting line gives the DRI authority to enforce harness standards across teams.

The wrong answer is "let teams pick their own approach." The whole point of the harness is shared standards.

Avoiding the Two-Year Curse

AI tooling configurations age fast. A CLAUDE.md written for 2024-era Claude models can constrain 2026-era model capabilities. A skill set tuned for the previous Anthropic harness pattern can be a drag on the new one.

The Two-Year Curse: configurations that worked 18 months ago silently degrade as the underlying models and patterns evolve. The harness gets less effective; nobody notices because the failure is gradual.

The cure is built into sponsorship: every 3-6 months, the DRI prunes the harness configuration. Specifically:

Review CLAUDE.md sections — what's still load-bearing? What can be deleted? What was specific to a tool version we no longer use?
Audit skills — which are getting invoked? Which are stale? Which need updates for new model capabilities?
Inspect lifecycle event hooks — do they still fire correctly? Are downstream consumers still listening?
Re-evaluate MCP server inventory — are all installed servers still useful? Are there new ones worth adding?

This is a 1-2 day exercise quarterly. Budget for it. The cost of skipping it is significantly larger than the cost of doing it.

Anthropic's harness guidance covers the principle: harnesses are living configurations, not one-time setups. The investment level for the harness ecosystem is "ongoing operational discipline," not "one-time tool acquisition."

Common sponsorship failure modes

The Steering Committee: "We'll have a cross-functional AI committee meet monthly." → nobody is accountable; the harness drifts.
The Stretch Assignment: "I'll have my best PM run this on the side." → the DRI work needs full attention; treating it as side work guarantees mediocrity.
The Pilot Trap: "Let's run a 90-day pilot, then decide." → 90 days is too short to converge AR(1) priors or build a Brief authoring habit. Budget 6-12 months minimum; check at 12 months.
The Vendor Captive: "Pick a tool and trust the vendor." → vendors optimize for their own roadmap. The harness needs to fit your org. The DRI's job includes choosing what to adopt and what to defer.
The Headcount Reduction Pitch: "AI lets us cut PM headcount." → this signals to the team that the platform exists to replace them. Trust collapses; adoption stalls. The honest framing is "same headcount, more outcomes per headcount."

A sponsorship checklist

Before approving the budget, confirm:

Named DRI, full-time, with a clear job description and a manager who owns their performance
Reporting line specified (engineering / product / shared)
Budget for harness work (skills, hooks, plugins) for the next 12 months
Integration plan for the major existing tools (Jira, GitHub, etc.)
Quarterly pruning cadence on the calendar
Success metrics defined and trackable (outcome attribution rate, forecast accuracy, drift detection latency — not throughput)
Adoption cadence that doesn't outpace the harness — DRI controls who onboards when
External audit checkpoint at 12 months — outside review of the harness configuration

If any of these are missing, the sponsorship will fail in a knowable way. The platform is not the problem.

PM33 ships harness skills that operationalize most of the above:

harness-prep, harness-planner, harness-coordinator — the skill chain a DRI uses for new major initiatives
gauntlet-review — the multi-specialist review pattern that catches problems before merge
The audit log — the visibility surface that lets a DRI see harness health without interrogating each team

These are tools for the DRI, not replacements for the DRI. A sponsoring executive should still expect to fund a full-time owner. The skills make the owner's job tractable; they don't eliminate the role.