Sit in on the kickoff for any CRM or CPQ project. Sales leadership says what they want. The system team says what’s possible. Between them, almost always, there’s one person who turns one into the other. Sometimes they have a title that reflects the work. Usually they don’t.
This person is a translator. They take “we need to know which deals are at risk” and turn it into a data model, a definition of risk, and a set of rules that determine when a flag fires. They sit between two groups that don’t speak the same language and don’t fully trust each other. When the role is filled well, projects work. When it isn’t, they don’t. In most companies, nobody can name the person doing it.
What translation actually is
Translation gets confused with other jobs. Project management isn’t translation — a PM keeps timelines on track without needing to know whether the data model actually answers the question sales asked. Business analysis is closer, but a typical business analyst documents requirements. A translator decides which requirements shouldn’t be built at all.
Real translation has three layers. Comprehension: understanding both sides well enough to see when they’re talking past each other. When a sales director says “I want a single view of the customer,” they probably don’t mean a single record — they mean they want to walk into a meeting with a number that’s correct. A translator catches that gap before it becomes a build. Reformulation: turning a vague commercial intent into something testable, and turning a system constraint into a business consequence. “If we can’t capture this at stage two, we won’t be able to forecast the way you want. Here’s what we’d lose.” Judgment: deciding which requests deserve to be built. Most don’t, at least not as originally asked. That’s the conversation that determines whether the system stays clean or accumulates a decade of well-intentioned debt.
flowchart LR
COM["<b>Commercial</b><br/>Sales · Marketing<br/>Intent & requirements"] <-->|"Comprehension<br/>Reformulation<br/>Judgment"| TR(("<b>Translator</b>"))
TR <-->|"Constraints<br/>Consequences<br/>Trade-offs"| SYS["<b>System team</b><br/>Admins · Developers<br/>Capabilities & constraints"]The role rarely has a name
Look at how revenue tech roles are titled: Salesforce Admin, Sales Operations Manager, Revenue Operations Lead. None describe translation. They describe ownership of a system or a process.
The translator shows up as one of these titles in disguise. The Salesforce Admin who spends half their week in sales meetings is doing translation. The Rev Ops Lead who can describe the data model in business terms and the business model in technical terms is doing translation.
Because the role isn’t named, it isn’t measured. People only notice its absence when something breaks: a field added that conflicts with three reports, an automation running on stale criteria for six months, a new sales process designed without checking whether the CRM can capture it. These look like execution failures. Most are translation failures.
Without a name, the role has no career path. A great translator is often a Salesforce Admin who has earned commercial trust — the next step on the org chart is usually senior Salesforce Admin. The translation skill that makes them valuable doesn’t get rewarded. Over time, the best translators leave for places where the work is recognized, or move into consulting where it gets billed by the hour.
What happens when there is no translator
Two failure modes. In the first, commercial leadership talks to the system team without anyone in between. Requests get built as stated. Six months later there are 240 fields, four overlapping approval flows, three definitions of “qualified lead,” and a custom object that exists because someone once asked for it and nobody knew enough to push back.
In the second, commercial and the system team operate as separate planets. Sales builds a process, the system team builds a system, and the two are loosely connected through whatever the original implementation produced. Both sides say the other is unresponsive. Neither is wrong. There just isn’t anyone making the work connect.
Both symptoms get diagnosed as something else — data hygiene, misalignment — and a quarterly alignment meeting doesn’t fix either one. The gap is structural.
What the skill actually requires
Going from commercial to technical, what gets lost is conditional logic. “We want to see at-risk deals” has to become: at risk by what definition, measured how, refreshed when, with what threshold. The translator pushes the original ask through those questions before anything gets built.
Going from technical to commercial, what gets lost are constraints and consequences. “This requires changes to lead-to-account matching logic” has to become: “Here’s what your reps will notice. Here’s what happens to the reports you currently rely on.”
Both directions require knowing enough about both worlds to be specific. Vague translation is worse than no translation. The standard: by the end of the conversation, both sides should be able to describe what’s about to happen in their own language and recognize the same thing in each other’s description.
The gap between what’s possible and what gets built is rarely about technology or budget. It’s about whether the right conversation happens before the build. The translator is the person responsible for making that conversation happen, repeatedly, at the right level of detail.
Notice who in your organization is already doing this work. Give the role a name. Make it visible in how projects get scoped. Pay for it the way you pay for anything else that determines whether the system you’ve invested in keeps doing what you bought it for.
There’s always a translator. The question is whether you know who yours is.