At work, I have the privilege of interacting with folks from other (non-engineering) teams often. I really enjoy this part of the job! I studied computer science in college and have worked as an engineer since so being in a role that gives me visibility into other roles is refreshing. I see every interaction with someone new as a chance to learn something and perhaps build together? π
So when I came across this blog post I was immediately intrigued:
Daniele Bernardi on Working with Non-Technical People and Getting Recognition Right
Sam Jarman π¨πΌβπ» γ» Mar 5 '19
This quote resonated with me:
"I'm not afraid to say I struggled with this aspect at the beginning of my career. I thought technical leadership would simply mean displaying your knowledge by painstakingly listing all the details in a project, but I soon found out that aspect is actually perceived as overzealous. Technical leadership is really about using your best judgement to condense the most difficult aspects into a straightforward statement; it also means hiding details you know don't require broad consensus among the key stakeholders of your project."
I recently created a document whose primary audience are not engineers. I was proud of having started the conversation that led to this very document being written. I truly believed this document was taking my team one step forward on the road to success. So, I included several hundred pages of sample records which took many evenings during off-hours to put together. I wanted to be as precise as possible and I felt good about my effort right up until I received feedback from the other team. They had removed the sample records because it didn't add to the discussion.
I realize I did not practice enough self-awareness when writing this document. Yes, I was concerned with how the readers would perceive me and my knowledge but now I see that I was more concerned with proving I knew what I was talking about. I missed the point.
The blog post I reference above is not the first time I hear about the delivery of simplified messages as a key aspect of technical leadership. Other people I look up to and respect have shared this with me. This is, however, the first time that it really hit home for me as I reflected on this experience with another team outside engineering. So I will be mulling over this lesson, practicing empathy in future interactions, and actively seeking feedback.
I am curious on your thoughts! Please send me a message or comment below.
P.S. I hate referring to folks as "non-technical" but I couldn't help how someone else titled their blog post. April Wensel explains some of the issues I have with the term on her blog.
Top comments (1)
I think it is fine and reduce the techno babble to just simplified easy to understand words that exist in real world to make it easy.
Think that your a teacher who is teaching a bunch of ppl.
Who doesn't know anything on what you do,so you are there to educate them.