DEV Community

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

Posted on

2

A technical leadership lesson from interacting with folks outside of engineering

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.

Image of Docusign

Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more

Top comments (1)

Collapse
 
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.

A Workflow Copilot. Tailored to You.

Pieces.app image

Our desktop app, with its intelligent copilot, streamlines coding by generating snippets, extracting code from screenshots, and accelerating problem-solving.

Read the docs