You are not bad at delegating. Your team cannot see the decision behind what you do.

That is the whole problem. The owner thinks the gap is trust. The team thinks the gap is information. Both are right, in different directions.

I spent eleven years running a contracting firm with three crews and a dispatcher. For the first six of those years, I was the bottleneck on every reschedule, every customer call, every job that ran into a problem the crew did not have a script for. I told myself I trusted my dispatcher. I trusted her with the calendar. I did not trust her with the decisions, because I had never written down what the decisions were.

That is not a delegation problem. That is a visibility problem.

The fix is a one-page decision doc. Five sections. Plain English. Written in the language of the person who has to make the call, not the language of the owner who has been making it on autopilot for years.

What the data actually says

Gallup studied 143 CEOs of Inc. 500 companies and found the ones with high delegation talent grew their companies 33 percent faster than the ones with low delegation talent — and generated 33 percent more revenue. Delegation is not a soft skill. It is a growth lever.

The owners I work with already know the cost. They feel it on Tuesday afternoons when the same six questions land on their desk that landed last Tuesday. The team is not lazy. The team is waiting — because the picture of the decision lives in the owner’s head and nowhere else.

Where most owners read this wrong

Mistake one: treating delegation as a personality issue. Owners say “I have a hard time letting go,” and what they mean is “I would let go if I trusted them more.” That framing puts the work on the wrong person. The team cannot earn trust on a decision they cannot see. If the dispatcher does not know what good looks like, she cannot show you good. You have to show her first.

Mistake two: verbal delegation. “Use your judgment.” Team uses judgment. The decision is reasonable and different from what the owner would have made. Owner is unhappy. Team is confused. Nobody is wrong. The owner was holding a default in their head that the team had no way to see. Verbal delegation transfers the work, not the picture.

Mistake three: over-engineering the doc. I have seen owners try to write a thirty-page operations manual to solve a delegation problem. Manuals are not the answer. A delegation doc is one page. Anything longer and the team will read it once and never again. The point of the doc is not to enumerate everything. The point is to make the picture in your head visible on the page.

The decision doc

Five sections. One page. Written for the person making the call.

Decision-doc template

The one-page decision doc

Written for the person making the call — not the owner who has been making it on autopilot.

[The decision being delegated. Plain English. One sentence.]

  • [What the person should look at before deciding.]
  • [Three to five inputs. No more.]
  • [If an input is hard to find, name where it lives.]

[The usual call. One sentence. Then one sentence on why — the reason the default is the default.]

  1. [Edge case people will mis-describe — and what to do.]
  2.  
  3.  

[The narrow band where this comes back to the owner. One sentence. Be specific.]

The sections are in that order on purpose. The decision is the headline. The inputs are what to look at. The default is what to usually do — and the why is critical, because the why is what lets the team deviate intelligently when the situation calls for it. The edge cases are the three traps people mis-describe to themselves. The escalation rule is the narrow door back to you.

This is a small-business simplification of decision-rights frameworks that have been around for decades. Bain wrote one called RAPID — Recommend, Agree, Perform, Input, Decide — and it is useful vocabulary if you have a larger team. At the owner-operator scale, the shorter doc covers the ground.

A worked example

Here is one I wrote for a dispatcher early on. The decision: what to do when a homeowner is not at the property when the crew arrives. Common, costly if mishandled, and exactly the kind of decision I had been making by phone from my truck for years.

Worked example — dispatcher

Reschedule a crew when the homeowner is not home

A filled-in version of the template above. Written in the dispatcher's language, not the owner's.

Reschedule a crew when the homeowner is not home at the scheduled start of a job.

  • Crew's calendar for the next three business days.
  • Whether this is a multi-day job already underway, or a same-day visit.
  • Whether the customer has missed a start before (CRM tag).
  • Forecast — is rain coming this week?

Reschedule to the next open slot within three business days, charge no fee, and send the customer a text. Why: keeping the crew billable beats keeping the slot. A return visit costs us less than a half-day of crew downtime.

  1. Customer texts during the drive saying they will be thirty minutes late: hold the slot, do not reschedule. Use the buffer to start the exterior work.
  2. Same customer has missed two starts in the last ninety days: reschedule but flag it for me — we will move them to deposit-required.
  3. The job is day three of a four-day project: work the day with whatever scope is accessible from outside, finish the inside work tomorrow.

Any reschedule that pushes the job past five business days — that is a customer-relationship call I want to make.

The page does three things at once. It tells the dispatcher what to do. It tells her why the default is the default — so she can decide intelligently when something is off. And it names the three edge cases she would otherwise have to call me about. That is where the bottleneck used to live.

When I wrote the dispatcher’s first decision doc, I expected it to take a couple of hours. It took a couple of weeks. Not because it was hard to write. Because every section forced me to look at a decision I had been making by feel and ask: what is the default? What inputs am I actually looking at? What edge cases keep showing up? Most of those questions did not have clean answers in my head until I tried to write them down.

That is the gift of the doc. It does not just transfer the decision. It clarifies the decision for you.

How to run it this week

Start with one decision. Not five. Not ten. One.

Pick one you keep getting interrupted on — a customer call, a scheduling judgment, an order quantity, a refund request. If you have answered it more than three times in the last month, it qualifies.

Sit down with the person who should be making the call. Walk them through the doc, section by section, in real time. Let them ask questions. Let them poke holes in the default. The answers to their questions go into the doc.

When the doc is written, give them one full cycle of running the decision themselves. You are reachable, but you are not in the room. After the cycle, sit down again. Update the doc with what surprised them. The doc is a living thing. It is more valuable for being edited, not less.

Then start the next one.

Five decision docs in a quarter, and you will feel the bottleneck loosen. Not because your team got better — they were always good — but because the picture you carry got transferred onto paper, where the team could see it.

The intellectual lineage, briefly

The idea is older than my dispatcher.

David Marquet, a former Navy submarine captain, wrote Turn the Ship Around! about replacing permission-seeking with intent-stating. He had his crew tell him “I intend to do X” instead of “permission to do X, sir?” The submarine ran better. The book is the canonical operator text on this idea.

Peter Drucker wrote about it earlier in The Effective Executive. His line that has stuck with me: most decisions are not unique events. They are instances of a general type. The first job of an effective executive is to recognize the type.

That is what the decision doc does. It names the type. It says: this is not a special call. This is that call. Here is what we usually do. Here is when it is different.

For the small-business-vernacular version of the same idea, Gino Wickman’s Delegate and Elevate — part of the EOS framework — is a useful complement. It helps you decide which decisions to delegate first. The decision doc helps you delegate them well.

The edge cases

“My team won’t read it.” They will, once. That is enough. The doc is not a manual. It is a description of the picture in your head. Once they have read it, they have the picture. They consult the page again only on edge cases.

“What if my team disagrees with the default?” Good. That is a sign the default is wrong, or the inputs are missing, or the why is weak. Update the doc. The disagreement is a gift, not a problem.

“What about decisions I make differently every time?” Those are not decisions yet. They are reflexes. Write the doc anyway. By the third edge case, you will see the pattern. If there really is no pattern, the decision is genuinely unique, and it stays with you.

“How many of these do I need?” Five to ten covers ninety percent of the recurring decisions in a small business. If you are writing fifty, you are writing manuals, and that is a different document.

For the canonical text on intent-based delegation, Turn the Ship Around! by L. David Marquet. Short, plainspoken, written by an operator.

For the older and more general piece, Drucker’s The Effective Executive. The two chapters on decision-making are worth the whole book.

For the Gallup data on delegation as a growth lever, the original Gallup article is short and worth a read.


You are not bad at delegating. Your team cannot see what you see. That is fixable, on a page, this week.

Write the picture down.

— Maya