# How I approach Cursor adoption in an engineering team > Source: > Published: 2026-10-09 03:59:52+00:00 After we adopted Cursor, I noticed a change in how developers worked: instead of waiting for an answer to every code question, they asked the chat, understood the answer and moved forward. Buying licenses was only one part of that change. These are my lessons from leading Cursor adoption at Elementor, in an engineering organization of 50+ engineers. Begin with a small group of volunteers, real tasks and a four-to-six-week pilot. Shared repository rules give the team one place for coding conventions and recurring mistakes. Otherwise, each developer gets different results. An internal forum or guild gives developers a place to share prompts, useful techniques and failures. Developers can learn from one another rather than depending on top-down training. AI-written code still needs human review. Automated review can support that process by learning from the team's comments and feeding agreed rules back into the repository. Track usage for each developer and check whether it translates into useful output. Without measurement, costs can surprise you. Usage alone is not a productivity result. Define which repositories and secrets must not be exposed to the tool. The common mistake is expecting the tool alone to improve productivity. The process around it is what changes the team's work. I help teams with AI adoption, shared rules, code review and measurement. [Professional background and selected work](https://ofershap.github.io/about/en/). This is an English adaptation of my [original Hebrew guide](https://ofershap.github.io/posts/cursor-team-adoption/).