Tips for developers on improving collaboration with domain experts

A domain expert isn’t just anybody who can do the job that you need to know more about. A domain expert have thought so much about it, have so much experience and have created an understanding on 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, it’s been a common comment from developers over the years that they are not able to get any time and attention from their domain experts. When hearing that, I suspect two different reasons. It might be that the domain expert doesn’t think that the initiative you are working on is important. If that’s the case, run away. There is little chance of success then 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 comment, but I got your attention, didn’t I? And I’m looking at myself as much as anybody else. I’ve done it, I’ve been so boooring. Going into the room of the domain expert 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 error we do.

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

So let’s just assume it’s your fault that the domain expert is a bit hesitant to your collaboration, what can you do about it? Here are 15 tips. (As a matter of fact, most of the tips are generic, you can use them in every day life, but I’ve especially used them 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 an as obvious tips 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 therefore should only be used for good.

2 - Really understand why

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

If you notice that you’re whys aren’t received well by the domain expert, 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 couple of 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 other people know 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 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 fit 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, but it’s actually a generic sub-domain, 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 questions about the basics over and over again. 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 are 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. It also 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, 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 in the comments the following great tips:

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 posting the tips three att a time on LinkedIn, I got a lot of good suggestions for books I should read. Those are still on my TOOD list, but I'm quite sure I will have more tips to share later on. But 15 (or 17?) will have to do for today! Oh, and please don't hesitate to ping me with more ideas!