Process theatre: Why your team is slow because it's big

The three-hour sprint planning that decided nothing

You're two hours into sprint planning. 20 people are on the call. The product backlog doesn't match the roadmap. The roadmap doesn't match what the CEO said last week. Someone is asking clarifying questions that should have been answered a month ago.

The Jira ticket assignee can't answer basic questions about the ticket they own. "I'll go back to the business," they say. That conversation will take three weeks.

By hour three, you've "planned" a sprint that everyone knows will change by Wednesday. Half the room has been on mute, catching up on Slack. The other half is wondering why they're here.

You have more people on the project, yet velocity has never been lower.

This isn't a planning problem. It's not a tooling problem. It's not even a people problem.

It's Process Theatre: the performance of rigour in the absence of output.

The uncomfortable arithmetic

When delivery slows down, the instinct is to add resources: more engineers, a dedicated BA, a release manager, a scrum master, maybe two.

The logic feels sound: more people, more capacity, more delivery.

The reality is the opposite. Every person you add creates:‍

• ‍More communication pathways. A 3-person team has 3 connections. A 10-person team has 45. A 30-person team has 435. Every connection is a potential delay, misunderstanding, or meeting.‍
• More coordination overhead. Someone has to align all these people. That becomes a job. Then it becomes several jobs.‍
• More process to manage the process. Stand-ups get longer. Sprint planning gets longer. Retros multiply. The work about work eclipses the work.

You didn't scale your output. You scaled your inefficiency.

The roles that shouldn't exist

Here's an uncomfortable question: how many people on your team actually build things?

Not manage things. Not coordinate things. Not "align stakeholders" or "groom the backlog" or "facilitate ceremonies."

Build things. In bloated teams, you'll find roles that exist purely to manage the complexity that the team's size created.

• ‍The Ticket Pusher (a.k.a. The Postman). Their job is to move cards across a board and chase updates. They can't answer questions about the work because they don't do the work. They're a human API between people who should be talking directly.‍
• The Permanent Intermediary. "I'll take that back to the business." Three weeks later, you get a partial answer that raises more questions. The intermediary can't ask the follow-ups, because they don't know enough about the work. So you wait another three weeks for the next partial answer. A bottleneck disguised as a bridge.‍
• The Release Manager. In a healthy team, releasing is a function, not a job, facilitated by modern release tooling. If you need a dedicated human to coordinate releases, your releases are too complicated, or your team is too fragmented to release without adult supervision.‍
• The Full-Time Scrum Master. Ceremonies shouldn't require a specialist to facilitate. If your team can't run their own stand-up, the stand-up isn't the problem.

These roles aren't filled by bad people. They're filled by capable people doing jobs that shouldn't need to exist.

Process isn't protecting quality. It's distributing responsibility until no one owns anything.

What lean actually looks like

At Harrier, we run engagements with pods of two people typically. It's a key ingredient our customers call out, driving speed & quality over name-brand consultants.

Not because we're cheap. Because two is where leverage lives. A lean team instead has:

• No intermediaries. It works directly with your product stakeholders. No telephone game. No "go back to the business." When a question arises, it gets answered, usually in the same conversation.‍
• No siloed thinking. A Product Architect who actually writes code and shapes architecture, not someone reviewing other people's work from the sideline. They understand business context and derive requirements instead of handing them off.‍
• No "not my job". When you have three people, everything is your job. Scope doesn't fall through cracks. Ownership isn't diffused across a matrix.‍
• No execution-only mindset. If engineers only build what the business asks for, the product can only be as good as the business can imagine. A good team proposes things the business wouldn't know to ask for.

This isn't about doing more with less. Small teams force the hard conversations earlier. There's nowhere to hide the problem, so the problem gets solved. Decisions stick because the people making them own the outcome, not because a ceremony ratified them.

The process theatre checklist

Before you add another body or another ceremony, ask:

1. ‍Is this role building, or managing people who build? If it's the latter, why can't the builders manage themselves?‍
2. Does this process produce decisions or defer them? A three-hour planning session that ends with "we need more clarity" isn't planning. It's theatrics.‍
3. Would this role exist if the team were five people? If not, you've created a role to absorb complexity you manufactured. Ask whether the hierarchy exists for its own sake.‍
4. How many handoffs does a decision require? Each handoff is latency. Each handoff is fidelity loss. The best teams have the fewest handoffs.‍
5. Can the people doing the work answer questions about the work? If not, you've separated knowledge from execution. That's how "I'll go back to the business" becomes your operating model.

Scale or theatre

There are two ways delivery gets bigger. You scale output, or you scale theatre.

Scaling output means smaller teams with sharper ownership. Decisions stick because the people making them own the outcome. No ticket pushers, no permanent intermediaries, no three-week loops waiting for a partial answer. Velocity compounds because complexity doesn't.

Scaling theatre works the other way. Every new person manages the complexity the last new person created. Every new ceremony performs the rigour that real work used to produce. You end up with a 20-person sprint planning session that ends where it started, and a Jira board that everyone knows will be wrong by Wednesday.

Adding people feels like progress: visible, countable, something you can point to. But if those people spend their days in ceremonies, pushing tickets, and waiting for answers that never come, you haven't invested in delivery. You've invested in theatre.

The next time delivery stalls and the instinct is to add headcount, ask a different question:

‍

If your team were half the size tomorrow, what would you actually lose?