What we call people and things

Naming is not a cosmetic exercise. It is one of the earliest forms of governance. Before a company can scale its decisions, it usually has to standardise its nouns.

In many organisations, naming is treated as a minor hygiene issue. Something to tidy up later, if somebody has time. A dashboard label here, a job title there, an internal system field nobody quite understands but everybody has learnt to work around.

This is usually a mistake.

What we call things shapes how work is understood, how data is interpreted, how responsibilities are assigned and how systems are maintained. It affects whether people are speaking about the same thing when they think they are, whether reports can be trusted, whether decisions travel cleanly across teams, and whether software remains legible to the humans responsible for changing it. Naming is not decoration. It is structure.

That is why one of the first documents I often create inside a messy organisation is called What We Call People and Things.

It sounds simple. It rarely is.

Because a surprising amount of confusion disappears the moment the nouns stop drifting.

Naming is one of the earliest forms of governance.

Poor naming is rarely the whole problem. It is often the beginning of it.

Most operational mess does not begin with a dramatic strategic failure. It begins with small inconsistencies that accumulate quietly.

Two systems use different names for the same entity. Three teams use the same word to mean different things. A metric label sounds settled, but its logic changes underneath it. A role title implies ownership that does not really exist. A product surface inherits terminology from the org chart instead of the customer's mental model.

Individually, these may look trivial. In aggregate, they create friction: duplicate work, reporting disputes, brittle integrations, muddled accountability, and low-grade confusion that becomes expensive precisely because it is rarely named as the problem. The AI Safety Institute of Japan's data-quality guide is unusually direct on this point: common data definitions and naming conventions help prevent inconsistencies across systems, reduce duplication and redundancy, and reduce errors and correction costs later in operations.

This is why naming matters more than many organisations realise. It does not merely describe reality. It helps organise it.

In data, naming is a trust issue

This is clearest in data.

Many companies want to be “data-driven” while tolerating naming and definition practices that make their own reporting unstable. Dashboards proliferate, metrics multiply, and teams spend extraordinary amounts of time arguing not about what to do, but about what a number actually means.

That is not a data maturity problem in the abstract. It is often a naming and definition problem in plain sight.

The point is not that every naming problem creates an eight-figure loss. It is that naming and definitions sit upstream of reliability. Once the labels are unstable, everything downstream becomes harder to trust.

This is why mature organisations create common definitions, reference models and data dictionaries. The Japanese AI Safety Institute's 2025 guide describes a data dictionary as the repository of names, definitions, formats and relationships that creates consistency across an organisation. That is exactly the right framing. A data dictionary is not admin. It is an agreement about meaning.

And without agreement about meaning, “data-driven” very quickly becomes theatre.

A data dictionary is not admin. It is an agreement about meaning.

In teams, naming shapes accountability

The same logic applies to people.

Job titles, role labels and team language are often dismissed as semantics. But the words an organisation uses for people do more than describe a structure. They imply ownership, hierarchy, responsibility and expected behaviour.

Call one person “the product” and two others “supporting functions”, and you subtly centre accountability in one role while reducing the others to delivery capacity. Call three people a product trio, and you are already communicating something different: that product management, design and engineering are all part of the act of shaping the product, not merely servicing it.

This is not pedantry. It is organisational design expressed through language.

That matters because many organisations create role ambiguity long before anybody writes it down formally. They create it through names. Through titles that imply decision rights nobody actually has. Through categories that separate work which in practice must be deeply integrated. Through language that obscures who owns what, who decides what, and what good looks like in the role.

What appears to be semantics is often structure in disguise.

In software, naming is comprehension

There is a third layer too, and software engineers have known it for years.

Names in code are not incidental. They are the primary way human beings communicate the logic of a system to one another over time. Variable names, class names, method names and identifiers all carry meaning. When they are vague, inconsistent or misleading, the code may still run, but the system becomes harder to read, maintain and safely change.

Research from the Open University found statistically significant associations between flawed identifiers and code-quality issues. In related work, the same researchers note that naming conventions support readability, comprehension and onboarding, and provide cues that help both developers and tools extract meaning from code.

This is a useful reminder for non-engineers too. Naming is part of how systems communicate with their operators. If the names are poor, the cognitive load goes up. If the names are strong, complexity becomes more manageable. Not decoration. Structure.

Before a company can scale its decisions, it usually has to standardise its nouns.

Why naming is usually neglected

If naming is so important, why is it so often left in such a poor state?

Partly because it sits in an awkward category. It feels too small to be strategic and too abstract to be urgent. It is rarely anybody's headline priority. There is always a launch to prepare for, a forecast to update, a hiring need to solve.

So naming gets inherited rather than designed.

Legacy terms survive long after the context that created them has gone. Teams improvise local language to get work done. Different systems evolve different labels for the same object. Over time, the organisation learns to live with the friction and stops noticing it clearly.

Until a larger problem appears.

A reporting conflict. A broken integration. A role dispute. A product taxonomy that customers do not understand. A roadmap argument rooted, in reality, in people meaning different things by the same word.

Naming is one of the fastest ways to create clarity

The good news is that the fix is often less dramatic than the consequences.

You do not always need a transformation programme. Quite often, you need a disciplined pass through language.

What are the core entities in the business? What do we call them? What do we not call them? Which terms are overloaded? Which labels have drifted from their definitions? Which roles imply accountability that does not really exist? Which dashboards, systems or documents use competing names for the same thing?

These are not glamorous questions. They are also among the most clarifying.

This is why I like beginning with a document called What We Call People and Things. It forces the organisation to slow down and agree on its nouns. Once that happens, other forms of clarity often arrive more easily: reporting improves, role boundaries become more legible, communication sharpens, and the system becomes easier to reason about.

A great many companies do not need more language. They need cleaner language.

The strategic value of good naming

What good naming does, in the end, is reduce interpretive friction.

It reduces the time people spend decoding what a term means. It reduces duplication across systems. It reduces disagreement that is actually definitional confusion in disguise. It reduces role ambiguity. It reduces the risk that a software system becomes more difficult to maintain than it needs to be.

It also raises the quality of decisions, because cleaner language makes patterns easier to see. A business cannot reason well about a system it cannot describe consistently.

That is why naming is not an afterthought to strategy. It is part of the operating system that makes strategy executable.

Before a company can scale its decisions, it usually has to standardise its nouns.

And before it can standardise its nouns, it has to accept something many organisations resist for far too long:

What looks like semantics is often architecture in disguise.