You need formal sign-off on an architecture decision from a stakeholder who keeps deferring - not rejecting it outright, just never quite approving it - and the deadline to start implementation is now days away. What do you do?

## Why deferral is corrosive A stakeholder who neither approves nor rejects an architecture decision, but simply keeps deferring, is one of the more corrosive failure modes in sign-off processes, because it doesn't trigger the obvious response a flat rejection would - there's no explicit objection to address, just a decision that never lands, quietly eating the project's schedule margin. The mechanism for handling it has three parts: 1. **diagnose the real cause of the stall**, 2. **address that specific cause** rather than just repeating the ask, 3. and if that doesn't resolve it, **force the decision** by setting a real deadline with real consequences and, if necessary, escalating past the stalled stakeholder. ## Diagnosing the cause Diagnosis comes first because 'won't sign off' has several distinct causes that need different responses. - **Sometimes it's a genuine unresolved technical or business concern** the stakeholder hasn't fully articulated - a direct one-on-one conversation, rather than another version of the same document, is usually what surfaces it. - **Sometimes the stakeholder doesn't actually understand** what they're being asked to approve well enough to feel comfortable signing, which is a communication failure fixed by walking through it live rather than relying on written material. - **Sometimes the stakeholder has no real objection**, but sign-off means putting their name against a decision that could go wrong, and in an organization where being the named approver of a failure carries real career risk, indefinite deferral is a rational, if unhelpful, way to avoid that exposure without the discomfort of an outright rejection. - **And sometimes the decision is simply genuinely low priority** for them relative to everything else on their plate. ## Matching the fix to the cause Each cause needs a different fix. - **A real unresolved concern** needs to be surfaced and addressed on its merits. - **A comprehension gap** needs a better explanation, not a harder push. - **Risk-aversion around being the named approver** often responds well to making the decision genuinely shared, or explicitly framing what's being asked as 'accept this specific, bounded residual risk' rather than an open-ended, unbounded endorsement, which is smaller and more comfortable to sign off on. - **Simple deprioritization** usually responds to making the cost of continued delay concrete and visible to the stakeholder and their manager - most people move an item up their list once they see the actual schedule or dollar cost of not deciding. ## Forcing the decision If diagnosis-and-fix doesn't produce a decision and the deadline is close, the next mechanism is forcing the decision explicitly rather than letting it drift. This means setting an actual date with an actual consequence attached, like 'if we don't have a decision by Thursday, we proceed with option A and document the residual risk as accepted by default,' and communicating that consequence in writing to the stakeholder and anyone who needs to know the timeline is at risk. This isn't a threat; it's making an implicit cost, the one already being paid by silent deferral, explicit, so the stakeholder faces a clear choice instead of a comfortable, cost-free non-decision. ## Escalating, and how to frame it If the stakeholder's sign-off is genuinely required by policy and they still won't commit, the final mechanism is escalation - going to their manager or a governance body with authority to force the decision. This needs careful framing: the escalation is about timeline and risk to the project, not a complaint about the individual, and should be paired with a clear account of what's already been tried so it reads as a reasonable last step rather than the architect going over someone's head at the first sign of friction. ## The trade-off The trade-off throughout is relationship cost versus schedule cost: pushing hard on a stalled stakeholder, and especially escalating past them, can damage a working relationship the architect will need again on the next project, so it should be proportionate to what's actually at stake and only after the softer diagnostic approach has genuinely been tried. Escalating too early burns trust for no real gain; escalating too late burns both the schedule and, eventually, the same trust anyway. ## The failure mode A common failure mode is the architect interpreting silence as implicit approval and proceeding without ever forcing an actual decision, which feels efficient but leaves the project exposed, because if something goes wrong, the stakeholder can credibly say they never actually signed off on it. The healthier pattern - explicit deadlines, explicit consequences, and a documented decision or escalation - is what makes sign-off actually mean something rather than being a formality nobody can point to later.