The roadmap told you what to do this quarter. This lesson is about the document that actually makes one quarter's initiative succeed - and about the single most common way AI initiatives fail on design teams, which is not a tooling problem but a people problem. You can pick the right initiative, write a flawless brief, and still split your team into two speeds: a handful of early adopters who race ahead and a frustrated majority who feel left behind, never catch up, and quietly conclude that AI is for other people. This lesson teaches you to write a quarterly initiative doc that has the four things every initiative needs - a brief, a success metric, a rollback plan, and adoption-curve sequencing - using a real example: rolling out design-system tokens plus a Storybook MCP server so AI tools can read your components. The adoption-curve appendix is the part that separates a strategist from someone who just announces tools, because it plans for the fact that your team adopts at three different speeds and designs the rollout so all three arrive, rather than only the fast.

The Anatomy of an Initiative Doc

A quarterly AI initiative is a bounded, fundable, measurable unit of change, and it needs exactly four components to be one rather than a vibe. Skip any of the four and the initiative fails in a predictable way. The brief says what you are doing and why, scoped to one quarter. The success metric says how you will know it worked, denominated honestly. The rollback plan says what you do if it does not, which is the component that makes the initiative safe to attempt. And the adoption-curve sequencing says how the actual humans on your team move from not-doing-this to doing-this, which is the component that determines whether the other three matter at all.

The reason to insist on all four is that initiatives fail differently depending on which one is missing. An initiative with no clear brief sprawls and never finishes. An initiative with no success metric cannot be defended or learned from - it just happened, and nobody can say whether it helped. An initiative with no rollback plan is a bet you cannot walk back, which means it should never have passed the reversibility test in the first place. And an initiative with no adoption-curve sequencing produces the two-speed team, which is the failure this lesson exists to prevent and the one strategists most reliably cause by accident.

The Running Example: Tokens Plus a Storybook MCP Server

Make it concrete with a real Q3 initiative, the kind the use-case matrix would surface as a prerequisite-cluster foundation: making the design system AI-readable by establishing a tokenized component layer and wiring a Storybook MCP server so that AI tools (a Lovable prompt, a v0 generation, an agent reading the system) consume real components and real tokens instead of hallucinating their own. This is a genuinely high-leverage initiative because it unblocks a whole cluster of downstream AI use cases, but it is also exactly the kind of initiative that produces a two-speed team, because the work is technical and the early adopters who love it will sprint while everyone else watches.

The brief. "This quarter we make our component library AI-readable: tokens published in a structured format, five core components documented in Storybook MDX so an MCP-enabled agent can read their intended use and props, and a working Storybook MCP connection demonstrated by a generation that uses real components. We are doing this because it is the prerequisite that stops every downstream AI generation from drifting off-system." One paragraph, scoped, with the why tied to the roadmap's prerequisite logic.

The success metric. Not "the team adopts MCP," which is unmeasurable, but something observable and honest: "By quarter end, a generation run through the MCP connection uses real system components with zero hallucinated props, and three ICs beyond the pilot have run it themselves." The metric has a quality dimension (zero hallucinated props) and an adoption dimension (three ICs beyond the pilot), because an initiative that works technically but only one person can run has not actually succeeded - it has created a single point of failure dressed as a win.

The Rollback Plan: The Component That Makes It Safe

The rollback plan is the component strategists most often skip, usually because it feels like planning to fail. It is the opposite: a rollback plan is what lets you attempt an initiative aggressively precisely because you know how to walk it back. For the tokens-plus-MCP example, the rollback is concrete: the token layer and MDX docs are additive and harmless even if the MCP connection is abandoned, so the genuine rollback question is narrower - if the MCP-driven generation proves unreliable, you revert to the human-rebuilt-from-tokens workflow you already had, losing only the time spent, with the token layer remaining as a permanent gain. Naming that explicitly does two things: it confirms the initiative is reversible (which is why the matrix sequenced it early), and it tells the team that trying it is safe, which lowers the adoption resistance the whole rest of the doc has to manage.

A good rollback plan also names the trigger - the observable condition under which you would actually pull back - so the decision is made in advance rather than in the heat of a bad week. "If by mid-quarter the generation still hallucinates props after the MDX docs are complete, we pause the MCP push, keep the token and doc gains, and re-scope." A trigger stated in advance is what prevents the two equal failures of abandoning an initiative at the first frustration and stubbornly pushing a failing one past the point of evidence. The rollback plan is the initiative's reversibility made operational.

Adoption-Curve Sequencing: The Part That Prevents the Two-Speed Team

Here is the heart of the lesson. Any change rolled out to a team meets three populations, and they are not a judgment of who is good - they are a fact about how humans adopt anything. The early adopters want the new thing and will run at it. The mid-pack will adopt it if it is made easy and the value is shown, but will not seek it out. The late adopters are skeptical, busy, attached to what works, or quietly anxious, and will adopt only with accommodation and time. The catastrophic mistake - the one that produces the two-speed team - is to roll an initiative out uniformly, which in practice means rolling it out to the early adopters, because they are the only ones who self-serve from an announcement. Three months later the early adopters are fluent, the rest are exactly where they started, and the gap has hardened into a culture: AI is for those people, not us.

Adoption-curve sequencing designs a different path for each population, on purpose, in the initiative doc. It is the appendix that turns a tool announcement into a change-management plan.

Early Adopters: The Pilot

The early adopters lead the pilot, but their job is not just to use the thing - it is to make it usable for everyone behind them. Name one or two ICs who are excited about the MCP work and give them the pilot, with an explicit deliverable that is not "use it" but "use it and produce the path the next group will follow": the setup doc, the worked example, the list of the three things that confused you so we can fix them before the mid-pack hits them. The early-adopter pilot's real output is a de-risked, documented path, not just a fluent individual. This reframes your fastest people from a source of the two-speed gap into the mechanism that closes it.

The Mid-Pack: The Training Plan

The mid-pack adopts on a shown-value, low-friction basis, so they get a structured training plan built from the pilot's output: a short session using the early adopters' worked example, a hands-on first run with the confusing parts already smoothed, and a clear "here is what this saves you" tied to their actual work. The mid-pack is the majority, so the initiative's success metric should be denominated against them, not the pilot - "three ICs beyond the pilot have run it" is a mid-pack metric, deliberately. If your metric is satisfied by the early adopters alone, you have measured the wrong population and will declare victory while the two-speed gap forms underneath you.

The Late Adopters: The Accommodation

The late adopters get accommodation, not pressure, and this is where strategists either prevent or cause the deepest damage. Some late adopters are skeptical for good reasons (they have seen tools overhyped), some are busy, some are anxious about what the tool means for their role - and the last group, if pushed, does not become an adopter, it becomes a quiet resister who confirms to everyone watching that the initiative is threatening. Accommodation means a longer timeline, a one-on-one rather than a group session, explicit acknowledgment that they do not have to be in the first wave, and - critically - making clear that the What Stays Human lines protect exactly the judgment they are expert in, so the tool is augmenting their craft rather than replacing it. The accommodation is not lowered standards; it is a recognition that the slowest adopters often hold the most senior judgment, and losing their trust costs more than their slower adoption does.

Rolling an initiative out uniformly means rolling it out to the early adopters, because they are the only ones who self-serve from an announcement. Three months later the gap has hardened into a culture: AI is for those people, not us. Sequencing the adoption curve is how you make sure all three speeds arrive.

Why the Two-Speed Team Is the Trap That Compounds

It is worth being precise about why the two-speed team is so damaging, because the cost is larger and more delayed than it looks. In the short term it is just uneven adoption, which seems tolerable. But the gap compounds. The early adopters, now fluent, get the interesting AI-augmented work, which makes them more fluent and more visible. The mid-pack and late adopters, stuck on the old workflow, fall further behind with each initiative, and the distance becomes demoralizing rather than closeable. Eventually the team has bifurcated into an AI class and a non-AI class, the non-AI class is the obvious target in the next headcount conversation, and the senior judgment that lived disproportionately in the slower-adopting late group walks out the door - which is precisely the capability the investment thesis bet the team's future on.

The two-speed team also poisons the culture in a way that makes future initiatives harder. Once the team has learned that an AI initiative means "the fast people get further ahead and the rest get left behind," every subsequent initiative meets pre-loaded resistance, because adoption is no longer a neutral act but a referendum on which class you belong to. Adoption-curve sequencing is partly a fix for this initiative and partly an investment in every future one: a team that experiences a rollout where all three speeds were planned for and all three arrived learns that initiatives are something done with them, not to the fast among them, and brings less resistance to the next one. You are managing the curve and the team's relationship to change at the same time.

It is also worth naming the cruelest mechanism of the trap, because it is the one strategists rationalize. When the gap appears, the natural managerial instinct is to route the interesting AI-augmented work to the people who are already good at it, because they will do it fastest and best - which is locally rational and globally catastrophic, because every such routing decision widens the gap it was responding to. The early adopters get more reps and more visibility, the rest get fewer, and within a few quarters the distribution that started as a slight difference in enthusiasm has been amplified by a hundred small staffing choices into a structural divide that looks like a difference in talent. The strategist has to actively resist this gradient, deliberately routing some of the AI-augmented work to the mid-pack and late adopters even when an early adopter would do it faster, because the point of the work is not only the output but the capability it builds in the person doing it. A team where capability is allowed to follow the path of least resistance will always bifurcate; keeping it from bifurcating requires spending some efficiency, on purpose, to develop the people the gradient would otherwise leave behind - which is the same development-category logic from the What Stays Human statement, now applied to who gets the reps rather than to which decisions stay human.

The Adoption-Curve Appendix as the Real Deliverable

The brief, metric, and rollback are the body of the initiative doc; the adoption-curve appendix is what makes it a strategist's document rather than a project manager's. The appendix names, for this specific initiative, who is in each population (by name, privately, because it is a planning tool not a public ranking), what each population's path and timeline is, what the pilot's documentation deliverable is, what the mid-pack training is built from, and what accommodation the late adopters get. It is the operational answer to "how do the actual humans get from here to there," and writing it forces the strategist to confront the team as it really is rather than as an undifferentiated "the team."

One discipline keeps the appendix honest: the populations are about this initiative, not about people in general. Someone can be an early adopter of research-synthesis tools and a late adopter of design-to-code, and labeling a person as globally "a late adopter" is both inaccurate and corrosive. Sort by their relationship to this specific change, re-sort for the next one, and never let the appendix become a permanent caste system - which would recreate the two-speed team by other means. The appendix is a per-initiative planning instrument, and its whole purpose is to ensure that the people who would be left behind by a uniform rollout are explicitly carried along by a sequenced one.

Key Takeaways

• A quarterly AI initiative needs exactly four components, and each prevents a specific failure: a brief (or it sprawls), a success metric (or it cannot be defended or learned from), a rollback plan (or it is a bet you cannot walk back), and adoption-curve sequencing (or it produces the two-speed team).
• Write the success metric with both a quality and an adoption dimension, denominated against the mid-pack, not the pilot. "Zero hallucinated props AND three ICs beyond the pilot have run it" - an initiative that works technically but only one person can run has created a single point of failure dressed as a win.
• The rollback plan makes the initiative safe to attempt aggressively, not a plan to fail. Name the concrete walk-back and the observable trigger that would invoke it in advance, so you neither abandon at the first frustration nor stubbornly push a failing initiative past the evidence. It is the initiative's reversibility made operational.
• Every rollout meets three populations - early adopters, mid-pack, late adopters - and this is a fact about how humans adopt, not a judgment of who is good. The catastrophic default is a uniform rollout, which in practice reaches only the early adopters (the only ones who self-serve from an announcement) and hardens into a two-speed team.
• Design a separate path for each population: the early adopters lead a pilot whose real deliverable is a documented, de-risked path for the next group; the mid-pack gets a low-friction training plan built from the pilot's output; the late adopters get accommodation (time, one-on-ones, and the reassurance that the What Stays Human lines protect their expert judgment), not pressure.
• The two-speed team is the trap that compounds: the gap hardens into an AI class and a non-AI class, the non-AI class becomes the next headcount target, and the senior judgment concentrated in the slower-adopting late group - the exact capability the thesis bet on - walks out the door. It also poisons the culture so every future initiative meets pre-loaded resistance.
• The adoption-curve appendix is the real strategist deliverable, naming each population's path for this specific initiative. Sort people by their relationship to this change, never globally - someone is an early adopter of one tool and a late adopter of another, and a permanent caste label recreates the two-speed team by other means.