How to say no to a project as a tech lead, with the exact words

Before you say no to anything, ask whether you hold the right to. Before the Room splits a decision into five roles: someone proposes it, someone decides it, someone pays for it, someone executes it, and someone can reopen it. A tech lead usually sits in proposes, pays and executes. The date and the priority usually sit with a sponsor, a product leader or a director. The book's line for the trap is short: "Caring about a decision, however much, is not a decision right."

That changes what your no is. If the decision is not yours, a flat refusal is either ignored or overruled, and you have spent credibility on a decision you never held. What you do own is the information the decider is missing: what the request costs, what it displaces, and what can go wrong. Your no becomes a refusal to let the trade happen silently.

The book's most useful question for this moment is three words long: "Whose call is that?" It forces ownership into the open before drift makes the decision for everyone. The worked version is in the table further down.

The chapter makes an observation worth keeping: pressure from above is less often a request for a specific answer than a request for confidence. The director who repeated the date is now exposed on it. A bigger estimate hands them a problem with your name on it and no way out, so they push back. They understand the math. It just does not tell them what they can still safely promise.

So the two common responses both lose. One engineer folds, gives a date they cannot hit, and later owns a failure that was visible weeks early. Another gives the lecture, correct and unwelcome, and gets labelled the blocker. What the pressure is actually looking for, in the book's terms, is a bounded commitment with a named risk owner: what engineering will commit to, under stated conditions, plus the one risk that remains and the person with the authority to accept it, who has accepted it by name.

"Launch on the thirtieth" is not one promise. It can mean:

• the feature visible to every user,
• the binary live in the store with the feature switched off,
• a limited cohort behind a flag,
• a partner announcement,
• or a foundation ready for the next release.

People who argue about the date without naming which one are often defending different commitments under the same word. The request on the surface is "can engineering make this date work". Underneath sits a decision nobody has stated: which risk are we accepting to hold the date, and what are we removing to make that risk explicit. Surfaced, the question becomes which promise are we making, and that is one the executive sponsor can answer and the engineer cannot.

On mobile the date breaks in places the ticket never sized. A new build has to clear App Store review, and a rejection means another trip through it. A widget is a new app extension with its own target. A changed backend payload means older app versions need a compatible endpoint or a forced update the app itself triggers. And approval is not arrival: with phased release on iOS, automatic updates roll out over seven days.

A single revised date invites a yes or a no and a debate about your judgment. Three options with named trade-offs, one of them recommended, invite a decision and put it with the person who owns the priority. The book carries them in a one-page three-option scope memo, each option named by the promise it keeps. For the order-tracking launch, condensed:

The options have to be real, and on mobile the fake ones are easy to spot. Planning around an expedited review is not an option, because nobody outside Apple controls review time. Submitting an unfinished build and hoping to finish before approval fails, because what is in the binary at submission is what ships. Forcing a minimum-version update on launch day locks out everyone who has not received the new build. Crunching nights to keep the full scope is unmanaged overtime pretending to be a plan. The rule I would keep from this chapter: "If an option only works when nothing goes wrong, it does not go on the memo."

Know what each brake stops. Pausing a phased release halts only automatic updates, so the server-side flag is the real brake. And a flag cannot hide a feature from App Review: option C goes in with the tracking screen documented and reachable for the reviewer.

Send the memo, then say it the day before the review: the original scope does not fit the date once review and rollout are counted, here are three defensible paths, and I recommend C because it takes review off the launch-day critical path. Then the three sentences that do the work:

"Engineering sizes the risks and recommends one. You own which promise we make. Which do you want?"

That is the no. It does not say the project cannot happen. It says the version on the table cannot happen without a cost, names the cost, and hands the choice to the person whose choice it is. Once they pick, one more line: "We update the partner and the launch plan today, so nobody keeps planning against the old version." If the old promise keeps circulating after the decision, the decision has not landed.

Not every no is a launch. The same move works on the requests that arrive every week, as long as you find the decision under them first.

The middle row catches strong engineers. In the book's composite, a careful, fast status answer becomes the cover for a hard external commitment ten days later, one the engineer never agreed to. The question before answering is the no he needed.

The pressure returns as "can the team just push" or "I need you to find a way", and each return tempts you to raise the volume. Before the Room's chapter on executive pressure calls that the lecture again: it loses because it tells a senior person you think they did not understand.

Its version of holding a line has three parts. Say it once, short, in the sponsor's terms: what you will hold and what it protects for them. When the pressure returns, add no arguments; repeat the commitment and hand the open part back as their decision. And change what you are defending, from a date or your own judgment to their ability to choose with their eyes open. The point the chapter makes about repetition is the one to remember: "the repetition is what makes it read as confidence rather than resistance."

Two tells show the line slipping. Your sentences get longer each round, which means you have started arguing. Or "we will monitor it" starts doing the work of a plan. Monitoring is a plan only if it names the failure mode, the alert, the person watching, the response and the level that sets it off. In the book's words: "Without those, monitor means hope while looking." And if the pressure comes back carrying new facts, a later window or a partner who will accept a limited cohort, it is evidence, and the line should move with it.

The memo does not guarantee your option wins. In the book's version of the launch, the tech lead recommends C, and the executive sponsor leans toward A, because the partner's campaign promises tracking to every customer and a cohort launch would make the campaign wrong for most of them. A's risk owner, the product sponsor, agrees to own its column as written. The sponsor picks A.

Now the job is to make the ownership explicit and run A as well as A can be run. The decision goes into the decision log the same day: which option, who chose it, which risks were accepted and by whom. Nobody relitigates it in side threads, including the tech lead. Effort moves to A's weak points: the feed load test pulled forward, the flag rehearsed in production.

Then set a threshold in advance, tied to the option's evidence gate. For A: if the build is not submitted by the internal cutoff, or a rejection pushes approval past a named day, the options go back to the sponsor. Said in advance, that is an instrument. Improvised later, it reads as going over someone's head.

The book puts the principle under all of this in one line, in its chapter on migrations: "The method does not promise agreement. It promises that the no comes from the person who owns the decision, with the cost in view." When the answer to your own ask is no, the same rule applies: record it, stop absorbing the gap, and let the cost sit where it was decided.

Handing the choice back is the default, not the only move. There are a few cases where the right sentence is a plain no, and the book names them:

• The deadline cannot move. A regulatory or safety deadline, or a vendor cutoff no one inside the company controls, is not a trade. Name it and plan backward from it.
• No one you can reach can rightly accept the risk. Regulatory, safety, security and privacy constraints are on the book's stop list. The instruction there is to hold the line.
• You are being handed accountability for a risk you cannot move. If you have neither credibility with the decision owner nor a path to them, the book's advice is direct: "the honest step may be to refuse the accountability rather than absorb a risk you cannot move."
• You are the only one still carrying it. Being able to lead without authority does not excuse the organization from providing the authority or the staffing the work needs. Name that gap to your manager.

Even then, a no lands better as a constraint with an owner than as a refusal: "this is a privacy constraint, and I cannot accept that risk on the team's behalf" survives the next meeting.

Before the Room gives each chapter a level line, and this one maps closely onto how interviewers score a pushback story:

From the hiring side, a strong pushback story has the same shape as the memo: what was promised, what it actually cost, the options, who chose, and what happened after. The story where the candidate refused and was proved right is weaker than it sounds, because the obvious follow-up is "who owned the date?". For how this fits the wider influence question, see the influence without authority interview question; for the status version of the same problem, see green status, red reality.

The strong column is not softer. It is harder to argue with, because it gives the other person a decision instead of a position to defeat. For the broader shift, see staff engineers change the decisions a team can make.

How do you say no to your manager as an engineer?

Make the cost visible instead of refusing. Say what you currently own, what taking the request would move, and what smaller thing you can offer without moving it, then ask which priority should give. Your manager can change priorities. What you refuse is pretending the new request costs nothing.

How do you push back on an unrealistic deadline?

Do not argue that the date is impossible. Name the promise hiding inside the date, then bring three options with named trade-offs, recommend one, and ask the person who owns the date to choose. On mobile, count review time, rollout and older app versions before you build the options, because that is usually where the date breaks.

Is this the "yes, and" technique?

Close to it, with one addition that matters. "We can, and here is the decision that comes with it" names the cost. The part that makes it work is the next question: whose call is that? A yes with a cost attached and no owner still lets the trade happen by default.

What if the deadline cannot move at all?

Then do not offer trades that do not exist. A regulatory or safety deadline, or a vendor cutoff nobody inside the company controls, is a constraint, not a negotiation. Say that plainly and plan backward from it. And where a risk is one nobody you can reach can rightly accept, such as a privacy or security constraint, hold the line.