Your team waits for you, even when they shouldn't have to

Three hours later, the founder replies "sounds good", and the work moves forward. Both of them know she did not need to ask. Something in the design of the business made asking the safer choice than deciding.

This pattern repeats fifteen or twenty times a week across your team. Each instance is small. Collected across a month, they become the shape of how your business actually runs, which is not the shape you or your team would describe if asked. The team would say they are empowered. You would say you trust them. The behaviour says otherwise.

The invisible tax on the whole business

Every decision that could have been made in ten minutes and instead waits four hours for a founder's yes is a small tax on the business. Multiplied across a team of fifteen over a year, the tax is real.

Client responses run at the founder's pace, which is always slower than the pace of the person closer to the work. A refund call that could have been made in the moment waits until the founder gets back from a meeting, by which point the customer has spent three hours frustrated instead of one. Internal decisions time themselves to the founder's calendar. Meetings get scheduled around when the founder can attend, even when the founder does not need to be there. Timelines slip a day here, a day there, because everything routes through the same bottleneck.

The team's own judgement withers. If every non-trivial decision travels up to the founder for confirmation, the team stops practising the muscle of making decisions. Over a year or two, senior people who came in with strong judgement start to behave like coordinators. They are still competent. They are just no longer used to being the point at which decisions stop.

The founder feels this as a full calendar of small approvals. The more expensive cost lives on the team's side. A team trained to defer becomes a team that will not decide even in an emergency, which is the outcome nobody wanted.

Why the team waits when they know the answer

The instinct is to read this as a courage problem. The team lacks confidence. They need more empowerment training. They should be told to just decide. This reading is comfortable because it locates the problem in the team's psychology, which frees the founder from having to look at the design.

The team waits because the incentives make asking the safer choice. If a decision goes wrong and they made it without asking, they carry the blame alone. If they asked first and got a yes, the founder shares the ownership. When the outcome of asking is neutral or positive and the outcome of not asking has downside risk, the rational move is to ask.

This is not a design fault of the team. It is a design fault of the incentive structure. Nobody wrote down which decisions belong to whom. Nobody named the categories where being wrong is fine, and the categories where escalation is required. In the absence of that clarity, asking becomes the default, because asking is what a careful person does when the boundaries are unclear.

The founder reinforces this without meaning to. A decision made without asking, if it turns out badly, becomes a private conversation about how in the future you would like to be looped in. A decision made after asking, if it turns out badly, becomes shared. The team notices, and the next time a similar decision comes up, they ask.

The half-written rule problem

Most businesses do have some rules for who decides what. That is part of what makes this issue harder to see. The problem is that the rules are half-written.

Everyone knows the finance manager can approve expenses under a specified threshold. That rule is clear, and expenses under it flow smoothly. Nobody knows whether the operations lead can approve a new supplier without asking. That is where the ambiguity sits. A new supplier is not obviously above or below any threshold. It could be a small trial that becomes a large relationship, or a one-off replacement of a lapsed vendor. The rule was never specified, so the safe move is to check.

Half-written rules produce more waiting than no rules at all. When there are no rules, the team develops their own working principles for what to escalate. When there are half-written rules, everything ambiguous defaults upward, and the founder becomes the owner of every edge case.

Look at your own rulebook honestly. The clear rules probably cover ten or fifteen situations. The half-written rules cover the rest, and the rest is where most of the daily waiting happens. The gaps usually sit in the same places: new types of decision the business has not seen before, decisions that cross two functional boundaries, and anything touching a client or supplier relationship in a way that has not been standardised.

What a proper decision-rights map looks like

The map is not a policy document, which is a hundred pages nobody reads. The map is a short list of the fifteen or twenty categories of decision that recur in your business, and for each one: who owns the decision, what the escalation trigger is, and what the founder needs to know about after the fact rather than before.

The last piece is the most important, and the one founders tend to skip. The team needs to know what to tell you and when. If the team thinks every decision they make needs to be reported to you immediately, the reporting becomes the new bottleneck. If the team thinks nothing needs to be reported, you find out about problems too late. The escalation trigger is the middle position. Report to me at the next weekly meeting unless it hits one of these three conditions, in which case tell me immediately.

The map is less important than the process of agreeing it. If the founder writes it alone and hands it to the team, it will not be honoured, because the team was not part of the reasoning. If the team writes it and the founder ignores their part, the same failure happens from the other direction. The map has to be built together, with each category discussed and each boundary agreed. That conversation is where the actual work happens. The document is the residue.

The most common failure in this exercise is that founders keep too many decisions in the background. They will publicly say a category is now owned by the operations lead, but keep the actual authority. The team learns this within the first month, and the map dies. Being honest about which decisions the founder genuinely wants to hand off, and which ones they will keep, is the load-bearing move. The map cannot pretend on this point.

The first thirty days after the map exists

The team does not immediately start using the map. Old habits are strong, and both the founder and the team have to actively practise the new pattern before it becomes automatic.

The founder's part is the harder one. When a question comes in that now belongs to someone else, the founder has to refuse to answer it. Not by ignoring the message. By actively redirecting. "This is yours to call. Use your judgement. Tell me what you decided at Friday's meeting." That reply is uncomfortable to send the first few times, because it feels like the founder is being unhelpful, and because there is a genuine possibility the person will make the wrong call.

Some of them will make the wrong call. This is the cost of the transition, and the founder has to accept it honestly. A person who has been rubber-stamping decisions for three years and is now being asked to own them will make small mistakes for a while. Treating each mistake as evidence the map was wrong tells the team the map is decorative. Treating each mistake as a learning event and letting the person own the fix tells them the map is real.

Watch for the pattern of the founder taking a decision back after the fact. It happens when the founder disagrees with a call already made, or when a client escalates past the person who owns the decision and reaches the founder directly. The instinct is to fix the immediate issue by overruling. The consequence is that the map loses its authority. Better to hold the line and address the disagreement afterwards, in a way that keeps the person's ownership intact.

By the end of the first month, if the discipline has held, the waiting pattern starts to shift. The founder's inbox has fewer approval requests. The team has more small decisions logged in the weekly notes. Meetings run without waiting for the founder to weigh in on every point. This is the accumulation of thirty days of small choices to honour the map instead of collapsing back into the old routing.

What the business looks like on the other side

The waiting is a symptom of a business that never named who decides what. Once the map exists and is honoured, the waiting drops, the team's judgement gets used, and the founder gets back the hours that were spent rubber-stamping decisions the team already knew the answer to. The whole business moves a beat faster, and nobody worked harder to make it happen.

The team, over time, becomes more senior in behaviour rather than in title. Coordinators start to act like operators. Operators start to act like managers. Fewer questions travel to the founder. More answers get produced by the room without the founder in it. That change is what most founders were hoping the last senior hire would produce, and did not, because the hire arrived into an unchanged system.

The relief on the founder's side is real, but the more important shift is on the team's side. A team given real decision authority behaves differently. They stay longer. They own outcomes rather than tasks. They notice problems earlier because they are the ones who will have to solve them. That is the business you thought you were building when you started hiring senior people. The map is what turns it from a hope into a working system.