The ADM Charter - What You'd Actually Own

The deal is signed before you walk in. Your job starts at the handoff and it ends when the customer renews and buys more. Everything between is yours.

Read this section as the role contract. The diagram or table names the surface area, but the interview signal is whether you can turn it into a clear operating claim: what you own, what you do not own, what evidence proves the work is working and where judgment matters.

The AI Deployment Manager owns the post-sale journey for a portfolio of enterprise accounts. You are not closing contracts and you are not running the pre-sales demo. You are the person accountable for whether a 2,000-engineer org actually changes how it builds software with Cursor and whether that change shows up in the renewal.

Say the charter in one sentence so it's reflex by the recruiter screen:

Three numbers define the job. Memorize them as a unit, because interviewers want to hear you treat them as one system, not a list:

Adoption is the leading indicator that drives the rest. A customer who provisioned 1,500 seats but activated 400 looks healthy on the invoice and is quietly dying. Un-activated seats are the silent killer of renewals, because at renewal the buyer divides spend by real usage and the math turns against you.

This is a Customer Success org seat. That places you apart from quota-carrying Sales and apart from pre-sales Field Engineering. You inherit the account after the close and you carry it for its whole life.

You don't own the customer alone. You own a slice of a unified account team and the seams between those slices are where deals quietly die.

Three functions surround you at Cursor: Sales, Field Engineering and Product. Each has a distinct relationship to the account and your value is partly defined by how cleanly you hand off to and from them.

The handoff from Sales to post-sale is the single highest-risk moment in the account's life. The AE has months of context - who the real champion is, what was promised, which exec cares about what - and most of it lives in their head. If that context doesn't transfer, you restart discovery from zero and the customer feels it.

Inside the account you also have to multi-thread. A single champion is a single point of failure and champions change jobs.

The person who signs the contract is not the person who decides whether Cursor sticks. Selling the renewal means speaking four different languages to four different people.

An enterprise engineering org has a layered set of personas and each one judges Cursor against a different yardstick. A pitch tuned for a CTO will bore a senior IC and a feature deep-dive that thrills a developer will lose a VP in thirty seconds.

Security and procurement deserve special attention because they are the persona most likely to surprise you. They are not in the room when the contract is celebrated and then they freeze a 1,000-seat rollout for three months over a data-retention question nobody pre-cleared.

Developers are the hardest and most important persona. They are skeptical of AI by default, they have strong tooling opinions and they decide adoption with their feet. You don't win them with executive ROIReturn on Investment. The value gained versus what it cost, the language an economic buyer funds deals in. charts. You win them by making a real task faster in their own repo, in front of them.

A generic enterprise CSM job hands you a playbook and asks you to run it. This one hands you a blank page and asks you to write it while the product changes underneath you.

Cursor is a research-driven AI company growing fast and that reshapes the post-sale job in ways a polished CS background doesn't prepare you for. The difficulty is real and naming it precisely is how you show you understand the seat.

The behavior-change point is the heart of it. Configuring SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. and provisioning seats is the easy 20%. The hard 80% is convincing a senior engineer who has tried AI tools and dismissed them to give Cursor a real chance in their daily flow. That is a culture problem you solve with proof, champions and patience, not a settings page.

The technical bar is what separates this from a standard CSM role. You cannot drive developer adoption from a relationship with the VP alone. A skeptical staff engineer will test you in the first five minutes and if you can't talk credibly about .cursor/rules, context, the agent and how Cursor differs from Copilot, you lose the room that actually decides adoption.

A job description is a list of test questions in disguise. Every bullet maps to a competency someone in the loop is assigned to probe.

Read the JD twice. The first pass tells you the work. The second pass tells you what each line is really testing, so you can walk in with evidence pre-loaded instead of improvising.

The "voice of the customer" line is the most commonly fumbled. Weak candidates describe themselves as a relay that forwards feature requests to Product. Strong candidates describe synthesis: spotting that seven accounts hit the same friction, sizing it and bringing Product a prioritized argument with adoption impact attached.

Make the stories concrete and numeric. "I improved adoption" is forgettable. "I found 1,100 dark seats, traced it to a broken SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. group mapping plus zero enablement, fixed both and took weekly active from 27% to 71% over a quarter" is the kind of specific that survives a panel's memory into the debrief.