"I'd rather just do it myself" is the phrase repeated most often by leaders who end up overloaded with tasks they should have delegated months ago. The explanation they give themselves is usually about trust: "I can't trust that it'll get done right." But in the vast majority of cases, that's not where the problem is. It's in how the request was formulated — or never formulated at all.
Delegating is making a request, and most requests are badly made
In the Ontology of Language, requests and promises are the basic unit of coordination between people. Delegating isn't "handing a task to someone": it's making a request. And a poorly formulated request —no clear recipient, no explicit conditions of satisfaction, no deadline— doesn't generate coordination, it generates friction that gets paid for, expensively, weeks later. "See if you can take care of this" isn't a request: it's a mention of a wish with no commitment from either party.
The automatic judgment behind "nobody does it as well as I do"
Underneath the "I don't trust it" explanation there's usually an automatic judgment that was never examined: the belief that personal control is the only guarantee of quality. That judgment acts as a filter and blocks any real act of delegation from the start, even when the leader says out loud that they want to delegate more. It's a direct example of the central premise: we don't see the world as it is, we see it as we are —and as long as that judgment goes unnamed, no delegation technique holds up.
Delegating isn't letting go of control: it's designing a request with clear conditions of satisfaction.
The four conditions of a request that can actually be fulfilled
An effective request has four components that are almost never all present in an improvised delegation: what concrete outcome is expected (not the task in the abstract, the observable result), who is going to do it (by name, not "the team"), by when (a date, not "whenever you can"), and to what standard it's considered fulfilled. Without these four explicit elements, any outcome is valid for whoever executes it and none is valid for whoever asked —and that's where the leader ends up taking the task back.
Conditions of satisfaction: the explicit, agreed-upon description of what makes a request count as fulfilled. Without them, judging whether something "went well" or "went badly" is left to each party's own criteria — and that's where conflict starts.
Coordinated follow-up, not micromanagement
Micromanagement isn't a personality trait of the controlling leader: it's what's left available when conditions of satisfaction were never made explicit. If the only moment of control is reviewing everything as it happens, it's because no one agreed in advance at which points progress would be checked. A well-designed request includes follow-up points agreed from the start —an interim date, a brief check-in— that replace constant supervision with explicit coordination between both parties.
Does your team need requests and delegation that actually work?
See free diagnostic Message on WhatsAppFrequently asked questions
Because what happened wasn't a request, it was a mention of a wish: "see if you can take care of this," with no clear recipient, no deadline, and no explicit conditions of satisfaction. Without those three elements, any outcome is valid for whoever executes it and none is valid for whoever asked — so it ends up back on your desk.
By defining the conditions of satisfaction upfront (what outcome, to what standard) and the check-in points agreed at the moment of the request, not improvised afterward. Micromanagement shows up when those conditions were never made explicit, so the only available control is reviewing everything as it happens.
Both. The technique of an effective request (what, who, by when, to what standard) is learned quickly. But if the judgment that "nobody does it as well as I do" is still running underneath, that technique gets dropped the first time a delivery isn't perfect. That's where ontological coaching works.
Comments