# How do you ask for disagreement?

**Asking for disagreement** works when you make the work easy to challenge and the social risk small enough to accept. Share the proposal, reason, and tradeoff in a short note. Keep your preferred answer private until people have examined the choice. Then replace “any questions?” with a concrete invitation such as “What risk am I missing?” or “What would make this fail?” The wording should direct attention toward the decision, not ask someone to judge you as a person.

        
## What should people receive before the meeting?

        
Send enough context for a useful objection. Name the decision, why it matters now, the option under consideration, and the cost you already see. For a design review, explain that the team needs an architecture that supports regional failover, that one option is familiar but expensive to operate, and that capacity evidence is incomplete. A short note gives silence a target. People can mark an assumption, gather a number, or prepare an alternative instead of reacting to a speech.

        
Keep the note short enough to read. A long document can hide the real choice as effectively as no document. Put supporting detail behind links and state which parts are open. If the deadline or budget is fixed, say so. If the implementation remains open, say that too. People are more willing to challenge when they know their effort can affect something real.

        
Do not include a paragraph about why your own answer is obviously best. Managers often believe they are merely providing clarity, but authority makes preference louder. Once a popular manager says “I strongly favor option A,” a quiet senior engineer must challenge both the design and the room's emerging alignment. Share the evidence first and your preference after independent views have surfaced.

        
## Which question should you choose?

        
Choose a prompt that requests the missing type of information. “What risk am I missing?” is useful when a plan appears complete but may hide operational effects. “What would make this fail?” encourages people to imagine conditions rather than declare support. “What would you do differently?” requests an alternative. “How can we improve this approach?” works when the direction is likely sound and you want changes rather than a verdict.

        
“Tell me why this is a bad idea” is direct and gives someone permission to build a counterargument. Use a curious tone and make clear that the person is testing the work. It can be especially useful when a design review has drifted into admiration for a polished proposal. Ask the room to find the most serious reason not to proceed, then compare that reason with the expected benefit.

        
Use “What am I getting wrong?” carefully. Some managers intend humility, but the wording centers the manager and can sound like an invitation to accuse them. A report may soften a technical concern to protect the relationship. You usually get cleaner information by asking what assumption is weak, what risk is absent, or what part of the approach should change.

        
## How do you avoid signaling the preferred answer?

        
Separate framing from advocacy. At the start, state the customer need, engineering constraint, and decision deadline. Ask people to review options before you rank them. If you created the proposal, name that fact without turning authorship into ownership: “I drafted this so we have something concrete to test.” A draft should be easy to alter.

        
Watch nonverbal and procedural signals. Calling first on a close ally, praising the proposal before debate, or describing objections as blockers tells the room what response earns approval. Ask the person closest to operations for risk, the person who will maintain the system for cost, and the product partner for scope effects. Different roles should inspect the choice from their real responsibilities.

        
If your authority requires a recommendation, give it after the challenge round. Explain what you prefer and which evidence could change your mind. A recommendation with conditions is more open than a confident conclusion followed by “thoughts?” The sequence allows teammates to form an account before adapting to yours.

        
## What should you do with the silence after asking?

        
Wait long enough for thinking. A precise question is not magic if you answer it three seconds later. People may be scanning the note, deciding whether their point is material, or watching whether someone with more status moves first. Say that you will give everyone a minute to write one risk. This converts an awkward pause into expected work.

        
Offer more than one route. Invite comments in the document before the meeting, let people send a concern privately with permission to attribute or anonymize it, and ask relevant owners directly without demanding instant performance. A quiet senior engineer may have a strong architecture objection and still dislike contradicting a popular manager in a crowded room. Written preparation lets the quality of the point lead.

        
Do not read silence as agreement. State what you heard and what remains untested. If nobody addressed support load, leave that question open and assign someone to check it. Silence is missing evidence. Treating it that way prevents a pleasant meeting from becoming false consent.

        
## Which prompt fits each decision?

        
| Situation | Prompt | Information sought |
| --- | --- | --- |
| Design review | What would make this fail? | Failure conditions |
| On call change | What burden am I missing? | Human cost |
| Scope cut | What outcome disappears? | Customer effect |
| Chosen direction | How can we improve this approach? | Better execution |

        
A prompt should be specific without leading people toward a ceremonial answer. Asking “Does anyone see a huge risk?” implies that only dramatic objections count. Asking “Which assumption needs evidence?” welcomes a narrower but valuable challenge. Match the threshold to the decision and invite ordinary uncertainty before it becomes a crisis.

        
Repeat the useful prompts often enough that they become normal. When every design note includes a failure question, dissent stops looking like a special act against the manager. It becomes one expected part of engineering work.

        
## What sequence produces useful disagreement?

        
- Write the proposal, reason, and tradeoff.
- Mark what is open and what is fixed.
- Let people review before you state a preference.
- Ask one specific question about the work.
- Wait and offer a written route.
- Test the strongest objection fairly.
- Record the point and the decision.

        
The sequence protects independent thought and creates a visible path from question to outcome. It does not guarantee opposition. Sometimes the team will find the proposal sound. The difference is that agreement follows a real test rather than the manager's confidence.

        
Use the sequence proportionately. A reversible tool choice may need a short note and five minutes. A major on call change deserves workload data, time for comments, and explicit review of fairness. Structure should serve the consequence, not become ceremony.

        
## How do you know the invitation is credible?

        
Observe what happens over several decisions. People should begin naming concerns earlier and with less cushioning. They may say “the failover assumption is unsupported” instead of opening with praise and apologizing for a small thought. Cleaner language suggests they believe the work can be challenged without managing your feelings.

        
Check whether different people participate. If only one confident engineer responds, the invitation may work for that person but not for the team. Ask whether the preparation time, meeting size, or public format blocks others. Change the route and compare what information appears.

        
Most importantly, connect questions to outcomes. Thank the challenge, investigate it, and later state what changed or why the original decision held. An unanswered invitation teaches people that disagreement is theater. A visible response teaches them that the next question is worth answering.

        
## How should you adapt the invitation to engineering work?

        
Engineering choices have different failure surfaces, so direct the question toward the people who can inspect each one. In a design review, ask the maintainer which dependency is likely to become operational debt. For an on call change, ask each person what coverage assumption fails during holidays or simultaneous incidents. For a scope cut, ask product and engineering separately which outcome or safety margin disappears. One broad invitation rarely reaches all of these concerns.

        
Use artifacts to reduce status effects. Let reviewers comment on assumptions before names are attached to positions, or collect risks in a shared note before discussion. You do not need anonymous voting for ordinary decisions. You need enough independent thought that the manager's preference is not the first fact everyone must process. When comments differ, group them by claim and evidence rather than by seniority.

        
End by reflecting what you asked for and what arrived. Say that the team identified migration risk and support burden but found no evidence against the customer timing assumption. That summary reveals the remaining gap without forcing debate to continue. It also helps the team improve future review. They can see that a useful challenge is concrete, connected to the choice, and recorded even when it does not become the final answer.

        
Before closing, ask someone to state the strongest unresolved concern in one sentence. This final check often reveals whether the discussion tested the proposal or merely improved its presentation. Put that sentence beside the decision so later evidence has a clear place to return.

## What are common questions?

### What is a better question than any questions?

Ask for a specific kind of information, such as a missing risk, failure condition, weak assumption, or different approach.

### Should a manager share a preferred option first?

Usually no. Let people inspect the proposal and evidence before authority shapes their answers.

### Is tell me why this is a bad idea too negative?

It can be useful when the tone is curious and the purpose is to test the work rather than stage conflict.

### How long should a manager wait after asking?

Give people real thinking time, or ask them to write briefly before anyone speaks.

### What if nobody disagrees?

Do not assume consent. Name what was tested, identify missing evidence, and leave a clear route for later concerns.

Related: [why being liked is not being trusted](https://isilta.com/blog/why-being-liked-is-not-being-trusted/), [handling the first disagreement](https://isilta.com/blog/how-to-handle-the-first-disagreement/), [explaining a hard decision](https://isilta.com/blog/how-to-explain-a-hard-decision/).