1 min lesson
Read adoption from the analytics, not from vibes
Compare two rows from "Read adoption from the analytics, not from vibes", then say when each one fits.
Step 1 of 2
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.
- Request volume
- High
- Acceptance rate
- High
- What it means
- Power users - the habit is real and producing value
- Your move
- Identify them; learn how they prompt via shared knowledge/transcripts and distribute those learnings
- Request volume
- High
- Acceptance rate
- Low
- What it means
- Trying hard but output isn't landing
- Your move
- An enablement/training opportunity - usually a context/rules gap
- Request volume
- Low
- Acceptance rate
- -
- What it means
- The tool isn't part of the day yet
- Your move
- Drive more adoption and awareness; check for an activation or champion gap
| Request volume | Acceptance rate | What it means | Your move |
|---|---|---|---|
| High | High | Power users - the habit is real and producing value | Identify them; learn how they prompt via shared knowledge/transcripts and distribute those learnings |
| High | Low | Trying hard but output isn't landing | An enablement/training opportunity - usually a context/rules gap |
| Low | - | The tool isn't part of the day yet | Drive more adoption and awareness; check for an activation or champion gap |
Admins can enable shared knowledge / shared transcripts at team level to study exactly how a power user works.
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.
Learn more
Full explanation
Standardize the org-wide configuration
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. Press Enter for the full definition., admin policy and good defaults the day they're added.
- SSO / SAML
- Identity wired once at the org level so onboarding a team is a group add, not a security project
- Admin policy
- Privacy mode, data-retention settings and model access decided org-wide and enforced by default
- Baseline rules
- An org-level rules baseline teams extend, so context quality doesn't depend on each team rediscovering it
- Seat governance
- A clear process for who gets provisioned, when and how dormant seats get reclaimed
Standardized config turns each new team's setup from a project into a checkbox.
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. Press Enter for the full definition. 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. Press Enter for the full definition. 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. Press Enter for the full definition. 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:
.cursoris 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.
The reason to lock distribution before scaling is that every team configuring from scratch is a chance for the habit to die on bad context. Push a baseline rules set and the high-value skills/hooks centrally via a private team marketplace, then let sub-teams extend it. The invocation analytics close the loop: you can see whether the skills you pushed are actually being used, and redeploy the ones that aren't landing as training material rather than guessing.
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. Press Enter for the full definition. 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.
Learn more
Full explanation
Hear it from Cursor
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.
The culture is to empower everyone to build, and accept that the centralizing problem is still open.
“It's easy to build a tool but a tool is not always going to be valuable immediately... but if there is strong adoption then very quickly the question is okay is this tool pulling on and using the right data sources and have the right access controls.”
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.
Initial excitement fades. Around weeks four to eight, the novelty wears off and usage on a new cohort can stall or dip. This trough is predictable and the ADM's job is to anticipate it: schedule a re-engagement push, surface a fresh use case or bring a champion win into view before the curve flattens. Teams that hit the trough unattended often never recover.
If a case asks you to "roll out to 2,000 seats," the wrong answer is a provisioning timeline. The right answer is a phased plan gated on activation health, with standardized config and an explicit plan for the post-novelty trough. Naming the trough unprompted signals you've actually run a rollout, not just read about one.
QAn eager CTO wants all 2,000 seats turned on next Monday to "get it done." How do you respond?
Learn more
Optional practice