Who gets to decide?

Once execution is understood as architecture and strategy has been translated into work, that question becomes unavoidable. It sounds simple. In most companies, it is not. Many organizations say they want speed, accountability, empowerment, and ownership. But when important decisions arise, the actual decision system is often unclear. Authority is implied. Input rights are informal. Escalation paths are inconsistent. Cross-functional decisions get negotiated in real time. Senior leaders become the default forum for issues the organization should be able to resolve closer to the work.

The result is predictable. Decisions slow down. Meetings multiply. Escalations increase. Accountability blurs. Teams wait for direction. The organization mistakes activity for progress while decisions sit unresolved inside the system.

This is why decision rights matter. Decision rights are not merely a governance formality. They are an execution system. They define who has the authority to make which decisions, at what level, with what input, within what guardrails, and through what escalation path. Done well, they allow decisions to be made faster, closer to the work, and with clearer accountability. Done poorly, they become one of the hidden reasons strategy stalls.

The hidden bottleneck in execution

Execution friction survives good architecture. A strategy may be clear. The initiatives may be defined. The metrics may be visible. The cadence may exist. But if the organization has not defined how decisions get made, the work still slows down.

Teams ask for approval because they are not sure they have authority. Functional leaders escalate because they do not know whether a decision is theirs to make. Cross-functional issues linger because each function controls part of the answer but no one owns the whole decision. Senior leaders get pulled in because the organization has learned that escalation is safer than ownership. This is how execution slows without anyone intending to slow it. The organization may look busy. Meetings are happening. Dashboards are being reviewed. But the real constraint is decision flow.

The question is not whether people are working hard. The question is whether the system allows the right decisions to be made at the right level, with the right facts, by the right people, at the right speed.

That is decision architecture.

What decision rights actually mean

Decision rights define the authority, input, approval, escalation, and accountability required to make decisions inside the business.

Exhibit 1

The decision architecture map

ElementThe question it answers
Decision category

What type of decision is this?

Decision owner

Who has the authority to make the call?

Input rights

Who must be consulted before the decision is made?

Approval and veto rights

Who can stop or override the decision—and on what grounds: risk, compliance, financial, legal, brand, or enterprise implications?

Thresholds

What dollar amount, risk level, customer impact, margin impact, or strategic significance changes the approval path?

Escalation path

When does the decision move up, and what facts must come with it?

Decision forum

Where is the decision actually made?

Cadence

How often are these decisions reviewed, revisited, or monitored?

Accountability

Who owns the outcome after the decision is made?

Readers familiar with decision-rights frameworks will recognize the family resemblance to Bain’s RAPID, which assigns roles — who recommends, who agrees, who performs, who has input, who decides. RAPID is useful as far as it goes, and it goes about one row deep. It clarifies roles for a decision. It does not define the thresholds that change an approval path, the forum where the decision actually gets made, the cadence on which it gets revisited, or the escalation design that determines what facts move with an issue. Roles are an ingredient. The rows above are a system — and it is the system, not the role labels, that determines whether decisions actually move faster.

The point is not to map every decision. The point is to map the decisions where ambiguity slows value creation, increases risk, or forces unnecessary escalation. A decision is not fully made when people agree in a meeting. It is made when accountability is clear, resources are committed, trade-offs are accepted, and the organization knows what will happen next. Without that, a decision is only a discussion that ended.

This is where many companies get stuck. They confuse participation with decision-making. They invite the right people into the room but do not clarify who has the authority to decide. They gather input but do not define how disagreement will be resolved. They debate trade-offs but do not establish who owns the final call. The result is a familiar pattern: more meetings, more follow-up, more escalation, and more ambiguity. Decision rights are designed to prevent that.

Decision rights are not bureaucracy

Decision rights can sound bureaucratic. They are not. At least, they should not be.

The purpose is not to document every possible choice inside the company. The point is to clarify who gets to make the decisions that materially affect strategy, resources, customers, risk, economics, capability, and execution.

A good decision-rights system has enough structure to reduce ambiguity, but not so much structure that it suffocates judgment. Too few parameters create confusion. Too many parameters create bureaucracy. The art is defining the decision architecture for the decisions that matter most.

Those usually include pricing, customer exceptions, capital allocation, hiring, product priorities, resource trade-offs, and acquisition integration — and in most businesses, pricing and customer exceptions alone account for a disproportionate share of the escalation traffic. These are the decisions that shape value creation. They deserve architecture.

The T&E analogy

Most companies understand spending authority. A manager may be able to approve expenses up to a certain limit. Larger expenses require additional approval. Certain categories require special review. Exceptions have escalation paths. The system defines thresholds, approvers, documentation requirements, and controls. That does not eliminate judgment. It channels judgment. Most companies would never require every expense to go to the CFO. Yet many effectively do that with operating decisions.

Pricing exceptions go to senior leadership. Customer issues go to the CEO. Product trade-offs get escalated. Headcount questions sit unresolved. Cross-functional priorities get negotiated repeatedly. Initiative conflicts drift because no one has authority to make the trade-off. In these moments, the organization has not empowered judgment. It has trapped judgment in escalation. No CFO would accept an expense policy that routed every hotel bill to their desk. The same executives accept exactly that arrangement for pricing, hiring, and customer decisions every day.

Decision rights set organizational clockspeed

Charlie Fine, the MIT professor and author of Clockspeed: Winning Industry Control in the Age of Temporary Advantage, has long influenced how I think about strategy and execution. His core insight was that industries, products, processes, and supply chains evolve at different rates. In faster-clockspeed environments, advantage is more perishable, value chains reconfigure more often, and management systems have to adapt more deliberately. That idea applies well beyond supply chain because every business has a value chain, and every value chain has a speed.

Every business has an organizational clockspeed: the rate at which it senses change, makes decisions, reallocates resources, sequences work, resolves constraints, and institutionalizes new capabilities.

Decision rights are one of the mechanisms that set that clockspeed.

If decision authority is unclear, the organization slows down. Issues wait for escalation. Teams hesitate. Cross-functional trade-offs are renegotiated. Senior leaders become bottlenecks. Decisions get revisited after they were supposedly made. The business may have urgency, but the decision system cannot process reality fast enough.

That is why decision rights matter to execution. They are not just about governance or control. They determine whether the organization can make the right decisions at the right level, with the right facts, at the right speed. In a slow-changing environment, unclear decision rights may be inefficient but survivable. In a faster-moving environment — a transformation, integration, growth platform, turnaround, new product build, or sponsor-backed value creation plan — unclear decision rights become a constraint on enterprise value creation.

The private equity clockspeed problem

This matters acutely in private equity ownership.

A sponsor-backed company does not have an unlimited time horizon. While actual hold periods vary and have stretched in recent markets, many value creation plans are still built around a finite ownership window, often with a five-year planning assumption. That means the value creation plan has to move quickly from thesis to action, and from action to measurable enterprise value.

In private equity, time is not background context. It is part of the return equation. Sponsors may underwrite to a meaningful multiple of invested capital — often 2x to 3x or more depending on the deal, risk profile, and starting point — but those returns do not materialize because the strategy was well articulated. They materialize because the organization translates the plan into decisions, resources, initiatives, operating cadence, and measurable results. In that context, unclear decision rights are not just an inconvenience. They are a direct constraint on value creation.

Every delayed pricing decision, unresolved customer exception, slow hiring call, deferred integration choice, ambiguous product trade-off, or escalated operating issue consumes time the ownership cycle does not give back. If the company has five years to create value, but the first year is spent negotiating authority, clarifying priorities, escalating decisions, and waiting for the senior team to resolve issues that should have been decided closer to the work, the value creation plan is already behind.

That is why decision architecture should be treated as part of the value creation infrastructure. It is not a back-office governance exercise. It is one of the mechanisms that helps a sponsor-backed company move at the pace required to create enterprise value within the ownership window.

Operating cadence creates the rhythm for reviewing reality. Decision rights determine whether that rhythm actually produces decisions. Without both, the organization has meetings, but not clockspeed.

Where decision rights break down

Decision rights usually break down in predictable places.

Exhibit 2

Common decision-rights failure modes

Failure modeWhat it looks like
Authority gaps

Everyone has input, but no one clearly owns the decision

Accountability gaps

The person accountable for the outcome does not control the decision required to achieve it

Veto gaps

A function can stop the work but is not accountable for the business result

Cross-functional gaps

Multiple functions own pieces of the answer, but no one owns the whole decision

Escalation gaps

Senior leaders become the default mechanism for resolving ambiguity

Forum gaps

Decision forums discuss issues but do not actually decide

Delegation gaps

Leaders say they want empowerment but continue to re-decide delegated decisions

This is why decision rights cannot live only in an org chart. The org chart tells people who reports to whom. It does not tell them how the business will make the decisions that matter. A company can have a clear org chart and still have unclear decision rights. In fact, that is common.

A supply chain example

I have built this architecture from a blank page. At a sponsor-backed energy producer, I was brought in to stand up a centralized supply chain organization where none existed — which meant the decision-rights question could not be inherited or assumed. It had to be designed. The conventional options were the two extremes: centralize procurement decisions entirely, or leave them with field operations and call the central team advisors. Both would have failed, for opposite reasons.

The design that worked split decision ownership by the character of the decision itself. For simple, commodity-like categories, the supply chain organization owned the decision, with structured input from the field. For complex, operationally critical categories — fracking services, most notably — field operations owned the decision, with supply chain input and a standardized category toolkit that ensured the decisions were made with common rigor even though they were made in different places. Authority followed decision complexity, not the org chart.

Six months later, the organization was running, a permanent leader was hired to run it, and the architecture did not need me anymore — which was the point.

Building decision architecture

Decision architecture should start with the decisions that most affect enterprise value. Not every decision needs to be mapped. But the critical ones do. The work is to define the decision categories, owners, input rights, approval or veto rights, thresholds, escalation paths, decision forums, cadence, and accountability mechanisms that allow the organization to move.

This is the difference between a decision-rights discussion and a decision system. The discussion says, “We need to clarify who decides.” The system says, “Here are the decisions that matter, who owns them, what requires escalation, where decisions get made, and who owns the outcome.” That is execution architecture.

Guardrails without suffocation

Decision architecture fails when it is either too vague or too detailed. If it is too vague, nothing changes. People still negotiate authority in real time. Teams still escalate to protect themselves. Senior leaders still become the default decision makers. If it is too detailed, it becomes unusable. People stop applying judgment. The system becomes a compliance artifact. The organization spends more time interpreting the matrix than making the decision.

Good decision architecture lives between those extremes. It defines guardrails, not scripts. The category toolkit at the energy producer was exactly that — a guardrail, not a script: common rigor, local judgment. It clarifies authority, not every possible action. It creates escalation thresholds, not universal escalation. It makes decision-making faster, not heavier. This is why designing decision rights requires judgment. It is not a template exercise. It requires leadership to understand where the business is actually getting stuck.

The best places to start are not hard to find:

Exhibit 3

Where to look first

The symptomWhat it signals
01The same decision keeps slowing down

A missing owner or threshold

02Authority gets negotiated in real time

Rights are implied, not designed

03Senior leaders sit in routine operating decisions

Escalation is the default, not the design

04Teams make calls they should not be making

Guardrails are missing below

05Risk is introduced because decisions sit too low

Thresholds are set wrong—or not at all

06Speed is lost because decisions sit too high

Judgment is trapped in escalation

07The same cross-functional issue keeps resurfacing

No one owns the whole decision

08Decisions get reopened after they were made

Forums discuss but do not decide

Decision rights are leadership choices

Defining decision rights is uncomfortable because it forces leadership to make authority explicit. That is why many companies avoid it. It is easier to say, “We need better collaboration,” than to say, “This person owns the decision.” It is easier to say, “We need alignment,” than to say, “This function provides input, but does not have veto authority.” It is easier to escalate than to clarify.

But unclear authority has a cost. It slows execution. It frustrates high-performing leaders. It creates shadow governance. It encourages political behavior. It allows decisions to be reopened. It gives people room to disagree without owning the consequences.

Decision rights force the organization to confront how power, accountability, expertise, and risk actually work inside the business. That is why they matter.

The best-run companies decide closer to the work

The best-run companies do not push every decision upward. They push decisions to the right level. That does not always mean lower. Some decisions should sit with senior leadership because they involve enterprise trade-offs, capital allocation, risk appetite, strategy, brand, or long-term capability.

The same is true for boards and sponsors. Some decisions properly belong at the board, sponsor, or senior leadership level because they involve enterprise risk, capital allocation, strategic direction, ownership priorities, or long-term capability. The failure is not escalation itself. The failure is using escalation to compensate for unclear authority.

But many decisions should be made closer to the work because the people closest to the customer, process, product, market, or operating constraint often have the best information. The goal is not decentralization for its own sake. The goal is decision quality at speed. That requires clarity.

When decision rights are clear, people know when they can act. They know when they need input. They know when they need approval. They know when to escalate. They know what facts matter. They know who owns the outcome. That reduces noise. It also increases trust.

Senior leaders can stop reviewing decisions that do not require their judgment. Functional leaders can stop protecting themselves through escalation. Teams can move with more confidence. Cross-functional work can progress without constant renegotiation. That is how decision rights become a source of execution advantage.

Decision architecture is working when fewer issues are escalated by default, decision cycle times shorten, meetings produce commitments rather than discussion, teams know when they can act, and senior leaders spend more time on enterprise trade-offs than routine operating decisions. The goal is not to eliminate judgment. The goal is to put judgment at the right level of the organization.

Decision rights turn strategy into speed

Strategy does not become valuable because it is well articulated. It becomes valuable when the organization can act on it. That requires work to be owned, sequenced, resourced, governed, measured, and managed through cadence. But it also requires decisions to move.

A company can have a good strategy, a strong value creation plan, and capable leaders — and still move too slowly if meaningful decisions are ambiguous, escalated too late, reopened too often, or left unresolved between functions.

Decision rights are one of the practical mechanisms that convert execution architecture into organizational speed. They help the business move faster without becoming reckless. They help leaders delegate without losing control. They help teams act without guessing. They help the organization escalate what matters and resolve what does not.

Most companies do not move slowly because people lack urgency. They move slowly because the decision system is unclear. The best-run companies do not leave decision-making to personalities, politics, or escalation habits. They build decision architecture: who decides, who contributes, what requires escalation, where decisions get made, and how decisions connect to accountability.

Every company already runs one decision system with this discipline: expenses. Thresholds are defined, approvers are known, escalation is designed, and nothing routine reaches the CFO. The discipline exists. It just stops at the expense report. The best-run companies extend that same architecture to the decisions that actually create enterprise value — pricing, customers, capital, talent, integration. That is where speed is worth the most. And that is what it means for decision rights to be an execution system.

Related: How Exelis creates value

Discuss a mandate