Walk into any company on your first day and you'll encounter something nobody warned you about: the language. Not English or French or Mandarin, but the company's own language. The internal vocabulary that shapes how people think, how they measure success, and how they talk about what matters. Every company has one. No two are alike. And your data almost certainly doesn't speak it.
Language as a living artifact
Even within the same industry, every company features a distinct language that has evolved from its unique history, leadership, and diverse business mix. This specialized terminology shapes how the company executes its strategy, talks to its stakeholders, and analyzes its performance.
Consider something as basic as what you call the people you're trying to hire. One recruiting company refers to "candidates." Another calls them "talent." A third uses "associates" or "applicants" or "prospects," each word carrying subtle connotations about how the company views the relationship. Onboarding programs will often emphasize these distinct cultural differences and how to "speak the language" as real barriers to overcome to be successful. New hires who don't pick up the vocabulary struggle to be effective, not because they lack skill, but because they can't communicate fluently in the environment.
I spent 13 years leading data organizations across staffing, telecom, retail, and career services. At The Adecco Group, working across a company with 60,000+ employees, I saw how language varied not just between companies but between business units, between countries, and between functions within the same building. "Placement" in one market was "assignment" in another was "engagement" in a third. Each term made perfect sense to the people using it. Each reflected real differences in how those teams operated.
Where the language comes from
Company language doesn't emerge randomly. It's shaped by specific forces: the founders' vocabulary, the industry norms that get adopted or rejected, the acquisitions that bring in competing terminology, the dominant leaders whose phrases take root, and the systems the company buys and configures. Over time, these influences blend into something that feels natural to insiders and bewildering to everyone else.
This is worth understanding because it explains why the same business concept gets different names at different companies, and why those names aren't interchangeable. When a company says "revenue," they don't just mean money coming in. They mean a specific calculation, with specific inclusions and exclusions, reflecting specific accounting decisions that evolved over years. The word carries all of that context. Swap in a synonym and you lose the meaning.
The system language problem
Here's where things get complicated. Data often does not speak this language. Whether the company calls it "candidates" or "talent" doesn't matter if they use the same applicant tracking system with its own, different, vocabulary. The system has opinions about what things are called, and those opinions rarely match the company's.
Most B2B software has certain "native" terms common across all users and other "custom" terms that are more local to the company implementing it. Salesforce calls them "Opportunities." Your sales team calls them "deals." Your CRM was configured four years ago by a consultant who called them something else entirely. The native terms are baked into the product: the menu labels, the documentation, the API field names. The custom terms live in configuration layers that vary by implementation.
This creates an odd phenomenon that I think of as language transfer. Commonly used systems create a kind of linguistic bleed between the system's vocabulary and the business processes that rely on it. If you hear people talking about unnaturally structured values like "the status is retrying transaction" or using the numeric version of an enumeration like "that's customer type 4," this is the language of the system influencing the language of the business. People start speaking in database values because the system trained them to.
Language transfer is a signal that the data architecture has failed to translate. Instead of the system adapting to the business, the business has adapted to the system. And once that happens, it embeds itself in meetings, in Slack channels, in how people think about their work.
Why this matters for data architecture
When a data team builds a report, a dashboard, or an analytical model, they have to decide which language to use. The business language? The system language? Some hybrid? Most teams default to whatever language the source system uses, because that's the path of least resistance. The data arrives labeled "OPP_STATUS_CD" and it gets surfaced as "OPP_STATUS_CD" or, with some effort, as "Opportunity Status Code." Neither of those is how anyone in the business actually talks.
The result is analytics that are technically accurate but semantically foreign. The numbers are right, but the words are wrong. And when the words are wrong, people don't trust the numbers. They build their own spreadsheets, using their own language, to get the same answers in terms they recognize.
This is not a training problem. You cannot fix it by teaching business users to think in system terms. The fix is architectural: your data layer needs to encode the company's language, not the system's language, as the primary vocabulary for analysis and reporting.
Building a semantic bridge
The practical work here is what I call semantic architecture, designing your data layer to speak the language of the business by intention rather than by accident. This means:
- Catalog the real vocabulary. Document what people actually say in meetings, in strategy documents, in quarterly reviews. These are the terms your data layer needs to use, not the terms in the system's documentation.
- Map between languages. Every company operates in at least two languages: its own and its systems'. A semantic layer makes the translation explicit, maintainable, and visible rather than buried in transformation code.
- Detect language transfer. When business users start speaking in system terms, that's a sign the translation layer is missing or broken. These moments are diagnostic. They tell you exactly where the semantic gap is widest.
- Design for the local dialect. Even within a single company, different departments and regions use different terms for the same concept. A good semantic architecture accommodates this rather than forcing false standardization.
The payoff
When your data speaks the company's language, something simple but powerful happens: people use it. They trust the dashboard because the labels match the words in their heads. They don't need a data analyst to interpret the report because the report already speaks their language. The friction between "what the data says" and "what I need to know" drops dramatically.
Every company speaks its own language. That's not a problem to solve. It's a reality to design for. The companies that get this right don't just have better data. They have data that people actually believe.
If your analytics feel like they need a translator, the issue probably isn't the data. It's the language. That's where we start at Eloquent Analytics.