Back to blog

How to communicate with non technical stakeholders

Communicating with non-technical stakeholders is a crucial skill for any software engineer. Whether you’re presenting a project update, explaining a technical challenge, or gathering requirements, bridging the gap between technical and non-technical audiences ensures everyone is aligned and projects move forward smoothly which is still a skill that I'm currently practicing and refining.

Understand Your Audience

Before getting into specifics, assess your audience’s technical background. Are they comfortable with technical terms, or do they prefer plain language? Adjust your explanations and examples accordingly. For instance, you might use more detailed technical references with a line manager who has a tech background, but opt for simple analogies and everyday language when speaking with analysts or editors who have limited technical experience.

Visual Aids Go a Long Way

Visual aids are invaluable for simplifying complex concepts. Tools like Excalidraw, Mermaid, draw.io, and Lucidchart make it easy to create quick sketches or structured diagrams, whether you’re drawing live during a meeting or embedding visuals in documentation. Diagrams, flowcharts, and simple illustrations can bridge understanding gaps and ensure everyone is aligned. A key lesson from my master’s thesis: if a diagram can’t stand on its own without explanation, it needs improvement. Well-designed visuals—such as a pipeline diagram for CI/CD—often communicate ideas more effectively than words alone.

Use Analogies and Stories

I remember interviewing with an international bank’s backend team, where I was asked, “How would you explain SQL queries and SQL to non-technical people?” At another company, the question was, “How would you explain an index in SQL?” In both cases, I used familiar tools like Excel to draw analogies—comparing SQL queries to filtering rows in a spreadsheet, and indexes to the way Excel quickly finds data in a sorted column. These relatable examples helped clarify the concepts, and I received positive feedback from both interviewers.

Avoid Jargon, or Explain It

Technical terms can be confusing. If you must use them, pause to explain. For instance, instead of saying “latency,” say “the delay between sending a request and getting a response.” This ensures everyone is on the same page.

Encourage Questions and Feedback

Foster an environment where stakeholders feel comfortable asking questions by making it clear that every question is welcome and valued. This not only builds trust but also encourages active participation and collaboration. If the group is quiet, proactively invite questions or prompt discussion to ensure everyone is following along. This aligns with the "1 question" step of the "3-2-1 method" recommended by Codie Sanchez. For more details on the full method, see Stop Rambling: The 3-2-1 Speaking Trick That Makes You Sound Like A CEO.

Recap and Confirm Understanding

At the end of your discussion, summarize the main points in simple terms. Ask stakeholders to repeat back their understanding or share their thoughts. This helps catch any miscommunications early.

TL;DR on how to communicate with non-technical stakeholders

  • Know your audience’s technical level
  • Leverage visuals
  • Use analogies and relatable stories
  • Minimize jargon, or explain it clearly
  • Encourage open dialogue
  • Confirm understanding

By applying these strategies, inspired by experienced engineers and communicators, you’ll ensure your message resonates with all stakeholders—technical or not.

This blog was inspired by after watching the Youtube Video of an ex-Amazon Principal Software Engineer (Steve Huynh) - The Easy Way To Be Seen As A High-Performer by A Life Engineered and Stop Rambling: The 3-2-1 Speaking Trick That Makes You Sound Like A CEO.