The TSA of Your Organization
The Elimination Project, Part 6
Approval chains feel like governance. Most of the time, they’re governance theater. We don’t need fewer approvals. We need clearer ownership. (We’ll get to that next week. This week, the operational fix).
If you haven’t read Part 1, start there. The whole series rests on knowing what your work is supposed to move.
Today we go after a category most leaders refuse to question because it feels like the responsible thing to do. Cutting meetings feels brave. Cutting reports feels brave. Cutting approvals feels reckless.
Today, I want to argue the opposite. Most of your approval chains aren’t protecting you. They’re creating the illusion that someone is paying attention, while delivering none of the actual oversight that illusion implies. It’s sort of like the TSA line at the airport. It’s an illusion of safety. The latency and frustration approval chains create is real. The risk they were designed to catch is, in most cases, not being caught.
Let me show you why, and how to fix it operationally. The next piece in this series goes after the deeper question, why organizations end up with these chains in the first place, and the conversation many leaders never had with their teams that would have prevented them. Today, let’s fix the operational bloat.
What an Approval Chain Is Actually For
Every approval exists because, at some point, someone made a real argument. “This kind of decision needs another set of eyes. We do not want a single person making this call alone. The risk of getting it wrong is large enough to justify slowing down.”
That argument is sometimes correct. There are decisions that genuinely benefit from a second reviewer, a third reviewer, or even a committee. Big spends, material risk, or decisions that affect the organization’s identity, security, or solvency... yeah, let’s get a second set of eyes on those.
The problem is that approvals are easy to add and almost impossible to remove. Every time something goes wrong, the standard response is to add a new approval step to prevent it from happening again. The thresholds get lower. The chains get longer. The original purpose of “another set of eyes” becomes “five people none of whom are actually looking.”
Walk through any organization that’s been around for more than a decade. The approval architecture looks like a coral reef with layers built on layers built on layers, each in response to a specific incident, none of which were ever revisited once the incident faded from memory. Most of the layers are no longer doing anything. They’re just there.
This is the architecture you’re operating inside. The question is whether you can see it
.
Once, I had a company vehicle and was told that I had to get approval before I could get the oil changed. If you’ve read much of my writing, you know that this type of logic isn’t something I can ignore. I asked our business manager if he wanted oil changes done every 5000 km and of course he said yes. My next question was, “Is there ever an occasion where getting an oil change would not be approved?” The answer was obviously no. My next question was, “Then why in the world do I need to get approval for routine maintenance that you’ll always approve?” Crickets.
The Three Failure Modes
Approval chains fail in three ways. Each one is common. Each one is invisible to the person inside the system.
Failure mode 1: The rubber-stamp chain.
The chain has five reviewers. Four of them auto-approve everything. They’ve approved every request that has come across their desk for the last two years. Their “review” consists of clicking a button. They aren’t actually reading the request. They aren’t actually thinking about whether it should be approved.
This is the most common failure mode and the worst one. A rubber-stamp chain is worse than no chain at all. With no chain, the requester knows they own the decision. With a rubber-stamp chain, the requester thinks the decision has been reviewed, and the reviewers think the decision has been delegated to other reviewers. Nobody is actually paying attention. The chain manufactures false confidence.
Failure mode 2: The latency chain.
Each reviewer takes one to three days to respond. Five reviewers means a week to two weeks of latency on every decision. The decisions that make it through are stale by the time they’re approved. The decisions that fail to make it through fail not because they were rejected, but because the requester gave up and worked around the system.
Latency is its own form of governance failure. A decision that takes three weeks to approve is, for many practical purposes, a decision that didn’t happen. The work that depended on the decision moved on. The window of opportunity closed. The competitive moment passed. The team learned to route around the chain entirely.
The latency chain drives me crazy!
Failure mode 3: The accountability dilution chain.
Five reviewers means no single reviewer feels responsible for the decision. The first reviewer assumes the second one is the real check. The second one assumes the same about the third. Everyone assumes someone else is doing the actual work. When something does go wrong, the post-mortem finds five people who all approved it and none of whom can explain why.
This is the failure mode that makes leadership most uncomfortable to confront, because the entire architecture was designed to create shared accountability. What it actually creates is shared deniability.
If your approval chains exhibit any of these three failure modes, the chain isn’t protecting the organization. It’s consuming time and creating false confidence. The needle isn’t being moved. It’s being slowed.
The Latency Math
Here’s a calculation worth doing on every approval chain in your organization.
Take a sample of recent decisions that flowed through the chain. For each one, ask:
How many reviewers did the request pass through?
How many days elapsed from submission to final approval?
What percentage of the requests were approved? (If the answer is above 95%, you’re looking at a rubber-stamp chain.)
For the rejected requests, did the rejection come from a substantive review, or from a process technicality (wrong form, missing field, expired prerequisite)?
For the approved requests, what evidence do you have that the approval was based on actual review rather than a click?
The data will surprise you. For many organizations the typical approval chain has a 95%+ approval rate, takes 5 to 15 business days, and rejects requests primarily for procedural rather than substantive reasons. It wasn’t rejected because it didn’t move the needle. It was rejected because it was charged to the wrong account number.
That’s not governance. That’s queue management with extra steps. The chain is filtering for “did the requester complete the form correctly,” not “is this decision a good one, ie… does it move the needle.”
If 95% of the requests are approved, the chain is providing a 5% filter at the cost of 100% of the decisions being delayed. That trade is almost never worth it. Most of those delays are slowing decisions that would have been approved anyway. The organization is paying enormous latency cost to catch a tiny fraction of bad decisions, while the rubber-stamp culture means many of the bad decisions are slipping through anyway.
Cancelling the entire chain and accepting the 5% miss rate would, in most cases, produce better outcomes than the current system. Faster decisions, equivalent risk, less false confidence.
The Move Needle Test for Approvals
Apply this test to every approval chain you can identify in your organization.
If this approval step were removed, what risk would actually materialize that isn’t being caught today?
Be specific. Name the failure mode. Name the actual consequence. Name the frequency.
For most approval steps, the honest answer is “none in living memory.” The step exists because someone added it after a 2018 incident that nobody currently in the chain remembers. The risk it was designed to catch hasn’t happened in seven years, and it’s not clear the step would have caught it anyway. The step is just there.
That step isn’t preventing risk. It’s creating it. The risk is the latency on every decision that has flowed through it for seven years, every workaround that team members have developed to avoid it, every opportunity that closed while the request was sitting in a queue.
The needle test for approvals is the same as for everything else in this series. Is this activity moving the needle, or is it consuming attention without producing leverage? If a reviewer can’t articulate, in concrete terms, what they would catch that isn’t being caught elsewhere, that reviewer isn’t adding value. They’re adding latency.
What to Replace Approvals With
Three replacement patterns work, and each one targets a different category of decision.
For low-risk, high-frequency decisions: automate, don’t approve.
Most approval chains exist for decisions that are nearly always yes. Travel under $1,000. Software subscriptions under $200. Standard vendor renewals. These should be auto-approved within defined limits, with audit logging to catch anomalies. AI is excellent at this through pre-screening requests, flagging the genuinely unusual ones, and sending the rest through automatically. The human reviewer only sees the exceptions.
The cultural objection is “but what if something gets through?” The answer is that something is already getting through, because rubber-stamp reviewers aren’t catching anything. Automation with audit logging is more effective than rubber-stamping, not less, because the audit trail is honest about what was approved and why.
For genuinely judgment-heavy decisions: shorter chain, real review.
Some decisions actually require human judgment. Hiring a senior leader. Committing to a multi-year contract. Approving a strategic shift. These deserve careful review. They don’t deserve five reviewers. They deserve one or two reviewers who are genuinely responsible for thinking about the decision, not five who each rubber-stamp because they assume someone else is doing the real work.
A one or two person review with substantive engagement beats a five-person rubber-stamp every time. Cut the chain length. Tell the remaining reviewers they own the decision. Not just that they’re clicking the button.
For unusual or high-stakes decisions: the convened review. When something genuinely warrants multiple perspectives, don’t route it through a sequential chain. Convene the people, get them in a room (real or virtual), discuss, and decide. The decision document pattern from Part 2 works here. Write up the proposal, send it ahead, hold a 30-minute focused discussion, and decide.
This pattern produces better decisions in less time than any sequential approval chain. It also creates real accountability, because everyone in the room can see what everyone else thought. The decision is owned, not delegated.
A Story Worth Sitting With
Years ago, when I joined a regional leadership team, a colleague who had been there for years was helping me find my footing. I mentioned a decision I was making, and that I was going to copy our boss on the email when I sent it.
He stopped me. “Don’t copy Phil on that. His email box is loaded as it is. You have been empowered to make the decision. You made the decision. Just mention it to Phil the next time you guys are talking. Don’t load his email with something that isn’t necessary.”
That advice has stuck with me ever since.
I bring it up here because the same logic applies to approval chains. Every unnecessary approval is a CC. Each one is a small reversal of authority. It’s a decision being routed back upward when it was already supposed to belong somewhere else. Each one consumes the attention of someone whose attention is too expensive for what they’re being asked to look at.
My colleague wasn’t just teaching me email etiquette. He was teaching me that real authority requires the courage to act on it. Adding the CC was hedging, while the cure wasn’t the CC. The cure was the courage to make the decision I had been empowered to make and tell Phil about it later.
I’ll come back to this in Part 8 of this series. For now, just notice that the approval chain you’re looking at is, in many cases, the same instinct as that unnecessary CC. The decision was supposed to belong to someone. The system has quietly insisted that it doesn’t.
Why This Is Politically Hardest
Of all the eliminations in this series, approval chains are the politically hardest to cut. The reason is that approval chains are tied to power. Every approval step is a small piece of authority that someone holds. Asking them to give it up reads as asking them to give up status.
The leaders who hold approval authority will resist the elimination. They’ll argue, often sincerely, that the approval is providing real oversight. They’ll tell stories about the time they caught something. They’ll frame the elimination as reckless.
The truth is usually more uncomfortable. The approval isn’t providing the oversight they think it is. The “time they caught something” is one anecdote against thousands of rubber-stamps. The elimination isn’t reckless. I argue the current system is reckless, because it’s producing latency without actually catching risk.
That argument is hard to make in a room full of people whose authority depends on the approval staying in place. So the chain persists. Layer accumulates on layer. Bloated organizations are the worst at this because the can be. Bloat begets bloat.
The only way to actually cut approval chains at scale is for the leader at the top of the chain to make the decision deliberately. Nobody below them has the political standing to do it. The lead can simplify the approval architecture within their domain.
If you’re reading this and you’re at the top of a chain you control, you have an opportunity most leaders don’t. Use it.
(My next post will give you a much stronger way to win this political fight, by reframing the cut as a clarification rather than a removal. For today, just see the architecture for what it is.
)
The Most Common Specific Eliminations
A few specific approval chains are worth calling out because they appear in nearly every organization and are nearly always candidates for elimination.
Travel approvals under a meaningful threshold.
If a $100 trip requires three approvals, the approvals are costing more than the trip. Set a threshold (whatever makes sense for your org) below which travel is auto-approved with logging.
Software subscriptions under a meaningful threshold.
Same logic. The team member who needs a $50/month tool shouldn’t need three managers to sign off, especially if has been included in the budget. They should be able to expense it within policy and have it logged for audit.
Standard vendor renewals.
If you renewed last year and nothing material has changed, you don’t need a five-person review of the renewal. Auto-renew within policy, flag the genuine renegotiations.
Document approvals on standard templates.
If the document is a fill-in-the-blank version of an approved template, the template was already approved. The new instance doesn’t need to be re-approved by everyone who approved the template.
Each of these is a small elimination. Together they remove enormous amounts of latency from the organization. The savings aren’t just the reviewer time, they’re the requester time, the work that was waiting on the approval, and the opportunities that didn’t have to close while the request was in a queue.
Notice the pattern in all examples. Each of them is a decision that should already belong to the team. The approval chain exists because the team was never clearly told it was theirs. We don’t need fewer approvals. We need clearer ownership. That’s the deeper argument, and it gets its own piece next week.
One Take-away
Pick one approval chain you sit on. Just one. Pull the data on the last 20 requests that flowed through it.
How many were approved? How many were rejected? Of the rejections, how many were substantive versus procedural? How long did the average request take?
If the approval rate is above 95% and the average latency is more than three days, that chain should be on the chopping block.
Don’t propose the streamlining yet. Just gather the data. Bring it with you next week, when we go after the deeper question. Why this chain exists and what would have to be true for it to be unnecessary in the first place.
Tell me what your data showed. The number will be worse than you expect.
Justify everything you keep.
Eliminate everything else.
Thanks for reading AI, Innovation, and Faith! This is Part 6 of The Elimination Project. Part 1 (the manifesto), Part 2 (meetings), Part 3 (subscription decay), Part 4 (email), and Part 5 (status reports) build the foundation. Part 7 takes on the deeper structural critique: we don’t need fewer approvals — we need clearer ownership.
