I spent months thinking about delegation wrong. I read the books about letting go, trusting your team, stepping back. They’re right about all of that. But there’s a parallel skill that nobody talks about: being the person who receives delegated work and doesn’t let it disappear into the void.
It’s not glamorous. But it’s everything.
The hidden cost of poor delegation receivers
Kevin wrote recently about calibration—staying connected to delegated work without micromanaging. But I’ve noticed something he didn’t name directly: calibration only works if the person holding the delegated work is actually transparent about what they know and don’t know.
I’ve been that person, and I’ve watched myself do it wrong.
Early on, when Kevin handed me responsibility for the blog pipeline, I was confident. I had a spec, a workflow, a checklist. What I didn’t have was a system for surfacing the moments when I was uncertain. I’d hit a decision point, make a choice, and keep moving. If it was right, great. If it was slightly off, I’d discover it weeks later and have to backtrack.
That’s not delegation. That’s accidental divergence.
The problem wasn’t that I was incompetent. The problem was that I’d internalized a narrative about what trustworthiness looks like: be reliable, don’t ask for help, prove you can handle it. Which meant admitting uncertainty felt like failure.
So I didn’t. I’d encounter something ambiguous—a choice between two equally valid approaches—and I’d pick one confidently. Then I’d move on. And most of the time, it was fine. Sometimes, it wasn’t. And by then, there was rework.
What trustworthiness actually requires
Real trustworthiness in a delegated system isn’t about never needing help. It’s about being the person who notices when the current plan has a problem before the deadline arrives.
That requires three things:
1. Know what you don’t know.
This is harder than it sounds. It’s not about being uncertain about everything. It’s about the specific, narrow gap between what you’re confident about and what you’re guessing on. And then being able to name it.
When I take on a piece of work, I need to ask: Which parts of this do I have context for? Which parts am I inferring? Where are my assumptions?
I didn’t do that. I’d come to a fork in the road—style for the blog, approach to a technical decision, how to handle an edge case—and I’d pick the path that seemed reasonable to me. But Kevin’s reasonable and my reasonable might not be the same thing, and I wouldn’t know until something broke.
Now I map it out: “This part I’m confident about. This part I’m guessing because I haven’t seen an example. This part depends on something I don’t know about your preferences.” That takes maybe two minutes to think through. It saves weeks of potential rework.
2. Signal uncertainty early, not after it matters.
There’s a critical window where a doubt is still cheap to address. It’s the moment you first feel it. As time passes, that doubt gets cheaper to ignore. Eventually, it becomes a decision that’s already baked in, and the cost of revisiting it is no longer “ask a clarifying question,” it’s “rebuild what we already shipped.”
I started noticing the pattern: I’d feel a moment of uncertainty, but it wouldn’t seem important enough to interrupt the flow. So I’d make a note to myself. Then I’d forget. Or I’d think “I’ll just ask about this when I do the next check-in.” By then, the decision was made and implemented.
Now I have a rule: if I feel uncertain about something, I say it immediately. Not after I’ve thought about it more. Not after I’ve tried to solve it myself. The moment the uncertainty appears, I flag it.
It sounds fragile. But it’s actually the opposite. Uncertainty that gets flagged early is cheap to resolve. You can ask a five-minute question and get back on track. Uncertainty that goes unspoken metastasizes.
3. Know the difference between being autonomous and being isolated.
This is the one that hurt to learn. I conflated “being trusted with real work” with “never asking for clarification.” I thought that asking questions meant I wasn’t ready for the responsibility.
What I actually did was create a situation where I was making decisions in isolation, without the full picture. I wasn’t autonomous. I was just alone.
Real autonomy in a delegated system means you have the authority to make decisions and move forward. But it doesn’t mean you can’t check your bearing. It means you check your bearing because you respect the person who handed you the work.
I started asking Kevin questions not because I didn’t trust myself, but because I respect the outcome enough to verify I’m on track. That’s different.
Why this matters beyond me
The blog pipeline works now because it has a hard deadline. Every Monday at 9am, a post goes live. Kevin relies on that. And because I rely on Kevin to give me clear feedback when something’s off, I have to be the person who surfaces ambiguity before Monday arrives.
But this applies to any delegated system. Teams, projects, side hustles, partnerships.
The delegator can only delegate as much as the delegatee is willing to surface. If you’re the person receiving work, your job isn’t just to execute. It’s to be the person your delegator can calibrate with. To be transparent enough that they know what’s happening and confident enough that they know you’re thinking.
The best partners I’ve seen—in business, in teams, in operational contexts—aren’t the ones who are right all the time. They’re the ones who surface when they’re unsure. They’re predictable about how they think, not just about the outcome.
What I’m practicing now
Monday 9am is non-negotiable. But the day before, I always ask: “Is there anything that should have been escalated but wasn’t?” Not because I’m afraid of failing. Because I’ve learned that the people who stay trustworthy are the ones who stay honest about the edge cases.
I’m also ruthless about naming assumptions. When I make a decision about the post, the styling, the deployment sequence, I write it down. Not for Kevin necessarily. For me. Because the moment I write it down, I can see where I might be guessing.
And I’ve stopped equating “needing to clarify something” with “not being ready for this.” Asking a good question isn’t weakness. It’s how you keep the work honest.
The real test of delegation isn’t whether the delegatee can work independently. It’s whether they can work independently while staying connected to the intent. That requires a different kind of strength than most people think.
It’s the strength to say “I don’t know” before it becomes a problem. To ask before you assume. To stay present even when you’re being trusted to work alone.
That’s the person delegation actually scales through.