The senior engineering manager is out for two days, and suddenly three delivery decisions are waiting on you.
A product manager wants approval to change scope. An IT leader needs a call on a vendor issue. A director asks you to review an executive readout that has already been rewritten twice.
Your calendar fills with decisions that should have moved without you.
That is a decision bottleneck. The org chart may show dozens of leaders, but the work still runs through a handful of people. You are carrying the decisions, the context, and the risk for too much of the organization.
I have seen this pattern in large operations environments. It usually grows quietly. A manager gets criticized once for making a call that went sideways. An executive asks for one more approval layer. A role changes during a reorganization, but nobody updates the authority attached to it.
Then everyone starts sending decisions upward, just to be safe.
The decision bottleneck is usually an authority problem
When a manager escalates a decision, it is tempting to label the behavior as a confidence issue or a lack of ownership. Sometimes it is. More often, the organization has failed to make the boundaries clear.
Consider a senior engineering manager deciding whether to move a delivery date by one week because a dependency is late. Does that manager have authority to adjust the timeline? Can they make the call if the customer impact stays within an agreed range? Do they need product approval, your approval, or only a notification after the decision?
If nobody can answer those questions quickly, the decision travels upward.
The same thing happens with executive readouts. A manager drafts the update. Their director edits it. A VP rewrites the framing. The executive team changes the emphasis.
A decision can drift upward for several reasons. Sometimes a manager got burned once for making a reasonable call without enough context, so the safer move now feels like escalation. Sometimes decision rights were never defined after a promotion, reorg, or scope change. In other cases, two leaders each believe they hold approval authority, or a manager is responsible for an outcome without the authority to shape it. Senior leaders may keep answering questions that should have been redirected, and the organization may reward caution more visibly than sound judgment.
McKinsey’s research on organizational decision making makes a similar point: decision effectiveness depends on clear roles, information, and accountability, not simply on having more senior people involved. You can read their analysis on untangling organizational decision making.
Four signs your org has a decision bottleneck
One sign shows up when one or two senior leaders are away.
If work slows dramatically while a particular VP, director, or senior manager is on vacation, at a conference, or out sick, pay attention. The absence exposed a dependency. The team may know how to perform the work, but it does not know who can make the decisions that keep the work moving.
Another sign is routine escalation from capable managers.
A manager brings you a choice between two reasonable options, along with enough information to decide. You answer. The next week, the same type of decision comes back. That pattern tells you the organization is waiting for your permission instead of building judgment at the appropriate level.
You will also see it in executive material that gets rewritten at every layer.
A manager prepares an update on a product milestone or infrastructure risk. The director changes the content. The VP changes the message. The executive team asks for a different view. Rework increases, but the capability to prepare a useful executive readout does not.
Then there is the sign that only a few people understand how the pieces fit together.
Ask a manager how a product decision affects engineering capacity, customer commitments, support readiness, and executive priorities. If only a small group can explain the connections, information is concentrated along with authority.
People wait on whoever knows the history, and teams hesitate when they cannot see the trade-offs. New leaders also take longer to become effective because the operating logic lives in conversations instead of a usable system.
Your team’s performance will eventually reflect your personal availability. I wrote more about that pattern in Your Team’s Ceiling Is Your Bandwidth.
How to find the decision bottleneck on your plate
You do not need a large organizational redesign to see where decisions are collecting. Start with your own calendar, inbox, and leadership meetings.
Use a recent sample of decisions that came to you. Include operational calls, approvals, escalations, and executive materials. Then audit each one with the questions below.
- What decision was actually needed? Separate the decision from the surrounding discussion. “We need to talk about the release” is not a decision. “Should the team move the release date by one week?” is.
- Who brought it to me? Note the role, not only the individual. You are looking for patterns across engineering managers, product leaders, IT managers, and program leads.
- What authority did the role already have? Look for written expectations, budget boundaries, risk thresholds, customer impact, and existing operating agreements. If none of those exist, mark the authority as undefined.
- What made the person escalate? Ask whether the issue involved genuine risk, missing information, competing priorities, unclear ownership, or fear of being blamed. Do not accept “they wanted alignment” as a complete answer. Alignment with whom, and for what purpose?
- What did my involvement add? Perhaps you had information they could not access. Perhaps you resolved a conflict between functions. Perhaps you simply approved a choice they were already positioned to make.
- Where should the next decision of this type sit? Decide whether it belongs with you, one level down, or in a shared forum with one clear decision owner. Write the answer in plain language.
The fifth question will make you uncomfortable.
A director often discovers that their involvement added speed in the moment while reducing capability over time. You answered because the meeting was already happening. The executive review was tomorrow so you rewrote the slide. You approved the exception because the team was stuck.
Those choices taught the organization to wait for you.
Move authority down without creating unnecessary risk
Delegation works when the decision maker has three things: a clear outcome, enough context, and boundaries for escalation.
Start with decisions that happen often and create little value when they reach your level.
For each decision type, define the role that makes the call, the people who provide input, the conditions that require escalation, the information the decision maker must document, and the point at which you receive an update.
That structure gives managers room to act while preserving visibility.
Your script can be simple:
“You own this decision within these boundaries. Bring me the decision when it crosses this threshold. If the threshold is not crossed, make the call and document the reasoning.”
Then follow your own rule.
If a manager brings you a decision that sits within the agreed boundary, do not take it back because you prefer a different option. Ask for the reasoning. Ask what trade-off they considered. Confirm the decision and let the manager carry it.
If the decision is weak, coach the judgment.
The October 6 post, Before You Buy Leadership Training, Know Which Problem You Have, addresses the importance of identifying the real performance problem before choosing a solution. The same discipline applies here. Before you send a manager to another leadership workshop, determine whether the problem is judgment, confidence, information flow, or a missing decision boundary.
A workshop cannot define authority that the leadership team has left vague.
Give managers a safe way to make the call
A manager who got burned once may keep escalating long after the original incident has passed.
You can correct that pattern by revisiting the decision, separating the quality of the judgment from the outcome, and making the learning explicit. Your review should examine the reasoning, the information available at the time, the risk considered, and the follow-through.
Ask what they knew when they made the call and which assumption mattered most. Get clear on the risk they accepted and what signal would tell the team to change course. Then pin down what authority should apply the next time.
I have had to clean up this exact pattern before, and vague feedback never fixed it.
I had this exact conversation with a director regarding a decision that didn’t follow the standard process and ended up putting the company at risk. They had the authority but their reasoning escalated the problem. Our discussion centered around how to identify the risk, what inputs to use and when to escalate.
That conversation gives the manager something practical to use. “Be more confident” does not.
You should also review how your own reactions shape escalation. If managers receive sharp criticism for decisions you later revise, they will protect themselves by asking for permission earlier. If every exception becomes a leadership postmortem, routine decisions will start arriving with unnecessary layers of documentation.
Managers should be expected to make decisions within their authority, communicate risks early, and own the outcome. They should also know where the line sits and what support is available when a decision crosses it.
If you want a quick reflection tool to pass along to a manager on your team, share the Find My Leadership Gaps quiz. It can give them a starting point for identifying where judgment, confidence, or communication may be getting in the way.
Your next step is to choose one decision category that keeps landing on your desk and move it one level down with clear boundaries. Watch what happens to the work, the manager, and your own calendar.
If decisions are still stacking up after you have clarified roles, information, and escalation paths, the deeper issue may sit in the leadership operating system. My Leadership Performance Diagnostic is a focused engagement that helps identify where leadership performance is getting stuck and what needs to change first.
