Saying no on the merits

Day 21: Saying No on the Merits When Building Is Nearly Free

'We don't have capacity' used to end the conversation. Now everyone in the room has watched an agent build something just like it before lunch, so the sentence doesn't hold up anymore. As a lead you get a vote on what gets built, and the vote that matters most is your no. Most of us only ever learned one way to cast it. Today you learn a better one.

The moment the old excuse stopped working

It was a Tuesday planning meeting. A PM asked for a configurable export pipeline for one customer. I was halfway through 'we don't have capacity for this sprint' when I realised it wasn't true. An agent could have drafted the whole thing before lunch, and the PM knew it, because they'd watched us ship three similar things that month. I stopped mid-sentence. Capacity wasn't my real objection. I didn't think the feature should exist. I had just never needed to say that out loud.

This lesson is about that gap between the reason you give and the reason you actually hold.

The hidden subsidy: effort used to make our hardest calls for us

For most of software history, building was expensive, and that cost quietly did a job for us. It filtered requests before anyone had to argue about whether they were any good. 'No capacity' was polite and hard to argue with, and it hid a judgment call. Nobody had to say 'this is a bad idea.' We said 'not now', and 'not now' usually became 'never'.

The subsidy had a weakness: it only worked when the cost was obviously high. In my founder years an enterprise prospect asked for a custom workflow feature. It looked small, so I said yes because we 'could squeeze it in.' Squeezing it in meant a branch. The branch became a fork, and we maintained that fork for about eighteen months. Every security patch, framework upgrade and new core feature had to be done twice or deliberately skipped for that customer. Building it took weeks. Owning it cost a year and a half of the team's attention. Nobody in the meeting did that maths, including me, because the only question anyone asked was whether we had time to build it.

• ▹Effort-no: 'We can't build it.' This is an argument about the builder's time.
• ▹Merit-no: 'We shouldn't own it.' This one is about the product, the system and where the team will be a year from now.

What changed: the cost moved from building to owning

With Claude Code, Cursor or Copilot in agent mode, the answer to 'can we build it?' is nearly always yes, often by Friday. Building isn't scarce anymore. Owning still is, and owning is where the real cost always was:

• ▹On-call. Someone gets paged when it breaks, and they need a working mental model of code they may never have read line by line.
• ▹Upgrades: every dependency bump, framework version and API change has one more surface to touch.
• ▹Cognitive load. It's one more thing the team has to keep in their heads while they work on everything else.
• ▹Roadmap lock-in, meaning the data models, public APIs and customer expectations you can't easily walk back once they ship.
• ▹Review and verification. Someone has to understand agent output well enough to approve it, and human attention is still finite.

An agent-written PR that passes its tests in four minutes is the cheapest part of the feature's life. The expensive part comes at 2am, when an engineer who didn't write it and didn't review it closely is trying to work out from a generated diff what it was meant to do. Agents bring the cost of producing code close to zero. They do much less for the cost of understanding it, and nothing at all for the cost of being responsible for it.

Why this matters for your career right now

Days 1 to 20 were mostly about delivery: shipping reliably, communicating clearly, using agents well. The step up to lead works differently. You get promoted because people trust you to decide what not to deliver, and there are two common ways to get that wrong:

• ▹The yes-machine says yes to everything because agents make it easy. Your output looks impressive, your team's surface area grows without limit, and leadership starts seeing you as throughput instead of judgment. Agents are turning throughput into a commodity.
• ▹The capacity-hider keeps saying 'no time.' Then someone watches an agent build the thing in an afternoon, and you lose credibility on more than that one request. People start wondering which of your other no's were cover stories too.

A lead's credibility rests on their reasons. When your reasons are honest and stated, people can disagree with you and still trust you. When they're pretexts, people stop trusting you even on the calls you get right.

The merit-no toolkit: three questions before any yes

• ▹1. Who owns this in six months, by name? 'The team' doesn't count. If you can't name one person who will understand it, keep it running and get paged for it, then it has no owner, and code without an owner is a liability that just hasn't come due yet.
• ▹2. What does this make harder to change later? Look for new data models, public APIs, per-customer branches, vendor dependencies and anything promised in a sales contract. Reversible things are cheap. Anything that sets a constraint is expensive, however fast it was built.
• ▹3. If it were free to build, would we still want it to exist? This is the question that matters most, because it takes effort out of the decision completely. If the honest answer is 'not really', that's your no. Capacity was never the reason.

In practice I ask question 3 first. It filters fastest, and it's the one people dodge most, because you can't answer it without having an opinion.

Scripts that keep the relationship intact

A merit-no is still a no, and the person asking still has a real problem. Your job is to make the no easy to accept. Here are three phrasings I use:

• ▹'We could ship this by Friday, and here's what it would cost us in March.' Capacity is off the table, and everyone can see the ownership cost.
• ▹'Yes to the problem, no to this solution.' The need is usually valid. The proposed implementation is often the expensive part. Separate them, then offer something cheaper: a config flag, a report, a manual process, or an integration someone else maintains.
• ▹'Not no, not yet: here's what would change my mind.' Name concrete conditions, such as three more customers asking, a named owner, or the migration being finished first. A closed door becomes a stated threshold.

Then write it down in one ADR-style paragraph. People can revisit a recorded decision calmly six months later. A no you only said out loud sounds like a mood, and moods get relitigated.

## Decision: Not building per-customer export pipeline (2026-10-13)

**Request:** Configurable export pipeline for Customer X (PM: ___).
**Decision:** No, for now.
**Why (merits, not capacity):** No named owner after Q1; it introduces a
per-customer code path we'd maintain through every schema change; and if it
were free, we still wouldn't want a one-off fork of the export layer.
**Instead:** Expose the existing CSV export via API; Customer X transforms on
their side.
**Would revisit if:** 3+ customers need the same shape, OR we ship the
export-layer refactor that makes configuration first-class.

Turn it on the agents, too

By default, agents are yes-machines: give them a ticket and they produce code. That's useful, and it's also how a codebase fills up with things nobody actually decided they wanted. Add a 'should this exist?' step before generation. Before you ask the agent to build anything, ask it to argue against the ticket:

Before writing any code, act as a skeptical staff engineer reviewing this ticket.

1. Argue that this should NOT be built. Give the strongest case.
2. List what this adds to ongoing ownership: on-call surface, dependencies,
   data model changes, anything hard to reverse.
3. Propose the smallest alternative that solves the underlying problem
   (including 'do nothing' or 'change a process').
4. Verdict: BUILD / BUILD SMALLER / DON'T BUILD, with one-line reasoning.

Do not write implementation code in this step.

Ticket:
<paste ticket>

Kill the tickets that don't survive the argument. The ones that do survive, you'll build with more confidence. Some will shrink to a third of their size. A few will turn out to be the wrong idea, and you'll find that out before you own them.

A note from my PhD work on multi-agent systems: in my experience, architectures with an explicit critic, verifier or veto role tend to hold up better than ones where every agent just produces more output. Published work points the same way. In the multi-agent debate study by Du et al. (2023), models that critiqued each other's answers over several rounds did better on factuality and reasoning tasks. Reflexion (Shinn et al., 2023) improved agents by having them reflect on their own failures before retrying. If every node in a system generates and none can refuse, errors pile up with nothing to stop them. Teams behave the same way. A team where nobody holds the critic role doesn't move faster. It just piles up more stuff.

Common pitfalls

• ▹Swapping one cover story for another. 'It's tech debt' or 'it's not strategic' with no specifics is still 'no capacity', just reworded. Name the actual cost.
• ▹Saying no to the person instead of the proposal. Always acknowledge the problem behind the request.
• ▹Never saying yes. Your merit-no only carries weight if you also give a fast, clear yes when something passes the three questions.
• ▹Skipping the write-up, so the same request comes back in three weeks and you start from zero.
• ▹Treating the agent's 'tests pass' as 'safe to own'. Passing tests tell you it works today. They don't tell you whether you can live with it.

Today's exercise

• ▹Open your current backlog or this week's incoming requests.
• ▹Pick one item you'd normally defer with 'no capacity' or 'not this sprint'.
• ▹Run it through the three questions.
• ▹Write the merit-based no in three sentences: what it would cost to own, what it would block or lock in, and what would change your mind.
• ▹Say it out loud in your next planning meeting, and pay attention to how the conversation differs from a capacity-no.

Tomorrow, Day 22, builds on this. Once you can say no on the merits, you need an equally deliberate way to decide what gets your yes.

Extend your knowledge

• ▹Read Michael Nygard's original 'Documenting Architecture Decisions' post (2011) and adapt the ADR format for declined feature requests.
• ▹Read Will Larson's 'An Elegant Puzzle' and 'Staff Engineer'. Focus on the parts about sizing and prioritising team work, setting technical direction, and writing decisions down.
• ▹Skim Du et al. (2023), 'Improving Factuality and Reasoning in Language Models through Multiagent Debate', to see how having agents critique each other's answers improved results in their experiments.
• ▹Add the 'argue against this ticket' prompt to your team's agent workflow, as a slash command or a pre-generation step, and track how many tickets it shrinks or kills over two weeks.