▸ Adoption · Power Shift

Who loses power when Intent is adopted

Hiding the losers from the pitch guarantees resistance you never see coming, because the resistance forms in rooms you're not in. Intent changes who holds power on a team. Some roles gain. Some lose. Some will actively resist adoption and have legitimate reasons to do so. Here is the honest map.

▸ Gains power

  • Solo ICs with high spec clarity (can now command agent execution end-to-end)
  • Architects — the Practitioner-Architect is Intent's canonical persona
  • AI-fluent senior engineers
  • "The operator" who reviews specs at the spec-shaping protocol layer
  • PMs who can write verifiable acceptance criteria
  • Craftspeople whose domain knowledge is hard to compile

◆ Loses power

  • Scrum Masters, RTEs, Delivery Coaches (the ceremony stack is obsolete)
  • PMs whose value was running prioritization committees
  • Junior engineers whose role was "do the tickets" — the productive struggle disappears
  • Anyone whose identity was "good at running Jira"
  • Managers whose span of control was headcount-driven
  • Large-team coordinators (Intent is 2–7 person teams only)

○ Will actively resist

  • PMOs — roll-up reports depend on ticket hierarchies Intent doesn't produce
  • Finance / Capacity planning — story points were how headcount was allocated
  • Auditors / Compliance — git-as-source-of-truth is alien to SOX/ITIL frameworks
  • Middle management translating strategy to tickets
  • External stakeholders who relied on velocity reports for status

▸ Before you continue

If you are adopting Intent in an organization that has any of the "actively resist" roles — and most orgs over 50 people do — you have a political problem, not a methodological one. Intent's technical merits do not survive contact with a PMO that needs weekly velocity rollups. Either the PMO gets translated-for (which is expensive and ongoing) or the PMO learns a new language (which is a change program, not a tool adoption).

Naming this upfront is not pessimism. It is honesty. If you try to adopt Intent without addressing the resistance, you will fail in month 3 and the failure will look like "the methodology didn't work" when the actual failure was unaddressed political gravity.

The role deep-dives

For the roles most affected, here is what the transition actually looks like — what's lost, what's gained, and what the role becomes. Intent does not make these humans less valuable. It changes what their value is.

The Scrum Master / Delivery Coach

Loses: ceremony orchestration craft · Gains: psychological safety facilitation craft

The craft of running standups, retros, and planning disappears with the ceremonies themselves. That's real. But the deeper craft — facilitating a team learning conversation, holding space for disagreement, noticing the silence before it becomes disengagement — is more valuable in Intent, not less. Intent's psychological safety contract (Promises 1, 2, 5, 6) depends on someone holding the meta-view of team dynamics.

Becomes: The Safety Facilitator. Runs the weekly Transition Check during the neutral zone, the Psychological Safety Check-in throughout adoption, and the Intelligent Failure Celebrations. The ceremony is gone; the facilitation discipline is load-bearing.

The Junior Engineer

Loses: the productive struggle of implementing well-defined work · Gains: exposure to spec-shaping earlier in their career

This is the transition Intent is most honest about being unsolved. Junior engineers traditionally developed craft by implementing tickets — the productive struggle of turning a story into working code is how judgment develops. When agents do that work, juniors lose the scaffold. We haven't fully figured out what replaces it. Current best answer: structured apprenticeship in spec-shaping, where a junior pairs with a senior on the four-persona protocol and learns by watching specs come together.

Becomes: The Spec Apprentice. Shadows senior engineers through spec-shaping sessions, reviews contracts for testability, learns to see the spec before learning to write the code. This is a worse onramp than the old one in some ways. It is an honest gap.

The Traditional PM

Loses: prioritization committee authority · Gains: spec clarity craft, measurable outcome ownership

PMs whose daily work was running prioritization meetings, writing tickets, and facilitating between stakeholders lose most of that work. PMs whose daily work was customer discovery, outcome definition, and spec clarity gain leverage. The shift is from managing the coordination layer to managing the clarity layer. Torres-trained PMs already operate this way; Jira-trained PMs don't.

Becomes: The Outcome Owner. Continuous discovery remains their craft. Spec-shaping becomes their primary deliverable. They stop managing tickets and start managing clarity. Not a new role — a recovery of what PMs were supposed to do before tickets ate the job.

The PMO Analyst

Loses: Jira-based reporting and rollup · Gains: nothing automatic

PMOs translate engineering work into stakeholder-legible reports. Intent's event streams don't roll up into the formats stakeholders expect. This is a hard break, not a soft one. The PMO can either learn a new reporting language (which is months of work and their stakeholders don't understand the new format) or push back on Intent adoption (which is often the right call for the organization). We are not pretending this is a win-win. It isn't.

Becomes: Either a translator (between Intent events and stakeholder reports, which is ongoing cost) or a blocker. Intent does not have a good answer for PMO-heavy organizations. If that's your context, see when NOT to adopt Intent.

The Large-Team Manager (8+ direct reports)

Loses: the entire team size bracket · Gains: nothing from Intent (needs a different methodology)

Intent is explicitly for teams of 2–7. Over 7 is out of scope. If your career identity is built around successfully managing 20-person teams, Intent says that team shape is a symptom of the wrong operating model — not because you're bad at it, but because AI shifts the economics so that large teams become harder to justify for engineering work. Your craft is real. Intent is not for it. That is honest, not dismissive.

Becomes: Nothing within Intent. Intent is not a large-team methodology and pretending it is would be dishonest. Large-team management craft remains valuable in many contexts — customer success, operations, support — but not in AI-native engineering delivery. This is a real narrowing that we are naming upfront.

What to do with this page

Before you adopt Intent, share this page with everyone who will be affected. Let them read it. Then have a hard conversation about who in your specific org will lose and who will gain. Identify which "actively resist" roles you need to work with, not against. Build your Kotter Step 2 guiding coalition around the honest reality, not the optimistic pitch.

If reading this page makes you realize Intent isn't right for your org, good. That is a valid outcome of honesty. We'd rather lose you here than six weeks into a failing pilot.

← Previous: Neutral Zone playbook Next: When NOT to adopt Intent →