The most senior thing an engineer does is rarely what they build — it is what they refuse to build, and the alternative they offer instead.
The room wanted a yes.
It was the kind of meeting where the date had already been promised to someone who had promised it to someone else, and the only thing left undecided was whether engineering would nod. The plan on the screen was a hard cutover — freeze the old system, build the replacement, flip everything over on a single weekend. Every person in that room was smart. Every person was under pressure. And the plan was going to hurt people, because plans like that always do.
I said no.
Not a dramatic no. I didn't have a speech. I said that I wasn't willing to put my name on a single irreversible weekend, that I'd seen that movie and knew the ending, and that I could give them most of what they wanted on a path I could actually defend — smaller, slower-looking, reversible at every step. There was the particular silence that follows when you've made a room's easy decision harder. Then the real conversation finally started.
I've been doing this for more than twenty years — building payments systems and ledgers and the kind of platforms that are not allowed to fail, the ones where an outage is a news story and a data error is a regulatory letter. And if you'd asked me at the start what made someone senior, I'd have pointed at the things they could build. Now I think it's closer to the opposite. The longer I do this, the more my value lives in the things I am willing to refuse, and in how well I refuse them.
This is an essay about that — the strange, late-arriving skill of saying no.
The first no is the cheap one
Every bad outcome I have ever been part of had a moment, early, where someone could have said no and it would have cost almost nothing. A raised hand in a planning meeting. A paragraph in a design doc. A quiet "I don't think this is going to work, and here's why."
The tragedy is that the no gets more expensive every week you wait, while the courage required to say it grows at the same rate. By the time the problem is undeniable, saying no means torching months of work and a lot of people's pride, so nobody does — and the thing ships, and then it fails on its own schedule instead of yours. I have learned to spend my objections early and cheaply, when they're just words, rather than hoarding them until they're catastrophes. The most valuable sentence in engineering is often the most awkward one to say nine months before anyone else can see why.
"No" is a complete sentence — and a terrible strategy
Here is where junior contrarians go wrong, and where I went wrong for years: they think the no is the contribution. It isn't. A no with no door behind it is just obstruction wearing the costume of rigor, and people learn to route around the engineer who only ever says it can't be done.
The senior move is never "no." It's "no — and here's the smaller, reversible thing we can do instead." No to the big-bang cutover, and yes to strangling the old system one endpoint at a time. No to shipping the AI agent that can move money unsupervised, and yes to letting it propose anything while a human approves the few things that are irreversible. No to the answer the system isn't sure of, and yes to making "I don't know" a perfectly acceptable thing for it to say. The refusal only earns its keep when it comes attached to a path. Anyone can be the person who stops the room. The job is to be the person who stops the room and then shows it a better door.
Saying no to your own cleverness
The hardest no I've had to learn isn't to other people. It's to myself.
There is a particular seduction in an elegant, intricate solution — the architecture with the beautiful abstractions, the framework that handles every case you can imagine and several you can't. Early in my career I mistook that elegance for skill. I built things that were impressive and that I, alone, could fully understand, which is another way of saying I built liabilities.
What I believe now is almost embarrassingly plain: complexity has to be load-bearing or it has to go. Most of the time the right answer is the boring one — the obvious data model, the dull and well-understood pattern, the technology that will still have a support community in five years. The discipline of senior engineering is largely the discipline of refusing your own cleverness: noticing the moment you're adding a layer because it's interesting rather than because it's necessary, and saying no to yourself before someone has to maintain your hobby at 3 a.m. The best architecture I've shipped is usually the one a new engineer can understand on their second day, not the one that made me feel brilliant.
The questions behind the no
People sometimes ask how I decide — how you know, in the moment, whether to plant your feet or get out of the way. I don't have a rule. I have a short list of questions I've been asking long enough that they've become a kind of reflex, and they're mostly about one thing: what happens when this is wrong?
Notice what they have in common. Almost none of them ask will this work? — because most things work in the demo. They ask whether it's reversible, because a mistake you can undo is a bad afternoon and a mistake you can't is a bad year. They ask about the blast radius and who owns it, because "it depends on everything" is not an architecture. They ask whether we can prove what happened, because in the systems I work on, "the computer did it" is not an answer you can give a regulator. They ask whether the complexity is doing real work. They ask whether it survives the worst night, not just the best demo. And, increasingly, they ask whether the system is honest under doubt — whether it can say I don't know instead of confidently making something up.
A yes that can't answer those is not a yes yet. It's an optimism I haven't earned the right to act on.
You have to earn the right to say no
None of this works if you've only ever said no. The engineer who refuses everything is just as useless as the one who refuses nothing, and trust is the currency that makes a no land instead of bounce. You earn the standing to stop a room by having delivered, repeatedly, the hard yeses — by being the person who shipped the thing that didn't fall over, who took the pager and meant it, who was right the last several times the stakes were real. Authority to say no is not granted by a title. It's accumulated, slowly, from a track record of judgment that turned out to be sound.
Which is why I've spent a chunk of my own time lately turning the patterns behind these refusals into things you can actually run — reference implementations of the reversible modernization, the governed agent, the grounded AI, the right coordination model. Not because the world needs more code, but because "trust me, I'm senior" is exactly the kind of unverifiable claim I'd say no to if someone else made it. The work should be checkable. The no should be earned in public.
The line
If there's a single thing two decades taught me, it's that the shape of the job inverts as you get more senior. It starts as a question of what you can add — what you can build, learn, ship. It slowly becomes a question of what you can subtract, and what you can hold the line against when everyone in the room, including the part of you that wants to be agreeable, would prefer you just said yes.
The systems I'm proudest of aren't the ones with the most in them. They're the ones where the right things were left out, the irreversible steps were made reversible, and the confident wrong answer was never allowed to leave the building. That's not the work of adding. That's the work of refusing — carefully, constructively, and with a better door already open.
Saying no, it turns out, was the job all along. I just needed twenty years to get good at it.
Everything I've described here, I've tried to make concrete and runnable rather than leave as advice: five open reference implementations — reversible legacy modernization, a governed AI-agent gateway, a production RAG engine that's allowed to say "I don't know," a pricing platform that orchestrates the core and choreographs the edges, and a streaming lakehouse — each built around the principle that the most important decisions are the ones you can take back.
Browse them here: https://github.com/mizbamd
I write about building platforms that are not allowed to fail — the patterns, the trade-offs, and the judgment behind them. Follow along.
Originally published on Medium.
Top comments (0)