4 Strategies To Elevate Your Communication Style From Engineer To Leader
Hi, fellow future and current Data Leaders; Ben here 👋
Today, we’re going to discuss how you can improve communication with the business to gain buy-in for a project or deliver better results and insights.
Before doing that, I wanted to let you know that in July, I’ll be hosting several webinars and discussions with data leaders about problems that extend beyond just technology (although we’ll likely touch on some infrastructure topics). So, if you’re interested in growing as a data leader, you can sign up here.
Now, let’s jump into the article!
One of the challenges many of us technophiles face is… well, being technophiles. We love the tools, the architecture, the solutions. We obsess over systems, stacks, and edge cases.
That’s all fine—until we try to talk to our business stakeholders as if they’re just as obsessed.
We start throwing around abbreviations and technical terms that take years of experience to fully understand.
We slip into jargon. Acronyms. Architecture diagrams. We might be speaking the same language but it goes right over our stakeholders heads.
Inside the data team, that language makes perfect sense. But when we step outside that bubble and talk to non-technical peers the same way, we lose them. Worse, we frustrate them.
So let’s talk about how to communicate with the business—without technobabbling.
Technobabbling
I don’t recall the first time I saw the Rockwell Retro Encabulator video, but it stuck with me. It perfectly illustrates how easy it is to throw around words that are technical but mean absolutely nothing to most people.
If you watched the clip, you probably caught the part where they rattle off a bunch of companies and brands. It’s oddly familiar—just like when we say we use Databricks, Iceberg, Data Lakehouses, Snowflake, ETLs, or whatever’s trending this week.
As if that means anything.
Then you layer in buzzwords and b*llshit, and suddenly, no one’s on the same page. That’s exactly how we sound when we point to our architecture diagrams and speak in industry terms.
So, how can you avoid falling into this trap?
1) Frame Everything in Terms of Impact, Not Tools
Once you move past the jargon, there’s another common trap: focusing too much on what you built and not enough on why it matters.
You might be proud you used Airflow, Snowflake, or dbt. Maybe you solved a gnarly data issue or implemented a cool new feature. But unless you’re talking to a fellow engineer, your stakeholders don’t care about your tooling, unless it clearly connects to a business result.
(Ok, sometimes you’ll get lucky and speak with someone who does geek out over tech. But most of the time? You’re talking to people who care about outcomes.)
This is where impact framing comes in.
As a technical professional, it’s easy to assume your value lies in solving complex technical problems. But the technical problem is generally a means to an end. You’re being hired for the outcomes your stack makes possible.
So shift your focus. Speak in terms of:
Time saved
Revenue
Risk reduced
Efficiency gained
Clarity delivered
You’re still describing the same work. But your framing should change depending on who’s in the room. That’s how you make your work resonate beyond the data team.
Tips for Strong Impact Framing
Lead with outcomes, then explain the work - Example: “We reduced customer churn alerts from hours to minutes by refactoring the pipeline that feeds the alerting system.”
Quantify when you can - Even a rough estimate is better than none. If you saved time, reduced costs, or sped things up—say so.
Name the team or person it helped - “Gave the finance team a real-time view of transactions” is far more effective than “Built a transactions table.”
Map it to a business goal - Tie your work back to company-wide initiatives or OKRs. It shows you understand the bigger picture.
For example:
❌ Without Impact: “We implemented automated anomaly detection on key metrics.”
✅ With Impact: “We can now catch revenue-impacting issues like billing spikes within minutes instead of waiting for someone to notice them the next day or week when they manually create their reports.”
You can also layer in business context to drive the point home:
❌ No context: “We reduced query costs by $20,000.”
✅ Context: “That’s the equivalent of hiring a new analyst for a quarter—just from optimizing five of our most expensive queries.”
This kind of framing helps the business understand the weight of what you’ve delivered. Even better? It gives them an easy win to share up the chain.
2) Highlight the Cost of Inaction
Sometimes, the best way to persuade the business isn’t by pitching the benefits, it’s by making the risks of doing nothing crystal clear.
As a consultant, I’ll often ask prospects a simple question:
"What if you didn’t hire me?” or “Why not just invest the money elsewhere?”
It’s a great way to reframe the conversation and surface the urgency.
A common case of inaction? When business executives want to fast-track ahead, skipping foundational data engineering work. It feels like progress in the short term, but it introduces hidden risks that don’t show up until it’s too late.
The key is to make those risks tangible. Use clear business language, potential financial impacts, or missed opportunities.
How to Surface the Risk
To effectively communicate the cost of inaction:
Point to a past failure (yours or one from another company)
Estimate the financial or operational impact of things going wrong
Use “if this, then that” framing to make the risk tangible
This kind of framing works especially well when the stakeholders are underestimating the importance of a technical investment, or pushing to “move fast” by skipping steps. It happens often, especially in tech environments where speed is prized over process.
3) Use Maturity Models to Set Realistic Expectations
Right now, just about every data team, whether it’s a solo analyst or a 100,000-person org, is being asked to deliver AI and ML. But the question is: Are they ready?
Do you need the perfect BI infrastructure in place to run AI? Not necessarily. But if you’re still struggling to do BI well, trying to layer AI on top is a red flag.
That’s where maturity models come in.
A maturity model gives you a shared language for showing where the company is right now and what needs to happen before more advanced capabilities can be successful. It helps you frame the conversation around progress instead of resistance.
Instead of saying, “We’re not ready for that,” you can say:
“We’re still in the ‘crawl’ stage. Jumping to AI before we can reliably report on the basics is like trying to fly before we’ve learned to walk.”
This allows you to provide a path forward instead of an all out no.
It also builds trust. You’re not just pointing out limitations, you’re showing leadership by mapping the next step forward.
How to Use Maturity Models Effectively
Use visuals. Draw the ladder, phase chart, or journey map on a slide or whiteboard to make the concept more tangible.
Plot your current state. Show where the company sits today and where it wants to go.
Frame it as progress, not limitation. Emphasize that growth is possible with the right investments.
4) Use Analogies That Make Sense to Your Audience
One of the most powerful tools in your communication toolkit is the analogy, especially when it connects to something your stakeholder already understands.
Talking to someone in manufacturing? Explain data pipelines like assembly lines: data comes in as raw materials, gets cleaned and shaped, and turns into something useful on the other end.
Talking to someone in finance? Frame data quality issues like bad inputs in a financial model, garbage in, garbage out.
The best analogies are:
Relevant to the stakeholder’s domain
Simple enough to land without extra explanation
The key is meeting people where they are, not expecting them to come to you.
Final Thoughts
It’s tempting to talk to the business the same way you talk to your data team. But the business has different goals, different priorities, and a completely different frame of reference.
That’s why it’s important to first understand your audience—who you are delivering to, then shape your message accordingly.
Use analogies. Speak in terms of impact. Frame the work in ways that make sense to them. That’s how you get buy-in. That’s how you build trust.
Not by confusing stakeholders with technobabble.
As always, thanks for reading.
Join My Data Engineering And Data Science Discord
If you’re looking to talk more about data engineering, data science, breaking into your first job, and finding other like minded data specialists. Then you should join the Seattle Data Guy discord!
We are now over 8000 members!
Join My Technical Consultants Community
If you’re a data consultant or considering becoming one then you should join the Technical Freelancer Community! We have over 1700 members!
You’ll find plenty of free resources you can access to expedite your journey as a technical consultant as well as be able to talk to other consultants about questions you may have!
Articles Worth Reading
There are thousands of new articles posted daily all over the web! I have spent a lot of time sifting through some of these articles as well as TechCrunch and companies tech blog and wanted to share some of my favorites!
7 Unwritten Rules for High-Impact Engineering Careers
When I joined the semiconductor industry 15 years ago, I was about as bright-eyed and bushy tailed as a fresh college graduate can be — excited to be a force to reckon with, eager to make a positive contribution, and ready for a steady climb up the career ladder.
As the years rolled by, I learned that things are a lot more complicated than that. For example, companies are not all that meritocratic as they claim to be. Or that proving you’re right today has consequences in the long term because people have feelings. And hold grudges. Most notably, it is often about who you know than what you do.
Time is the best teacher of the unwritten dynamics of chip design companies.
The Basics of SFTP: Authentication, Encryption, and File Management
If you’re looking to pass hundreds of GBs of data quickly, you’re likely not going to use a REST API.
That’s why every day, companies share data sets of users, patient claims, financial transactions, and more via SFTP.
If you’ve been in the industry for a while, you’ve probably come across automated SFTP jobs that do just that. You’ve also likely had to encrypt or decrypt a CSV and had to interpret a schema file with parsing instructions that—somehow—are always a bit off the first time.
Now, sure, we all want to build real-time systems that use LLMs and other flashy new tools and solutions. Sometimes, that’s not what is called for.
After all, companies of all sizes—even tech giants like Facebook and Airbnb—still use SFTP to share critical information for analytical purposes(as well as operational). So, let’s dig into what SFTP is and how you will likely work with it.
End Of Day 183
Thanks for checking out our community. We put out 4-5 Newsletters a month discussing data, tech, and start-ups.
If you enjoyed it, consider liking, sharing and helping this newsletter grow!
That video make me laugh so much!!
Agree with your point here Ben. I actually see data leaders make this mistake often.
Really interesting. Thanks