Options-With-Consequences

"We cannot do that" invites a negotiation about whether engineering is being obstructive, and against a revenue deadline that negotiation resolves the same way every time.

"Here are three ways to do it and what each costs" invites a business decision — and it establishes the constraint as a fact about the system rather than an opinion about priorities.

Why it matters

The architect rarely owns the trade-off. Whether 150ms on the order path is acceptable is a business judgement, and the architect's contribution is to make it a judgement rather than a guess.

It also protects the cases where the answer genuinely must be no. A team that has never said anything but no is not heard when it matters; a team that routinely produces options is.

Implementation patterns

• Three options where possible, including the fast one with its cost stated concretely.
• Consequences in the listener's vocabulary. Not "adds a synchronous call to a service with a p99 of 150ms" but "orders acknowledged 150ms more slowly, and during the market open that is when customers notice most". The translation is the architect's job, and it is where most of these conversations fail — not because the analysis was wrong but because it was unusable by the audience.
• Include "do nothing" as an option with its cost, since it is always available and is frequently right.
• State what would change the recommendation, which makes it a position rather than a preference.
• Be honest about the recommendation's weaknesses, which is more persuasive rather than less — a presentation with only benefits invites the audience to hunt for the omission.
• Avoid anchoring, which means not including a deliberately bad option to make the preferred one look reasonable. It is detected and it costs credibility.

Industry example

Trading platforms such as Zerodha have a hard, quantified constraint on the order path, which makes the conversation unusually concrete: a feature's latency cost is measurable and its consequence is describable in terms the business already tracks.

Most domains are less clear-cut, and the discipline is therefore harder and more necessary — the less measurable the constraint, the more the framing determines the outcome.

Failure scenarios

• Presenting a binary, which loses against a deadline.
• Options presented in engineering terms, which the decision-maker cannot evaluate.
• Omitting "do nothing", so the discussion assumes something must be built.
• Anchoring with a straw option, which is noticed.
• Escalating without a recommendation, which asks someone with less context to decide.

Trade-offs

Producing three costed options is more work than raising an objection, and some of that work is on options nobody will choose. It also risks the business selecting the fast, damaging option — which is a real possibility and is the correct outcome of a properly informed decision.

An architect who withholds the fast option to prevent it being chosen has substituted their judgement for the accountable person's, which works until it is discovered and then permanently damages the relationship that makes the role effective.

Interview question

"Product wants a feature that will measurably slow your most important path. Write me the three sentences you would say in the meeting, and tell me what you do if they pick the option you recommended against."