Decision Rights And Who Breaks A Tie

Watch a decision that took eleven weeks and you will usually find that almost none of the eleven weeks was spent thinking. It was spent establishing who was entitled to decide. The analysis was done in week two. Weeks three to ten were a slow, polite negotiation about whether the answer could be given by the person who had it, conducted mostly by people who were not in the original conversation and were not sure why they had been added to it.

This is the most common form of decision latency and the most tractable. It needs no better judgement, no more senior attention and no cultural change. It needs someone to write down, in advance, who decides what — and, crucially, who does not.

It goes unwritten because decision rights are the actual currency of an executive layer — budget, headcount and org charts are proxies for them. Making the map explicit makes the distribution explicit, and somebody always discovers they own less than they thought. That discomfort is the entire cost of the exercise: a one-off cost against a recurring benefit, which is a good trade that organisations decline to make for years at a time.

The four populations around any decision

Every decision of consequence has four groups attached to it, and confusing them is where the time goes.

The person who decides. Exactly one. Not a committee, not a role, not a function — a named individual who can say yes or no and be held to it. A decision owned by "the architecture group" is a decision owned by nobody, which is why it will be discussed four times.

The people who must be consulted. They hold information or expertise the decider needs. Their input is genuinely required, their agreement is not. This distinction is the single most useful thing in this article and the one most often lost in practice.

The people who must be informed. They are affected by the outcome but have nothing to add to the choice. They need to know quickly and accurately, which is a communications problem, not a governance one.

The people who want to be involved. They have a view, an interest, a history with the topic, or a concern about precedent. They are not on the first three lists. They are on the invitation, because it was easier to add them than to explain why not, and their presence is a large fraction of why the meeting is ninety minutes and inconclusive.

The fourth population is the one nobody names out loud, and it determines how long the decision takes. An engaged, senior, articulate person with an opinion and no accountability will extend a decision indefinitely, not through malice but because the meeting design invites exactly that. The fix is to move them from the decision to the consultation, explicitly and in advance, so their input arrives as input rather than as a veto delivered at minute seventy.

Mapping it, and how the mapping fails

RAPID-style frameworks exist for this and they work: separate the recommend, agree, perform, input and decide roles, assign each to a named person, and publish it. RACI does a similar job with a different vocabulary. Which you pick matters far less than whether you finish the exercise honestly, so use whichever your organisation will not spend six weeks debating.

What matters is knowing how these maps fail, because a failed map is worse than none — it provides a document to argue about in addition to the decision.

Mapping roles instead of decisions. The common failure. Someone produces a grid of job titles against generic categories and everyone nods. It changes nothing, because real decisions do not arrive labelled with categories. Map actual recurring decisions instead: which of two platforms we standardise on, whether a team can deploy without a change advisory board, who signs off a price change. Twelve real decisions beat a complete taxonomy.

Assigning the decision upward for safety. If every consequential decision maps to the executive committee, you have documented the bottleneck rather than relieved it. A good map pushes most decisions down, and it will only do that if someone senior gives authority away in writing.

Confusing agree with input. An "agree" right is a veto. Sometimes correct — legal on a contractual commitment. Usually not. Every veto multiplies wait time, because the decision now waits for the slowest of several independent queues rather than one. Most organisations have three or four where one would do.

Producing it centrally and publishing it. A map written by a transformation team and announced is a document. A map written by the people who hold the rights, in a room, with the disagreements surfaced and settled, is an agreement. Only the second survives contact with a contentious call.

Consensus, consultation and the difference that costs quarters

These two words are used interchangeably by people who mean very different things, and the ambiguity is expensive.

Consultation means the decider gathers input, weighs it, decides, and explains the reasoning to those who disagreed. It has a bounded cost — the time to gather input — and it terminates.

Consensus means the decision cannot proceed until everyone can live with it. It has an unbounded cost, because it terminates only when the least agreeable participant relents, and it hands enormous leverage to whoever is most willing to keep objecting. It is not democratic; it is a system that rewards persistence over judgement.

	Consultation	Consensus
Who decides	One named person	Effectively the last holdout
Terminates when	The decider decides	Everyone stops objecting
Cost	Bounded by input-gathering	Unbounded
Failure mode	Input ignored, trust erodes	Decision never lands, or lands watered down
Right for	Almost everything	Genuine peer commitments with no shared boss

Consensus has legitimate uses — a commitment between peers where no common authority exists, or a decision whose implementation requires willing effort from people who cannot be directed. Outside those cases it is a way of avoiding the discomfort of deciding, dressed as inclusion. Organisations drift towards it because consultation done badly is genuinely worse. If you gather input and then decide against it without explanation, people learn that consultation is theatre and stop contributing. The obligation that makes it work is the explanation: the decider owes the dissenters an account of what was weighed and why it went the other way. That is the price of the authority, and leaders who take the authority while skipping the explanation convert their organisation into a consensus culture within about two quarters, whatever the documents say.

Escalation designed rather than improvised

Most escalation paths are not designed. They are the org chart, used as a fallback, by people who have run out of other options. This produces two predictable pathologies.

The first is that escalation reads as failure. If a question only travels upward when two parties have fallen out, escalating is an admission that you could not handle something, and people avoid it for weeks — weeks during which the work sits blocked. An organisation where escalation is socially costly has, in effect, an unbounded decision latency for anything genuinely contested.

The second is that escalation travels the whole chain. A disagreement between two team leads goes to their managers, then their directors, then the first common executive, accumulating a meeting cycle at every hop. Four hops on a weekly cadence is a month of pure routing.

Designing this properly takes about an hour.

Name the tiebreaker in advance, per decision type. For every recurring contested decision, write down who breaks the tie if the normal route does not converge. Not a forum — a person. Knowing this in advance usually prevents the escalation entirely, because both parties can predict the outcome and settle.

Set a timebox that triggers escalation automatically. If a decision has not landed in five working days it goes to the named tiebreaker, without anyone deciding to escalate. This removes the social cost entirely, because escalation is a clock expiring rather than a person complaining.

Skip the intermediate hops. Escalate to the lowest level with authority over both parties, not up one rung at a time. Intermediate managers can be informed; they do not need to be traversed.

Treat frequent escalation as a design signal. If the same boundary generates escalations every month, the problem is not the decisions — two teams have overlapping accountability, or a dependency that should not exist. Fix the structure and the escalations stop. This is the organisational equivalent of attacking the queue rather than expediting items, and it is argued in organisational design above team topologies.

Pushing decisions to where the information is

The strongest argument for distributed decision rights is not empowerment. It is information economics.

A decision requires context, and context is expensive to move and degrades in transit. Move the decision upward and you must summarise the context into something that fits a slide and an executive's fifteen minutes, which destroys precisely the detail that would have made the decision good. Move the authority downward and the context travels nowhere.

The question for any decision is therefore not who is most senior, but where the relevant information lives. That produces a usable rule: decide at the lowest level that can see all the consequences. Lower and you get local optimisation. Higher and you get decisions made on summaries.

Delegating a decision is therefore not primarily an act of trust. It is an act of design, with three obligations: state the boundary the decision must stay inside, state what information you expect afterwards, and then actually not intervene. Delegation that is silently reversible is worse than none, because the team learns to check anyway and you have added a queue rather than removed one.

When two executives both own it

This is the situation the maps never cover and the one that consumes the most senior time.

Two leaders each believe, sincerely and with organisational backing, that a particular call is theirs — the platform director and the product director on a technology standard, the CFO and the COO on a funding model. Neither is unreasonable; both have a mandate that plausibly covers the ground. The decision does not get made, and because both are senior and the relationship matters, nobody names the conflict. It becomes exploratory conversations, a working group, and eventually a compromise that satisfies the politics and not the problem.

Three things help, in order of preference.

Split the decision rather than the authority. Most mandates overlap because the decision has been framed too coarsely. Break it into components and each usually has an obvious owner. Who chooses the standard, who funds the migration, who sets the deadline, who accepts the risk of not migrating — four decisions with potentially four owners, and framing them separately dissolves perhaps half of these disputes.

Name the tiebreaker and use them early. If both parties report to the same person, that person should break the tie in week one rather than week nine. They usually do not because both parties are reluctant to be seen escalating against a peer. A standing rule that unresolved peer decisions go up after two weeks removes the stigma, because it is policy rather than choice.

Decide the decider first, as a separate, faster decision. If there is no common authority short of the chief executive, the question that goes up is not "what should we do about the platform" — it is "who owns this class of decision from now on". That is faster to answer, settles a category rather than an instance, and prevents the next nine occurrences.

What does not work is waiting for the ambiguity to resolve itself. Ambiguous ownership is stable: both parties can continue indefinitely believing they own it, because nothing forces the contradiction into the open. It persists until someone with standing names it, and naming it is almost always cheaper than another quarter of drift.

What to do on Monday

Take the twelve most consequential recurring decisions in your area and write them as a list. For each one, write a single name against "decides" and a short list against "consulted". Do it alone first, in thirty minutes, before consulting anyone — your instinctive answer is diagnostic. Any decision where you cannot write a name without hedging is a decision that is currently costing you weeks.

Then take the list to your peers and compare. The disagreements are the map. Settle them in one session, publish the result, and add a default rule at the bottom: anything not on this list is decided by the person closest to the work, and if two people both think it is theirs, it goes to a named tiebreaker after five working days. That last sentence will do more for your decision latency than the twelve rows above it.