Engineering Influence: How to Communicate for Real Product Impact
A Practical Guide to Building Trust Beyond the Code
You just finished giving your best presentation performance. You explained everything - from the intricacies of cloud resources optimization to a deep dive into globally distributed databases.
There is a moment of silence. Then, the VP of Product Management shifts his gaze from you to your manager. “I thought we wanted to improve load time for a smoother user experience. Why are we burning time with this work?”
At that precise moment, it doesn’t matter that you’ve actually improved the load time by all those optimizations. What matters is that you failed to bridge your engineering efforts and product outcomes.
Engineering is often framed as a purely technical discipline—master the code, build the product, and ship the features. But that’s an incomplete story. Communication is not a “soft skill.” It’s a core product driver.
No matter your technical brilliance, when communication is ineffective, it remains hidden or misunderstood.
However, when communication is successful, teams align quickly, product decisions are more informed, and stakeholders have confidence in the roadmap.
In this article, you’ll explore communication not as a box to check on a “soft skills” checklist but as a fundamental component of your engineering toolkit.
Know Your Audience Before You Speak
Effective communication starts with understanding who you’re talking to and what they care about.
Whether it’s an executive, a customer, or a colleague from another department, you’ll need to choose the level of detail, vocabulary, and emphasis that resonates most with them.
Think of it as applying product thinking to your communications: you’re building a “message product,” and your stakeholders are your users.
The first step is to understand who the “customer”, aka. the listener, is and how much technical depth they can handle. You might ask simple questions like:
“Have you dealt with similar systems before?”
“Are you familiar with microservices, or should I briefly explain?”
Their answers—or puzzled expressions—will help you decide how detailed your explanation should be.
The table below captures several core stakeholder groups, their primary focus, and an ideal communication style for effectively engaging them.
Make Your Message Stick
Once you know whom you’re speaking to, the next challenge is communicating technical information in a way that resonates.
The goal is to create common ground and understanding as soon as possible. If you delay this step or overwhelm your listeners with technical details before it, you will either lose their interest or make them irritated that you are wasting their time.
In my experience, two simple yet effective approaches, depending on the context, are Analogies and Tiers.
I use analogies to create common ground in shorter interactions or ad hoc discussions.
Analogy:
a comparison of two otherwise unlike things based on resemblance of a particular aspect. [Merriam-Webster]
Analogies or metaphors are great tools to use when you want to translate a complex concept into a more familiar realm. For example, I often use analogies with the car industry:
“In the initial phases of the project, there will be fewer visual features to demo for stakeholders, as we need to bootstrap the overall architecture for it. Think of it as building a strong engine for a car so that later on, we can add features such as autonomous driving, self-parking, or heated seating.”
This way, listeners can create a mental image of something they are familiar with (a car) and project that image onto the product’s development process.
Will it be 100% accurate? Of course not. But if you start by explaining to your Go-to-Market manager how you are going to write Terraform scripts to run your Go service on demand in Docker containers on AWS Lambdas while having a cross-regional NoSQL Mongo database cluster, they will probably find someone else to talk to.
Leading with the “Why”
This is an essential tactic for almost any communication. As posts on social media try to engage user attention with “hooks” within their first few sentences, you can do the same with your communication.
Explain how your technical work addresses a real problem—like reducing page load time by 30%, improving reliability during high-traffic events, or streamlining checkout processes to boost conversion.
Remember, writing code is never the end goal. Framing the conversation around outcomes keeps non-technical listeners engaged. Your goal is to help them see the direct line between an engineering work and its impact on users or the business.
Tiered Levels of Explanation
You often need to present your work or ideas to a diverse audience. An example is a sprint review or a planning meeting, where people from engineering, product, customer support, or marketing are present.
Using Tiers in this context means starting from high-level benefits or impact and moving to deeper and deeper details tier-by-tier.
Let’s look at an example of how to lead with “why” and offer a multi-tier level of technical details:
Why: “Based on our forecasts, we expect a significant increase in user traffic next quarter. If we don’t prepare, our users could face slow load times or errors, which risks revenue and customer satisfaction because our current system is already at its limits.”
Tier 1 (High-Level): “We’re shifting from a single, monolithic database to a distributed architecture to handle this growth seamlessly. We’ll no longer rely on just one database instance for all reads and writes. Instead, we’ll adopt a cluster of smaller, independent databases that can operate in parallel.”
Tier 2 (Mid-Level): “We’re moving from our traditional relational database to a NoSQL solution that scales horizontally. This move fits our use case and will help us handle large volumes of concurrent requests more efficiently.”
Tier 3 (Detailed): “Under the hood, we’ll implement Apache Cassandra, known for distributing data across multiple nodes. This setup minimizes bottlenecks and improves fault tolerance, so the system keeps running if a node goes down.”
At this point, everyone in the meeting should have enough information to be on the same page and broadly understand what will happen and why. A follow-up discussion will be much more effective.
Quick-Reference Checklist
With the previous sections in mind, the next step is to embed these ideas into your day-to-day workflow. Keep this checklist on hand for a quick reminder before jumping into a meeting or creating a presentation.
1️⃣ Clarify Your Purpose
What are my goals? Why am I communicating this information?
What do I need from my audience? Is it a decision, an approval, or is my purpose to share knowledge?
What is my “success metric” for this communication?
2️⃣ Know Your Audience
What is their familiarity with the topic?
What do they care about?
Do they need to know technical details, business impact, user experience, ROI, or something else?
Use the table from the section “Know Your Audience Before You Speak”
3️⃣ Create a Tiered Message
Start with high-level benefits or impact first.
Dive deeper into technical or business details based on your audience.
4️⃣ Anticipate Roadblocks
What concerns might be raised (budget, timeline, priorities)?
How will I address them?
Can I address them proactively?
5️⃣ Include The Audience
Include sections to pause for clarifications or go deeper if there’s interest.
Reiterate the core points to make sure everyone understands.
Summarize key points after the discussion, especially if decisions were made, and share them.
Summary
Effective communication is as integral as writing clean code. It bridges the gap between technical details and strategic objectives.
Use the checklist above to gauge if your communication aligns with that goal.
It’s your responsibility to help stakeholders understand how your technical work solves real problems.
📖 Read Next
Discover more from the Product Engineering track:
If you’re looking for a space where you can learn more about software engineering, leadership, and the creator economy, with Dariusz Sadowski, Michał Poczwardowski, and Yordan Ivanov 📈, we’ve created the Engineering & Leadership discord community:
📣 Recommended Reading
6 secrets for never being blocked again by
and in5 learnings when building and scaling a service-based tech company by
and in- in