How to Communicate Technical Issue to Non-Technical Stakeholders (from a PM who learned the hard way)

Jessica Ryder, SealingTech PM became an expert in translating technical complexity into something stakeholders could understand and act on—ultimately affecting the success of her customer’s mission.

As a Program Manager (PM) in Cybersecurity, I’ll be the first to admit it, I did not come into program management with a technical background. Early on, I could run a meeting, build a plan, and keep things organized, but the second an engineer started talking about application programming interfaces (APIs), living off the land (LotL) techniques, or latency issues . . . I was mentally buffering. Over time, though, I learned how to translate technical complexity into something stakeholders could actually understand, and more importantly, act on. Not because I suddenly became deeply technical, but because I figured out how to communicate in a way that worked for me while I was learning. 

Lead with the Impact 

When technical teams explain issues, they often start with what’s happening. Stakeholders, on the other hand, care about why it matters. Early in my career, I would try to relay everything I heard, repeating highly technical explanations that didn’t land. It didn’t take long to realize this approach wasn’t effective. Now, I focus on framing the issue first in terms of mission impact. Instead of leading with technical jargon, I explain how the issue affects performance, timelines, or the user experience. Once stakeholders understand why it matters, they are much more open to hearing the supporting details if needed. That shift alone made my communication significantly more effective. 

Be a Clear and Effective Communicator 

One of the biggest mistakes I made early on was acting like a middleman instead of a translator. I would take what engineers said and repeat it almost word-for-word, assuming accuracy meant effectiveness. In reality, it just created confusion. So, I started asking myself what the clearest, most straightforward way to explain the issue would be. I also thought back to what would have helped me understand the same concept when I was less familiar with the technical side. If something still didn’t make sense, I got more comfortable asking follow-up questions, even if they felt basic. That process improved my communication and accelerated my own learning. 

It’s good to remember too that not every conversation requires a deep technical breakdown. Some stakeholders are primarily focused on understanding the issue, its impact, and the plan to resolve it. Others may want to go further into the technical details. Learning to read the room has been an important skill to develop. Simply giving stakeholders the option to go deeper keeps communication efficient while still being responsive to their needs. 

At the end of the day, clear communication of technical issues isn’t just a “nice to have;” it directly impacts the success of the mission. When stakeholders truly understand what’s happening, why it matters, and what the path forward looks like, decisions get made faster and teams stay aligned. Miscommunication or overcomplication, on the other hand, can slow everything down, introduce unnecessary confusion, and ultimately put mission outcomes at risk. 

Know When to Bring in an Expert 

Lean on your technical leads (seriously). I wouldn’t have gotten comfortable with any of this without the people who took the time to explain things to me early on. My previous technical leads played a huge role in helping me build that initial foundation. They answered my questions, broke down complex topics, and created an environment where it was okay not to know everything right away. I also rely heavily on my current Technical Lead, Josh Kehm, who I consider my right hand. He’s the person I turn to for deeper dives when my base knowledge isn’t enough. Having that kind of partnership has been invaluable. Knowing when to bring in the right expertise is just as important as understanding the basics yourself. 

Be Honest About What You Don’t Know 

This was something I had to learn over time. There’s often a temptation to sound more technical than you are, especially in environments where technical knowledge is highly valued. I’ve found that approach usually creates more problems than it solves. Being transparent about your level of understanding builds trust and keeps communication accurate. When needed, I frame my input as my current understanding and loop in the technical team to validate or expand. That approach strengthens credibility and creates more productive conversations.  

Final Thoughts: Know Your Strengths 

Being a strong Program Manager isn’t about being the most technical person in the room. It’s about connecting the dots, communicating clearly, and making sure everyone involved understands what matters and why. This enables leadership to make informed decisions and keeps the program and mission moving forward with purpose. For me, that meant building enough technical knowledge to translate effectively while relying on the expertise of others for deeper insights. Learning how to communicate this way wasn’t just about getting better at my job, it was about making sure I was contributing meaningfully to the mission and helping the entire team succeed. It’s always good to know your strengths . . . and your weaknesses. 

And if you’re still figuring it out, you’re probably doing it right.