A small business owner I know was running a project review on a Thursday afternoon last fall. His team walked him through five active client projects. On four out of five, the same phrase came up. "We are waiting on you."
Not waiting on a vendor. Not waiting on the client. Waiting on him.
He was in meetings from 8am to 6pm. His inbox was a backlog. His team had stopped sending quick questions because they knew he would not respond until Saturday. So they stopped. They just waited. Work sat.
He did not have a time management problem. He had a design problem. The entire operation was built so that nothing moved unless it moved through him. And when he got busy, which he was always going to get, the whole thing froze.
This is the single most common pattern I see in growing small businesses. It is also one of the most fixable, once you stop treating it as a personal failing and start treating it as a system.
Why this happens
It starts for good reasons. Early on, you are the only one who knows the business well enough to make the calls. You want quality. You want consistency. So decisions route through you.
Then the business grows. You are still the default decision maker, because nobody ever decided otherwise. The volume of decisions grows with the business. Your bandwidth does not. So more and more stuff starts piling up at your desk, and the team, rationally, stops trying to move until they hear from you.
Goldratt called this the Theory of Constraints. Every system has one thing that limits the pace of the whole thing. If you do not change the constraint, you do not change the pace. You just pile more work against the bottleneck and watch it compound.
When you are the bottleneck, more hiring does not fix it. More process does not fix it. More tools do not fix it. The only thing that fixes it is moving decisions and information out of you and into the system.
The three moves that actually help
There are really only three things that consistently break this pattern. They work together. None of them work alone.
Decision frameworks. Most of what your team is waiting on is not a complex judgment call. It is a decision they do not have permission to make, or they are not sure whether they have permission. Write it down. Under what conditions can they decide on their own. Under what conditions do they loop in a manager. Under what conditions does it actually come to you. Keep it simple. One page. Once that page exists, the volume of questions hitting your inbox drops by something like half almost immediately. Not because your team is suddenly different. Because they finally know what is theirs.
Documented information. Most of the rest of what your team is waiting on is not a decision. It is information. What is the policy on this. How do we handle that. What did we decide the last time this came up. If the answer only lives in your head, the only way to retrieve it is to ask you. If it lives in a shared doc, they look it up and move on. A small knowledge base, even a scrappy one in Notion or a shared Google Drive, takes hours you already have on a slow Friday. It saves hours every week after that.
Response time norms. If you are going to stay the person who handles the genuinely complex decisions, your team needs to know how long a response actually takes. Same day. Next day. Friday. Whatever it is. When they know, they can plan. They can send the question, keep working on something else, and come back to it when your answer lands. When they do not know, they just stop, which is what they have been doing.
That is the whole playbook. Frameworks, documentation, response norms. It is not complicated. It just has to get built, which most small businesses never quite do.
The Deming piece
W. Edwards Deming used to say that most performance problems are system problems, not people problems. On the order of 94 percent by his count.
When your team is stuck waiting on you, the easy story is that they are not taking initiative. Occasionally that is true. Mostly it is not. Mostly they are behaving rationally inside a system where the fastest path to getting the right answer is to wait for your answer. If you want them to take more initiative, you have to change the system so that initiative is actually the fastest path.
That change is not a pep talk. It is a framework, a doc, and a response norm.
What "asynchronous first" actually means
One of the quiet shifts that comes with this is moving the team toward what I would call asynchronous first. Meaning: questions go in writing, in a shared channel, with a reasonable response expectation. Real-time conversations are reserved for things that actually benefit from real time.
Most of what currently consumes your day as an owner does not need real time. It needs a thoughtful written response, which you can batch into two or three chunks a day instead of being interrupted continuously.
When you do that well, two things happen. Your own deep work comes back. You have hours, not minutes, to think about the hard stuff. And your team gets faster, because they can look at your past written answers and see the pattern of your judgment, which they could never do when every answer was a hallway conversation.
The common mistake
The most common mistake I see is trying to solve this by just working longer hours. The thinking is that if you could just clear the inbox, the team would unblock. That does not work, because the inbox is a symptom, not the cause. You clear it on Saturday, it is full again by Tuesday, because the system is still routing everything through you.
The other common mistake is trying to solve it by hiring a chief of staff or operations lead with no framework in place. The new hire becomes the new bottleneck, because the system still routes everything through one person. You just changed who.
The framework has to come first. Then hiring against a framework works. Without one, you are adding bodies to a broken design.
Monday
Look at your inbox and your Slack DMs from last week. Pull out every question that came in from your team. Read them.
Sort them into three piles. Ones they should have been able to decide on their own. Ones where the answer already exists somewhere, they just did not know where. And ones that genuinely needed your judgment.
The first pile is your decision framework. Those are the categories that need written boundaries, so the team stops asking. The second pile is your documentation project. Those are the questions that deserve a one-page answer somewhere they can find it. The third pile is what your job actually is.
Start on the biggest category in pile one this week. Write one paragraph that says what your team can decide on their own in that category. Send it. Then stop answering those questions. When the next one comes in, link them back to the paragraph and ask them to make the call. Adjust the paragraph as needed.
That is the whole beginning. One category. One paragraph. You are not trying to redesign the business in a week. You are trying to build one channel so that one kind of work can flow without you. Do it again next week with the next category.
The point
You did not start a business to be the bottleneck. You probably did not even realize you had become one, because from inside it feels like you are just doing your job.
The fix is not working harder. It is not being nicer about delegation. It is building the system so that decisions and information flow through it instead of through you. That work takes a few hours a week for a few months. And then, quietly, your team stops waiting, your calendar opens up, and the business starts moving at the speed of the team, not the speed of your inbox.
If you want help mapping where the bottleneck actually is in your specific operation, a Flow Check is a two-week diagnostic that covers exactly that. You come out with a clear picture of what is blocking your team and a 90-day plan for moving those decisions and that information out of your head.