Insights · The Growth Coach HK
Decision Rights Aren't Just a Leadership Problem. They're a Team Design Problem
6 August 2026
Introduction
Decision rights do not fail because one leader hoards authority. They fail because the team was never designed with explicit boundaries for who decides what, so authority defaults to whoever is loudest, most senior, or most available in the moment.
That distinction matters, because the two diagnoses point at completely different fixes. One asks a leader to change their behavior. The other asks the team to be designed properly, usually for the first time.
Main Insight
Ask a team who owns a specific category of decision, pricing exceptions, hiring within budget, vendor selection under a certain size, and the honest answer in most companies is that it depends who is around. That answer is not a character flaw in any one leader. It is a gap in team design, because decision rights were never actually specified, only assumed.
Assumed decision rights work fine while the team is small enough that everyone can see everyone else's context. They break as soon as the team grows past that point. The unwritten rule that worked when five people sat in one room stops working when there are three layers of reporting and half the team has never had the context to make the call confidently.
What replaces the assumption is not a long policy document. It is a short, specific list, by decision category, of who owns the call, who needs to be consulted, and who just needs to be informed after the fact.
Common Mistakes
One mistake is diagnosing unclear decision rights as a personality problem, one leader who cannot let go. Sometimes that leader exists. More often they are filling a vacuum the team design created, because when nobody formally owns a call, the most senior person present inherits it by default.
Another mistake is responding with a governance document nobody reads. Decision rights that live in a thirty-page policy are functionally the same as decision rights that do not exist. The useful version fits on a page and covers the decisions that actually recur.
A third mistake is specifying the dramatic decisions and ignoring the frequent ones. The categories that matter most are the ones that come up often enough to create friction but are too small to individually justify a meeting: pricing exceptions, scope changes, hiring within an approved role, vendor swaps under a threshold.
Framework: Specifying Decision Rights by Category
List the recurring decision categories. Start with the decisions that generate the most repeated friction or escalation, not the largest ones. Frequency, not size, is what makes ambiguity expensive.
Assign one owner per category. For each category, name who owns the call, who must be consulted before it, and who is informed after. One owner. Shared ownership is the ambiguity wearing a different name.
Set thresholds where size changes the answer. A vendor swap under a certain amount belongs to one person. Over that amount, it moves up. Explicit thresholds are what let people act confidently without guessing where the line is.
Test it against last month. Take the decisions that actually got escalated in the last thirty days and check them against the list. Every escalation that the list would have resolved is confirmation it is working. Every one it would not have resolved is a category to add.
Practical Lessons
Teams that have decision rights designed explicitly move faster on exactly the decisions that used to generate friction. Not because the people got smarter, but because the ambiguity that used to cost a day of back and forth was removed before it had the chance to slow anything down.
There is a second effect that shows up a few weeks in. Escalations to senior leaders drop, and the ones that remain are genuinely worth their attention, because everything that had a designated owner stopped traveling upward out of habit.
Conclusion
Unclear decision rights are usually described as a leadership failure. More often they are a design gap: nobody ever specified, in writing, who owns which category of decision, so the team defaults to whoever is present or senior when the moment arrives.
Design closes the gap. A page of named owners, consulted parties, and thresholds does more for team speed than most process investments many times its size.
FAQs
What are decision rights?
Decision rights are the explicit specification of who owns a given category of decision, who must be consulted before it is made, and who is informed afterward. In most businesses they exist only as assumptions, which hold in small teams and break as soon as growth removes shared context.
How do I clarify decision rights without creating bureaucracy?
Keep it to a page. List the recurring decision categories, name one owner per category, and set thresholds where the answer changes with size. A thirty-page governance document nobody reads is functionally identical to having no decision rights at all.
Which decisions should be specified first?
The frequent small ones, not the dramatic large ones. Pricing exceptions, scope changes, hiring within an approved role, vendor swaps under a threshold. These recur often enough to create real friction but are individually too small to justify a meeting, which is exactly why their ambiguity is so expensive.
This site requires JavaScript for the full experience. Email us or enable JavaScript to continue.