Conditional Acceptance

A blanket no is a shock—almost an insult. An unconditional yes feels generous, but generosity can destroy the economics of a shared system.

There is a useful middle ground: conditional acceptance. Say yes, provided the requester meets one reasonable condition.

I learned this while managing a network department in a large institution. Firewall changes moved through a queue. Each change needed security review, technical review, deployment, and synchronization. The process took a few days because the work had real steps and real costs.

Every so often, a manager would approach someone in the department and ask whether one change could be expedited. The request sounded small and personal. That was exactly the problem.

The cost of saying yes was visible in the queue: one expedited change pushed other projects back, and some requests were already being moved quietly, almost under the table.

But saying no had a cost too. In an earlier case, the same person was told that his request could not be expedited. He answered loudly enough for much of the office to hear: “Oh, so now you’re refusing to help me.”

That accusation created tension and pushed the problem to a flashpoint. A simple refusal protected the queue, but it made the department look unhelpful and turned a process decision into a personal confrontation.

A request that was free to make

The queue existed for a reason. Moving one person ahead moved everyone else back. Yet the earlier confrontation showed that a blanket no left the person receiving the request exposed to a noisy accusation of refusing to help. We needed to protect the queue without turning every exception request into a personal conflict.

So I invented a simple policy.

If you want an expedited change, fill out a short form. State why the request is important and why it must be done quickly. Both answers are required.

This was not another approval layer. We did not ask for a business case, executive sponsorship, or a committee review. We said: just disclose why, and we will expedite it.

Not one person did.

The form was easy. The questions were obvious. Yet every request disappeared.

The condition priced accountability

The real cost was not writing two sentences. The real cost was putting a name beside a claim.

A corridor request creates no durable record. It asks for an exception while keeping the reason off the books. A written request invites scrutiny. It makes a follow-up question possible: if this is urgent now, and the project has been running for months, why did you wait this long?

Nobody had to ask that question. The form made it askable, and that was enough.

The condition also helped the requester make an honest assessment. Was the delay really severe? Apparently, it was manageable enough that writing two answers cost more than waiting in line. The policy did not reject those requests. It revealed what they were worth to the people making them.

This is the accountability function of a record. As I argued in Governance Is a Record, Not a Judge, a system does not need to decide whether a claim is good. It can simply preserve the claim in a form that makes the responsible person answerable for it.

The policy also removed the fairness argument. Once the condition was public and consistently applied, nobody could reasonably say that the department refused to help. The department had offered help. Requesters declined the terms.

The middle ground between no and yes

An unconditional yes breaks the economics because bypassing the process costs the requester nothing while imposing work and delay on everyone else.

A blanket no has a different defect. It treats every exception as illegitimate before hearing it. It can turn a reasonable request into a conflict and spend goodwill from the team's political ledger for no useful purpose.

Conditional acceptance preserves both possibilities.

A genuine need can satisfy the condition and move forward. A discretionary preference can withdraw without a fight. The manager does not need to accuse anyone of exaggerating. The condition does the sorting.

This resembles the consent structure in Work Assignments as Contracts: obligations should be explicit, proportionate, and accepted with their real costs visible. The requester is not forbidden from asking. The provider is not forced to pretend the exception is free.

Friction is only the instrument

Friction has a bad reputation for good reason. It is also the favourite tool of dark patterns.

The US Federal Trade Commission describes dark patterns as designs that can impair consumer choice—for example, by making cancellation difficult, obscuring important terms, or steering people into actions they did not intend. Its report on dark patterns documents friction designed to make the user fail or give up.

Conditional acceptance uses friction in the opposite way.

A dark pattern hides the path or makes the condition effectively impossible to satisfy. A legitimate condition states itself plainly and is designed to be met. It protects a shared process rather than extracting value from the person facing it.

That distinction can be tested:

• Is the condition visible before the decision?
• Is it proportionate to the cost or risk it protects?
• Can a reasonable person satisfy it?
• Does satisfying it actually produce the promised yes?
• Does the benefit run toward the shared system, rather than only toward the operator?

The last question matters. Trace the Downline argues that a system inherits the direction of the outcome it supports. The firewall form protected everyone waiting in the queue. A cancellation maze protects the company from the customer's choice. Both create friction. Their downlines point in opposite directions.

One reasonable condition

The condition must be reasonable. It should not be unusual or cruel. You should be able to reason your way through it, and a casual observer should be able to look at it and say: yes, why not?

It also needs an emergency path. A junior employee, a person writing in a second language, or someone handling a real crisis may have a legitimate need and little ability to present it elegantly. The purpose is to price discretionary demand, not suppress emergencies. Plain answers should be enough, and help should be available when the form itself becomes the obstacle.

The design sequence is simple:

1. Identify the real cost that an exception shifts onto the provider or other users.
2. Attach one condition that reflects that cost.
3. Make the condition clear, proportionate, and satisfiable.
4. Apply it consistently and keep an honest emergency route.
5. Observe which requests survive.

The disappearance of requests is not automatically success. It is evidence. If legitimate requests also disappear, the condition is too expensive or poorly designed. If only casual requests disappear, the mechanism is doing useful work.

Let the request bear its own weight

The firewall policy never said no. It said yes, if you will explain why.

That small change aligned the economics of the request with the economics of the work. It replaced interpersonal pressure with a public rule, invited accountability without staging a trial, and let people decide for themselves whether the exception mattered.

A blanket no ends the conversation. An unconditional yes transfers the cost.

Conditional acceptance offers something better: a real yes, provided the request can bear one reasonable condition.