It took me a month to build an FAQ solution for the support pages. ASP, MS Access as the database, nothing fancy. Just a searchable collection of frequently asked questions and step-by-step instructions for managing telecom equipment. Yes, including the classic "have you tried turning it off and on again." Working prototype, tested, ready to go.
Guess how long it took to get permission to put it live. Four months.
Not four months of technical work. Four months of convincing. Meetings with stakeholders who hadn't seen a support page in years but suddenly had opinions. Reviews from teams that would be "affected" by customers finding answers on their own. Alignment sessions with people whose primary concern was making sure their department's name appeared in the right place.
The feature that was built in weeks sat in a slide deck for months. Not because it wasn't ready. Because the organization wasn't ready to let someone just ship something.
The math doesn't work
Here's what happens when companies grow. In a team of 8, you have an idea Monday morning and you're testing it by Wednesday. Maybe you check with one or two people. Maybe you just do it and show the results.
In a team of 80, that same idea needs a proposal document. The proposal needs review. The review surfaces "dependencies" with three other teams. Those teams need to be consulted. Consultation leads to a joint planning session. The planning session reveals conflicting priorities. Conflicting priorities require escalation. Escalation requires executive alignment. Executive alignment happens in a monthly forum. By the time you get a green light, the market has moved, the original context is stale, and someone suggests starting a new discovery phase.
Sound familiar? The actual development work, the building part, is maybe 20% of the total time from idea to launch. The rest? Getting buy-in. Documenting decisions. Explaining why this won't break something else. Reassuring people who feel their turf is being stepped on.
This is what I call the permission tax. And it compounds with every person you add.
People are the problem (but not the way you think)
This isn't about having bad employees or incompetent managers. It's closer to physics.
Every person you add to an organization creates new communication lines. Add one person to a team of 5, and you've added 5 new relationships to manage. Add a whole new team of 8, and you've just created dozens of new interfaces that didn't exist before. Each interface needs alignment, documentation, approval workflows, and regular sync meetings.
But here's the part nobody likes talking about: a lot of organizational friction isn't structural. It's emotional.
When a small team starts doing something new, touching a domain that was "owned" by another team, what's the first reaction? It's rarely "great, that'll move faster now." It's usually "wait, that's our area." People feel their ownership being diluted. Their influence shrinking. Their relevance questioned.
This is change management at its core, and it's messy. People don't resist new processes because they love the old ones. They resist because change feels like a threat to their role, their status, their sense of being needed.
So what you end up with is an organization where every decision triggers a negotiation. Not about what's best for the product or the customer, but about who gets to decide, who needs to be consulted, and who feels respected enough in the process.
I've sent emails to 5 key people and watched the thread balloon to 30+ within a day. Everyone knew someone else who should weigh in, someone else who "does this," someone else who might be affected. By the end, nobody knew who was responsible for what or who owned the decision. But everyone had an opinion.
The people who learned to say no, make swift decisions, and ship fast - the heroes of the early days - become the "difficult" ones. They still expect speed, but now every turn has a roadblock. The same instincts that built the company now make them look like they're not playing nice.
The hiring trap
A product team wants to expand into a new area. New segment, new feature domain, new part of the business. The first thing they reach for: more people.
So they write a hiring plan. Get budget approved. Start recruiting. Three months later, new people show up. The existing team spends weeks onboarding them, getting them up to speed on context, systems, history, relationships. The new hires need access, documentation, introductions.
Meanwhile, the thing they were hired to build? Still in the proposal stage. Because now it's not just the original team making a decision. There's a new team with a new mandate, and suddenly there are "alignment meetings" and "RACI matrices" and "ways of working workshops" to figure out who does what.
The irony is painful. You hired people to move faster. Their existence made you slower.
The answer almost nobody considers first: descope. Refocus. I've written before about why half your roadmap probably doesn't matter. Do less with the people you have, but do it with the speed and autonomy that made them effective in the first place. Adding people to a slow organization doesn't make it faster. It just adds more weight to the same broken wheels.
The process symptom
You can diagnose the permission tax by looking at what your teams actually spend time on. If an increasing share of effort goes toward:
- Documenting how teams should work together
- Creating and reviewing "ways of working" agreements
- Running workshops to align on process before any work starts
- Building elaborate approval chains for things that used to be informal
- Standing up governance forums and steering committees
...then you're not solving a problem. You're institutionalizing the friction.
Process is supposed to remove ambiguity so teams can move faster. When process becomes the work itself, when teams spend more time negotiating how to work than actually working, something has gone wrong.
When your teams spend more time writing documents about how they should work together than building things for customers, the permission tax has overtaken the product.
At some point, process stops being about making work easier and starts being about avoiding the work altogether. A well-placed "we need to align first" buys another two weeks of not having to commit to anything.
Why this matters right now
AI is rewriting what small teams can accomplish. A team of 3 with good AI tools can now build what used to require 15 people. Not in theory. Right now, today.
But who's actually moving fast with AI? Not the large enterprises with dedicated AI strategy teams, innovation labs, and cross-functional working groups. It's the small companies. Startups. Teams small enough that someone can just try something without filing a request.
Large companies are stuck in exactly the cycle I described above. Someone proposes using AI for a specific workflow. That triggers a security review. A legal assessment. A vendor evaluation. An ethical review board. A pilot program proposal. A steering committee decision. By the time all of that clears, the small company down the street has already shipped, iterated, and shipped again.
The small company's advantage isn't better technology or smarter people. It's the absence of the permission tax. No layers of procedures slowing them down. No ego battles over who owns the AI strategy. No political fights with stakeholders who think it's their right to approve every experiment.
This is why small companies will close the gap on large ones faster than most executives expect. The bottleneck was never the technology. It was always the organization.
Fighting back
I'm not going to pretend there's a simple fix. You can't eliminate organizational gravity by reading a blog post. But there are things that actually help.
Measure time-to-ship, not time-to-build. Most teams track development velocity. Nobody tracks how long it takes from "this is a good idea" to "customers are using it." Start measuring that, and the permission tax becomes visible. My FAQ example? The build was 20% of the total timeline. That ratio should alarm anyone paying attention.
When a team wants to expand, challenge the assumption that more people is the answer. What could you stop doing instead? What could you simplify? A focused team of 6 doing 3 things well will always outperform a team of 15 doing 8 things poorly. Descope before you hire.
Protect team autonomy like it's the most valuable thing you have. Because it is. Every approval chain you add, every "just loop in" you request, every governance layer you introduce costs something. Sometimes that cost is justified. Often it's not. Default to trust and course-correct when needed, not the other way around.
The companies that will win aren't the ones with the most people or the biggest budgets. They're the ones where a good idea can go from someone's head to a customer's hands without passing through a gauntlet of meetings, reviews, and political negotiations first.
The permission tax is real. And it compounds. The sooner you start reducing it, the more you'll actually ship.