Maurice Studio treats founder dependency as an operating design question. A usable decision record connects authority, evidence and escalation so the team knows what it can decide and when it must ask.
Our unit of redesign is the repeated decision
In Operating Model work, we start with decisions that repeatedly return to the same senior person. An organisation chart rarely explains why a particular approval waited for two days. The useful evidence sits in the request, the missing information, the authority boundary and the consequences someone was unwilling to accept.
Our decision record puts five things together. The decision itself, the authorised role, the evidence required, the boundary of that authority and the trigger for escalation. A supporting playbook makes the relevant material available. The record explains who may act and under which conditions.
Before changing the arrangement, we replay actual cases against the proposed rule. Could the intended owner have decided? Would they have had the evidence? Would a consequential exception have reached the right authority? This exposes whether the bottleneck sits in permission, information or capability before the team is told simply to take more ownership.
| Observed bottleneck | Design response | Check before delegating |
|---|---|---|
| Permission is unclear | Define an explicit authority boundary | Can the owner distinguish an ordinary case from an exception? |
| Evidence arrives incomplete | Specify inputs and make them accessible | Can the owner reach a reasoned conclusion from the record? |
| Judgement requires support | Provide review, development or retain authority | Is the person competent and authorised for the consequence? |
Investigate the recurring decision
Founder dependency is sometimes described as a delegation problem. It can also be an information, capability or control problem. A team may keep escalating because the scope is unclear, the evidence is hard to find or the consequences exceed its authority.
Review decisions that returned to the founder or senior leader during a recent operating period. Record what was being decided, who requested approval, what information was available and why the decision moved upward. Use actual messages and meeting records rather than a general impression that everything needs approval.
Group recurring decisions by type. Routine scheduling, scope changes, quality acceptance, client commitments and risk acceptance may need different boundaries. Delegating them all in the same way would be careless.
Separate authority from responsibility for the work
The person preparing a recommendation is not necessarily the person authorised to approve it. The person coordinating delivery may not own acceptance of a consequential finding. State those roles explicitly.
For each repeated decision, identify who provides evidence, who must be consulted, who decides and who implements. Keep the arrangement simple enough to use. A role matrix helps only if people understand the specific decision it describes.
Where legislation, professional obligations, contract terms or governance arrangements reserve a decision, respect that boundary. An internal operating redesign does not transfer authority that the organisation does not have the right to delegate.
| Decision record | What to define |
|---|---|
| Decision type | The recurring choice, not a broad activity label |
| Decision owner | The role with authority to make it |
| Required evidence | The information needed before approval |
| Boundary | The conditions within which the owner can decide |
| Escalation trigger | The exception that moves the decision to another authority |
| Consultation | Whose input is required and by when |
| Record | Where the rationale and conditions are retained |
Delegate within a defined boundary
A useful boundary combines scope, evidence and consequence. A delivery lead might approve a scheduling change within an agreed window when it does not affect a client commitment. A material change to the objective or contract would still require a different approval.
Define escalation triggers in observable terms. New legal exposure, a missing required control, a disputed finding or a commitment beyond agreed capacity may trigger escalation. Avoid vague rules such as escalate anything important, which return the judgement problem to the team.
Provide access to the information and capability needed to use the authority. Delegation without reliable records, training or review support creates an accountability gap. Fix those conditions alongside the decision rule.
Pilot the authority change
Start with a recurring, bounded decision where the consequences can be managed. Agree a review period, record decisions and check whether the boundary is understood. The senior leader should review the quality of reasoning rather than silently remake every decision.
Track decision waiting time, unnecessary escalations, rework and exceptions. A reduction in escalations is useful only if decisions remain sound. Pair the speed measure with a quality review and a check for decisions made outside authority.
Where judgement is disputed, examine the rule and available evidence before blaming the individual. If the boundary cannot accommodate normal cases, revise it. If the issue is competence, provide support or retain the decision at the appropriate level.
Keep the operating model current
Decision rules need review when the business, client commitments or regulatory context changes. A boundary suitable for a small internal project may be unsuitable for a multi-entity engagement. Attach a review owner and trigger to the record.
Use a short decision log to preserve important reasoning. Record the choice, evidence, conditions and review point. Do not turn every routine approval into a lengthy report. The record should be proportionate to the consequence.
The aim is dependable decision-making at the appropriate level. If the founder is no longer a routine bottleneck but still receives consequential exceptions with useful evidence, the redesign is doing its job.
Put it to work
A practical next step
Write a decision record for one repeated approval. Replay three recent ordinary cases and one exception against it. Record where permission, evidence or capability remains insufficient. Resolve those gaps before moving the decision.
Explore the toolsSources and method
This decision-record method is a Studio recommendation. It does not replace statutory duties, contractual approvals or professional accountability.