Use ubiquitous language

Eric Evans coined the term ubiquitous language in his classic book on designing software, Domain Driven Design (which I highly recommend having on your bookshelf), and the concept remains one of the most important in my day-to-day work.

In my experience, developing a ubiquitous language for your organization is one of the most important things you can do to minimize miscommunication and help ensure that you're building the right things.

The basic idea is that you want to have definitions of key concepts that are shared across the organization, so there is no mistaking what someone means when they use certain words.

To take an example from the ad-tech world: consider the terms audience and segment. The concept of audience segmentation, or identifying and dividing up users or consumers into buckets that have specific characteristics (e.g. people with a college degree, people who live in Miami, people who own dogs) has been a key component of online advertising for years, and those groups of users have often been referred to interchangeably as audiences, segments, and even audience segments. They all seem to describe the same thing, so what difference does it make what someone calls it?

When it comes down to actually developing your system, it matters a lot.

One of the many things you can do on a platform like Facebook is target specific niche groups of users by using different combinations of existing groups. For example, I could target an ad to college-educated dog owners in Miami by combining three basic audiences:

"people with a college degree" AND "people who live in Miami" AND people who own dogs

Essentially I am using the existing audience segments as building blocks to create a more complex audience.

Here, the terminology we use can have significant implications on how solutions get built. Let's say we decide to make a distinction between "simple" audiences, which are synonymous with a single segment ("people with a college degree"), and "complex" audiences, which are made up of multiple segments in some combination. You would need some terminology to describe this.

You could refer to it as "simple" and "complex", as I just did, but an engineer might just as easily refer to the atomic "simple" segment as the segment, and the more "complex" segment as the audience that is made up of one or more "simple" segments.

A decision like this will impact everything from how the data is presented in the UI to what the database schema looks like. You might have two different tables in your database, one called segments and another called audiences.

Once you've codified something like this in a database schema, now there are real implications when business stakeholders might throw around the terms segments and audiences. It doesn't take much to see how these words could get thrown into a user story that then results in the audiences table being modified when really we wanted to change the segments table, or vice versa.

So now that we have a sense for the problems that can be caused by the lack of a common understanding of key definitions, there are many ways to help develop and promote a ubiquitous language. Here are a few:

Always seek clarification.

Always seek clarification about what the other person means when they use a term X. As you confirm your understanding, always use the terms that your system uses as you try and say back to the other person what you heard. Here you're leading by example to try and get the other person to internalize the definitions you just used. If the other person finds that they are more easily understood using your organization's ubiquitous language, they are liable to start shifting their language naturally.

Eliminate interchangeable terms.

If there are terms that in your system are (at the moment) truly interchangeable, you should endeavor to choose a single term to use exclusively. The fewer ways there are to describe a thing, the less chance someone in the future might misconstrue one term for another.

Coming back to the ad-tech example, if audiences and segments are truly interchangeable in your organization, then choose to call them either audiences or segments, but stick to that one term.

Build a glossary.

For important key terms, it can be helpful to have a place in your documentation where you list out the specific definitions for your organization. Every organization develops a unique set of terms, and it can be incredibly helpful for new hires (as well as long-tenured employees) to have a place they can refer back to in order to understand key definitions.

In cases where you are working with external customers or vendors that might have their own terminology, the opportunities for miscommunication multiply. While you might not be in a position to change the way they define things, you can help your own organization by adding to your glossary translations of what your external parties call specific things. Your client-facing team members will want to make sure they translate foreign terms back into your ubiquitous language.

Be pedantic.

Lastly, it's okay to be pedantic about it. Don't let what may seem like minor differences in terminology slip past you. It could lead to major misunderstandings in the future (i.e. building the wrong product). Don't let the other person dismiss the difference ("Audiences, segments, whatever"). It's often not intentional, and it's hard to break bad habits and develop new ones.

If you're serious about fostering a ubiquitous language, you'll need to work at it. It will take time. Find others in your organization that are interested in developing your organization's ubiquitous language. Like many things in management and leadership, the results won't be instantaneous or obvious, but over time, you'll find that your organization will be communicating more quickly and with fewer misunderstandings.