Domain-Driven Design: focus on collaboration - a ubiquitous language will follow

A shared mental model and a common language can make a team more productive. But what if your team lacks both? How can you help your team to start the journey towards a shared mental model?

First steps

Building a common language with your team might sound like a daunting task. I mean: where would you even start?

Well, let me tell you about the techniques I tried just after I learned about Domain-Driven Design. To me these techniques felt like obvious, straightforward and natural first steps. But I was in for a surprise. None of them had the desired effects. In fact, most of them turned out to be detrimental to my goals.

Interestingly enough though, I wasn’t the only one who thought these techniques might work. I’ve observed others trying the same thing. They weren’t successful either.

So let me save you some time and effort by sharing with you three techniques that (probably) won’t work:

  • A glossary: Creating a glossary for your team feels like the obvious way to establish a common language. Unfortunately, no one is ever going to read it. You don’t believe me? Then tell me this: when was the last time you read the entire content of a glossary? Exactly. Glossaries are great for looking up a term you don’t know, but they are not great for learning an entire set of vocabulary.

  • Documentation: I’ve seen people pour all their energy into writing a long document, carefully explaining all of the terminology that might be relevant to you, perhaps even attaching UML diagrams. Despite the author’s best efforts, these documents tend to be difficult to comprehend. As a result, most people won’t derive good value for the time they have spent reading.

  • Code reviews: If your team adopted a code review process (e.g. pull request reviews), you might think of it as a good place to point out all the incorrectly used terminology. This behaviour is often perceived as nitpicking and can easily lead to resentment.

Typically, all these techniques are pursued by a single individual with good intentions. But good intentions won’t always translate into good results. Oftentimes, the rest of the team is not willing to take on the additional work, seing no or little value in it. And so the goal of establishing a common language is soon abandonded again.

A better approach

I was still iterating my way through different techniques, when I realized something: human beings already have a powerful method of arriving at a shared vocabulary. It is one we practice all the time.

Every time a group of people comes together, they start mirroring each other’s behaviour to some extend. We don’t just pick up behaviour though. We also pick up the words and phrases others use. Even better: we do this unconsciously and therefore seemingly without effort.

The more time a group of people spends together, the more they will align their terminology (which is exactly how a specialized jargon forms in each profession).

If this is the case, however, how come your team still doesn’t speak a common language?

I’d like to argue that the reason is a lack of collaboration in your team. In fact, you might not even have a team. It’s more likely that you’ve got a collection of individuals who mostly work for themselves.

If you paid close attention to the way your team members interact with each other, I bet you would see a direct correlation to how aligned their language is.

I would, for example, expect a company with a strong split between developers and product managers to show a noticeable difference in the terminology between these two groups.

This means that a team doesn’t arrive at a common language because of any particular action you take. Instead, a common language is the result of working in a particular way.

Don’t try to align the language everyone speaks and hope it will get people to collaborate. Make sure people work together well (not an easy job of course) and their language will align automatically.

Don’t turn this relationship upside down. I’ve tried that. It doesn’t work.

Putting collaboration first

I suppose, asking everyone to please stick to the terms listed on a glossary is a way to get people to work together more. But it’s definitely not the most effective technique to help collaboration.

There are far better ones. Here’s a list of techniques that I have seen work really well in the teams I was a part of (but of course there are many more):

Each of these techniques will bring your entire team together and create plenty of opportunities for collaborative problem solving. As your team members spend more time together, their language will align almost automatically. And together with that comes a shared mental model.

Which of these techniques will work best depends on your team’s unique situation. Unfortunately, there are no clear-cut answers or off-the-shelve solutions that will work for everybody.

You’ll need an open mind and a willingness to experiment, to try out new ways of working, to find out what is working and what isn’t, and to adjust accordingly.

But these things take time. Teams can only run so many experiments in parallel. What’s more, getting good at any new technique requires practice and learning. These things can’t be rushed.

Lastly, all of these techniques require everyone’s participation. Although you’ll need an individual to step forward, to model good behaviour and to educate the team about why a shared mental model is important, you won’t be successful unless everyone is willing to make it work.

It should be obvious now that establishing a common language in a team is no easy task, but the promise of Domain-Driven Design is that all the effort will be worth it. I’ve personally witnessed the profound results of collaborative problem solving and would thus recommend you give it a try too.

In the next article we’re going to see how far you can take the idea of a ubiquitous language.