Tips for developers on improving collaboration with domain experts

A domain expert isn’t just anybody who can do the job you need to know more about. A domain expert has thought so much about it, has so much experience, and has developed an understanding at a meta level. A domain expert can even think about how a machine should work to do the job (as Dan Bergh Johnsson puts it).

So they are rare, and when we find one, our success depends on our collaboration.

Yet over the years, I've often heard developers say that they can't get any time or attention from their domain experts. When I hear that, I suspect two different reasons. It might be that the domain expert doesn’t think the initiative you're working on is important. If that’s the case, run away. There's little chance of success, and why would you or the company spend development effort on something that isn’t important?

The more probable reason, though, is that you are... boring. I know, that was a very blunt, but I got your attention, didn’t I? And I’m looking at myself as much as anyone else. I’ve done it, I’ve been so boooring. Going into a domain expert's room and saying things like repository, higher-order function, and closure of operations… They tune out after the first word when we only speak geek. And that’s just one of the errors we make.

Anyway, the moment we realise that a problem is our fault is the moment we start solving it. As the saying goes, it’s enormously easier to change yourself than to change someone else! I always feel happy when I realise it’s my fault. Then I’m in control and in charge. Things can start rolling!

So let’s just assume it’s your fault that the domain expert is a bit hesitant about collaborating. What can you do about it? Over a series of LinkedIn posts – and with a lot of great input from the community along the way – I collected 15 tips. (As a matter of fact, most of them are generic and can be used in everyday life, but I’ve especially put them to use in software development situations.)

Here goes…

1 - Develop a shared language

If I had a Euro for every time I’ve heard someone describe a problematic situation with “we don’t speak the same language”, I’d be rich by now. :) It’s annoyingly common and often true. If only there were a solution to this problem!

If you’ve come across DDD, you’re probably familiar with the concept of “ubiquitous language”. Trying to apply it together with your domain expert is as obvious a tip as it is helpful. I wrote a bit about the power of sharing a language in an old post. It’s still a good reminder to myself that the power is almost scary, and should therefore only be used for good.

2 - Really understand why

Understanding the domain expert is absolutely crucial since without first understanding, it won't be possible to collaboratively develop the new thinking that is needed. To understand, it’s not enough to listen and capture; you need to really get why. That said, there's a risk of overusing that word in conversations, and when that happens it can start to feel almost like an attack.

If you notice you’re whys aren’t received well, try switching tactics. Instead of just asking why, try describing your current understanding, preferably using a concrete example. This often changes the dynamics in the room!

If you didn’t understand because you were talking past each other, now there’s something to gather around. Your description will almost certainly contain a few errors, but that’s actually a good thing. It makes misunderstandings visible and helps the domain expert see exactly where clarification is needed and what to focus on next.

3 - Ask the “stupid” questions

Let go of your pride and ask the questions you’re afraid will sound really stupid. Showing that kind of vulnerability can be very effective for changing the atmosphere in tense situations. More often than not, it also helps someone else in the room get a new idea. And it might not be a stupid question at all, that’s impossible to know beforehand.

What often stops us from using this tool is the fear of letting others see that we don’t get it yet. But you should optimise for understanding, not for looking smart or seeming like you already know everything.

Goldratt says it well in The Choice: “We need humble arrogance. Be humble to assume that one doesn't know. Be arrogant – have the confidence that one is capable of figuring it out.”

Pippi Longstocking says something along the lines of “I’ve never tried that before, so I’m probably very good at it”, but that might be taking it a step too far.

4 – Use different model presentations

You’re trying to create a shared mental model together, and different ways of doing this will suit different domain experts more or less well. It’s also highly contextual.

Sometimes it helps to sketch on a whiteboard. Sometimes it’s enough to talk and really play with the words, evolving the ubiquitous language together. Sometimes writing text together works best, or sketching a user interface. And don’t forget code, it can work like a charm too.

Another powerful shift is to move back and forth between looking at the big picture and diving into the details. It’s also helpful to alternate between abstract models and concrete examples.

It’s not just about finding the right tool for a specific domain expert. It’s about viewing the concept you’re working on from multiple angles. When you get stuck in one, switch to another.

5 – Understand the core objectives of the business

The sub-domain you are working on together with the domain expert doesn’t exist in isolation. Make sure you understand how it fits into the broader business strategy of the company, and how it connects to its core objectives. If you, for example, believe you’re working in the core sub-domain when it’s actually a generic one, misunderstandings are bound to happen.

6 – Read up on the basics

Earlier, I recommended asking “stupid” questions – and I still stand by that. But be mindful not to exhaust domain experts with repeated questions about the basics. Doing some reading before and between conversations will definitely be helpful, and it’s also a matter of respecting their time.

If the domain expert notices that you are making a real effort, they're more likely to meet you halfway.

A good starting point is to ask what book students would be given in an introductory course on the subject. Or maybe there are lectures, talks, or other resources that would suit your way of learning better?

It is worth remembering that in most cases you do not need to become a domain expert – you just need to be able to understand one.

4-6 are inspired by Tobias Fors, Nyari Samushonga, Patrik Fredriksson and Gregory Young.

7 – Say thanks and mean it

Of course you say thank you when someone helps you. We all do. Still, it’s worth being very explicit about.

Saying thanks is about respecting someone’s time. It’s about showing appreciation for their work, their expertise, and the insights they share. If a domain expert takes time out of what was supposed to be spent on something else to help you understand a tricky concept – and doesn’t even get a thank you in return – that doesn’t exactly set things up nicely for the next session (if there will even be one).

Also, be explicit internally in the organisation about who has helped you with what. That’s not just nice, it helps others in the organisation understand who is worth turning to for help.

7 is inspired by Katharina Damschen.

8 – Act like a mirror

A simple communication technique that can be very powerful in certain situations is to act like a mirror. When a domain expert explains something important and complicated to you, try repeating it back to them in your own words, based on how you understood it.

First of all, it’s a good way for you to deepen your understanding and gives you a chance to validate that you actually got it right. At the same time, the domain expert feels heard, which in itself has positive effects, both in the moment and over time.

Finally, for those of us who have that lovely, automatic impulse to jump straight to problem-solving, this tip will help you pause that default behaviour for a moment. Sometimes the most helpful thing you can do is to stay with them for a bit longer, rather than rushing back to you and your ideas!

I suspect this tip may be as challenging for some you as it’s been for me. I still struggle with this, very often. But trust me, it can be extremely helpful!!!

8 is inspired by Lotta Nilsson

9 – Talk in four dimensions

Another communication technique I find very useful is to talk in four dimensions by explicitly describing:

1. what you observe
2. what you think
3. how that makes you feel
4. what you want

This creates a much richer picture for the person listening, and is typically received quite well.

It’s especially powerful in situations where simply describing what you observe tends to create friction, for example, when the receiver experiences it as an attack.

Even though I’ve known about this approach for a long time, and used it with good effect on many occasions, it still doesn’t come naturally to me. The good news is that if a conversation didn’t go well the first time, you can usually go back and ask for a new try. You don’t just get one chance; try again, but change something.

You can read more about this in the book Clear Leadership by Gervase Bushe.

10 – Make it a dialogue

It’s good to act a bit like a crocodile: small mouth, big ears. But it’s a misunderstanding to think that your job is simply to listen to the domain expert and capture everything they say.

A good conversation isn’t just one-way. For it to be useful, it needs to be a dialogue. For example, your experiences from other domains and situations are often highly interesting to the domain expert (when shared at the right moment) and can help them rethink aspects of their own domain.

If you started out knowing exactly the same things as the domain expert, the collaboration would be pretty useless. Celebrate your differences and be generous about sharing them.

Also, listen to what is said between the lines. If the domain expert doesn’t understand something when you try to explain it, that’s a strong signal that you might have misunderstood. And that’s actually a very good thing. Lack of understanding is an invitation to dig deeper – and might be the start of a real breakthrough!

11 – Create a sense of belonging

Wanting to belong is a deeply human thing, and it applies to both you and the domain expert. So, it’s worth considering how you can create that sense of belonging together.

Try not to see your conversations as transactions. Think of them as the start of a relationship instead. It might seem like you don’t have much in common at first, but in my experience, it often turns into something surprisingly fun and meaningful over time!

This tip is actually quite simple: treat the domain expert like a human. Talk about other things now and then, share a bit about yourself, listen carefully even when it’s not about the domain, grab lunch or have a coffee together. Nothing fancy, just normal, human stuff!

12 – Check alignment

When you start working with someone new, take a moment early on to understand their goals and values. If you’re aligned, there’s usually a solid foundation for trust. If you're not, that's genuinely useful to know early.

The mistake I keep making is assuming everyone shares the same outlook as me and is naturally pulling in the same direction. But people come with different backgrounds, priorities and ideas of what “better” looks like.

A good starting point is to identify one shared outcome you can both agree on, something concrete and simple. Something you both find valuable, even if you don’t share all the same values. Start the session with the mindset “we all want to make things better”.

11 and 12 are inspired by Suzi Edwards-Alexander.

13 – Create the situation

Kenny Baas Schwegler wrote a post about that the situation might not be optimal for a group to come up with the best ideas. Rank, experience, reputation, personality, etc lead to a dynamic that always favors the same few people. The best ideas might not even have been articulated...

This probably needs a book on its own, but I know that Cecilia Hilton would suggest the two first here:

• Agree on some basic rules to make sure everybody is heard and everybody listens. For example, that everybody has one minute to speak about the topic. Then everybody speaks another minute about what they think and feel after having heard the others.
• Use retrospectives (including the domain experts) for improving psychological safety. It’s amazingly powerful if done in a good way. (Weird, I first wrote “psychedelic safety”, wonder what that means…)
• Celebrate new mistakes. And if old mistakes are causing problems, the fault and action is on the organisation for not having created guardrails. Since they have happened, they are proven to be possible and even likely. Even domain experts are allowed to make mistakes. :)
• Be kind!

14 – Language as an icebreaker

Writing scenarios in the style of Behavior-Driven Development (BDD) (created by Daniel Terhorst-North) definitely have large value in itself as documentation and as automatic tests. But the biggest value as I see it is in the discussion between domain experts and developers.

It can be a powerful icebreaker. You write three words on the whiteboard, and then somebody says that “we actually don’t call them customers, rather…”. The person asks for the pen and continues writing. The discussion is started and work of evolving the ubiquitous language is on.

Don’t take my word for it, it must be experienced!

15 – No derogatory thoughts

Your mindset should always be curiosity and a genuine desire to learn, not letting thoughts like “that seems stupid” through. Goldratt gives clear advice on this in “The Choice”: beware of derogatory thoughts. It’s a trap, a really bad one! Your thinking will create the situation you were thinking about. If you are aware that derogatory thoughts are a trap, it gets easier to recognise them and see them as what they are: just a stupid thought on my part.

Why it works to have a curious mindset, I think it’s because when you continue investigating what seems stupid, you reach understanding and understanding is the cure! A lack of understanding, well then most things seems stupid.

Related to this, Suzi Edwards-Alexander mentioned “fundamental attribution error”. The solution is to focus on the behaviour, not the person. I guess this is useful for tips 13 as well.

Bonus

Dan North mentioned the following great tips in the comments, when I shared these tips on LinkedIn:

For 14 – Language as an icebreaker, two concrete examples I've experienced:

1. Event Storming as an interactive, high-energy form of value-stream mapping, leads to some great conversations around process, domain concepts, what goes where, who owns what, etc.
2. DDD in the code, where a domain SME can be helping developers because the code literally says what the domain does.

When I posted these tips three at a time on LinkedIn, I got a lot of good book suggestions. Those are still on my TODO list, but I'm quite sure I'll have more tips to share further down the line. For now, 15 (or 17?) will have to do. Oh, and please don't hesitate to ping me with more ideas!