Hook

Video Poster Image

Key Takeaways:

  • Process Before Platform
    Map your customer journey first. Then choose the tools that support it. Automation without clarity just amplifies the chaos.
  • Build a Single Source of Truth
    Stop juggling multiple systems. Pick one core platform for data and integrate everything else into it.
  • Automate the Repetitive, Personalise the Rest
    Automate the predictable. Keep the personal moments human. That’s how you stay connected while scaling.
  • AI Should Be Your Teammate, Not Your CEO
    Use AI to assist, not decide. It should lighten your cognitive load — not replace your judgment.

If your business feels like it’s held together with spreadsheets and wishful thinking, this episode will show you how to scale without losing the soul of your brand.

Sub-Header 1

Sub-Header 2

Sub-Header 3

Sub-Header 4

Sub-Header 5

Sub-Header 6

Sub-Header 7

Sub-Header 8

Sub-Header 9

Sub-Header 10

Delegation for cybersecurity founders: what to hand over, and what to keep

Aug 11, 2026
Founder Trap

You’ve probably been told to trust your team more. It sounds sensible. Leadership-y, even. And for a cybersecurity founder, it’s so vague it’s useless.

Trust them with what, exactly?

You’d never walk someone into a client environment, hand over every credential, and announce that you’ve decided to trust them. You’d give them access to what the job in front of them needs, and nothing else. That feels completely normal in cyber. It’s just how responsible access works.

Then delegation comes up inside your own business, and suddenly you’re expected to make one enormous decision about a whole human being. Trust this person? Yes or no.

 

Why delegation stalls in cybersecurity consultancies

Delegation stalls when a founder treats trust as a single yes-or-no verdict on a person. In a cybersecurity company, where one mishandled client issue carries real consequence, that binary question almost always resolves to no. The work stays with the founder, the team stays dependent, and the business pays for capacity it can’t use.

Key takeaways

  • Trust is contextual in your client work and binary in your own business. That gap is where founder dependency lives.
  • “I don’t trust them” usually means 5 different things, and each one has a different fix.
  • You already run graduated trust for a living. It’s called access control. You’ve just never pointed it at your own team.
  • Classify the decision by how hard it is to reverse, rather than classifying the person.
  • A permission written down can be tested. A permission held in your head can only be guessed at.

 

Trust already comes in levels. You just haven’t written them down

Think about one person on your team and 3 situations.

1. They send a client update. Fine, probably. You’d sign that off in your sleep.

2. They handle a difficult conversation when the client starts pushing back on scope. Less comfortable.

3. They make a recommendation where the client’s environment and your reputation are both on the line. That’s a different level of trust entirely.

It’s the same person, but you’d likely give three answers. So the honest answer to “do you trust them” was always “in some situations, yes.”

The typical delegation advice flattens all of that into “you need to let go.” But the resistance I’ve seen arise with cyber founders is real. That sense of “which bits, exactly? And to whom?” Without the business going up in flames.

The same problem arises with “let them make mistakes.” Which mistakes? A typo in an internal document, grand, you’d get over that. A badly handled client issue involving confidential information is a very different item. Confidentiality and information protection is the business you’re in. So no.

You feel that difference more sharply than most founders because risk is how you think for a living. You’re trained to spot what could go wrong, to look for the vulnerability, to weigh the consequence of a poor decision. That instinct has protected your clients for years and probably built your reputation. So when someone tells you to relax and trust the team, part of you thinks that sounds lovely, and also completely reckless.

 

The loop that keeps capable people looking incapable

Here’s what happens instead. You keep the important work. The team gets the safer work, the stuff where a mistake is survivable: research, prep for reports, documents and admin.

Then the moment something needs nuanced judgment, it comes back to you. Six months later you’re saying they’re still not ready. Maybe they aren’t. That’s genuinely possible. And, if that’s the case, they’re either brand new to your world or else they’re not actually a good hire. But there’s a second explanation worth sitting with: you may have been waiting for trust to arrive before handing over anything meaningful enough to earn it.

That’s a catch-22. So nothing changes. They keep asking questions. You keep stepping in. They get more dependent on you. And their dependence becomes the evidence that you were right not to trust them. It’s an efficient cycle, even if it isn’t a useful one.

I’ve watched founders run this loop with genuinely capable people. They hire someone precisely because they want to grow. Then the first time the stakes rise, the founder steps back in. Sometimes so fast that the other person never gets to decide at all, good or bad. And afterwards the founder says, see, they weren’t ready.

The founder’s discomfort is the only established fact here. Whether the person was unready is still a guess, not a finding.

 

What “I don’t trust them” actually means

“I don’t trust them” is a complete sentence. It sounds final. Conversation over, decision made, the work stays with you. So it’s worth breaking it into its parts, because it’s usually got one of 5 different meanings beneath it, and each one needs a different response.

WHAT’S UNDERNEATH IT

WHAT TO DO ABOUT IT

They made one poor decision, a while back, and it’s still sitting there.

Name the specific decision out loud, to yourself and to them. Then give them a comparable one with a review point built in.

The work carries genuine risk, i.e. client data, a live environment, your name on the recommendation, etc.

Keep the decision. Hand over everything that surrounds it: the research, the draft, the reasoning, the options with a recommendation attached.

You haven’t seen enough of how they think yet.

Manufacture the evidence deliberately instead of waiting for it to appear. Ask for their strategy on a real situation before you share yours.

You trust them in one context and not another, and the boundary lives in your head.

Write the boundary down. An unwritten boundary can only be enforced by you being in the room.

They’ve never been in a hard situation without you there.

Stage one. Sit in as an observer rather than a rescuer, and debrief afterwards.

Notice that only one of those 5 is actually about the person’s capability. The other 4 are about information you haven’t gathered or decisions you haven’t defined.

 

You already run graduated trust. It’s called access control

Here’s the strange part. You work in a world where trust is contextual by design. Access depends on the person, the job, and the consequence of that access. Nobody in cybersecurity treats it as one enormous yes-or-no call, and nobody calls that indecision. It’s simply how responsible access works.

You run this every day for clients. You’ve just never pointed it inside your own business.

WHAT YOU DO FOR CLIENTS

THE SAME THING POINTED AT YOUR TEAM

Least privilege. People get the access the job requires, not everything and not nothing.

Give the decision rights the role requires. “Everything” and “nothing” are both lazy settings.

Role-based access. Permissions attach to a role, defined in advance.

Permissions attach to the role, written before the pressure arrives, rather than to how you feel about someone on an off day.

Elevated access, time-bound. Higher rights for a specific job, then revoked or reviewed.

“You own pricing on this project up to £X, and we review after it closes.” Temporary by design, which lowers the stakes of saying yes.

Change control. High-consequence changes get a second pair of eyes before they go live.

Name the small number of decisions that require your sign-off, so everything outside that list is genuinely theirs.

Logging and review. You can see what happened after the fact.

Move from approving before to reviewing after. Same oversight, none of the bottleneck.

That last row is the one that buys back the most hours. Approval before means the work waits for you. Review after means the work moves and you still see everything.

 

Classify the decision, not the person

The fastest way to stop the yes-or-no question is to stop asking it about people. Ask it about decisions, sorted by how hard they are to undo.

  1. Reversible and internal. Formatting, scheduling, internal documentation, tool admin. Hand over completely. No review, no check-in.
  2. Reversible and client-facing. Status updates, chasing information, booking sessions, routine reporting. Hand over with a template and a standard for tone, then review the output monthly rather than each time.
  3. Reversible and commercial. Scoping conversations, first-draft proposals, pricing inside a set band, follow-up on warm leads. Hand over with a band, a named escalation trigger, and a review point. If pricing consistency is the sticking point, the Cyber Project Quote Check is a quick way to see whether your own quotes are consistent enough to hand the first draft to someone else.
  4. Hard to reverse. Technical recommendations in a live client environment, anything touching confidential information, contract and liability language, incident communication. You keep sign-off. They own the preparation, the options, and a recommendation with reasoning.

Most teams in founder-led consultancies are stuck at levels 1 and 2, which explains a lot, because level 3 is where most of the founder’s week actually goes. Proposals, scoping calls, pricing, follow-up. It’s commercially heavy and, in almost every case, reversible.

So if you want a week back, level 3 is where to build first.

 

Write the permission down in one sentence

Here’s the format I use with founders. It fits on a line, and it removes the ambiguity that keeps work bouncing back to you.

[Name] can decide [specific decision] within [scope or limit] without asking me. If [trigger], they bring it to me first. We review at [point in time].

A worked example:

John can scope and price follow-on work for existing clients up to £8,000 without asking me. If the client asks for anything touching their production environment, or the value goes above £8,000, he brings it to me first. We review every scoped job at the Friday team meeting.

Four things happen when the permission is written rather than assumed.

  1. They stop guessing where the line is, so they stop checking with you as a precaution.
  2. You get evidence. A written permission can be tested and reviewed. A vague one can only be enforced by you hovering.
  3. The escalation trigger does the worrying for you, which is what actually lets you step back.
  4. The next hire inherits a decision rule instead of inheriting your instincts.

Do this for one person and one decision this week. Not the whole org chart. If you’re not sure which decision to start documenting, the First SOP Finder will point you at the one worth writing down first.

 

The hiring ceiling nobody connects to delegation

This shows up in places you wouldn’t immediately link back to trust. One cybersecurity founder I worked with knew he had to come off the tools for the business to grow. The problem was that he could only really imagine hiring people he’d already worked with. People he’d seen operate under pressure. People he’d watched engage with clients when things went wrong, because things do go wrong. Anyone outside that circle felt like a much bigger risk, which makes complete sense.

It also meant his business could only grow as far as his personal working history with other humans. His hiring shortlist was, effectively, his memory. Once that list ran out, every new person was a gamble. That was his glass ceiling.

When he broke it, the business grew 400% in a single year. And the shift wasn’t that he woke up one morning feeling wildly trusting. It was recognising that the word “trust” had been doing the work of two things at once: his professional hypervigilance, and an actual assessment of risk.

 

What the missing model costs you

This stops being a leadership annoyance and becomes a commercial problem the moment you’re paying for people. You’ve added headcount. Payroll has grown. Even with contractors, their rate is almost certainly lower than yours. The business has become more complex because those people exist. And the amount of meaningful work that can happen without you hasn’t moved much.

That’s a plateau. It shows up as:

  • A team member sitting on a project because they need an answer only you can give.
  • Client relationships that belong to you personally, so every account is a retention risk tied to your calendar.
  • Longer hours after hiring than before it.
  • A business that can’t be valued properly, because the asset is your head.

 

The head count grew. The trust model never did.

 

A quick self-check

Six questions. Answer them honestly and quickly.

  1. Is there someone you’ve described as “not ready” for more than 6 months?
  2. In the last month, did anyone on your team make a decision you’d have made differently, and you let it stand?
  3. When a project stalls, how often is the blocker an answer only you can give?
  4. Could any client name someone other than you as their main relationship?
  5. If you took 3 weeks off, which decisions would queue up, and how many of them are genuinely hard to reverse?
  6. Have you written down, anywhere, what any team member can decide without you?

If the answer to number 6 is no, the other 5 answers were already decided for you.

 

Where to start this week

Pick one person and one recurring level 3 decision. Something commercial and reversible. Write the permission sentence for it: 10 minutes, maximum.

Put the review point in the calendar before you hand it over. The review is what makes the handover safe, and it’s the bit most founders skip.

When they bring it back to you, ask what they’d do before you answer. Every time. That question is how you gather the evidence you’ve been waiting for. Following instructions tells you very little. Watching someone think when the answer isn’t obvious tells you everything.

How trust grows through the levels after that is a longer conversation. For now, seeing the loop is enough. Once you can see it, “I don’t trust them” stops sounding like a complete answer and starts sounding like a question that needs more precision.

Delegation without defined permissions is unrestricted access with a job title. Delegation with defined permissions is exactly what you’d design for a client.

 

Frequently asked questions

What is founder dependency in a consultancy?

Founder dependency is when the business needs the founder personally for the sale, pricing, explanation, delivery standard, or final decision. It shows up as a growth plateau: revenue and headcount rise, but the work that can happen without the founder stays flat. The usual symptom is a busy founder with a capable team that still queues for answers.

Why is delegation harder for cybersecurity founders?

Because risk assessment is the professional skill. You’re trained to look for vulnerabilities and weigh the consequences of a poor decision, and that instinct doesn’t switch off at the edge of a client engagement. Generic advice like “trust your team” ignores that confidentiality and information protection are the product. The fix is defining permissions with the same precision you’d apply to client access.

How do I know if someone is ready for more responsibility?

You gather evidence rather than waiting for a feeling. Give them a reversible decision with a defined scope and a review point, then watch how they reason, not just whether they got it right. Ask what they’d do before you give your answer. If you’ve never seen how someone thinks under pressure, “not ready” is an untested assumption.

What should I delegate first?

Start with decisions that are commercially significant and reversible: scoping conversations, first-draft proposals, pricing within a set band, and follow-up with warm leads. This is where most founder hours go, and a mistake there can be corrected. Keep sign-off on anything touching a live client environment, confidential information, or contract liability.

Is delegation the same as letting people make mistakes?

Only within a defined boundary. A mistake in an internal document is a learning cost. A mishandled client issue involving confidential information is a reputation event, and in cybersecurity that’s the whole business. Set the level of the decision first, then the mistakes that follow are affordable by design.

How long does it take to get work off the founder?

It depends on how much of the expertise is written down. Handing over one defined decision with a review point can happen this week. Moving an entire function, like sales or delivery, takes months because it needs documented standards, templates, and escalation rules before anyone can run it without you. Start with one decision, not the whole function.

See where your business is still too dependent on you

If reading that has made you realise how much still sits with you, the Cyber Scale Diagnostic will show you where. It takes a few minutes, and it maps the places your business still runs through you, so you can see your next smartest move rather than guessing at it.

Take the Cyber Scale Diagnostic →

Stay connected with episodes, news and behind-the-scenes updates!

We hate SPAM. And we will never sell your information, for any reason.

Frequently Asked Questions

Resources Mentioned

Recent Episodes

Delegation for cybersecurity founders: what to hand over, and what...

Why Marketing Money Disappears When Brand Strategy Comes Second

Why your LinkedIn posts aren't converting into clients