Recommended resources
The freely available resources this lesson will direct you to.
Introduction
Welcome back! In our previous lesson, we focused on crafting concise written summaries of complex technical topics for non-technical audiences. You learned the "Inverted Pyramid" principle and the "Problem, Solution, Impact, Ask" framework to ensure your message lands with busy executives and product managers.
Today, we transition from the written word to real-time, verbal communication. Our goal is to equip you to explain a technical concept or blocker to a non-technical stakeholder using simplified language. This is a high-leverage skill that separates senior-level contributors from the rest. When you can calmly and clearly articulate a technical challenge in terms of business impact, you build trust, manage expectations, and empower leaders to make informed decisions—all critical functions on your path to becoming a Senior Developer and Digital Manager.
1. The Goal: Clarity Over Complexity
Before you even speak, the most important step is to set the right intention. Many developers, consciously or not, communicate in a way that aims to sound smart or technically proficient. This is counterproductive. As a leader, your true goal is to achieve clear understanding.
The video "How To Work With Non-Technical Stakeholders" by Tim Corey provides an excellent foundation for this mindset.
264. How To Work With Non-Technical Stakeholders
This video cuts to the core of why technical communication so often fails. It starts by addressing the single most important factor: your goal.
Please watch the first section, "Have the right goal". Pay close attention to how your underlying motivation—whether to sound smart or to ensure understanding—radically changes the words you choose.
When your goal is clear understanding, your entire approach shifts. You instinctively start to simplify, check for comprehension, and focus on the listener's needs rather than your own desire to convey technical nuance. This aligns with the "elephant and rider" concept from Stanford communication coach Matt Vassar. Your first job is to engage the listener's emotions (the "elephant") by explaining why this matters to them, before you attempt to inform their logic (the "rider") with the details.
2. Translating Technical Issues into Business Language
The key to engaging your stakeholder's "elephant" is to speak their language. They think in terms of customer satisfaction, revenue, risk, and deadlines. A technical problem is only relevant to them once it's translated into one of those categories.
Your role as the technical expert is to be the translator. The article "How to Effectively Communicate Quality to Stakeholders" offers a superb example of this translation process.
How to Effectively Communicate Quality to Stakeholders?
This article, while focused on "quality," provides a masterclass in translating technical jargon into business impact. This is the core skill for today's lesson.
Please read the section titled Technical Findings to Business Language. The example of reframing "race conditions against async statefulness" into "users may experience unexpected behaviour when making very fast inputs" is a perfect illustration of this principle.
Let's apply this to your technical stack. Imagine you're working on a Spring Boot backend and discover a significant source of technical debt.
- Bad (Technical Language): "We have a lot of tightly-coupled components in the user service, which violates SOLID principles and makes it hard to maintain."
- Good (Business Language): "The part of our system that handles user information is built like a tangled ball of wires. This means that making even small changes—like adding a new profile field—is slow and risky, and could break the login process. To move faster on future projects, we need to untangle it."

3. The Power of Analogy in Real-Time
In our last lesson, we saw how analogies clarify complex ideas in writing. Verbally, they are even more powerful because they create an instant mental picture. Your ability to create simple, relevant analogies on the fly is a superpower.
A great analogy is built on a concept your audience already understands intimately. The video from Jeff H Sipe provides a brilliant, detailed example of using an airport to explain cloud architecture.
How would you explain something technical to someone who is not technical? Q&A
This video demonstrates how to build a comprehensive analogy and then connect it directly to a stakeholder's specific concerns, making the abstract concept tangible and relevant.
First, watch the breakdown of the airport analogy, which maps technical components like storage and computing to familiar airport functions like luggage claim and air traffic control. Next, see how he connects these concepts to a marketing manager's goals, explaining how load balancing and auto-scaling directly contribute to the success of an ad campaign.
Let's build one for your world. Imagine you need to explain the concept of a message queue (like RabbitMQ or Kafka) in your Spring Boot application to a product manager.
"Think of our services as different departments in an office, like Sales and Accounting. Normally, if Sales needs a report from Accounting, they have to walk over, make the request, and wait for the accountant to finish. The Sales person is blocked. A message queue is like introducing a central mailroom. Now, Sales can just drop a request form in the mailroom and get back to their work. The mailroom guarantees the request will get to Accounting, and Accounting can process it when they have capacity. It makes our whole system more efficient and resilient because no single department is waiting on another."
This analogy works because it's anchored in a familiar real-world system (an office) and clearly illustrates the benefits (efficiency, resilience) without using a single technical term like "asynchronous," "decoupling," or "producer/consumer."
4. How to Explain a Blocker
Explaining a blocker is one of the most stressful but critical communication tasks you'll face. A blocker is essentially a risk that has come to pass. Your goal is not to deflect blame but to create clarity, manage expectations, and drive a decision.

When a blocker arises, non-technical stakeholders have three questions:
- What's the impact on what I care about (the deadline, the budget, the customer)?
- Why did this happen (in simple terms)?
- What's the plan?
A simple, effective structure for answering these questions is Impact, Analogy, Plan & Ask.
-
Impact First: Start with the bottom line. Don't bury the lead.
- Example: "Quick update: The launch of the new payment feature is blocked. If we don't resolve this by end-of-day, our go-live will be pushed back by at least one day."
-
Explain with an Analogy: Briefly explain the root cause using a simple, non-technical metaphor.
- Example: "The issue is with our payment provider's system. They just changed their locks, and the key we were using no longer works. We need to build them a new key that fits their new system."
-
Present the Plan & Ask: Outline the concrete next steps and state what you need from the stakeholder.
- Example: "I'm already working on the fix. I've carved out the next four hours to focus on it. To ensure I'm not interrupted, could you let the team know I'll be unavailable until this afternoon? I will give you another update at 3 PM."
This approach immediately addresses the stakeholder's primary concerns, provides a simple-to-understand reason, and shows that you are in control of the situation. It transforms a moment of panic into a moment of professional problem-solving.
Practical Application: Scripting a Blocker Explanation
It's time to put this framework into practice. Consider the following scenario:
You are working on a new feature in your React application that uses a third-party library for data visualization. You've discovered a significant memory leak in the library. When a user keeps the page open for more than a few minutes, the app becomes sluggish and eventually crashes. Replacing the library will take a full day of work, which will push the delivery of the feature past this week's deadline.
Your task is to write a short script (5-7 sentences) for how you would verbally explain this blocker to your non-technical Product Manager during your daily stand-up meeting.
Use the Impact, Analogy, Plan & Ask framework. Your goal is to clearly communicate the problem and its consequences while maintaining your manager's confidence in your ability to handle it.
Conclusion
In this lesson, you've learned how to translate complex technical concepts and blockers into clear, simplified language for non-technical stakeholders. This skill is not about "dumbing down" information; it's a sophisticated form of communication that builds trust and establishes you as a leader.
Key Takeaways:
- Your Goal is Clarity: Shift your mindset from sounding smart to ensuring the other person truly understands.
- Translate to Business Impact: Connect every technical issue to what the stakeholder cares about: customers, revenue, risk, and timelines.
- Master the Analogy: Use familiar, real-world concepts to explain technical mechanisms. The airport and mailroom are now part of your toolkit.
- Explain Blockers with "Impact, Analogy, Plan & Ask": This structure addresses a stakeholder's key concerns head-on, turning a crisis into a managed process.
In our next lesson, we will continue building your verbal communication skills by focusing on the STAR method. You'll learn how to apply it to structure compelling stories about your past projects and accomplishments, a vital skill for interviews, performance reviews, and demonstrating your impact.