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. Sometimes the company knows how much depends on them. Usually it doesn’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 take “the field has to be required at stage three” and turn it back into “you can’t move the deal forward without filling this in, and here’s why we’re asking.” They sit between two groups that don’t speak the same language and don’t fully trust each other. They make the work move.
I’ve worked with companies where this role was filled by a senior sales ops manager. Companies where it was a Salesforce admin who had grown into it over time. Companies where the role was held by an external consultant for the duration of an implementation, after which everything quietly drifted because nobody internal could maintain the bridge. The pattern is consistent. When the role is filled well, projects work. When it isn’t, they don’t. And 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 project manager keeps timelines and dependencies on track. They don’t need to know whether the data model the system team proposed 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, and convinces the people who asked for them.
Real translation has three layers.
The first is comprehension. You have to understand 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. The technical answer to those two things is completely different. A translator catches that gap before it becomes a build.
The second layer is reformulation. Once you understand what was actually meant, you have to say it in a form the other side can use. To the system team, that means turning a vague commercial intent into something testable: a clear definition, a data source, a refresh cadence, and a fallback when the data isn’t there. To commercial, it means 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 are the three things we’d lose.”
The third layer is judgment. A translator decides which requests deserve to be built. Most don’t, at least not as originally asked. The honest version of the conversation sounds something like: “What you’re asking for would solve a different problem than the one you actually have. Here’s the problem I think you have. Tell me if I’m wrong.” That conversation is hard. It requires standing, tact, and a willingness to be told you’re wrong. It’s also the conversation that determines whether the system stays clean or accumulates a decade of well-intentioned debt.
The role rarely has a name
Look at how revenue tech roles are usually titled. Salesforce Admin. Sales Operations Manager. Revenue Operations Lead. CRM Manager. Business Systems Analyst. None of these describe translation. They describe ownership of a system, a function, or a process.
The translator usually shows up as one of these titles in disguise. The Salesforce Admin who spends half their week in sales meetings is doing translation. The Sales Operations Manager who configures the discount approval rules themselves is doing translation. The Revenue Operations 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. Nobody asks whether the company is good at translation, or whether there’s enough of it. People only notice its absence when something breaks. A field gets added that conflicts with three reports. An automation runs on stale criteria for six months before anyone notices. A new sales process gets designed without checking whether the CRM can actually capture it. These look like execution failures. Most of them are translation failures.
Without a name, the role also has no career path. A great translator is often a Salesforce Admin who has earned the trust of commercial leadership. The next step on the org chart for a great Salesforce Admin is usually senior Salesforce Admin. The translation skill that makes them valuable doesn’t get rewarded in title or pay, because it isn’t part of how the role is defined. Over time, the best translators leave for places where the work is recognized, or move into consulting where it gets billed by the hour. Both outcomes leave the company that trained them with the same gap.
What happens when there is no translator
Two failure modes show up when nobody is doing translation. Both are common.
The first is direct line. 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 different definitions of “qualified lead,” and a custom object that exists because someone once asked for it and nobody knew enough to push back. The system becomes a record of every conversation, not a tool that supports a process. I’ve written before that most companies don’t have a CRM problem — they have a process problem dressed up as a CRM problem. That post focused on the process side. The system side has a parallel cause. Every request got built because there was no one in the middle deciding which ones shouldn’t be.
The second failure mode is no line at all. 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. When sales changes how they work, the system doesn’t follow. When the system team changes the data model, sales finds out by accident. Both sides say the other is unresponsive. Neither is wrong. There just isn’t anyone making the work connect.
In both cases, the symptoms get diagnosed as something else. The first looks like a data hygiene problem. The second looks like an alignment problem. A data governance committee or a quarterly alignment meeting doesn’t fix either one, because the gap is structural. There’s no role doing the daily work of bridging.
What the skill actually requires
A good translator isn’t just bilingual. The hard part is knowing what gets lost in each direction and being willing to say so.
Going from commercial to technical, what usually gets lost is nuance and conditional logic. Sales says “we want to see at-risk deals.” The technical specification has to answer: at risk by what definition, measured how, refreshed when, with what threshold, distinguished from what other categories. The translator has to push the original ask through those questions before anything gets built. Most commercial stakeholders don’t enjoy this conversation. Done well, it doesn’t feel like an interrogation. It feels like someone trying to make sure they get what they actually need.
Going from technical to commercial, what gets lost are constraints and consequences. The system team says “we can do that, but it requires changes to the lead-to-account matching logic.” A translator has to turn that into: “If we make this change, the way leads attach to accounts will work differently. Here’s what your reps will notice. Here’s what happens to the reports you currently rely on.” Most technical people aren’t trained to do this. They’re trained to deliver what was asked.
Both directions require the translator to know enough about both worlds to be specific. Vague translation is worse than no translation. “It depends” is sometimes accurate, but a translator who only ever says it isn’t doing the job. The standard is: 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.
There’s also a quieter requirement, which is the willingness to push back without making a performance of it. A translator who turns every request into a debate becomes exhausting. One who pushes back too rarely becomes a conduit for bad decisions. The version that works is closer to a gentle, persistent re-asking of the question. What are you trying to accomplish? Let’s make sure we’re solving for that, not for what you originally asked. It’s the same posture that works in discovery, and the same one that determines whether change runs with the grain or against it.
Why this is worth recognizing
The recurring pattern in revenue operations work is that 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.
When that role is recognized, you get faster implementations and fewer of the slow failures that show up six months after go-live. When it isn’t, every new request adds a small amount of debt to the system, and the people who actually understand both sides quietly start leaving — because their best work is invisible inside the company and immediately recognized outside it.
The fix isn’t complicated. Notice who in your organization is already doing this work. Give the role a name. Make it visible in how projects get scoped and how decisions get made. 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, and whether they know that’s the job.