# The permission tax: when growing teams ship less, not more **Author:** Ivan Misic **Published:** 2026-02-24 **URL:** https://ivanmisic.net/blog/ways-of-working/permission-tax-growing-teams **In plain English** In my FAQ project, the build took one month and approval took another three to four. That is one case, not a universal ratio. Measure the full time from an agreed idea to customer use, remove approvals that cannot name the risk they control, and reduce scope before assuming another hire will make delivery faster. I expect some smaller companies to test AI workflows sooner because they have fewer dependencies, but that is a bet to measure, not proof that small teams always win. 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.
Timeline of the FAQ case showing one month of building followed by four months of approvals, with a short team-of-8 decision path and a much longer team-of-80 path
My FAQ case, shown at the upper end of the range: one month to build and about four months to approve. The team paths show the 8-person and 80-person comparison above, not an industry benchmark.
## 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](/blog/product/laundry-list-trap-prioritization). 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.