Disagree With the Brief
Push back on a requirement that will not survive contact with reality — with a specific failure case and a way forward.
When to reach for it
When you have been asked to build something you believe is wrong, and the options in your head are silent compliance or an argument you have not prepared.
What changes
- The objection is stated as a specific failure — the case, the user, the number, the device where it falls apart — rather than as a feeling about quality.
- The goal gets separated from the requested solution and confirmed out loud, which resolves a surprising share of disagreements before they start.
- You check whether you are right before you speak, cheaply: real numbers, a query, half an hour of prototype.
- Every objection arrives with an alternative that serves the same goal, or an explicit admission that you have none.
- If the answer is still no, the decision and the risk you raised are written down, and you build it properly instead of building it resentfully.
Pairs with
- Estimate HonestlyGive a range, name the assumptions holding it up, and say what it would take to make it narrower.
- Ask One QuestionWhen you are blocked, work out the single question that unblocks the most — and ask that one, well.
- Explain the WhyRecords the reasoning a diff cannot show — what you rejected, and what would make this the wrong choice later.
Disagree With the Brief
You have been asked to build something you think is wrong. The useful move is neither silent compliance nor a fight; it is a specific objection carrying a way forward.
1. Restate the goal and get it confirmed
Say what you believe this requirement is for, in one sentence, and check it. A surprising number of disagreements end here, because you were arguing with a mechanism that was never the point.
2. Find the failure case
An objection is only useful when it is concrete. Name it:
- What breaks, exactly
- At what volume, on what device, for which kind of user
- How often that case really occurs
- What the person on the other end sees when it happens
"This does not scale" is a feeling. "At two hundred rows the page freezes for four seconds on a mid-range phone" is an argument.
3. Check whether you are right
Cheaply, before speaking: look at the real numbers, run the query, prototype the risky part for half an hour. Being wrong here is fast and free. Being wrong out loud twice costs you the next objection, which may be the one that mattered.
4. Price both directions
What it costs to build as asked and be wrong. What it costs to build your way and be wrong. Say both. An objection that only counts one kind of mistake is a preference in a suit.
5. Bring an alternative
Something that serves the same goal, plus a smaller version that tests the assumption first. If you genuinely have no alternative, say that too — it is real information and it changes the conversation honestly.
6. Say it once, where the decision is made
Not in a side channel, not after the fact, not as a comment in the code six weeks later. Once, clearly, to whoever decides.
7. If the answer is still yes, build it well
Record the decision and the risk you raised, in writing, without editorial. Then do the work properly. A half-hearted build proves nothing except that you are difficult to work with.
Rules
- Do not disagree by going slow, or by building it badly on purpose.
- Do not argue from taste. Ugly is not a failure case.
- Do not repeat an objection that has no evidence behind it. Go and get the evidence, or let it go.
- Do not reopen a decision you already lost unless something new has appeared, and then lead with what is new.
- Do not aim any of this at the person who wrote the brief. The requirement is wrong; they are just the one holding it.