As a software engineer you almost never work on topics that you are an expert in. Sure you understand how to design a system, how to fix a bug or how to improve the performance of it. But often your business has quite special needs, be it in advertisement, logistics or legal topics. We work together with many experts who usually built a great intuition to fill the gap. If this works well you learn to rely on them and in the best case you develop a really great working mode. You might not really learn to appreciate this unless you experienced what happens when this does not work well.

A situation that I encountered many times is that during development we interact with experts, everyone has a great feeling and is happy about the progress. But when it gets serious and we are closing in on a GoLive, then all of a sudden details pop up. We can handle these but it always introduced additional stress that you really don’t want before a GoLive. There is enough to do during that period. While trying to understand why this happens we found one common pattern: The interaction with the experts went too smoothly. They introduced the topic, we implemented a solution, they checked it and were happy. Where I work we often trust our team leads with a lot and they are all really great in what they do. This often also reflects in their confidence which might sometimes result in accepting a simple: “I checked everything you sent and it looks good” from an expert as validation of their good work. But sadly that’s usually not enough.

In essence: You get real value out of your interactions by making the other party think. It is often easy to present something that is seemingly right and get your “yes” in return.

How to build proper understanding #

The most important thing is to activate everyone involved before you build someting. Building some piece of software without understanding it properly and then fixing things after you receive feedback is broken by design. I advocate for the following approach, when you are introduced to a new topic:

1. Don’t mix topics. Take time for each separate topic. Don’t accept long monologues for the entire feature.
2. Avoid pretty prepared presentations. They create distance and discourage conversations. If someone wants to give them as a handout, fine.
3. Don’t copy their wording. Repeat what experts say in your words, write it down, they correct you.
4. Don’t copy their structure. It probably makes sense. You should still go by your intuition and run into dead ends to understand why things matter.
5. Explain your ideas on how to implement the topic. Reverse sides so that experts try to understand what you want to build. Encourage them to ask questions.
6. And the classic: Ask open ended questions, to get more out of them like: “What do you think will be the most challenging part?”

In my daily work we often strive to remove friction, become more efficient and make processes streamlined. In communication however I would be quite careful. Meetings often feel meaningless, not fruitful etc.. but this is also due to the nature of how most meetings are designed. People often do not listen until it is the one topic they want to clarify. That is also why workshops often can do magic. People swear on specific methodologies, but the important part is to force everyone to actively process the topics. It usually takes a bit of time and friction to activate all the knowledge in everyone.

Remember the three O’s #

Speaking of methodology. I would summarize the approach with the three O’s:

1. Own the wording
   Phrase everything important in your own way, but do it with intention. Don’t just echo what the other person said. Boil it down to the essence, add details you think matter, and when discussing topics throw in a metaphor both sides can relate to and which is bold – gives some “attack surface”. Friction points are good: if they disagree, they will correct you, and that’s where you get the important information.
   Example: “So this is like a train station: Limited slots for trains, if all are occupied you have to wait?”

2. Own the flow
   Take time for each step. Do not try to capture a 30 minute description of a system in one go. Sometimes the other side gives you the full story with all the nuances, other times they’ll skip the tricky parts. Your job is to structure it: pause, ask, rephrase, and write it down in a way everyone can see and correct. Make sure that it makes sense to you.
   Example: “The user starts in this screen, they enter details, validation feedback is immediately displayed in the sidebar, process is not critical timing wise. Anything missing before we move on?”

3. Own together
   Make the other side invested. Redefine the task as a shared goal and give them a visible role in success. It’s easier when you are in person, but the principle is the same: don’t let it stay your work and their review.
   Example: “Could you check the performance in the old system so we know what to compare against?”

Own the wording, own the flow, and own together: that’s how you build understanding and shared responsibility.