Tales & Co.

Istanbul — San Francisco

Notes

Decision architecture

5 min read

Decision Rights Are Inherited, Not Assigned

Most decision rights were never designed. They were inherited from whoever happened to own the first case, and a growing company inherits the wrong owner as often as the right one.

Most decision rights were never assigned. They were inherited from whoever handled the first case.

The first pricing exception at a young company is decided by whoever picks up the phone when the request comes in — often a founder, sometimes whoever is closest to the deal. Nobody convenes a meeting to assign that category of decision to that person. They simply handle the first one, and handling it is what makes them the owner of the next one, and the one after that.

A precedent is not a policy, but it behaves like one

By the tenth pricing exception, everyone routes the question to the same desk without asking why. The routing looks like a decision right — stable, predictable, generally respected. It isn't one. Nobody chose that desk for that reason; the desk chose itself, the first time, by being the one in the room.

A decision right assigned this way is real until the moment it's tested, and untested is most of the time. It survives for years on the strength of habit alone, which is indistinguishable from a deliberate design right up until two people both believe, with equal conviction, that the call is theirs.

None of this shows up as a mistake at the time. Each individual handoff looks like common sense: the person who did it last time is the obvious person to ask again. The company only notices what happened once someone else, with an equally reasonable claim, asks the same question and gets a different answer.

This is a different failure from the one a room falls into over full agreement: that piece is about a single meeting with no named decider. This one is about a decision type nobody remembers assigning in the first place.

A company can staff every decision correctly and still watch two teams claim the same one.

Inheritance works cleanly as long as the company stays small enough that everyone remembers who handled the last one. Growth breaks that memory. A function splits in two; a new hire takes over half of what one person used to do; a second office starts fielding its own version of the same request. Each new group inherits its own partial memory of who used to own the call, and each memory is locally correct and mutually incompatible.

The same mechanism, seen twice already

A payment product decision that belongs, by charter, to nobody and a checkout roadmap fought over by product and risk are not fintech problems. They are this mechanism, caught in a sector specific enough to see clearly. The underlying failure is the same wherever a decision type outlives the memory of how it got assigned: nobody designed the ownership, so nobody can point to why it should stay, or move.

The tell is rarely a shouting match. It's two teams each quietly proceeding as though the call were settled, in opposite directions, until a customer or a board member notices the company said two different things.

Each side can point to a real case where they made this exact call before, which is what makes the disagreement so hard to settle in the room. Both memories are accurate. Neither one was ever a rule.

The fix is a registry of decision types, not a chart of decision-makers.

An org chart answers who reports to whom. It does not answer who decides what, and the two questions only look similar. Fixing inherited decision rights does not start with redrawing boxes; it starts with writing down the recurring decision types the company actually makes, separate from who currently happens to make them.

Three questions per decision type

  • What is the decision type, stated narrowly enough to be checked against a real case? "Pricing" is too broad to assign; "exceptions to list price for a single customer" can be.
  • Who currently decides it, in practice, not on paper? This is a question about the last three cases, not the org chart.
  • Is that still the right owner, given who holds the information the decision actually needs? The person who inherited the call and the person closest to the information it depends on are not always the same person.

The list is short at first, and that's the point. Ten to fifteen decision types account for most of the ones that get relitigated in a growing company; the rest genuinely don't need a registry entry, because nobody is arguing over them.

Reassigning a decision right costs more than assigning one for the first time.

The registry above reads like paperwork. Building it is not the hard part. The hard part is what happens when the answer to the third question is no — when the person who inherited a decision right is not the person who should hold it now, and everyone in the room knows it.

Why this gets skipped even after it's diagnosed

Reassigning a decision right that someone has held for two years reads as a demotion whether or not anyone frames it that way, and the person losing it will treat it that way even when the company gains from the move. This is the reason most decision-rights work stalls after the diagnosis: naming the mismatch is easy; moving the right is a conversation someone has to have with a person who will hear it as a verdict on them.

A reassignment announced as a one-off exception invites the next person to treat it as reversible, and it quietly reverts within a quarter. A reassignment recorded in the same registry as the other nine or ten decision types reads as what it is: a correction to a document, not a verdict on a person.

The registry itself is what makes that conversation possible without it turning personal. A decision moved because a written rule for who should hold it changed is a different event, to the person losing it, than a decision moved because someone decided they were the wrong person for the job — even when the practical outcome is identical.

Where this becomes work.

Most companies discover their decision rights were inherited, not assigned, only after two teams have already collided over the same call. By then the registry is being built under a deadline, with two functions already dug into opposing positions, which is the most expensive time to build one.

The earlier version of this work is quieter: a short list of the decision types that actually recur, an honest answer about who holds each one today, and a plan for the two or three where that answer no longer fits. Our consulting engagements do this work before the collision, not after it, because the list takes a fraction of the time to build when nobody in the room is defending a position yet.