Delegation is usually described as a management skill. That makes it sound personal: a leader learns to let go, a capable employee earns trust, a team becomes more efficient. At institutional scale, delegation is not a personality trait. It is an operating system. It determines how intention becomes action when more than one person, company, jurisdiction, device and professional discipline are involved. If that operating system is vague, the institution either centralises every decision around an exhausted principal or allows authority to diffuse through custom and convenience.
Access is not delegation
Giving someone a login does not give them a mandate. Giving someone a mandate does not ensure they have the access to execute it. Giving them both does not establish how the result will be checked. A complete delegation has five linked parts:
- Mandate: the purpose, scope, limits and duration of the authority.
- Decision: the judgment the delegate may make without returning to the principal.
- Execution: the systems and counterparties through which the decision becomes real.
- Evidence: the record that shows what was decided, on what basis and by whom.
- Reconciliation: the later check that execution matched the decision and remained within the mandate.
Most control failures are a broken link between these parts. The invoice is approved but paid to a changed beneficiary. The adviser has a mandate but the bank has an outdated signatory list. The assistant executes correctly but no record explains an unusual exception. The principal believes a delegation was withdrawn while the technical account remains active.
Define the unit of delegated authority
Job titles are too blunt. “Chief of staff,” “family-office director” or “operations lead” says little about a specific decision. Define authority as a set of decision objects. For example:
- May approve recurring household expenditure within an agreed category and monthly ceiling.
- May release a due-diligence data set from an approved room to named recipients for a defined period.
- May instruct the technology provider to isolate a compromised device, but may not destroy data or notify external parties.
- May negotiate commercial terms within a range, but may not sign or represent that approval is final.
A useful unit states the object, action, boundary, trigger and expiry. It can be understood by the delegate, implemented by a system and recognised by a counterparty.
Separate preparation, recommendation, approval and execution
Many institutions concentrate all four stages in one trusted person because it is fast. It is fast until that person is mistaken, compromised, conflicted or absent. Not every action needs four different people. The separation should follow consequence. But the stages should remain conceptually distinct:
- Preparation assembles the facts and options.
- Recommendation applies expertise and states a preferred course.
- Approval commits the relevant authority.
- Execution performs the authorised action.
For low-risk routine work, one person may hold all stages under a standing mandate. For high-value or irreversible work, at least one independent boundary should exist between the request and the final act.
Exceptions reveal the real system
The written process is rarely the operating system. The exception process is. A principal calls from a new number. A deadline advances. A bank portal fails. A trusted adviser asks to use a personal account. Staff create a workaround, then the workaround becomes precedent. Every exception should answer four questions:
- Who has authority to permit it?
- What additional evidence compensates for the missing normal control?
- How long does the exception last?
- Who confirms that the normal state was restored?
An exception with no owner or expiry is a permanent delegation created under pressure.
Make authority observable
A principal should be able to see where meaningful authority sits without reading every email or approving every task. Build a compact delegation register containing the active decision objects, delegates, systems, limits, effective dates and review dates. Connect it to actual technical roles and external mandates. Produce exception and reconciliation reports, not a flood of activity logs. The useful management view is not “what did everyone do?” It is:
- Which consequential decisions were taken under delegated authority?
- Which actions approached or exceeded a limit?
- Which exceptions remain open?
- Which delegations are unused, duplicated or dependent on one person?
- Where did execution differ from approval?
Design revocation at the same time as delegation
Authority is easy to grant when a relationship is healthy and painfully difficult to recover when it is not. Define revocation before the mandate begins. The revocation plan should name the person who can trigger it, the systems and counterparties that must act, the evidence of completion, the treatment of records and the fallback if the delegate is unavailable or hostile. This is not cynicism. It is the same discipline used for keys, contracts and financial instruments: control includes the ability to end control.
The point is speed with integrity
Good delegation does not trap the principal inside every decision. It allows the institution to move without continuously borrowing the principal’s attention or identity. The operating system works when ordinary actions are fast, extraordinary actions become visible and revoked authority truly disappears. It should survive personnel changes, provider changes and moments of pressure. Trust remains essential. Delegation simply gives trust a shape that other people and systems can honour.