DEV Community

Cover image for A technical leadership lesson from interacting with folks outside of engineering

A technical leadership lesson from interacting with folks outside of engineering

Learning from my elders and sharing my own experiences. Won't stay quiet. Views are mine.
・2 min read

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:

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.

Discussion (2)

steelwolf180 profile image
Max Ong Zong Bao • Edited

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.