Your Best Work Is Invisible Because You Describe It Wrong
Most data engineers talk about what they built. The ones who get promoted talk about what it changed. Here's the difference.
This article is part of the Lead & Grow playlist. Click here to explore the full series.
I spent three years shipping some of the best engineering work of my career and getting almost zero recognition for it. I built solid pipelines, clean models and efficient infrastructure. And nobody outside my immediate team had any idea what I had done or why it mattered.
I thought the work would speak for itself. It didn’t. Work never does.
The problem was the language. I described everything in the terms I built it in, and those terms meant nothing to the people who controlled my career trajectory. I had a translation problem, and I didn’t even know it existed.
The Language Gap That Keeps You Invisible
Here is the thing about technical work: The better you do it, the more invisible it becomes.
A pipeline that runs flawlessly at 3am generates no Slack alerts, no urgent emails, no visible crisis for anyone to notice. Your success looks like nothing happened.
So when someone asks what you have been working on, you say something like “I migrated the ingestion layer from ETL to ELT“ or “I refactored the dbt models to use incremental materialization“. And the person in the Zoom square nods politely and moves on, because those words carry zero weight in their world.
The people deciding your promotion, your project funding, your headcount don’t think in pipelines and materializations. They think in revenue, cost, and risk.
Every time you describe your work in technical terms to a non-technical audience, you are asking them to do the translation for you.
They won’t. They have their own problems to think about.
So the credit goes to whoever already speaks their language. The PM who presents the dashboard you built, the analyst who shares the insight your pipeline made possible get the visibility because they describe the outcome, and you described the plumbing.
This pattern is career poison, and it compounds. One invisible quarter becomes a year of “solid contributor“ ratings that never break through to “high impact“. The frustrating part is that you are already doing high-impact work. You are describing it in a way that buries the impact.
The Three-Column Translation
I use a framework with my direct reports that fixes this. It forces you to take any piece of technical work and push it through three columns until it lands in language a CFO would repeat back to you.
Column 1: Technical Input. What did you change? Eight words max. Use past tense. “Migrated ETL to ELT“. “Refactored the ingestion layer“. This is where most engineers stop, but that’s the least important column.
Column 2: Enablement Outcome. What became faster, more reliable, or self-serve as a result? Put a number on it. Percentage improvement, hours saved, or direct dollar impact. “Analysts build and modify transformations without engineering tickets“ or “Query runtime dropped from 90 to 18 minutes“.
Column 3: Business Driver. Which business bucket does this fall into: revenue, cost, or risk? Name the specific stakeholder behavior or decision that moves the number. This is the column that matters, and this is the column most engineers skip entirely.
Here is what the full translation looks like in practice.
An ETL to ELT migration:
Column 1: “Migrated ETL to ELT”
Column 2: “Analysts build and modify their own transformations directly in the warehouse without filing engineering tickets“
Column 3: “Product team runs independent analyses, cutting 2 weeks from the launch decision cycle“
A dbt refactor:
Column 1: “Added daily partitions“
Column 2: “Runtime dropped from 90 to 18 minutes, 80% reduction“
Column 3: “72 analyst hours freed per month, equivalent to $1.2M in retention analysis capacity“
Look at the difference between Column 1 and Column 3. Column 1 is what you did. Column 3 is why anyone should care.
Read your Column 3 out loud and ask yourself if the CFO would repeat it in a sentence. If it still sounds technical, it hasn’t crossed the line yet.
Stories Beat Updates
Translation is half the problem. Delivery is the other half.
Most data engineers send updates. You share what you did, what changed, and what comes next. The information is accurate and nobody acts on it, because updates are passive. You inform, but you don’t move anyone toward a decision.
The fix is a four-part structure that turns any update into something people act on:
Context: what problem were you solving?
Insight: what does the work show?
Impact: why does this matter to the business?
Action: what should happen next?
That last step is the one everyone leaves out, and it is the most important one. Send an update without a recommended next step and your audience will do nothing. They will read it, nod, and go back to their inbox. End with a clear recommendation or a specific decision you need from them, and the message becomes a conversation.
The language matters too. Drop the engineering voice when you talk to business stakeholders. Lead with what surprised you and what changed. Use phrases like “what stood out to me“ and “the implication for the team is“ because they signal there is a human being behind the update with a point of view, not a system generating a status report.
A story that leaves someone thinking the same way they started is unfinished. If your update doesn’t change what someone believes or what they do next, it was noise.
Final Thoughts
The data engineers I see get promoted are rarely the best builders on the team. They are the ones who learned to describe their work in terms that register with the people holding the budget, the headcount, and the promotion decisions.
This is a skill. It’s easy to learn, and most people never develop it because nobody tells them it exists.
Everything I covered here is a piece of a larger system I built and use with my own team. The Business Translation Kit, including the interactive worksheet, the KPI mapping framework, and the executive framing templates, is available as a free resource.
More on the Topic
Talk Techie to Me: Translating Data Complexity for Business Leads
Business value mapping playbook: How to translate data work into executive language
4 awkward stakeholder conversations you have to master if you want more money and respect
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
See what people say about working with me.
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went!