Applying organisational design theory to one of the most persistent problems in Customer Success
Organisations spend a lot of time defining who is responsible for what. They build RACI charts. They write job descriptions. They assign accountability in planning cycles and performance reviews.
What they rarely do is define who has the authority to make the decisions that those accountabilities depend on.
This gap shows up everywhere cross-functional work happens. In post-sales, especially in Customer Success Management, it is felt most acutely. The reason is that Customer Success sits at the intersection of every other part of the business without direct authority over any of them. And this is also the reason why this topic gets so much attention in professional forums and communities.
Jay Galbraith, one of the most influential thinkers in organisational design, argued that the formal structure of an organisation does two things: it allocates decision rights, and it creates the information flows needed to exercise them.
His Star Model defines five interconnected design elements that together determine how an organisation actually functions:
Galbraith's central argument is that these five elements must be aligned. A change in one without corresponding changes in the others produces friction or failure.
This article focuses primarily on Structure (decision rights and authority) and Business Processes (how those rights are embedded in cross-functional workflows), with Reward Systems as the adjacent element that most directly determines whether the decision architecture produces the behaviour it was designed for. Strategy is the necessary starting point. People are the necessary enablers. Both deserve separate treatment.
Brickley, Smith and Zimmerman, in their foundational work on organisational architecture, offer a complementary lens. They argue that effective organisations rest on three interdependent pillars:
While Galbraith does not mention performance evaluation as a separate element, focusing solely on rewards, Brickley et al. stress both, and this addition is very meaningful. Performance evaluation acts as a guardrail, directing behaviour in real time, whereas reward systems determine consequences. Both are needed. Neither alone is sufficient.
Nadler and Tushman add a third perspective: organisational design is the configuration of formal structures, processes, and systems that make up how an organisation actually works, not how it is supposed to work on paper. The gap between those two things is where most cross-functional friction lives.
This article draws on all three frameworks.
CS is accountable for retention and expansion. That accountability is real, as it shows up in targets, in board conversations, and in headcount justifications.
But the decisions that determine whether retention and expansion are achievable are made elsewhere.
RACI says CS is Accountable. It does not say CS controls the decisions.
Accountability without matching decision rights is not a role. It is a liability — and an unfair one.
The most common mistake in designing decision rights is starting with the current process — mapping what happens now and trying to assign ownership to it. This gets the sequence wrong.
Decision rights should be designed to serve strategic objectives, not to reflect existing habits. The starting question is not "who currently makes this decision?" It is "who should make this decision, given what we need to achieve?"
For a CS organisation, that means answering four questions before touching the process map:
Only after these questions are answered does it make sense to look at how decisions are currently made and identify the gap between the design that serves the strategy and the reality on the ground.
Once the strategic intent is clear, the next step is making decisions visible in the process.
A decision is not just the outcome of a process. It is a step in a process, with its own owner, inputs, and output. It belongs in the process map alongside every other activity.
When you draw a swimlane diagram, decision points belong in specific lanes. In whose lane does this decision sit? What information does it require? What changes as a result, and who acts on it?
When decisions are invisible in the process map, they get made by default, not by design. This is when ownership disputes start: sometimes too many people claim the right to decide, sometimes nobody does. The resolution should come from the organisation's design, not from whoever has the strongest personality in the room.
RACI is not the wrong tool, but it is often applied incompletely.
The person who is Accountable carries the decision rights that come with that accountability. This is what Accountable means.
Applied properly, RACI forces a harder question: if this person is Accountable for the outcome, do they have the authority to make the decisions that determine it? If not, either the accountability is misassigned, or the decision rights need to change.
Once the strategic logic is established, authority parameters need to be defined explicitly.
The simplest and most universal mechanism for decision-right distribution in post-sales is a Delegated Authority Limit: a ceiling on the financial impact a role can approve independently, expressed as a percentage of the ARR under that role's management per year.
This single parameter covers the three major decision categories in post-sales:
One limit, three categories, no ambiguity about which decision sits where.
Consider a CSM managing a portfolio of €10M ARR with a 3% annual limit. That CSM can independently approve up to €300K of cumulative financial impact per year. A €100K discount on one renewal, a €100K scope addition on another, a €50K defect fix — that is €250K used and €50K remaining.
When the limit is reached, or when a single decision exceeds what the limit covers, the decision automatically moves to the next level. This is not an escalation request: it is an automatic rule.
The specific percentages will vary by organisation, commercial model, and average contract size. What matters is that they are defined, communicated, and consistently applied, and that they reflect the strategic priorities established at the outset. A business that prioritises retention and on-time renewals will delegate more. A business that prioritises margin protection will centralise more.
| Role | Delegated Authority Limit | Scope |
|---|---|---|
| CSM | Up to 3% of portfolio ARR per year | Pricing, scope, product decisions within portfolio |
| VP CS | Up to 6% of total CS-managed ARR per year | Decisions exceeding CSM limit |
| CRO | Up to 10% of total revenue base per year | Decisions exceeding VP CS limit |
| CEO and Finance | Above CRO threshold | Structural or precedent-setting decisions |
When a decision exceeds the delegated limit, two parallel tracks activate.
The internal track is how the decision moves up the organisation. When the CSM exceeds their limit, VP CS takes the decision. When VP CS exceeds their limit, CRO takes it. When CRO exceeds their threshold, CEO and Finance are involved. Each level has defined authority, and each handoff is automatic, not negotiated.
The external track is how the customer escalates when they do not accept the answer. A customer contact escalates to their manager, who contacts the corresponding level on the vendor side. This escalation path should be designed and communicated to customers at the beginning of each engagement.
The underlying principle is matching the authority of the conversation to the authority required to close it. When a customer escalates and the vendor responds at a level that cannot make the call, trust erodes. When the response comes from someone who can, the conversation closes. This is not hierarchy for its own sake. It is design.
Decision rights cannot be designed in isolation from the organisational model that surrounds them.
A centralised CS team, where all CSMs report into one function with unified standards, makes it relatively straightforward to define and enforce authority limits. Decisions escalate within a clear hierarchy.
A decentralised or matrix structure, where CS sits within business units, product lines, or geographies, creates a more complex picture. A CSM in a matrix organisation may have two reporting lines: a functional manager who sets CS standards, and a business unit leader who sets commercial priorities. When those two lines conflict on a decision, who wins?
Without an explicit answer, the CSM absorbs the conflict. Every contested decision becomes a political navigation exercise rather than a governed process.
The organisational model determines the shape of the decision architecture. Before defining who decides what, the organisation needs to answer a prior question: how is the CS function structured, and does that structure support the decision-making speed and quality the strategy requires? This is a large topic that deserves its own treatment. What matters here is the sequence: organisational model first, decision rights second. Designing authority limits for a structure that is itself unclear produces clarity on paper and confusion in practice.
Defining who can decide is necessary, but it is not sufficient.
Brickley, Smith and Zimmerman identify three interdependent pillars of effective organisational architecture: decision rights, performance evaluation, and reward systems. All three must be aligned. A well-designed decision rights architecture that is not supported by the right evaluation and reward systems will not reliably produce the behaviour it was designed for.
Performance evaluation is how the organisation measures whether each role is making decisions well. These are the guardrails: the metrics that signal in real time whether behaviour is on track. A CSM who knows that gross margin contribution is tracked alongside NRR will make different decisions within their authority limit than one who is measured on NRR alone.
Reward systems define what happens as a result of that evaluation: recognition, compensation, career progression, or consequences for systematic deviation from expected behaviour. The two work together — rewards reinforce the direction that evaluation defines. When evaluation metrics and reward systems are misaligned with the decision rights architecture, the system produces outcomes no one intended.
The example is straightforward. A CSM with a 3% portfolio ARR authority limit who is measured only on portfolio NRR will use that limit aggressively, approving discounts and scope additions to protect renewals regardless of margin impact. The same CSM measured on NRR plus gross margin contribution will make more selective decisions within the same limit. The authority has not changed. The behaviour has.
Three questions apply to each role with decision authority:
Performance evaluation and reward system design extend well beyond the scope of this article. The point here is structural: decision rights without aligned evaluation and rewards are a governance architecture without a nervous system. The structure exists, but it does not reliably produce the behaviour it was built for.
What does CS need to deliver? What decisions most directly affect those outcomes? What should move fast and autonomously, and what requires central oversight? What is the cost of a wrong decision at each level? The answers define the target architecture.
Does the current structure support the decision-making speed and quality the strategy requires? Is the reporting structure clear enough to support defined escalation tracks? If the model is unclear, resolve that before defining decision rights.
Based on strategic priorities and organisational model, determine where decision rights should sit, what Delegated Authority Limits apply to each role, what the internal and external escalation tracks look like, and which metrics and incentives will reinforce the desired decision behaviour at each level.
Draw the swimlane diagram. Capture every activity and every decision point. Apply RACI to every step, including decisions. Compare the current state to the target architecture. Where they diverge, update RACI assignments, define and communicate authority limits, establish escalation tracks, align incentives. Document and share.
Every accountability should come with a matching set of decision rights: not unlimited authority, but enough authority to act on the accountability that has been assigned.
This applies to any cross-functional role. It is felt most sharply in post-sales, because CS, Implementation, and Support sit at the intersection of every function, accountable for outcomes that depend on decisions made elsewhere.
Starting from strategy, not from the current process, is what makes the difference between a decision architecture that serves the business and one that merely reflects existing habits.
Start with one question: what does CS need to be able to decide independently to deliver on its accountability? Everything else follows from that.
Does your CS team have defined authority limits — or does every non-standard situation become a negotiation?