Language as a tool for engineering teams

I've been more interested in language recently, largely from investing more time in studying music. Watch Jacob Collier explain harmony to audiences ranging from a 7-year-old to Herbie Hancock to see what I mean by it:

In seconds, Jacob adapts his language from zero musical knowledge (00:00-1:05) to meta-language (11:00-12:00). At the final stage, the exchange is wordless — yet communication is fully intact. That's language's primary purpose: communication.

The parallel to technology is obvious. We work immersed in non-trivial terms, concepts, and abstractions — much like harmony in music. Here's where language can make engineering teams more effective.

Cohesion between team and stakeholders

The best example from my career was my first exposure to payments systems. The domain terminology alone was overwhelming: card authorisation, capturing funds, clearing, settlement, reversals vs refunds vs voiding, chargebacks. Worse, stakeholders used the same concepts interchangeably or inconsistently.

Learning something new is hard enough. When language is loose between business and technical people, it becomes much harder.

My preferred solution is Eric Evans' Domain Driven Design. His framing of the problem:

• When stakeholders and technical teams don't share language, each group builds understanding in silos;
• Translation between separate vocabularies is expensive at best; at worst, incompatibilities go unnoticed;
• This bleeds into system design and code, rendering domain concepts incomplete or wrong;
• Stakeholder language doesn't serve technical needs either, deepening the isolation.

The solution is what Eric coined Ubiquitous Language: a shared vocabulary that articulates a domain model simply, without leaking implementation details or excessive jargon. Everyone uses and shapes it. The result is a language usable everywhere — representative of the domain at the right level of granularity and abstraction for any context, useful to both engineers and domain specialists.

Beyond stakeholder relationships, Ubiquitous Language reduces onboarding friction, supports internal mobility, facilitates cross-domain knowledge sharing, and helps engineers have broader impact within a domain.

Goal setting and accountability

Goal setting typically combines expected impact with measurable outcomes. OKRs are a common framework. Here's how language can improve goals.

The value of achieving a goal should be obvious. If you can't articulate the benefit clearly, you may be solving the wrong problem or masking symptoms. Teams are especially prone to this — confirmation bias and herd behaviour make it easy to align without questioning. Five whys can help challenge whether you're solving the right problem.

The goal itself should be obvious, so use simple language. Avoid overly technical terms, acronyms, component names, nicknames, or domain-specific lingo that outsiders wouldn't understand. Technical terminology is fine in deeply technical teams, but recognize it as a trade-off — new joiners or external audiences will struggle.

Goals should be opinionated and outcome-focused, not output-focused. Phil Calcado's article on OKRs draws a great parallel: KRs as tests for the Objective. The choice of measurable results inherently expresses an opinion about what achieving the desired impact means.

Goals shouldn't be bendable. Ambiguous language lets goals get relativised unintentionally. Language should enforce accountability and keep the team honest about success. To reduce ambiguity: choose words carefully for objectives and key results, and prefer boolean grading ("yes"/"no") over percentages or statuses ("in progress"), which invite subjectivity.

In short, a well-written goal has an obvious upside, simple language, a clear why, clear "how much"s, and communicates what success looks like unambiguously.

Metrics and baselines definition

Metrics are central to goal setting, and goals implicitly demand focus. It's hard to articulate a metric concisely while capturing all its nuances — supporting metrics, competing baselines, upstream or downstream consequences of optimising for it.

A metric that isn't driving a goal can still matter. Ignoring supporting metrics or competing baselines can lead you to hit your target while missing the value you expected. As Goodhart's law puts it:

"When a measure becomes a target, it ceases to be a good measure."

—Charles Goodhart

Example: teams responsible for user onboarding, targeting "increase registered users by 20% in H1." Over-indexing on lead quality means more identity check friction, more churn, and higher upstream advertising costs. Over-indexing on intake means fraud costs downstream and operational overhead from terminations.

Language can help by creating a composite metric. Call it "genuine registration" — one that bakes in both baselines: identity check churn stays below 5%, identity fraud declines stay below 0.1%. The new goal becomes "increase genuine registrations by 20% in H1." This is more transparent: grow sign-ups while maintaining quality and intake levels. It also focuses the team on what they actually own:

• How can we improve the sign-up experience?
• How can we reduce friction or churn during sign-up?
• Which ML fraud model features can better predict fraudulent sign-ups?

This technique works beyond baselines — it helps whenever you have implicit supporting metrics or a complex definition of value. Monthly active users (MAU) and daily active users (DAU) are a good example. Every product defines "active" differently (usage, engagement time, etc.), but the word itself carries useful information even without diving into the details.

For more on baselines, see Will Larson's article on Goals and Baselines, which explores similar dynamics with a different approach to goal setting.

As Jacob Collier demonstrates, language works best when it's considerate of the audience. It takes different forms in different settings. The best part is figuring out what works — together.