What actually requires you?

A few years ago, I flew five hours to meet a founder in person who had stopped travelling.

He had built a fairly complex wealth structure over many years, with different investments, entities and advisers around him.

The problem was that almost all of it still depended on him.

He knew why things were structured the way they were. He knew who to call. He knew what had been agreed with the accountant, what the lawyer was working on, where the liquidity sat, which commitments were coming up and which decisions were still open.

His family didn't have that picture.

His advisers each knew their part, but nobody other than him really knew the whole.

So travelling started to make him uncomfortable.

The wealth had created freedom in one sense, but the way it was organised had started taking some of that freedom back.

I think about that story quite often, because the obvious response is usually: delegate more.

But delegation isn't really the first problem. The first problem is much simpler:

What actually requires you?

Many of the people I write for built their wealth as founders. But as the wealth becomes more complex, they are playing a different role. They are no longer only the founder. They are now the principal of a family wealth system.

The problem is that we often bring the operating habits of the founder into a role that requires something different.

The founder becomes the default approval system

Founders are great at making decisions. That is part of how they built what they built.

They are used to staying close to important things. They have good judgement. They are comfortable taking responsibility. When something is unclear, the easiest thing is often to ask them.

And for a long time, that works.

Then wealth becomes more complex. There are investment managers, lawyers, accountants, banks, private investments, properties, trusts, companies, tax matters, commitments and family decisions.

Each specialist owns their part.

But more and more questions begin travelling upward.

Should we pay this? Which entity should make the investment? Do you want to renew this adviser? Can we send the tax payment? Are you comfortable with this structure? The capital call has arrived; which account should we fund it from? Do you want to sign this?

Individually, none of these is especially difficult.

Collectively, they create a strange operating model where the principal becomes the place every workflow goes when the system doesn't know what to do next.

That is very different from being in control.

Control and involvement are not the same thing

Founders sometimes confuse these two. If I am involved, I have control.

But the opposite can also be true. If every recurring decision depends on you, you don't necessarily have more control. You have more dependency.

The system is dependent on your presence.

The same instinct that helped you create control while building the wealth can eventually make the system dependent on you. That's what I call the founder's paradox.

And the answer isn't to suddenly delegate everything. There are things you absolutely should continue deciding.

Whether you trust someone. Whether you want to make a major investment. Whether you want to sell an asset. How much risk you are comfortable taking. How you want to support your children. Whether the family should move jurisdiction. What you ultimately want the wealth to accomplish.

No workflow should remove those decisions. That is principal work.

The opportunity is to remove everything surrounding those decisions that never needed your judgement in the first place.

Decide the rules before the decision arrives

This is where decision rights become useful.

Take a simple capital call. If you have already committed to a fund, the investment decision was made months or years ago.

When the notice arrives, there are several things that need to happen. Someone has to identify the investment, confirm the entity, validate the amount, check the original commitment, check liquidity, prepare the payment, get the required approval, send the money, store the evidence and update the commitment record.

The principal may need to approve the payment. But the principal should not need to reconstruct the entire process around the approval.

In a good system, what reaches you might simply be:

Fund X capital call. £275,000. Due 24 September. Amount is consistent with the commitment. Cash is available in HoldCo. Approval required.

Approve. Done.

The judgement didn't disappear. The orchestration did.

Four buckets

A simple exercise: take the recurring decisions around the family and put them into four buckets.

→ Automatic. The rule already exists, so the activity happens without asking again. A valid recurring invoice within an approved engagement is a simple example.

→ Delegated. Someone else has authority within an agreed limit. They do not need to ask permission each time.

→ Escalate. The activity normally sits elsewhere, but something has moved outside an agreed rule, threshold or expected condition.

→ Principal-only. The decision genuinely requires your judgement, authority or personal preference.

The numbers and rules will be different for every family. That is not the important part.

The important part is that you decide them before the next email arrives.

Otherwise, every new situation starts with the same question: "What should we do with this?"

A system asks a better question: "According to the rules, who owns this?"

That small change removes a surprising amount of cognitive load.

Not less information. Better compression.

Sometimes the principal genuinely does need to decide. The problem is how the decision arrives.

Five forwarded emails. Three PDFs. A WhatsApp conversation. A call with the accountant. Another call with the lawyer. Then twenty minutes trying to remember what was agreed six months ago.

That isn't a decision. That is context reconstruction.

A good operating system should do that work before the decision reaches you. The principal should receive something closer to: what happened, why it matters, what the options are, what the relevant adviser recommends, what could go wrong, and what decision is actually required.

You still make the decision. But you are spending your attention on judgement rather than information retrieval.

That is one of the biggest differences between being the system and being principal of the system.

It's not about delegation

Delegation is usually discussed as though the principal has to become more comfortable letting go. Sometimes that is true.

But it puts too much responsibility on the person. If the authority is unclear, the information is fragmented and nobody owns the workflow, of course the principal stays involved. They are often the only reliable control the system has.

So I wouldn't start by telling a founder to let go. I would start by making it safer not to be involved.

Write down the decision rights. Define the thresholds. Give one person accountability. Make the information retrievable. Build the recurring workflows. Define what constitutes an exception.

Then see what still needs to reach the principal. That remaining work is probably much closer to the work only the principal can actually do.

This is really the transition from founder to principal.

As a founder, you became valuable by being close to everything and making things happen.

As a principal, the job changes. You still set direction and make the decisions that require your judgement, but you build a system that knows when it needs you and when it doesn't.

Being the system → building the system → becoming principal of the system.