A company moves several teams into a new product structure. The chart shows a product director, engineering managers, and shared specialists. The first disputed launch date exposes a gap in the redesign: nobody can explain whether the director may change the date, whether engineering agreement is required, or who can commit the shared team’s capacity.
Reporting lines can help establish authority, but they do not answer every operational question. Decision rights specify who may make a particular choice, what that choice can commit, what input or approval is required, and how disagreement is resolved.
A useful design begins with decisions the organisation repeatedly needs to make. It should let ordinary work proceed within known boundaries while providing a dependable route for exceptional, cross-functional, or high-consequence choices. Completing a chart or assigning an ownership label is only part of that work.
Identify Decisions at a Useful Level of Detail
Broad categories such as product, technology, or customer experience are usually too large to allocate as a single right. They contain decisions with different consequences, information needs, and dependencies.
For the launch, distinguish setting the intended date, confirming technical readiness, changing scope, approving customer commitments, and allocating support. Some choices can be local; others require coordination or a separate approval.
Start with recurring bottlenecks and contested decisions. Review recent examples and identify what actually waited: a choice, missing evidence, unavailable capacity, or a required control. Calling everything an authority problem can lead to a redesign that leaves the real constraint untouched.
Specify the decision question clearly enough that a person can recognise a case. A category such as changing a launch date after an external commitment is more useful than a general instruction to own delivery. It identifies both the action and a condition affecting authority.
The authority-and-responsibility article explains how these rights relate to the duties and outcomes assigned to a role.
Distinguish Preparing, Advising, Approving, Deciding, and Implementing
Different contributions need different expectations. Someone may gather evidence and recommend an option, another may supply specialist input, and another may make the final choice within scope. The people implementing it need a clear instruction and usable resources.
Bain’s RAPID framework separates Recommend, Agree, Perform, Input, and Decide roles. It offers one vocabulary for clarifying participation. Using its labels does not itself confer authority or establish that the arrangement fits every kind of governance.
For the launch, an engineer could prepare the readiness evidence, customer operations could identify service implications, and an authorised release role could decide whether the conditions are met. A separate approval may be necessary for changing a contractual commitment or exceeding an established internal limit.
Limit approvals to their defined purpose. Consulting a specialist need not give them a veto over every aspect of the decision. Conversely, calling a required approval input should not silently remove the control it exists to provide.
A collective decision body is also possible. Define its mandate and decision rule rather than assuming that inviting several senior people will produce a binding answer. Participants need to know what happens when agreement is not reached.
Specify What the Decision Can Commit
A role may choose a date while lacking authority to secure the people needed to meet it. That is a commitment gap, even if the decision label is clear. Resource rights and dependencies need to be part of the design.
Record the relevant limits: budget, capacity, scope, customer impact, duration, and cross-team effects. Use values meaningful to the organisation rather than importing arbitrary thresholds from another business.
For example, the release role might postpone an internal trial within an agreed window but require sponsor approval for a change affecting an announced customer date. The sponsor’s decision may still depend on required readiness conditions and the resources another team can commit.
Make the difference between selecting an option and authorising its implementation explicit. A recommendation to add weekend coverage does not allocate staff. A meeting’s preference for a solution does not approve expenditure if the participants lack that delegation.
Authority is also bounded by applicable requirements. An internal owner cannot make an otherwise impermissible action acceptable merely by accepting its risk. Where the constraint is uncertain, obtain the appropriate assessment rather than treating it as an ordinary preference trade-off.
Design the Information and Timing Around the Choice
Define what the decision-maker needs and who provides it. For launch readiness, that could include unresolved defects, affected users, recovery arrangements, dependency commitments, and options for narrowing scope. The brief should preserve the conditions on which a recommendation depends.
The decision-access article examines how evidence reaches an authorised choice. Rights without a way to obtain and challenge the relevant information can create a formally clear but poorly informed process.
Set a latest useful decision point. A request answered after the team has passed an irreversible commitment has not supported the intended decision. The timing should reflect what the organisation needs to do afterwards, not simply the next scheduled committee meeting.
Name the person responsible for preparing the request and someone able to answer clarification questions. This avoids a queue of nominally complete submissions that repeatedly return because nobody can resolve a factual uncertainty.
Distinguish an acknowledgement from a decision. If further work is required, state what is missing, who will obtain it, and when the issue returns. Silence should not be treated as approval unless an explicit, appropriate rule establishes that effect for the particular situation.
Give Exceptions a Bounded Route
Local delegation needs a way to handle cases outside scope. Identify the destination, expected response, interim state, and backup when the usual role-holder is unavailable. An escalation that arrives at another person without sufficient authority has only moved the uncertainty.
For a disputed launch, the interim arrangement might preserve a limited trial while external expansion waits. That choice should itself be authorised and assessed for consequences. Stopping, continuing, and narrowing scope are different actions, each with costs and risks.
Record why the exception exceeded the local boundary. Repeated requests about the same issue may indicate an overly narrow delegation, unclear rules, or a new pattern requiring wider attention. Review the evidence before expanding authority automatically.
The authority-gaps article focuses on detecting and containing the exposure while a decision remains unresolved. Decision-rights design should make that containment route available before pressure makes it necessary.
Test the Design With Representative Cases
Walk through a routine decision, a disputed case, an absent approver, and a time-sensitive change. Ask who can act at each point and whether the resources, permissions, and information actually exist.
The GOV.UK governance principles for agile service delivery emphasise timely decisions at the appropriate level and involvement of the right people. They provide a practical public-service reference, rather than proof that a particular business structure must use one model.
For the product organisation, the test might reveal that a director can change the date but cannot obtain an answer about shared-team capacity. Resolve that interface with the shared service’s owner. Merely moving that team onto the chart may not settle its commitments to other products.
Change the Operating Arrangements With the Reporting Lines
Update actual delegations and tools alongside the description. An approval workflow, budget setting, or legacy meeting can preserve an old authority pattern after the new document is published. People need a consistent operational signal about which arrangement applies.
Plan the transition for decisions already in progress. Identify whether the previous owner will close them, whether they transfer to the new role, and how participants will be informed. An unresolved launch should not acquire two apparent owners because the reporting change takes effect halfway through its review.
Provide deputies and handover where needed. A named decision right that depends on one unavailable person can still create a queue. The replacement needs the relevant mandate and context, not simply access to the person’s inbox. Check the first few live decisions after the change to establish whether old approval expectations persist and whether the new arrangement has the resources it assumes.
Maintain the Rights Through Real Work
Assign ownership of the decision design, including updates when roles, services, or constraints change. The record should be accessible to the people using it and identify when the current version took effect.
Measure whether decisions arrive in time, include the necessary evidence, survive implementation, and require avoidable rework. A shorter approval queue is not sufficient if risk has simply moved into unreviewed commitments.
Review a sample of decisions with participants. Did required advice arrive? Did someone exercise an undeclared veto? Did the named decision-maker commit resources beyond their scope? These findings can guide specific corrections to the arrangement.
Preserve room for judgement. A useful design provides authority and boundaries without attempting to document every possible choice. Its success is visible when teams can identify the relevant category, proceed with ordinary work, and obtain a binding answer when a case crosses the boundary.
For the launch, the revised organisation should be able to connect readiness evidence, customer commitments, capacity, and an authorised decision. That is the decision structure the chart was expected to support, made concrete enough for people to use and for the organisation to improve.
