The Slack thread went quiet after the first hard question. Then somebody tagged you.
The team may be capable. Waiting can still be the safest move the business has trained into them.
Your team waits because waiting is rational inside the current system. They may have tasks, titles, and meetings, but not a clean right to approve, reject, spend, or carry consequence without you. Another delegation speech will not change that. Name which decisions are theirs and which ones still come back.
The manager knew the client, the margin, the promise, and the deadline. Then one detail moved outside the normal script.
Instead of deciding, they gathered the facts, wrote the safest possible message, and tagged you.
You answered because the client was waiting. The work moved. The business learned the same lesson again: when a decision carries consequence, send it to the owner.
Nobody said no. Nothing moved until you said yes.
Every returned decision weakens the person closest to the work and adds another reason for the company to watch your availability.
Routine work moves. Exceptions wait. The owner becomes the place where every undefined edge lands.
A careful update is safer than an independent call when the standard is unclear or last time the call was reversed.
A meeting, flight, family day, or uninterrupted work block can stop decisions that should happen close to the customer and the work.
A job title is not permission. A meeting is not authority. “Use your judgment” is not a usable standard when the downside still belongs to you.
The team needs to know four things before a hard call arrives: what it owns, what good looks like, where the boundary sits, and what must come back.
If any one of those is missing, waiting can be the most intelligent response available.
One worked example: a client asks for an exception.
The person closest to the client makes the call.
The manager decides when price, scope, delivery promise, and the relationship do not materially change.
The call returns when it changes price, scope, delivery, legal exposure, or the relationship itself.
Share the result and reasoning so the standard becomes easier to use next time. Do not copy the owner only for comfort.
Do not redesign the org chart. Start with one call that came back twice and make its authority visible.
Use the actual Slack tags, copied emails, meeting notes, spend requests, and client exceptions. Memory will make the pattern cleaner than it was.
Do not write “operations” or “customer service.” Write the actual call: approve a replacement, adjust a deadline, choose a vendor, or accept an exception.
Name what the person can decide, the standard they should use, and the specific change that requires escalation.
If the decision stays inside the boundary, do not quietly take it back because you would have chosen differently. Improve the standard after the result.
Usually because waiting is safer than deciding inside the current system. The team may own the task, but not the right to approve, reject, spend, or carry consequence.
Sometimes. But if capable people can do the work and still freeze at judgment, inspect the right to decide before you give another delegation speech.
Look at the last five decisions that came back. Name the decision, the person who should own it, the standard they should use, and the exact boundary that triggers escalation.
Work with Stan when the permission loop is one symptom inside a bigger business pattern and you are not sure which decision to move first.
Bring the recurring permission loop to 1:1 business work when the same yes keeps returning to you. The point is to move one real decision, not give the team another speech.
