Enterprise Rollout & Adoption Playbook

A pilot is not a free trial with a friendly logo. It's an experiment you run to manufacture the evidence that justifies a thousand-seat rollout.

The contract is signed, the org is curious and you have a window of goodwill. Spend it on one team that will generate a defensible story. The pilot's deliverable is not happy users. It's a readout with a baseline, a number that moved and two or three quotes from engineers the rest of the org respects.

Team selection is the first decision and the one people get wrong. The instinct is to pick the easiest, most enthusiastic team. That gives you a result nobody believes, because the skeptics will say "of course the early adopters loved it."

Pick a team with a motivated champion on a mainstream stack, doing the kind of work most of the org does. You want a result that a VP can point at and say "that's us."

Set the baseline before you touch anythingevidence, not vibes

If you don't measure the before, you can't prove the after. Capture the baseline in the first week, while the team is still working the old way. This is the difference between a pilot that produces evidence and one that produces vibes.

Time-box it and instrument itthe pilot is an experiment

An open-ended pilot drifts into a permanent trial that never converts. Set a window, usually four to six weeks, long enough to get past the novelty and into real habit, short enough to keep urgency.

1. 1Define success criteria up front. Write down what "good" looks like before you start - e.g. 70% of the team weekly-active by week four, plus three concrete workflow wins documented.
2. 2Capture the baseline. Quantitative, adoption and qualitative, all recorded in week one.
3. 3Instrument the run. Watch activation and usage depth weekly; don't wait for the end to discover a stall.
4. 4Run a mid-pilot check. A short pulse at the halfway mark catches a fading team while you can still intervene.
5. 5Build the readout as you go. Collect quotes, screenshots and the moment a skeptic flipped - these are the assets that sell the expansion.

Surface security and admin requirements earlydon't let procurement ambush the scale-up

The pilot is where you flush out the questions that would otherwise block the expansion three months later. Large eng orgs gate AI tooling on real concerns and the security team rarely shows up until you try to scale.

Get the security and admin conversation onto the pilot agenda deliberately. If zero data retention or SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. is a hard requirement, you want to know in week one, not when you're provisioning team number twelve and procurement freezes the order.

You cannot personally onboard two thousand engineers. Adoption scales through their peers or it doesn't scale at all.

A developer trusts another developer in their own org far more than they trust a vendor. The whole game of enterprise rollout is converting that trust into a self-propagating habit. Your scaling mechanism is not your own hours. It's the champions you equip to do the spreading for you.

Find and equip the championsadoption travels peer to peer

Equip the ones who are real. Give them early access to new features, a direct line to you, a little internal status and the assets they need to look good in front of their team. A champion who feels like an insider will outwork any campaign you run.

Treat resistance as signal, not noisebehavior change is the actual work

Some engineers will push back and the worst response is to route around them. A senior skeptic who goes quiet doesn't disappear - they become a slow drag on the room. Resistance is data about a real objection and engaging it is where trust gets built.

Enablement that meets the real workflowtheir codebase beats your slides

Generic training on a toy repo teaches nothing that survives contact with real work. The demo that converts is the one run live on the customer's own codebase, solving a task the team actually has open.

• Use @-symbols and codebase indexing to pull in their files, not a sample project, so the agent answers questions about code they wrote.
• Solve a real ticket from their backlog in front of them - nothing sells like watching a familiar problem get handled.
• Show the verify-and-review loop, so it lands as a trustworthy workflow rather than a magic box.
• End with the one move each person should try tomorrow on their own work.

Lower the activation barrier with shared assetsmake the right setup the default

Every engineer who has to figure out good configuration alone is a chance for the habit to die. Build the assets once, centrally, so a new team inherits a setup that already works.

Pull the four adoption levers, in orderchampions are one lever of four

Champions are the engine, but they don't fire on their own. The orgs that get real adoption pull four levers together, and a champion program with no executive sponsorship or aligned incentives stalls the moment the novelty fades. Name the levers explicitly so the buyer can see where their rollout is thin.

The levers compound in sequence. A clear why gives leaders something real to model; a leader who models it gives champions cover; champions who win in public give HR and recruiting a reason to bake the habit into the culture. Skip a lever and the ones after it work harder for less.

The fastest way to kill a rollout is to provision everyone at once. Un-onboarded seats don't sit neutral - they sit dark and dark seats drag your health score down.

There's a temptation, often from an excited exec, to flip on all 2,000 seats day one and declare the rollout done. Resist it. Allocation is not adoption. A seat that's been provisioned but never activated is a future renewal liability, because at renewal someone divides spend by real usage.

Measure depth, not provisioning - the adoption trap"100% adoption" that's really once a month

The most common self-deception at the leadership level is reporting "100% adoption" because every seat is provisioned, while the usage data shows the median engineer opens Cursor about once a month. Provisioning is not depth. A seat that lights up once in thirty days is functionally a dark seat that happens to have a login.

Run the four-step rollout measurement loopbenchmark, find power users, layer autonomy, measure at three levels

Provisioning seats is step zero. The rollout that actually deepens usage runs as a measured loop: establish where the org starts, learn from the people already winning, raise the ceiling with autonomous workflows, and read the result at every altitude so a healthy org average can't hide a dark team.

1. 1Benchmark. Capture the starting line - weekly-active rate, agent vs. Tab usage, requests per active user - so every later number has a before to beat.
2. 2Identify power users. Find the high-volume, high-acceptance engineers and study how they prompt; their patterns are your training material and your next champions.
3. 3Layer in autonomous workflows. Once a team is steady on the basics, introduce agent-driven and background workflows so the ceiling on value rises instead of plateauing at Tab completions.
4. 4Measure at org, team and individual. Read adoption at all three levels - the org average proves the program, team-level health finds the dark cohorts and individual usage tells you who to coach or champion.

Phase the rollout to match enablement capacitypace provisioning to onboarding, not to enthusiasm

Each phase has a gate. You don't open the next wave because a month passed; you open it because the current cohort is genuinely active and your enablement bandwidth is free. That discipline is what keeps the health score climbing instead of inflating with dark seats.

Read adoption from the analytics, not from vibesrequest volume × acceptance rate

Two admin-dashboard signals, read together, turn the rollout from a guessing game into a quadrant with clear actions. The pair is request volume and the acceptance rate of committed code.

When you spot the repetitive workflow a team does by hand, that's the signal to recommend their first automation. The data-backed starter is "Summarize Changes Daily" - Cursor's stickiest automation at 89% retention - which posts a daily engineering digest of notable repo changes to Slack. Build local until a workflow gets repetitive, then automate it; people have a blind spot for what's automatable.

Standardize the org-wide configurationevery new team inherits a working setup

By the time you're rolling out waves, nobody should be configuring from scratch. Lock the org-level config so a new team inherits SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool., admin policy and good defaults the day they're added.

The actual mechanism: distribution scopes and the Teams Marketplace

"Standardize the rules" is the goal; this is how it physically happens. Rules, skills, commands and hooks have three distribution scopes - user-level (only you), repo-level (committed, anyone with repo access) and team/org level via Teams Marketplaces (org-wide configs, with sub-team configs - e.g. one set for the design team, another for backend infra). That sub-team granularity is what lets a 2,000-engineer org standardize without forcing one config on everyone.

• Admins can push skills, hooks and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. integrations centrally to the whole team from one place - then see analytics on how many skills, hooks and MCP servers are being invoked across the org, surfacing which see heaviest usage and where the gaps are.
• Orgs can create PRIVATE team marketplaces by creating a manifest and uploading it - the internal app store for your standardized config.
• A single marketplace pluginA Cursor marketplace package that bundles MCP servers and skills (sometimes sub-agents and hooks); one click installs all of it into your Cursor instance. bundles all six primitive types at once (rules, skills, sub-agents, commands, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. servers and hooks), so one install brings a whole working setup; third-party plugins are Cursor-vetted, and everything except the MCP server is readable, so browsing is a way to study well-written config.
• Convention: .cursor is ignored by default - unignore what you want committed; to keep a personal rule set private, create it in the rules directory and add it to .gitignore.

Govern the explosion of internally-built toolsvalidate adoption first, then add controls

Once a team is fluent, people start building their own tools - small internal apps, hosted scripts, MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. integrations that pull from real systems. That sprawl raises the questions a security team will eventually ask: where is this hosted, who can reach it, what data does it touch. Centralizing and maintaining that is genuinely unsolved across the industry, so don't promise a tidy answer you can't deliver. Cursor's own team is candid that they're flying the plane as they build it.

The sequencing that works is crawl-walk-run, and the first gate is adoption, not governance. Building a tool is cheap; that doesn't make it valuable. Most internal tools never get traction and governing those is wasted effort. The moment one earns strong adoption, the governance question becomes urgent and concrete: is this pulling the right data sources, does it have the right access controls and data guardrails. Empower everyone to build, then govern the few tools that actually spread.

Build a rollout kit you can reuse across the portfoliothe motion has to work for more than one account

You own a portfolio, not a single account. If every rollout is bespoke, you don't scale and neither does the company. Package the motion into a kit so the second and tenth account go faster than the first.

• A pilot template: selection criteria, baseline worksheet, success-criteria menu, readout deck skeleton.
• An enablement curriculum with tiered paths you adapt per account.
• A security/admin checklist covering the questions large orgs always ask.
• A champion playbook plus the shared-asset starters: rules baseline, prompt-library template, channel charter.
• A health-scoring model so every account reports adoption the same way.

One-size enablement fails everyone. The skeptic needs a first win; the convert needs the agent depth that makes them never go back.

A developer's first hour with Cursor and their fiftieth hour are different problems. The first is about getting one real task done and feeling the value. The fiftieth is about mastering the agent and context so the tool reshapes how they work. A good program tiers these so nobody is bored and nobody is lost.

Tier the curriculum into three pathsskeptic to power user

Most engineers move through the first two paths. The third is where you mint your next generation of champions, so invest disproportionately in the people who reach it.

Train on real repositories and real taskstransfer beats theory

Training that uses a sample project teaches a skill that evaporates the moment the engineer opens their actual work. Anchor every session in the customer's repositories and the team's live backlog, so what they learn transfers to Monday morning with zero translation.

Pair enablement with measurementconfirm behavior actually changed

A session attended is not a habit formed. Close the loop: after a team is trained, check whether their activation and usage depth actually moved over the next two weeks. If they didn't, the training failed regardless of how good the room felt.

1. 1Baseline the team's usage before the session so you have a before.
2. 2Run the tiered session on their repo and live tasks.
3. 3Watch the two-week window for a real lift in weekly-active and agent/Tab usage.
4. 4Re-intervene if flat. No lift means a wrong path, a missing champion or an unresolved blocker - diagnose, don't repeat the same session louder.

Hand enablement to the championsit has to survive without you

You won't be in the room forever and you shouldn't want to be. Train the champions to run the curriculum themselves. A program that depends on the vendor's presence collapses the moment your attention moves to the next account.

A stalled rollout is a diagnosis problem before it's an effort problem. Throwing more enablement at the wrong cause just burns goodwill.

When usage flattens or drops, the instinct is to push harder - more sessions, more nudges. That's how you exhaust your credibility on the wrong fix. Start by reading the data to classify the failure, because activation, depth and value problems each need a different intervention.

Triage from the data firstclassify before you act

Run down the usual suspectsthe common root causes

Re-segment the accounta healthy team and a dead team need different things

An account is rarely uniformly stalled. Usually some teams are thriving and others are dark and the org-level average hides both. A single blanket push wastes effort on the healthy teams and under-serves the dead ones.

• Break the account into team-level health, not one org number, so you can see who's actually stalled.
• Mine the healthy teams for the success story and the champion you'll redeploy.
• Give the dead teams a targeted intervention aimed at their specific problem type, not the generic deck.

Escalate the right blockersdon't absorb them silently

Some blockers are not yours to solve and quietly absorbing them is a failure mode. A deep technical issue belongs with Field Engineering; a genuine product gap belongs with Product, carried as synthesized customer voice rather than a raw complaint.

1. 1Triage from data. Classify it: activation, depth or value perception.
2. 2Find the root cause. Champion, security, context/rules or stack mismatch.
3. 3Re-segment. Separate healthy teams from dead ones and treat them differently.
4. 4Escalate what isn't yours. Route technical blockers to Field Engineering, product gaps to Product.
5. 5Engineer a fresh win. Pick a high-visibility use case and broadcast the result.