Your Stakeholder is Wrong (and it’s Your Fault)
If you’re waiting for a stakeholder to bless your logic, you are just an expensive, slow version of an LLM.
We’ve all been there. You’re sitting in a conference room, and a VP of Growth is explaining a “new way” to look at customer acquisition. It doesn’t make sense. It ignores three edge cases you spent all of last quarter fixing.
But instead of pushing back, you nod. You look for “alignment.” You go back to your desk to build a dashboard that fulfills their specific, broken whim, fueled by the rare high of total agreement, convinced that you’re finally being a “good partner”.
In reality, you’ve just demoted yourself to human middleware.
If your value as a data professional is simply to translate a stakeholder’s vague desire into a SQL query, you are obsolete. An LLM can do that faster, cheaper, and without complaining about its weekends. When you wait for a stakeholder to “bless” your logic before you build it, you aren’t an engineer, but an expensive, slow API between a non-technical person’s mood and a database.
The truth is that if the logic of your work only lives as a shared memory between you and a VP who is already half-checked out and scrolling LinkedIn for their next role, you haven’t built a project. You’ve just rented their current state of mind.
The second that person resigns, your work enters a death spiral. A new stakeholder arrives with their own set of biases, and because you relied on the “vibe” of a conversation instead of an undeniable structural contract, you have no shield.
You’re stuck in the rework loop, rebuilding the same fundamental logic for the third time in eighteen months, not because the business changed, but because you refused to own the reality of the data.
The Cost of Presumption Debt
You’re smart, and that’s exactly why you’re failing. Data engineering attracts people with high IQ, but in a requirements meeting, that intelligence is the thing that turns you into a servant.
Because you’re smart, you feel a subconscious pressure to have all the answers. You treat the discovery phase like an oral exam you didn’t study for. When a stakeholder describes a logic gap, you don’t call it out. Instead, you use your brain to bridge it. You fill the silence with a guess because you don’t want to look “uninformed“ in front of a room full of senior managers.
This is how you take on Presumption Debt.
But here is the truth: every time you skip a “stupid” question to save face, you are abdicating your power. You are allowing the stakeholder’s broken intuition to become the physical law of your pipeline. You think you’re being helpful, but you’re actually being a coward. You are letting them be wrong, and then you are signing up to be the one who has to maintain that wrongness in code for the next twelve months.
That hesitation is the death of structural integrity. When you show your work three months later and hear “That’s not what I expected”, don’t blame the stakeholder for being vague. Blame yourself for not challenging the logic when it was still just words in a room.
You’re being forced to pay back that Presumption Debt with the only currency you have left, your weekends, all because you chose to be “smart“ instead of being the arbiter of reality.
Complexity is a Choice
There is a fundamental law in data engineering:
Code complexity always follows business complexity.
When a stakeholder gives you a vaguedefinition of “Revenue“, they are handing you a grenade. If you accept that vagueness, and take on that Presumption Debt, the only way to resolve it is through code.
You end up with a 500-line SQL model filled with CASE WHEN statements, COALESCE hacks, and edge-case filters that only you understand. You think you’re being a “hero“ by making the data fit the stakeholder’s messy reality.
You aren’t. You’re just an enabler.
Every time you “figure it out“ instead of forcing the stakeholder to define the logic, you are choosing to build a brittle system. You are trading your future peace of mind for a moment of “alignment“ in a meeting.
Every experienced data professional knows that simplicity is a political act. To keep a codebase clean, you have to be willing to walk back to that VP and tell them their logic is broken. You have to refuse to write the code until the business rules are undeniable. If the logic is a mess, the code must be a mess. There is no magic transformation layer that turns “vague feelings“ into “structural truth“.
When you stop being an order-taker, you realize that your primary tool isn’t Python or SQL. It’s the ability to say: “I cannot build this because your logic doesn’t exist yet”. If you don’t fight for that clarity at the source, you aren’t an engineer. You’re just a translator for a language that doesn’t have any grammar.
Final Thoughts
Most data engineers think their job is to be “helpful“. They think that walking out of a meeting with a handshake and a “we’re on the same page“ is a success.
It’s a surrender.
When you accept a handshake, you are agreeing to become a human proxy for Claude Code. You are taking a vague, logically inconsistent human thought and doing the manual labor of turning it into code.
If that’s all you do, you are obsolete. An LLM can take a messy prompt and hallucinate a query in seconds. If you aren’t adding a layer of structural logic to that request, you aren’t an engineer, but an expensive, slow interface.
To survive, you have to stop looking for a handshake and start fighting for a Logic Contract.
This Contract isn’t a 50-page requirements doc. It’s a point of friction. It’s the moment you stop the meeting and say:
We cannot calculate Active Users this way because the math creates a loop we can’t close. We are either going to define it with specific, signed-off, logic, or we aren’t going to build it at all.
The contract is the physical boundary of what is possible in the system. When you force a stakeholder to sign off on a structural definition before you write a single line of dbt, you are doing the one thing an AI can’t do: Exercising Judgment.
Claude can write the SQL, but it can’t tell the VP of Sales that their definition of a “Lead“ is a mathematical impossibility that will break the company’s reporting in six months. That is your job.
If you build on handshakes, you’re building on sand. When that stakeholder leaves, the handshake vanishes, the logic collapses, and you’re left holding a pile of spaghetti code that an AI could have written better anyway. But if you build a Logic Contract, the project survives the person. The logic remains undeniable because it’s no longer a “feeling“, but a requirement.
Thanks for reading,
Yordan
PS: The next time you’re in a meeting and you don’t understand the logic, don’t nod. Disrupt it.
PPS: Last week, I posted my practical system for turning vague requests into frozen specs, staged delivery, and non-negotiable exit criteria. Check it here.
"your are expensive, slow version of an LLM." that was rude but true 🤣 - something I experienced with this is the fact that even when you reject requests because it will cascade into a lot of other problems stakeholders can't anticipate, an LLM won't care, provide it right away and call it a day. But then the slow version of the LLM is the only one to be held accountable when the cheap-fast version messed it up.