The Decision Rights Framework: Clarifying Authority in Complex Organisations
The Decision Rights Framework: Clarifying Authority in Complex Organisations
A SaaS scale-up I advised last year had, on paper, a perfectly sensible org chart. A Head of Product, a Head of Engineering, a Head of Customer Success, all reporting into a COO. Clear titles, clear teams. What it didn’t have was any working answer to a much smaller, much more consequential question: when Product wanted to ship a feature that Customer Success believed would multiply support ticket volume, who actually got to decide whether it shipped?
Not who was consulted. Not who was in the room. Who, when the room disagreed, had the standing to make the call and make it stick.
Nobody could answer that with confidence, including the COO. I asked six people separately and got five different responses. The honest answer was that it depended on who escalated fastest and how much political capital they were willing to spend that week. The feature shipped. Support volume tripled. The retrospective spent four hours on the feature’s design flaws and about four minutes on the fact that the decision had never actually belonged to anyone - which was the real cause and the only one guaranteed to recur.
That scale-up isn’t unusual. It’s the median case. Most organisations past a certain size don’t have a decision-making problem in the sense people usually mean it - bad judgment, slow meetings, insufficient data. They have an authority problem: an accumulated, undocumented, largely improvised set of assumptions about who gets to decide what. Those assumptions were roughly accurate when the company was fifteen people in one room. They have quietly stopped being accurate at every size since and nobody ever sat down to rebuild them on purpose.
I want to work through why this failure is so common, why the standard tools don’t fix it and what a decision rights framework that holds up under real complexity looks like.
The diagnostic: authority doesn’t scale the way structure does
Across nearly every fast-growing organisation I work with, the same pattern holds. Org charts scale reasonably well - you can draw a bigger chart, add layers, add titles. Decision authority does not, because authority was never actually assigned in the first place. It was inherited from a founding moment when the founder held every decision by default, simply because there was no one else to hold it.
As the company grows, that default authority gets delegated piecemeal and informally, in response to whatever crisis or hire prompted the delegation. Nobody deliberately designs who should hold which category of decision at scale. A VP gets hired and absorbs “product decisions” as a vague bundle. Which product decisions? Pricing, roadmap sequencing, feature scope, architecture trade-offs? Which of those actually sit inside the bundle and which remain - unstated - with the founder or the executive team?
The bundle feels like clarity because there’s a name attached to it. It functions as ambiguity, because the boundary was never drawn.
This is the structural reason RACI matrices and org charts fail to solve the problem, even when organisations diligently fill them out. A RACI matrix answers “who is responsible, accountable, consulted, informed” for a task. But most consequential organisational conflict isn’t about who executes a task. It’s about who has the standing to resolve a disagreement about a decision - a different question, answered by a different structure.
You can have a perfectly clear RACI for “who builds the feature” and zero clarity for “who decides whether the feature should exist, given the support-cost trade-off.” That second question was never a task on anyone’s matrix. It’s a judgment call that surfaces only when two legitimate functional priorities collide - and collision points are precisely the places RACI was never designed to arbitrate. The scale-up above had a RACI for feature delivery. It had nothing for feature approval under cross-functional trade-off, which is where the expensive mistake actually occurred.
Why the standard responses fall short
Faced with visible paralysis or a costly bad call, most organisations reach for one of two fixes. Both under-deliver in predictable ways.
The first is escalation-by-default: when functions disagree, push it up a layer and eventually to the executive team or the founder. This works the first few times. Then it becomes the organisation’s real decision-making mechanism by accident. Executives who resolve enough of these escalations personally never have to build a system that resolves them without their involvement. Worse, every escalation they handle is implicit proof, to everyone watching, that the system works fine as is.
It doesn’t scale. Escalation-by-default has a hard ceiling: the number of disputes a small group of senior people can personally adjudicate per week. Organisations hit that ceiling right around the point where growth has produced more cross-functional collision points than the executive team has attention. Not coincidentally, that’s usually the stage at which I get the call - because the founder has just spent a Tuesday resolving three disputes that shouldn’t have needed them and is beginning to suspect this isn’t leadership. It’s a bottleneck wearing leadership’s clothes.
The second fix is the comprehensive governance rewrite: a project, often consultant-led, to document every decision type across the company and assign it formally. This is directionally correct and usually fails anyway. The failure has nothing to do with the quality of the analysis and everything to do with sequencing. These projects try to map decision rights for the entire organisation at once. They produce an exhaustive document six months later. By then the org has changed shape, two of the people the document assigned authority to have moved roles and the document’s main afterlife is as an artifact nobody consults - referenced occasionally in a dispute as evidence, never used as the operating system it was meant to become.
Comprehensive and current are in tension for a fast-moving organisation. Projects that optimise for comprehensive lose currency faster than they can be adopted.
Both failures share a root cause I’ve written about before in a different context: they treat decision authority as something you solve once, comprehensively, rather than as infrastructure you build incrementally at the exact points where it’s load-bearing and revisit on a cadence. (It’s the same sequencing mistake I discuss in Scaling Without Chaos - comprehensive-but-static structure loses to targeted-but-maintained structure at every stage of growth I’ve observed.)
A framework: decision rights mapped by collision point
What actually works is narrower and more disciplined than a full governance overhaul: identify the specific points where functional authority collides and resolve those points explicitly, before the collision produces a costly ad hoc decision. Four components.
1. Collision-point identification, built from real disputes, not hypothetical org design. Don’t try to map every conceivable decision. Start from the disputes that have already happened, or that senior people can name as recurring friction. The product-versus-support trade-off above is one instance of a category - “features with material downstream operational cost” - that will recur. Mapping that category matters far more than mapping every decision Product theoretically makes.
In practice, this means interviewing the leadership team with one question: where, in the last two quarters, did a decision involve genuine disagreement between two functions and how was it actually resolved? The answers cluster fast, usually into five or six recurring categories. Those categories are where the framework applies first.
2. Explicit authority per category, with a named decision-owner - not a bundle. For each category, assign a single named role. Not a committee. Not “product and support together.” One role with the explicit standing to make the final call when the functions disagree, after input has genuinely been sought from the other side.
This is the part organisations resist most, because it feels like it disempowers the function that doesn’t get the authority. The honest response to that discomfort: ambiguity was never empowering anyone. It was deferring the fight to whoever had more energy or standing in the moment - a worse allocation mechanism than a deliberately chosen owner, even one a given function occasionally disagrees with.
3. An escalation path that is genuinely rare, not a relabeled default. Some decisions will be significant or novel enough to warrant escalation above the named owner. But the framework only works if escalation stays the exception, reserved for consequences beyond what the category anticipated - not the same default-to-the-top pattern with an extra documented step in front of it.
A useful test: if the same category escalates more than roughly once a quarter, either the ownership assignment is wrong or the owner isn’t being given the standing the document says they have. Either problem needs fixing at the root, not absorbing as routine escalation volume.
4. Scheduled review, not permanent assignment. Revisit ownership on a fixed cadence - every two quarters for a fast-growing organisation. The collision-point categories themselves shift as the company scales. New ones emerge, old ones become irrelevant and the right owner at one stage of growth is not automatically the right owner at the next. A built-in expiry-and-renewal mechanism is what stops the framework calcifying into exactly the kind of static document that made the comprehensive rewrite fail.
Implementation risks and trade-offs
This framework carries real costs and leaders should weigh them honestly.
Naming a single decision-owner for a category will, correctly, feel like a loss of influence to whichever function doesn’t get the authority. That reaction needs managing directly, not smoothing over with vague language about “collaborative decision-making.” The entire point of the framework is that collaboration happens in the input stage, not in the final call. Pretending otherwise reintroduces the ambiguity the framework exists to remove.
Starting from real disputes rather than comprehensive mapping means some categories will go unaddressed until they produce their own costly collision. Leadership has to accept that the framework is deliberately incomplete at any given moment, prioritising the highest-friction categories first. This is a genuine trade-off, not a flaw to apologise for. Complete coverage delivered slowly arrives too late and too stale to be useful. Partial coverage delivered where the friction actually is compounds in value, because each resolved category removes a recurring source of ad hoc conflict.
The review cadence, skipped once under time pressure, tends to get skipped permanently. There’s rarely an obvious trigger forcing the review the way there is for the original collision. The org just gradually re-accumulates ambiguity as it changes shape - quietly, until a new dispute makes the drift visible, by which point the fix costs more than the review would have.
And there’s a habit underneath all of this worth naming directly. Once decision rights are assigned, the temptation is to treat the owner’s call as unchallengeable rather than accountable. The framework is meant to produce clear authority with genuine input from affected functions - not authority that stops listening once it’s been formally granted. Confusing the two turns a governance improvement into a new source of the same resentment the ambiguity originally produced, just relocated to a different name on the document.
The strategic reflection
The organisations that scale without descending into paralysis or chaos are rarely the ones with the most sophisticated org charts. They’re the ones that did the less glamorous work of deciding, deliberately and in writing, who actually makes the call at the specific points where functional priorities collide - and then had the discipline to revisit that assignment as the organisation changed shape.
The SaaS scale-up above didn’t need a better feature-review process. It needed one person with the standing to say “this ships” or “this doesn’t,” known in advance by everyone in the room, so the decision didn’t have to be re-litigated from first principles, under time pressure, by whoever showed up loudest that week.
If your organisation resolves cross-functional disagreements primarily through escalation, seniority, or whoever argues longest, the question worth asking isn’t whether you need better people in the room. It’s whether you’ve ever actually assigned authority for the categories of decision that keep colliding - or whether, like most organisations at your stage, you’re still relying on an informal allocation system that was never built to survive the size you’ve already grown past.
Gustavo De Felice is a senior digital project leader and systems architect with over 1,200 managed projects across technology, logistics and digital transformation. He writes on execution governance, performance accountability and the structural design of teams that deliver under complexity.