Decision Rights in a Scaling Company Need an Expiry Date

A pattern we meet in growing software and payments companies starts with a rule nobody remembers writing down. At sixty people, the head of sales approves every discount below list price. The rule works because the head of sales knows every deal, every customer and the margin each one can bear. Approval takes a message and a few minutes.

The same rule, three years later

At two hundred and fifty people the rule has not changed, and almost everything around it has. There are three regional sales leads, a deal desk, a finance partner who models margin, and a pipeline several times the size. The head of sales now approves discounts on deals they have never heard of, for customers they will never meet, on the strength of a summary written to get the approval through. The queue on that one desk sets the pace of the quarter's closing. The regional leads have started, quietly, to price just inside the threshold so the deal never reaches it.

Nothing about the original assignment was wrong. It fitted a company of sixty. In a scaling company, a decision right is correct for a size, and it gives no signal on the day the company outgrows it. That is the gap the usual method leaves open. Most guidance on how to assign decision rights treats the job as a one-off design exercise: list the decisions, name an owner, publish the matrix. In a company that is growing, a matrix like that starts to decay the week it is published.

How rights get acquired by accident is the subject of the note on inherited decision rights. This note is about the deliberate version: assigning a right so that it keeps fitting, and so that it says when it has stopped.

Two tests for the decider

Every assignment starts with two questions about a decision type. Who holds the information the decision depends on, without a meeting to assemble it? And who lives with the consequence, and will be the first to see it go wrong? Early in a company's life both answers are usually the founder or one senior person, which is why concentrating decisions there is efficient rather than a flaw.

Growth pulls the two answers apart. Information moves outward, to the regional lead who knows the customer, the product manager who knows the usage, the engineer who knows what a change will break. Consequence moves more slowly, and some of it stays at the top: the company's margin, its risk position and its reputation still land on the people who answer to the board.

When the tests point at different people

The common mistake is to resolve the split by seniority, which keeps the right with the consequence and starves it of information. The decision gets made by someone working from a summary, and the summary is written by the person who wanted a particular answer. The assignment that holds gives the decision to whoever holds the information, and protects the consequence with a limit rather than an approval step. The regional lead decides discounts within a defined range. The head of sales decides the cases above it, and no longer sees the rest.

Why names fail first

A right assigned to a person lasts as long as that person stays in that seat with that scope. In a company adding people every month, that is not long. The person is promoted, their role is split, a second hire takes half their remit, and the right goes wherever their memory of it goes. Written against a role, the right survives the turnover: whoever runs the regional sales team holds it, and a new hire inherits it with the job rather than by finding out the hard way.

Limits that grow with the company

The limit is where most assignments go stale fastest. A spending approval or a discount ceiling written as a fixed sum is set for one size of business. Two years of growth later, the same sum is so small that every ordinary decision crosses it, and the senior approver is back to signing everything. A limit expressed in the units of the decision moves with the company instead: a share of the deal's contract value, a fraction of the quarter's budget line, the number of customers a change touches, whether a change can be undone within a release. The note on reversible and irreversible decisions covers the last of these, which is often the most useful.

A limit written in the decision's own units ages at the company's pace rather than against it. It still needs revisiting. It simply needs it less often, and for better reasons.

Why an annual review misses the moment

Companies that do revisit decision rights usually put it on the calendar once a year, alongside the operating plan. The review arrives either long after the assignment broke or in a year when nothing changed, and in both cases it is treated as paperwork. Assignments do not break on a schedule. They break at identifiable events, and those events can be named when the right is first written:

• a function splits into two teams, or a second office starts handling the same kind of request
• a new role is created whose job includes the information the decision depends on
• the queue of cases waiting on one desk starts to set the pace of the work around it
• the limit is crossed so often that nearly every case escalates, or so rarely that none ever does

Reading the escalation pattern

The last trigger is the one a leadership team can watch without any new system. If nearly every case goes above the limit, the limit is too low and a senior leader has become a queue. If none ever does, the limit is too high or nobody is checking whether cases should have gone up. Both are visible in a month of the decisions themselves.

A limit that every case exceeds has turned a senior leader into a queue.

Writing the trigger in at the start changes what a reassignment is. When a right moves because a named condition was met, it reads as the assignment doing what it said it would. A trigger agreed in advance turns a reassignment from a verdict on a person into a scheduled change to a document. Moving a right someone already holds is the hardest part of this work, and it is far easier to settle before anyone holds a right worth defending.

The practical starting point is the decisions that waited longest last quarter. For each one, the two tests show where the information sits and where the consequence lands, and the assignment follows: a role, a limit in the decision's own units, and the events that reopen it. In our work the list rarely needs more than a couple of dozen entries before it covers the decisions that actually stall. The entries record choices rather than tasks, which is the line drawn in the note on decision rights and RACI.

Our consulting work builds those assignments with leadership teams inside the decision architecture pillar, starting from real cases rather than the org chart. Our training programmes cover the habit that keeps them current, which is noticing a trigger when it is met rather than a year later. A decision right that says when it expires can be moved without a fight, and one that does not will be defended long after it stopped fitting.