Objection Triage

A design review produces eleven written comments. Security wants an additional control. Finance objects to the three-year cost shape. A principal engineer prefers a different message broker. The platform team notes the paved road does not support the chosen runtime yet. The product director thinks the first release is too small.

Treated as one list, these consume four weeks and the architect concedes on whichever point its author pushed hardest. Treated as three categories, most of them are closed in a day.

Why it matters

The cost of a review is not the meeting; it is the elapsed time between the meeting and the decision, which in many organisations runs to weeks. That delay has a second-order effect: teams hedge against slow decisions by building optionality they do not need, so a slow review process does not merely delay designs, it makes them more complicated.

Triage attacks the delay directly. It also protects against the worst failure of a review, which is that the loudest objection is treated as the binding one while a quiet, genuinely binding constraint is recorded as a comment and forgotten until build.

Implementation patterns

• Three buckets, decided by one question: what happens if we proceed anyway?
• Constraint — the design is not permitted or will not work. A legal obligation, a data residency rule, a contractual notice period, a hard capacity limit. Response: redesign.
• Cost — the design is permitted but someone's number gets worse. More run cost, a longer timeline, more operational load on another team. Response: re-price and let the budget holder choose.
• Preference — the objector would have built it differently. Response: record it, name the decider, move on.
• Make the objector state the bucket. Asking "is this a constraint or a preference?" in the review changes behaviour, because few people will claim constraint status for a taste.
• Demand the source for every claimed constraint. A clause, a regulation with its article, a contract page, a measured limit. Constraints that cannot be sourced are preferences wearing a uniform, and the single largest source of unnecessary redesign.
• Take the constraint-holders first and separately. Compliance, legal and finance usually hold the constraints; their objection changes the design, while most others change the plan. Reviewing them in the wrong order means designing twice.
• Price costs in the currency of the person who holds the budget, not in engineer-days. A control that adds 12% to run cost and 60 days to the date is a sentence a budget holder can act on; "significant extra work" is not.
• Give preferences a written answer, not silence. An unanswered preference returns as an escalation at the worst moment.

Industry example

Regulated change is the clearest setting. Under an operational-resilience regime of the kind European financial firms prepared for through 2024 and 2025, a requirement to hold tested exit plans for critical third-party arrangements is a constraint: no amount of senior sponsorship makes a design without one acceptable. A preference for a particular cloud provider inside that design is not. Teams that fail to separate the two spend their programme time arguing about the second while the first quietly slips.

Failure scenarios

• Seniority substituted for classification. The most senior objection wins, which teaches everyone to escalate rather than to explain.
• A real constraint recorded as a comment. Found during build, it costs a redesign at the point where the cost is highest.
• Preference inflation. Once one engineer's taste is accepted as a constraint, every subsequent reviewer frames theirs the same way.
• Costs accepted silently by the architect. Agreeing to a control that adds 12 weeks without taking it back to the budget holder transfers a commercial decision to the wrong person.
• No record of what was decided, so the review repeats when the sponsor changes.

Trade-offs

The practice is confrontational by design: asking someone to classify their own objection makes a social cost explicit. Some reviewers find it bureaucratic, and in a small, high-trust team it is overhead — three engineers around a screen do not need a taxonomy.

What it buys is time and honesty. A review that closes in days rather than weeks removes the incentive to over-build for optionality, and the written record of accepted costs and recorded disagreements is the artefact that survives a change of sponsor.

When not to use it

Skip it when the group is small enough that disagreement is resolved in conversation, and when the decision is reversible and cheap — classifying objections to a change you can undo in an afternoon costs more than the change. Avoid it in a genuinely exploratory review, where the point is to generate options rather than to close them; applying triage too early shuts down the preference-shaped comments that are often the best ideas in the room.

It is also the wrong tool for a political problem. If two directors disagree about who owns a capability, no classification scheme resolves it, and pretending it is a technical objection wastes everyone's week.

Interview question

Q: Your design review produces a long list of objections from five functions and you have one week before the build starts. How do you work through it, and how do you handle someone who insists their preference is a constraint?

What a strong answer covers: classifying by what happens if you proceed; requiring a source for every claimed constraint; sequencing constraint-holders first because they change the design rather than the plan; returning costs to the budget holder instead of absorbing them; writing down recorded disagreements with the named decider; and handling the inflated constraint by asking for the clause rather than by arguing about judgement.

Quick check

Quiz: A reviewer says the design "must" use the platform's standard broker. What single question tells you whether that is a constraint? Ask what happens if you proceed without it — if the answer is a policy clause or a support withdrawal, it is a constraint; if the answer is discomfort, it is a preference to record.

Flashcard: What are the three buckets an objection falls into and what does each oblige you to do? — Constraint: redesign. Cost: re-price and hand the choice to the budget holder. Preference: record it with the named decider and proceed.