Editorial disclosure: The viewpoints and opinions in this article are fully formed by TRIOD’s human experts. This article was written with AI assistance to express those human-developed perspectives.
A founder can ask the team to take more ownership while remaining the only person allowed to approve a discount, resolve a complaint, or alter a deadline. The request and the permissions need to be examined together.
When a decision repeatedly returns to the founder, there may be a good reason. The consequences could be substantial, the team may need further experience, or the business may be handling an unfamiliar situation. Delegation should respect those conditions.
But “they need to be more proactive” is an incomplete diagnosis if nobody has established what staff are authorized to decide.
Identify the dependency precisely
Take a hypothetical service firm where every scope exception requires founder approval. Some requests could change the commercial risk of an engagement. Others involve small substitutions that staff could manage within a clear boundary.
Counting all approvals together would hide that distinction. Review a sample and identify why each decision returned to the founder. Was authority missing? Was the necessary information unavailable? Did the founder reverse earlier decisions made within the supposed permission? Or was escalation appropriate?
The records may show a training need. They may show an unclear offer. They may show decisions that should remain with the founder. They may also reveal that staff have the capability but no stable permission to use it. These possibilities require different responses.
A new management tool cannot settle that distinction. It may make pending approvals more visible while preserving the same dependency.
Transfer the boundary as well as the task
Delegating a decision requires a purpose, a usable rule, and limits. A person needs to know what they can approve, what information they must check, and what conditions require escalation. They also need access to the information on which the rule depends.
For the hypothetical firm's small substitutions, the boundary might require equivalent effort, no change to the accepted outcome, and consent from the delivery owner. Anything outside those conditions would return for approval. The exact rule belongs to the business; the example illustrates what permission needs to contain.
Start with a category of decisions where the consequences can be bounded. Review how the rule was used, including cases that produced an unexpected result. A mistake may reveal unclear guidance or a capability gap. It should be investigated before concluding that delegation itself has failed.
The founder must also decide how later disagreement will be handled. If a team member follows the agreed rule and leadership silently reverses the decision, the practical rule becomes harder to predict. Either explain why the case fell outside the boundary or revise the boundary openly.
Some discretion will remain difficult to codify. Coaching and shared review can be appropriate there. A document should not pretend to transfer judgment that the recipient has not yet developed.
The desired result is a defensible distribution of decisions, with appropriate oversight. Removing every founder approval is not a useful target on its own. Nor is building a second bureaucracy that takes longer than the dependency it replaces.
Ask which recurring decisions the team can now make responsibly, which still require help, and why. That gives “more ownership” a practical meaning the next time an exception arrives.