November 2025 · 5 min read
Saying No, Specifically and Publicly
A vague no costs you twice. You spend the political capital of pushing back and get none of the protection a real no provides. Here's what a real no sounds like.
The Python decision from the last post did not get reversed. I want to be honest about that up front. The pillar lead wrote it in Python, it ran for six weeks, it broke on a Friday afternoon before a board prep cycle, and the platform team spent the weekend reverse-engineering a transformation that should have lived in dbt next to thirty others like it.
The lesson was not that I was right. I was right on day one. The lesson was that being right in private is the same as being wrong.
The vague no is worse than yes
When a senior pillar lead tells you they are going around the platform, the instinct is to push back gently. “I’d really prefer if we kept this on the warehouse.” “Let’s talk about whether that’s the right call.” “Can we loop in the platform team?”
Every one of those is a yes wearing a costume. The pillar lead hears hesitation, files it as friction they can outlast, and ships the Python job by Thursday.
A vague no costs you twice. You spend the political capital of pushing back, and you get none of the protection a real no provides. The work still ships. The sprawl still happens. And now you are also the person who tried to stop it and failed, which is a worse position than the person who saw it coming and stayed quiet.
If you are not willing to say no in a way that creates a paper trail, do not say no at all. Save the capital.
What a real no sounds like
A real no has three parts: the decision, the reason in the business’s language, and the consequence you are accepting on their behalf.
“We are not going to run this transformation in Python outside the platform. The reason is that we lose lineage, we lose the freshness alerts finance depends on, and we lose the ability for the merch team to reuse this logic next quarter when they hit the same problem. If we make an exception here, the next three pillars will ask for the same exception, and we will be running four parallel stacks by Q3. I am not willing to own that outcome. If you want to escalate this, escalate it to the CFO with me in the room.”
That is a no. It is specific. It names the costs in terms the business understands. It refuses to absorb the externality quietly. And it offers the escalation path on your terms, not theirs.
Notice what it does not do. It does not say “best practice.” It does not say “industry standard.” It does not say “the data team thinks.” Those phrases are how nos get rounded down to suggestions.
The publicly part
Saying no to the pillar lead in a 1:1 is not saying no. It is venting.
The no has to land in a place other people can see. A decision log. A thread the CTO is on. A section of the architecture review document with your name next to it. Something that exists when the Python job breaks at 2 a.m. and someone asks how we got here.
This feels political and ugly the first few times. It is political. It is also the only mechanism that makes the no real. Private nos evaporate the moment the pillar lead tells their team a different story, which they will.
The goal is not to embarrass anyone. The goal is to make the decision exist outside your head, so the eventual cost lands on the right ledger.
When the no does not hold
Sometimes you will say no, in writing, with the three parts, and the pillar lead will go to your boss and your boss will overrule you. This will happen. It is not a failure of your no. It is a feature of how organizations work.
What matters next is what you do with the overrule. The wrong move is to relitigate. The right move is to document the reversal, in the same place the original no lived, with the same specificity.
“Decision reversed by [name] on [date]. The transformation will run in Python outside the platform. The accepted risks are: no lineage, no freshness alerting, single-owner code with no reuse path. Revisit when the first incident occurs.”
Now the cost is named, the ownership is clear, and when the incident happens, the conversation starts from “we knew this” instead of “how did this happen.”
You did not lose. You moved the loss onto the right ledger.
The job, restated
Most of the leadership work in this function is loss management. You will not win every call. You will not keep the platform clean. You will not stop every pillar lead from going around you.
What you can do is make sure that every concession is named, every cost is owned, and every reversal is documented. Over a year, that is what separates the data leader who is treated as a strategic peer from the one who is treated as a service desk that occasionally complains.
Saying no is not the work. Saying no in a way that survives the room is the work.