The permission tax: when growing teams ship less, not more

It took me one month to build an FAQ solution for the support pages.

Getting permission to put it live took another three to four months.

The technical work was the short part. The decision took months.

The organization had enough capacity to build the feature. It did not have a short path to approve it.

The math doesn't work

The coordination cost becomes clearer as the company grows. 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 run a small test and show the results.

In a team of 80, the same idea may need a proposal, reviews from three other teams, a planning session, and an executive decision. Each step can be reasonable on its own, but together they can make the original context stale before approval arrives.

In my FAQ case, one month of building was followed by three to four months of approval.

This is what I call the permission tax. It grows when more people and teams need to approve the same decision.

More people create more coordination

The problem is usually not the people. It is the number of dependencies around every decision.

Adding people increases the number of possible communication paths. A team of 5 has 10 possible pairwise links. Add a sixth person, and there are 5 more. Those links do not all need active management, but each real dependency between teams needs an owner and a way to resolve decisions.

Some friction is structural, but some comes from people protecting their ownership and influence.

When a small team starts working in an area owned by another team, the discussion often moves from the customer problem to ownership. People want to understand who will decide and what remains under their control.

This changes who gets to decide, so deal with that concern directly.

The decision then becomes a negotiation about ownership and consultation. The customer outcome can easily become secondary.

People who were trusted to decide quickly in a small company can struggle when the same decisions later require several approvals. The behaviour stayed the same, but the organization around it changed.

The hiring trap

When a product team expands into a new area, its first proposal is often to hire more people.

The sequence can look like this: write a hiring plan, get the budget approved, recruit, then spend the first weeks giving new people access, context, and introductions.

The new team can arrive before the work has moved past the proposal. Now you also need to agree who owns what.

By then, onboarding and new dependencies can delay the work the hiring plan was meant to speed up.

I would first reduce the scope and refocus the existing team. 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 does not fix a slow decision process. It gives the same process more dependencies to manage.

The process symptom

You can diagnose the permission tax by looking at what your teams actually spend time on. Warning signs include:

• 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

If this takes more time than customer work, the process is preserving the problem.

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.

If teams spend more time documenting how to work than building for customers, I would reduce the process before adding another rule.

Process becomes a problem when it delays the decision it was meant to support. Another alignment meeting can add delay without changing the outcome.

Why this matters right now

My bet is that AI will make the permission tax easier to see. When execution gets faster, each approval step takes a larger share of the timeline.

A large company may need security, legal, vendor, and governance reviews before testing an AI workflow. Those controls can be necessary. The problem is treating every experiment as if it carries the same risk.

I expect some smaller companies to test AI workflows sooner because fewer teams need to approve each experiment. In those cases, the advantage is a shorter decision path, not better technology or smarter people.

Fighting back

Start by measuring where the time goes.

Measure time-to-ship, not time-to-build. I would measure the full time from an agreed idea to customer use, not only development velocity. In my FAQ case, one month of building was followed by three to four months of approval.

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 doing fewer things well can outperform a larger team spread across too many priorities. Descope before you hire.

Protect team autonomy. Some approvals are necessary, but each one should have a clear risk it controls because approval steps add time and dependencies. I would default to team autonomy when nobody can name that risk.

My bet is on companies that let a team test a good idea without months of approval. Budget and headcount matter less when the decision process blocks the work.