This article is part of the Stakeholder Influence playlist. Click here to explore the full series.
I spent part of the weekend thinking about a senior engineer I know. He is technically strong, prefers the technical work, and wants to become a lead. I’m not sure that is the right move for him, but that is another story.
What I know is that his technical work will not carry him into that role by itself. I watch capable engineers explain every query, dependency, implementation detail, and wrong turn, then assume the value must be obvious at the end. If the listener still has to extract your point, you force them to do the last part of your job.
But before that, I have a huge news!
Make Your Judgment Visible in Your Promotion Case
If your next step is a promotion or a raise, I’m teaching a five-session live course about building the case before that conversation.
You’ll collect delivered wins, choose the title and salary number you will ask for, translate technical work into business impact, and assemble a promotion case your decision maker can review before the meeting.
All five sessions run live from 14 to 23 September. They’re free and open to everyone. Paid Data Gibberish subscribers get the recordings and the complete Promotion OS.
Save the event to your calendar. Don’t miss it. I promise this works!
Clear Communication Works Like Clear Code
You would not approve a pull request that forces the next engineer to trace six functions before they can work out what the code does. Good code has structure. It uses names, boundaries, interfaces, and familiar design patterns to make its intent clear while it keeps the hard parts available.
Your communication needs the same discipline. A pipeline update without a clear point is the spoken version of a function with twelve responsibilities. The logic may be correct, but nobody wants to touch the damn thing because the intent is buried inside it.
This is the pain point technical people prefer to dismiss. If you cannot write clear code, nobody trusts you with the hardest parts of the platform. If you cannot express your judgment clearly, nobody trusts you with the more ambitious projects that cross Finance, Product, Operations, and senior leadership. Clear communication never guarantees a promotion. Poor communication still puts a ceiling on the scope other people will risk with you.
You may call that bullshit politics because the engineering should matter more than the explanation. I disagree. On a cross-functional project, your explanation is part of the engineering. A schema migration can be technically perfect and still wreck a finance close if nobody makes the dependency, risk, and cutover decision clear.
Clear communication does for your judgment what clean code does for your logic. It makes the important part visible so nobody has to reverse-engineer it.
Replace Investigation Order With Decision Order
Data engineers often report work in investigation order. You start with the first Airflow alert, move through the task error, explain the retry behaviour, trace the upstream schema change, and eventually reach the fact that the morning SLA is at risk. That sequence makes sense to you because it mirrors the investigation and proves the work is thorough.
The listener does not need to relive the investigation. They need the change, the consequence, and the next move before the technical history. Once those points are clear, lineage, logs, and query plans become evidence instead of a maze.
Your work happens in investigation order. Your explanation needs to happen in decision order.
This does not mean you strip out technical depth. It means you rank the information. Put the decision at the top, then provide enough detail for another engineer or stakeholder to challenge it.
Put the Decision Before the Detail
Answer Four Questions
Decision order becomes useful when it survives your next Slack update or project call. Before you paste logs, map the dependency chain, or explain the dbt model, answer four questions.
What changed?
Why does it matter now?
What do you recommend, or what happens next?
Which technical evidence supports that recommendation?
The first three answers should fit into a few sentences. The evidence comes next at whatever depth the risk and audience require. Its job is to help somebody test your judgment, not hunt for it. A routine schema-change update could read like this.
The warehouse cutover moves to Tuesday because two downstream dbt models still depend on the old schema. I recommend that we keep the old tables read-only until those models move across. The lineage output and cutover checks are below.
Put the decision where people can see it, then show them the evidence.
Give Technical Evidence Its Proper Place
The update keeps the engineering work intact. It gives the listener the change, consequence, and recommendation before it asks them to inspect the evidence. If they need column-level lineage, the data-quality failure, or the validation query, give it to them.
Some engineers will push back here because this feels like a demand to dumb down technical work for non-technical people. It is the opposite. You show mastery when you know which detail affects the decision and which detail belongs in an appendix. An unranked fact dump makes the listener do the prioritization you should have done.
Failure Updates Need Fewer Logs and More Control
Separate Impact From Cause
A failure update exposes your judgment faster because the listener already wants to know whether a deadline, customer, or regulatory report is at risk. If you make them sit through a technical preamble while they wait for the impact, your accuracy starts to sound like avoidance. That is the wrong moment to make somebody excavate your point. Use the same decision order, but draw a harder line between fact and uncertainty.
State the impact.
Give the confirmed cause, or say that the cause remains unknown.
Explain what you have contained and what happens next.
Ask for the decision, owner, or support you need.
Do not turn a theory into a confirmed cause because silence feels uncomfortable. “We do not know yet” is a complete answer when you pair it with the evidence you have, the checks you still need, and the next update time. False certainty buys a few calm minutes and costs trust when the facts change. A pipeline failure update could read like this.
The overnight warehouse ingestion is down, so the finance models will not be ready before Finance starts its daily review. We have not confirmed the cause. The failure is isolated to the orchestration task, and the raw files remain intact. We will validate the last successful checkpoint before we start the backfill. I need Finance to choose whether to wait for corrected models or use yesterday’s numbers for the review.
That update stays honest about the open incident. It states the impact, separates fact from theory, describes containment, and gives Finance a decision it can make now. The task logs still matter, but they belong under the update rather than in front of it.
Put a Boundary Around Uncertainty
If you need no decision yet, name the owner and the next update time. “We will look at it” is a useless close because it gives nobody a boundary. Bad news becomes easier to trust when your uncertainty has edges.
Use the Pause to Think
A Pause Is Not a Failure
Silence feels uncomfortable on a live call. Someone asks whether a backfill will breach the SLA, a few seconds pass, and you start to worry that everyone can hear you not know the answer. So you fill the gap with half-sentences, repeated words, and guesses that sound less certain with every breath.
That noise steals the attention you need for the answer. You now have to reason about the dependency, compose the next phrase, monitor your voice, and hide the silence at the same time.
I had to practise a simpler response. “Good question. I need a minute to think”. The sentence tells the other person what happens next and gives me permission to stop talking. The silence felt strange at first, but the pause got easier once I stopped treating every quiet second as a communication failure.
Name When You Will Return
Some questions need more than a minute. Then I say, “I don’t have an answer now. Let me check the lineage and come back to you by 2 p.m”. That answer is honest, but it only earns trust if I return by the time I named. If I still do not have the answer, I send an update before the boundary passes.
You may think the pause makes you look unprepared. A confident guess that turns out to be wrong makes you look worse. Senior judgment includes the ability to separate what you know from what you need to check.
A request for time shows judgment only when you close the loop.
The pause creates room to think. The follow-up makes the pause trustworthy.
Bigger Scope Follows Judgment Other People Can See
Technical competence is the foundation for wider scope, but it is not the only evidence people use. Ambitious data engineering projects cross systems, teams, budgets, and business deadlines. The person who assigns that work needs to see whether you can sort signal from technical noise and make a recommendation other people can act on.
Clear updates expose that judgment. They show how you assess risk around a schema change, choose a backfill plan, protect an SLA, or decide whether a quality-check failure should stop a release. The code still matters, and the quality of your work still matters. Your explanation determines whether people outside the repo can see enough of that work to trust your call.
Test your next update before you send it. Write the first four lines like this.
What changed?
Why does it matter now?
What do you recommend, or what happens next?
If something remains unknown, who owns the check and when will you update them?
Read only those four lines. Could the other person repeat the impact and next move without the logs underneath? If not, fix the order before you add another paragraph of evidence.
Final Thoughts
Your technical work needs all of its detail and an interface that lets other people use your judgment. Decision order gives you that interface. A pipeline incident or schema migration can stay technical while the change, consequence, and next move remain clear.
Start with the change, consequence, and next move. Put the logs, lineage, and validation checks underneath. When you do not know, say so and put a time boundary around the answer.
You already use structure and design patterns to make code easier to trust. Use the same discipline when you speak. Otherwise, the most ambitious work will go to the engineer whose judgment is easier to see.
And this is what my free course is aobut. Save the dates.
—
Until next time,
Yordan
PS: Now is the perfect time to upgrade and get the course and all the content in the premium content library with a massive discount. Upgrade now.