2 min lesson
Team-level enablement - make habits spread without you
Recall the main items in "Team-level enablement - make habits spread without you", then connect each one to the work.
Step 1 of 2
Team-level enablement - make habits spread without you
You cannot coach 800 engineers one at a time. You build the mechanisms that let adoption spread peer to peer, then you feed and protect them.
- Internal champions - find the respected engineers, make them great at Cursor first and let their endorsement carry weight yours can't.
- Shared rules files - a team-owned
.cursorrulesso good context becomes the default for everyone, not a per-person discovery. - A prompt library - capture the prompts that worked for real tasks so the next person reuses them instead of relearning.
- Brown-bag demos - a champion showing a real change they shipped with Agent converts more skeptics than any vendor deck.
- Office hours - a recurring slot where stuck engineers get unblocked, which keeps trial users from quietly churning.
One-size guidance fails. A Go backend team in a clean monorepo and a JavaScript team in a sprawling legacy app need different first workflows, different rules and different proof points. Generic enablement reads as a vendor who hasn't looked at their code. Ask what they build, in what language, in what repo shape, then tailor the first win to that reality.
When asked how you'd drive adoption on a team, resist generic enablement language. Pick a concrete workflow (say, test generation), describe how you'd prove it on the team's real code, then explain the mechanism - champion plus shared rules plus a brown-bag - that makes it spread. Specificity is the signal that you've actually done this.