You Hired Them. Now What?
You hired the person you said you needed. The title is filled. The Slack channel exists. There's a calendar invite for the weekly 1:1. And it's 11pm on a Tuesday and you're the one still in the doc, cleaning up the thing they were supposed to own.
The bottleneck didn't move. It multiplied.
You thought hiring would give you your time back — that's what "building a team" was supposed to mean. Instead, you're spending three hours a week in meetings to align on what used to take you fifteen minutes to just do. You're reviewing work that needs revisions. You're answering questions about decisions you assumed were already clear. You're still the one who knows where everything is, what's at risk, and what needs to happen next.
The new hire isn't bad at their job. That's not the problem. The problem is that hiring solved a capacity issue — you needed more hands — but it didn't solve the trust, delegation, or execution-handoff problem. And nobody told you those were different.
Hiring Solves Capacity. It Doesn't Automatically Solve Structure.
Here's what I've watched happen: A founder makes their first real senior hire — director of operations, head of marketing, senior developer, doesn't matter. The role is defined. The person is qualified. The onboarding happens. And three months later, the founder is still doing the work they hired someone else to do, just with more Slack notifications about it.
The failure mode isn't that the hire was wrong. It's that the structure to let them do the job you hired them for doesn't exist yet.
What does that look like in a normal week? Constant check-ins. Re-dos. Bailouts. The new hire sends you a draft, you realise it's not quite right, and instead of sending it back with edits, you just... do it yourself. Because it's faster. Because you know exactly what it needs to be. Because the meeting is tomorrow and there's no time to explain.
Or: they ask a question in Slack. You answer. They ask a follow-up. You answer. Then another. And you realise you've just spent forty-five minutes recreating the context that lives only in your head — context you didn't know you had, context you never wrote down, context that the [organisational systems you built when it was just you were never designed to transfer](https://hbr.org/2020/07/your-company-is-only-as-good-as-your-writing).
The hire isn't failing. The handoff is. And the handoff is failing because it was never built.
Why This Happens (And Why It's Not Your Fault)
I'm going to say it: this is not a personal failure. It's not that you're bad at delegating, or that you have control issues, or that you "just need to let go." Those are convenient explanations that put the blame on your habits instead of on the thing that's actually broken — which is structural.
Here's what's actually happening.
You hired for skills, not ownership. The job description said "manage X" or "lead Y," but what you really needed was someone who could own the outcome — which means making decisions without checking in, spotting what's about to break before it does, and knowing when to escalate and when to just handle it. Skills are transferable. Ownership is contextual. And contextual ownership requires structure: clear authority, defined decision rights, and systems that make the boundaries of "your call" obvious. If you didn't build that structure before the hire, the new person defaults to checking with you — because that's the safe move. You become the approval gate, not because you want to be, but because the structure makes you the only one who can say "yes, that's right."
The systems that worked when it was just you don't scale to a team. When it's just you, the system is you. You know where the files live. You know what "done" looks like. You know the three things that always break and the two things that matter most. That knowledge doesn't live in a process doc or a playbook — it lives in your head. And when you hire, you assume the new person will just... pick it up. But they can't. Not because they're not smart, but because the system is implicit, not explicit. [What worked at five people breaks at fifteen](https://review.firstround.com/give-away-your-legos-and-other-commandments-for-scaling-startups); what worked when you were solo doesn't survive the handoff to someone who wasn't there when you made the original decisions.
You're still operating like a solo founder even though you're not one anymore. This is the hard one. You built the business by doing everything yourself — and that worked, so the muscle memory is deep. But now there's a team, and the things that made you successful as a solo operator are the things that make you a bottleneck as a leader. You're still the first one in the doc. You're still the one who rewrites the email before it goes out. You're still the one who knows the client history and the project nuances and the thing that happened last quarter that everyone else has forgotten. The new hire wants to take it off your plate. You want them to take it off your plate. But neither of you knows how to make the transfer happen cleanly, so it just... doesn't. You stay in the loop. They stay tentative. And the bottleneck holds.
None of these are failures of character. They're structural gaps. And structural gaps don't get fixed by trying harder — they get fixed by building the structures that were missing in the first place.
What Actually Fixes It
Not another hire.
I know that's the obvious next move. If one senior hire didn't clear the bottleneck, maybe two will. Maybe a COO. Maybe an executive assistant. Maybe just one more person who can "take things off your plate."
But here's the thing: [adding more people to a system that doesn't have clear ownership and decision structure just adds more coordination overhead](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/). More people means more handoffs. More handoffs means more places for things to fall through. More meetings. More alignment conversations. More Slack channels where you're still the one answering the question because you're still the one who actually knows.
What fixes it is building the structure that should have been there before the hire — or at least, building it now, in parallel with the team you already have. And that usually doesn't happen from the inside, because the founder is too deep in the execution to step back and build the system, and the new hire doesn't have enough context yet to do it themselves.
This is where a fractional engagement makes sense. Someone outside the team who steps in to execute the stuck thing — the process that needs documenting, the decision framework that needs defining, the handoff protocol that keeps breaking — while simultaneously building the internal capacity so the team can carry it after. Not a consultant who delivers a report. Not a coach who tells you to delegate better. Someone who does the work and transfers the capability at the same time.
The goal isn't to add another person to the team permanently. The goal is to build the scaffolding that lets the people you already have do the job you hired them for. Clear ownership. Explicit decision rights. Systems that don't live in your head. Handoffs that work without you in the room.
You don't need more people. You need the people you have to be able to do the job you hired them for. And that means building the structures that make that possible.
If This Sounds Like Your Week
Let's talk. Not a pitch — a real conversation about what's stuck, where the handoff is breaking, and whether fractional support is the right shape of help for what you're actually dealing with.
I've built these structures before; I know what it looks like when hiring creates a trust gap instead of solving a capacity problem. And I know what it takes to close that gap — not with another hire, but with the clarity and structure that should have been there in the first place.
Email [email protected] or send me a message on LinkedIn. If it's your 11pm Tuesday, I'd like to hear about it.
---