Explaining Tech to Anyone

Introduction

In our last lesson, we mastered the art of writing a high-context pull request description, a crucial skill for communicating effectively with your fellow engineers. We focused on providing the necessary business context, technical approach, and testing instructions to make the review process smooth and efficient.

Today, we shift our audience. Instead of writing for technical peers, we will focus on communicating with non-technical stakeholders—executives, product managers, and colleagues from other departments. The learning outcome for this lesson is to write a concise technical summary of a complex concept for a non-technical audience. This skill is a hallmark of a senior engineer and is fundamental to your goal of becoming a digital manager. It's about translating technical complexity into business impact, enabling you to influence decisions, advocate for important initiatives, and demonstrate your value beyond just writing code.

1. The Three-Audience Problem

A common mistake engineers make is writing one document and expecting everyone to read it the same way. In reality, your technical proposals have at least three distinct audiences, each with different needs and reading habits. Understanding this is the first step to effective communication.

The article "Writing Technical Documents That Non-Technical People..." provides a brilliant framework for this.

The key takeaway is that you must front-load the conclusion. Non-technical stakeholders, especially executives, want the "so what?" immediately. They don't have time to wade through pages of background and technical detail to find your recommendation. By putting the most important information first, you ensure your message is received, even if they only read the first paragraph.

2. The Anatomy of an Executive Summary

The primary tool for communicating a complex idea to a non-technical audience is the executive summary. This is a short, standalone document (or the first section of a longer one) that boils your proposal down to its essential business case.

This video from High-Value Writing offers a quick, practical overview of the purpose and structure of an executive summary.

While several structures exist, the most effective one for technical proposals is focused on business outcomes. The "Writing Technical Documents..." article provides a powerful four-part structure: Problem, Solution, Impact, and Ask.

Let's break this down:

• Problem: State the business pain point in quantifiable terms. Instead of "the API is slow," use "Customers are abandoning their carts 15% of the time due to checkout page latency, costing us an estimated $50k per month."
• Solution: Describe your proposed fix in high-level, non-technical terms. Focus on the what, not the how. "We will rebuild the checkout service to be faster and more reliable." not "We will refactor the monolithic checkout service into event-driven microservices using Kafka and Spring Boot."
• Impact: Explain the expected positive business outcome, again in quantifiable terms. "This will reduce page load times by 80% and is projected to cut cart abandonment in half, increasing revenue by $25k per month."
• Ask: State clearly what you need to proceed. "We are asking for two engineers to be allocated for three weeks to complete this work."

This structure forces you to connect your technical work directly to business value, which is precisely what decision-makers need to see.

3. The Art of Simplification: Killing Jargon with Analogies

The language you use is just as important as the structure. The goal is to be understood by someone with zero technical knowledge. This means ruthlessly eliminating jargon and using analogies to bridge the gap.

The video "Explaining Technical Information to Non-Technical People" provides excellent strategies for this, even though it focuses on verbal communication.

When you write your summary, actively look for technical terms and replace them.

• Instead of: "We need to refactor the monolith to a microservices architecture."
• Try: "We need to break our large, single application into smaller, independent services. This is like turning a single large department into several specialized teams; if one team gets busy, it won't slow down the others."

Given your background in Java and Spring Boot, you might be proposing a change that involves message queues like Kafka or RabbitMQ.

• Instead of: "We'll use a message queue for asynchronous communication between services."
• Try: "We'll set up a central mailroom (the message queue) for our services to send messages to each other. This way, they don't have to wait for an immediate response and can keep working, making the whole system more efficient and resilient."

This skill of creating clear, simple analogies is a form of "First Principles Thinking" applied to communication—breaking a concept down to its fundamental truths and building it back up in a way anyone can understand.

4. Practical Application: Summarize a Recent Change

Now it's time to put this into practice. Think of a recent complex feature you built or a technical problem you solved. It could be a performance optimization, a bug fix in a distributed system, or a database migration.

Your task is to write a one-page executive summary about that change, intended for a non-technical product manager or executive. Follow the Problem, Solution, Impact, Ask structure we've discussed.

1. Identify the change: Choose a real piece of your work from the last few months.
2. Draft the summary: Write a concise summary (under 300 words). Be ruthless in cutting jargon. Use at least one analogy to explain the core technical concept.
3. Test it: Ask a non-technical friend or colleague to read your summary. Then, ask them to explain back to you, in their own words, what the problem was and why your solution was valuable. If they can do this accurately, you've succeeded. If they are confused, it's a sign you need to simplify further.

This exercise will build the muscle for translating technical details into business narratives, a critical step in your journey toward senior and management roles.

Conclusion

In this lesson, we moved from communicating with a technical audience to engaging non-technical stakeholders. You learned that effective technical summaries are not "dumbed-down" versions of technical documents; they are sophisticated translations tailored to a specific audience and purpose.

Key Takeaways:

• Know Your Audience: Executives, product managers, and engineers all read differently. Structure your documents accordingly.
• Use the Inverted Pyramid: Put the most important information—your conclusion and recommendation—first.
• Structure for Business: Frame your summary around the Problem, Solution, Impact, and Ask to focus on business value.
• Simplify with Analogies: Replace technical jargon with clear analogies that connect complex ideas to everyday concepts.

This skill of concise, impactful writing is a cornerstone of executive communication. In our next lesson, we will adapt these principles for real-time interaction as we learn how to explain a technical concept or blocker to a non-technical stakeholder using simplified language during a meeting or conversation.