A residential property management company oversees rental portfolios for close to three hundred landlords across a mid-sized city. For four years, nearly every maintenance request above a modest dollar figure lands on the founder's desk before a tradesperson gets approved. Every landlord upset about a vacancy, a late payment, or a repair bill that ran over eventually gets put through to her directly. Every tenant complaint the front-line coordinators can't resolve in one call sits in her inbox by the end of the day.
The business grows steadily. Landlords refer other landlords. By year four, she hires an operations manager specifically to take maintenance decisions and landlord relationships off her desk, the thing that's been eating her calendar for longer than she'd like to admit.
Three months later, she is just as busy. The new hire is competent, well-liked, clearly working hard. And somehow the founder is still approving the same maintenance requests, still getting looped into the same landlord calls, still fielding the same escalated tenant complaints. Just one email thread later than before.
The Task Moved. The Decision Didn't.
The easy read here is that the hire was wrong, or that the founder can't actually let go, whatever she tells herself about wanting to. Neither is usually true, and both miss what's actually happening.
Delegating a task and transferring the capability behind it are not the same action, even though they feel identical in the moment of handing something over. A task has a beginning and an end: here is the work, go do it. Capability is different. It is the standing to decide what "done well" means without checking first, and it only exists once several specific things have actually moved from one person's head into somewhere the new person can reach them.
Hand over the task without the rest of it, and the work genuinely leaves the founder's desk. It just doesn't stay gone. It comes back wrapped in a question, a meeting, an email asking whether this is okay to approve, because nobody ever decided out loud what "okay" means.
What Actually Has to Travel With the Work
*The Designed Business* is specific about what that "rest of it" consists of. Before concluding that a new hire simply isn't ready, the book suggests checking five things directly: does this person know the result they're responsible for, not just the task list in front of them? Do they know which decisions they're allowed to make on their own? Do they have the information required to make those decisions well? Do they know exactly when to escalate, and when not to? And do they understand the standard the work is judged against, not just what needs doing?
Miss any one of these, and the task returns home disguised as something else entirely: a training problem, a confidence problem, a give-it-more-time problem. It is usually none of those. It is a specific, nameable thing that was never handed over, sitting quietly underneath a task that was.
Where the Operations Manager Actually Stood
Run those five questions against the property company's new hire, and the gap stops being mysterious.
The result she owned was never defined precisely. "Handle maintenance and landlord relationships" sounds like a result. It's actually a task list with no finish line attached, no number or outcome she could point to and call good for the month.
The decision right was never named either. Nobody had said, in words, that she could approve a repair up to a certain amount without checking first, or offer a dissatisfied landlord a specific concession within a defined range. So every maintenance call above a token amount, and every uncomfortable landlord conversation, kept arriving at the founder's desk by default. Not because the operations manager lacked judgment, but because nobody had told her she was allowed to use it.
The information gap was quieter but just as real. The founder carried years of context that never made it into any file: which contractors actually show up on time, which landlords get anxious and need a call rather than an email, which properties have a history that changes how a routine request should be handled. None of that lived anywhere the new hire could reach it. She wasn't failing to use judgment. She was making calls with half the facts the founder had been using for years.
The standard existed only as a feeling. The founder knew what "handled well" looked like the moment she saw it, and had never once described it in words specific enough for someone else to check their own work against before it reached a landlord.
And the escalation boundary ran backward. Instead of a clear line marking what truly needed the founder's input, the operations manager had absorbed, correctly, that almost anything might need it, so she escalated early and often, just to be safe. From the founder's side, that looked like someone who wasn't ready to take ownership. It was actually someone behaving exactly as the business had trained her to behave.
Four of the five things never moved. The task did.
Turning What's in Your Head Into Something the Business Can Use
The useful part of this isn't the diagnosis. It's that each of the five gaps closes differently, and none of them closes by waiting for the new hire to get more comfortable.
A pattern the founder repeats without thinking about it can usually become a method someone else can follow: the specific sequence she actually runs through before approving an unusual repair, written down once, rather than relived from scratch every time. A standard she recognizes instantly but has never described can become a short, concrete checklist, not a sprawling manual, just the two or three things that separate acceptable from not. A decision she keeps making the same way whenever a familiar situation recurs can become an explicit rule, stated once, rather than a fresh judgment call every time it comes up. Information that currently lives only in her memory can move into whatever the team actually uses day to day, a shared note, a property file, a short briefing, so the right person has the right detail without needing to ask her for it. And the boundary for when something genuinely needs her, rather than everything needing her by default, has to be stated as a specific line, not a vague sense that she's generally available if something comes up.
None of this requires documenting every thought the founder has ever had. It requires identifying the handful of things that keep recreating the same bottleneck, and moving exactly those, deliberately, instead of hoping proximity and time will eventually do it on their own.
Before Handing Off the Next Task
A few questions worth running honestly against whatever you're about to delegate, or already have.
Can you state, in one sentence, the actual result this person owns, separate from the list of things they're doing?
Have you told them, explicitly, which decisions are theirs to make without you, or have they only learned the boundary by watching what gets overturned afterward?
If the answer to either is no, the problem probably isn't the person you hired. It's the things you haven't handed over yet, still waiting underneath the one you have.
A Team Is Something You Design, Not Something You Hope For
None of this argues against hiring, or suggests a founder should document every decision before trusting anyone with anything. Early in most businesses, staying close to the work is exactly right. The founder needs to see where things actually go wrong before she can describe it to someone else.
The shift that matters is simpler than it sounds: noticing when a task keeps bouncing back, and asking which specific thing beneath it, the result, the decision right, the information, the standard, the escalation line, was never actually handed over. Delegation that only moves tasks will always feel, eventually, like it made things busier rather than lighter. Delegation that moves capability is the only kind that ever actually lightens the load it was supposed to.
The property company's founder didn't need a different hire. She needed to notice that she'd handed over the easiest of the five things and quietly kept the other four for herself, the way most founders do, right up until someone points out that they're still holding them.
If this sounds like your business, last week's piece looks at the other half of the same problem: not what a new hire still needs, but what the founder herself has been personally carrying all along, trust, judgment, memory, standards, or courage, and why that's usually several different problems wearing one name. Worth reading alongside this one: The Founder Is Not Always the Real Bottleneck.