Playbooks

06 Scaling Operations

Operational Bottlenecks
in Growing Teams

Growth reveals hidden weaknesses.

Kristina Golovko · MindDesign7 min read

The bottleneck system

Dependency

Work requires input from a scarce resource

Friction

Work stacks up waiting

Bottleneck

Velocity controlled by the constraint

Delay

Output limited regardless of team size

A bottleneck doesn't disappear when you hire more people. It becomes more expensive — because more people are waiting on the same constraint.

Why this matters

Scaling exposes bottlenecks that didn't exist — or didn't matter — at smaller scale.

Every organisation has constraints. At small scale, constraints are manageable: the founder reviews all contracts, the lead engineer approves all architectural decisions, the head of product signs off on every feature. These constraints create quality control. They are also, at small scale, fast enough not to matter.

As the organisation grows, the same constraints become bottlenecks. The founder reviewing all contracts now has 20 more things to review than they did at Series A. The lead engineer approving architectural decisions is now in the critical path for six parallel workstreams. The throughput of the constraint hasn't changed — but the demand has grown significantly.

Identifying bottlenecks is a precondition for removing them. Most organisations don't map their bottlenecks explicitly — they experience them as general slowness, without understanding that the slowness is concentrated at specific structural points.

Founder reality

Map the bottlenecks in your current organisation before the next growth phase:

01

Which person or process, if unavailable for a week, would cause the most work to stall across the organisation?

02

Are there decisions or approvals that reliably take longer than they should — and do they involve the same people?

03

Which team or function consistently has work waiting on input from another team or function?

04

Are there skills or capabilities that exist in only one or two people — making those people structural dependencies?

05

When projects run late, is the cause usually a specific type of constraint — rather than random delays?

Bottlenecks often feel like slowness in the team. They are actually slowness at specific structural points — which is a different and solvable problem.

The system

Four types of operational bottleneck and how to address them

Identify the type before designing the fix. Different bottlenecks require different solutions.

01

Person bottlenecks — critical work flowing through one individual

The most common bottleneck: a senior person whose approval, input, or review is required for too many things. Fix: audit what requires this person's involvement, distinguish what genuinely needs them from what could be delegated with the right documentation and authority, and systematically distribute the second category.

02

Process bottlenecks — workflow steps that take longer than they should

Legal review, security review, QA, compliance checks — processes that were designed for smaller volume and slower pace. Fix: redesign the process for current volume (batch reviews, automated checks, tiered approval thresholds) without reducing the quality of what the process was designed to protect.

03

Skill bottlenecks — capabilities that exist in insufficient supply

When a specific skill is scarce — a particular technical expertise, a language capability, a regulatory knowledge — work that requires it waits. Fix: hire for the skill, train adjacent team members, or redesign the work to reduce dependency on the scarce skill.

04

Decision bottlenecks — authority that is too centralised for current scale

Decisions that require executive approval for operational questions that should be decided at team level. Fix: define a decision authority framework — which decisions require which level of authority — and actively push authority to the level closest to the work.

Common mistakes

01

Hiring around a bottleneck instead of removing it

Adding people to a team that's waiting on a bottleneck adds cost and headcount while the throughput constraint remains. Fix the bottleneck first, then assess whether more people are needed.

02

Treating bottleneck symptoms without mapping the bottleneck

Pressure to move faster, additional standups to track progress, and escalation frameworks don't remove bottlenecks — they manage the experience of being bottlenecked. Map the constraint, then remove it.

03

Removing bottlenecks without communicating the change

When a bottleneck is removed — authority redistributed, a process streamlined — the people previously involved in the bottleneck need to know their role has changed. Unannounced changes produce confusion and often create parallel informal bottlenecks.

04

Optimising the wrong constraint

In a system with multiple bottlenecks, optimising a non-critical constraint produces no increase in overall throughput. Identify the primary constraint first — the one that most limits total output — and address it before addressing secondary constraints.

Example scenario

A cybersecurity SaaS company, 65 people. Sales growing 40% year-over-year. Customer onboarding consistently 3 weeks behind forecast. Engineering capacity sufficient. Sales team healthy. The bottleneck was invisible.

The bottleneck mapping

01

Onboarding flow mapped end-to-end. Total process: 14 steps across 6 teams.

02

Delay pattern identified: 80% of delays occurred at step 7 — security configuration review, conducted exclusively by one senior security engineer.

03

Security engineer's capacity: 4 reviews per week. Current demand: 11 reviews per week.

04

Queue: new customers waiting an average of 14 days for a step that took 2 hours.

The fix

01

Security engineer documented the review process and trained two adjacent engineers to handle standard configurations (80% of cases).

02

Review tier introduced: standard configurations reviewed by trained team, non-standard escalated to senior engineer.

03

Throughput: increased from 4 to 11 reviews per week within 3 weeks.

The outcome

Onboarding time reduced from average 5.2 weeks to 2.1 weeks. No new hires required. Security engineer's involvement in standard reviews: reduced from 80% to 20% of time — freeing capacity for higher-value security work.

Takeaway

Bottlenecks are specific. Solutions need to be too.

Map the constraint, identify its type, design the appropriate fix. More people rarely solve bottlenecks — better structure does.