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.
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.
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âŚ
Are we assuming that those peers and stakeholders really want to learn it? Because nobody learns things they donât want to.
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.
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.