Communication Techniques

How can we better communicate technical knowledge to peers and stakeholders that doesn’t relate to code?

I think by demonstrating and walking them through the knowledge is a good way, not only for you to solidify what you know (by teaching them) but by showing them they are more likely to take it in and actually appreciate it all.

1 Like

I find it helps to convey technical information by explaining it terms that are universal and using those terms in a practical way while using a relatable example. If the person can visualize what you’re saying to a situation that they know and can relate to then it creates the context and empathy needed to gain understanding.

1 Like

My biggest surprise was, that we don’t listen enough to each other. We talk, but we don’t listen. I don’t use techniques like NLP or sth. like that, but every book, report, whatever I read was about how to listen to other people. The biggest difficulty for the speaker ist, to speak in the listeners language. That’s from the NLP, okay. My methodology is quite simple: I explain my wife, what I’m going to explain the next day to the customers or users. She is not in the IT-business and far away from technical stuff. But if she can understand my explanations, the other will too. In contrast, she explains me the German tax system… :wink:

3 Likes

Are we assuming that those peers and stakeholders really want to learn it? Because nobody learns things they don’t want to.

1 Like

I guess it depends what technical knowledge it is that you’re conveying? I try to talk in terms of what it means to the business or the product/project, as most of the time they don’t want or need to know the tech details. If they do, then we can gauge how much they know and go from there.

1 Like

This was rattling around my brain yesterday. I always struggled a bit on this front, so did some reading. Learnt about cognitive bias and the way the brain works and all that jazz. Basically, I learnt to break stuff down into stories - often from the end user perspective. So I would explain how X would impact Y because of Z and if we were to change X, we’d also have to change P because of those edge cases. Removing the dev speak and breaking it down into functionality where possible. Most folks understand impact etc. Don’t know if that helps, but it used to work for me.

1 Like