The CEO as middleware: how approval chains become the company bottleneck

Consider a €12,000 purchase order waiting for three signatures. One approver is unavailable; another needs context nobody attached. The supplier cannot hold stock indefinitely. This example is a way to inspect a queue, not a client result.

Nobody designed that approval chain. It grew. Each layer was added for a reason that made sense at the time. A bad vendor decision in 2019. A compliance question that scared someone. A founder who trusted nobody else to read a contract.

The old controls may have been useful. Review whether their present routing still matches the risk and the people authorized to decide.

When routine decisions reach the CEO

Middleware is the thing that sits between two systems and translates between them. It is necessary when the systems cannot talk directly. It becomes the bottleneck when every message has to pass through it, in order, before anything else happens.

An approval chain can route money, client and hiring decisions through the same person even when others have the expertise. Before changing it, check which decisions need executive authority and which are waiting for a boundary the company never defined.

The pattern shows up in small ways first. The email you get copied on that does not need you. The meeting where nothing gets decided because the right person was not in the room and you were. The Slack thread that sits for four days waiting for your green light on something that, if it were a bad idea, would cost the company less than the time you spend reading about it.

Then it shows up in ways that cost real money. The client who waited three weeks for a pricing exception and went to a competitor who answered in two days. The hire who accepted another offer because your approval process for the package took longer than the other company's entire interview cycle. The vendor contract that expired because nobody could get the renewal terms signed before the deadline.

None of those are strategy failures. They are routing failures. The decision was obvious. The chain was not.

There is a reason this happens, and incompetence has nothing to do with it. The pattern was rational behavior at a specific point in the company's history.

When the company was small, the founder needed to approve everything. That was the control. That was how quality stayed high and money did not disappear. The company grew. The founder stayed in the approval loop because it had worked. Nobody built a different structure. The informal system scaled because the founder could still read every email.

At some point, the volume exceeded what one person could process without becoming the delay. That point is different for every CEO. For some it was fifty people. For some it was a hundred and twenty. For some it was the first client who asked a question the founder could not answer from memory.

The rational response is to delegate. The structural response is to build the conditions where delegation is safe.

Most companies do the first without the second. They give people titles and responsibilities. They do not give them decision boundaries. The result is that the person who was delegated to still escalates, because escalation is safer than a wrong call. The CEO is still in the loop. The middleware is still running.

Check three conditions in a stalled decision: the person authorized to decide, the information available to them and the consequence of acting late. A title without a usable decision boundary leaves the escalation in place.

That last one is the quiet killer. A slow decision has no name. It does not appear on any report. It shows up as the quarter that felt flat, as the team that stopped proposing things, as the clients who drifted away without a dramatic moment.

Review mistaken decisions alongside delayed ones. A faster process is only useful if the responsible person has the evidence and authority to make a sound decision.

Decision speed alone is a poor target. A reversible purchase and a safety-critical commitment need different review. Measure delay alongside risk and the quality of the decision.

Review the last five decisions

Take the last five decisions that went through you. For each one, ask: if this decision had been made by someone else, at the appropriate level, with the information they had, what is the worst that could have happened?

If the answer for most of them is a manageable mistake, a delayed outcome, or a learning moment, then the problem is the routing itself. The decision quality was fine. The person would have handled it.

If the answer is genuine existential risk, then those specific decisions do belong at the top. The question becomes whether you can distinguish the real ones from the ones you have been trained to treat as real because of something that happened once, years ago, in a smaller company.

Use the answers to separate executive decisions from routine approvals whose authority and evidence can be defined elsewhere.

The fix is not to approve things faster. It is to stop routing them through you in the first place.

That requires naming what a decision boundary looks like. A purchase under a certain amount, with a known supplier category, approved by the ops lead, does not need you. A client exception that deviates from standard terms by less than a defined threshold, with the margin protected, goes to the sales director. A hiring decision for a role that has been defined, with a salary inside the approved band, gets signed by the hiring manager and HR.

Write down the limit, permitted evidence, approver and exception path for each decision. Review the boundary after a failure or a material change in the business.

The companies that solve this do not solve it by trusting people more. They solve it by designing systems where the decision does not need to travel. The information is assembled at the edge. The boundary is explicit. The exception path is known. The CEO sees the pattern, not the packet.

There is a cost to being the middleware that rarely gets calculated.

Every hour you spend routing decisions is an hour you are not doing the work only you can do. The strategy. The client relationship that keeps a key account. The hiring decision for the next leader. The product direction that determines whether the company matters in three years.

Record how much leadership time the queue consumes and what decisions are being delayed. That makes the tradeoff visible without assigning an invented hourly value to the CEO.

The team on the other end of your approvals is also paying. They are learning that proposing things takes weeks. That the safe play is to wait. That the person who escalates gets answers and the person who decides gets audited. Over time, the team optimizes for not triggering the queue. Initiative goes down. The company gets slower. And the middleware gets busier.

It is a loop. The only way out of the loop is to build the structure that makes the routing unnecessary.

Start by checking whether the approval queue is a material problem in your operation. Map its actual decisions and compare the delay with the controls each one requires.

In diagnostic work, one of the first things that gets mapped is the decision flow. Not the org chart. The actual paths a decision takes from trigger to outcome. The handoffs. The waiting. The information that gets lost between layers. The places where the same decision gets reviewed twice by people who do not know they are reviewing the same thing.

For each handoff, ask why it exists. Keep the legal, financial and operational controls that remain necessary. Test whether historical duplication or missing decision boundaries explain the rest.

Solve IT routes each qualified case before prescribing an engagement. A diffuse cross-functional problem may need a War Map. An already-defined workflow may go directly to a bounded Feasibility Sprint. Scope, timing, price, and risk controls are agreed for the actual case before work begins.

The map is the starting point. Not the fix. The fix comes after the company sees, in specific terms, where its decisions are traveling and why.

You did not build your company to be its message bus. You built it to make something, serve someone, and grow in a direction you chose.

The middleware pattern is a side effect of success. The company got big enough that one person could not hold every thread, but the structure never got built that would let the threads run without that person.

The companies that stop treating the CEO as middleware do not become reckless. They become legible. Decisions move. The team learns what good looks like. The founder gets their time back, not because they delegated more, but because the routing problem was solved at the structure level instead of the inbox level.