HN Debrief

Ask for no, don't ask for yes (2022)

  • Management
  • Startups
  • Productivity
  • Workplace

The post recommends a simple workplace tactic: when a task is already in your scope but you want visibility or a quick gut check, do not ask for a positive approval. State the plan, set a deadline, and let the other person veto it. Readers treated that as useful shorthand for situations where ownership is clear and speed matters, not as a general way to manage up. The strongest consensus was that this only works when you are already the right person to decide, the action is low to moderate risk, and the people around you trust your judgment.

Use this as a coordination pattern, not a shortcut around approval. If you want teams to move this way, make scope, ownership, rollback expectations, and who must be notified painfully clear first.

Discussion mood

Mostly positive on the core idea, but only as a narrow tool for trusted people operating within clear ownership. The pushback came from people picturing it as a sneaky way to force manager approval or to push risky changes without real sign-off.

Key insights

  1. 01

    It works by shifting responsibility

    The point is not clever wording. It changes who owns the decision. Declaring a plan tells the other person you are carrying the burden unless they see a problem. That lowers their cognitive load and preserves their authority, because they can still stop it without having to actively sponsor it. This also explains why insecure employees over-ask. They think they are being considerate, but they are really pushing responsibility upward for work they should own.

    If you want this to land well, make the ownership legible. Use it only when you are prepared to own the outcome and cleanup yourself.

      Attribution:
    • notatoad #1
    • torben-friis #1
    • epolanski #1
  2. 02

    Rollback plans and stakeholder coverage decide credibility

    This pattern is only professional when the message includes enough detail for someone to spot a bad idea quickly. That means scope, timing, who is affected, and what happens if it goes wrong. The useful examples were concrete operational notices with a clear rollback path or low blast radius. The hostile reaction shows what happens when the same template is used for production-risky work without that scaffolding. Then it reads as recklessness dressed up as initiative.

    Before using default-yes language, write the message as if someone needs to veto it in 30 seconds. If you cannot summarize impact and rollback cleanly, you are not ready to send it.

      Attribution:
    • dspillett #1
    • neilv #1
    • slowcache #1
  3. 03

    Managers often want finished work, not question queues

    Several operators said this style is valuable because it prevents teams from turning every small decision into manager work. The better outcome is an inbox with completed tasks and a few corrections, not an inbox full of permission requests. One commenter said they now encode this rule in staff docs and even in AGENTS.md for LLM-assisted work, because forcing assumptions and post-hoc documentation is cheaper than answering endless clarifying questions. That extends the idea beyond management style into workflow design.

    If you lead a team, document where autonomous decisions are expected and ask for written assumptions after action. You will cut approval traffic and surface the rules that actually need to be made explicit.

      Attribution:
    • tyre #1
    • icantevenhold #1
    • dools #1
  4. 04

    This is an old pattern with established names

    People recognized the tactic as "lazy consensus" rather than a novel management trick. Another comment tied it to Chris Voss's "Never Split the Difference", where prompting a "no" can feel safer than demanding a "yes". That matters because it reframes the article from quirky advice into a known coordination mechanism. The idea has already been battle-tested in groups that need motion without unanimous active approval.

    If you want adoption, present this as an existing operating norm, not a personal hack. Known labels make it easier to train teams and to define where the pattern does and does not apply.

      Attribution:
    • gwd #1
    • tuatoru #1
    • unstatusthequo #1

Against the grain

  1. 01

    With your manager, this can look like a power play

    The sharpest objection was that giving your manager an opt-out deadline can read as disrespectful rather than efficient. In that framing, you are not reducing work for them. You are trying to convert their silence into approval. That is especially toxic when they are slow to respond or when the boundary of your authority is fuzzy. The only place this holds up is where startup norms are broad enough that nearly everything is implicitly in play and managers are expected to unblock, not gatekeep.

    Do not assume this wording is neutral. Test it against your actual power structure first, especially if you are communicating upward rather than laterally.

      Attribution:
    • crazygringo #1
    • kstrauser #1
  2. 02

    Default consent can feel manipulative

    Some people recoiled because the structure resembles opt-out tactics used in advertising or other dark patterns. The discomfort is not just about management hierarchy. It is about using silence as consent when the other side may not be watching closely. In low-trust environments, that kills the whole premise. The same sentence that signals ownership in one culture signals gamesmanship in another.

    If your org already has trust or incentive problems, this pattern will amplify them. Fix the trust issue before trying to speed decisions with opt-out language.

      Attribution:
    • Simulacra #1
    • reader9274 #1
    • EGreg #1

In plain english

AGENTS.md ↩
A repository file used to give coding agents persistent instructions about the project, workflow, or conventions.
blast radius ↩
The scope of systems, users, or functions that could be affected if a change goes wrong.
lazy consensus ↩
A decision-making pattern where a proposed action moves forward unless someone objects within a set time.
LLM ↩
Large language model, a type of AI system trained on huge amounts of text and code that can generate responses or software from prompts.
prod ↩
Production, the live version of a software system that real users depend on.
rollback ↩
A planned way to undo a change and return a system to its previous state if something goes wrong.

Reference links

Books and frameworks

Prior discussions and references