Project Management for Scale-Ups (10-100 People)

The characteristic mistake is adding process faster than the problems arrive. The second characteristic mistake is adding it later than the problems arrive. Both are common, and the signals that distinguish them are observable.

Quick answer: Three things break as a company grows from ten to a hundred: the founder stops being able to act as the coordination layer, teams form and dependencies appear between them, and nobody can hold the whole picture in their head any more. The work of scaling project management is managing those three transitions in the right order, without importing an operating model designed for a company ten times larger.

What Breaks Between 10 and 100

Coordination stops being free, dependencies emerge between newly formed teams, and no single person retains visibility of everything.

The founder stops being the coordination layer

At ten people, a founder holds the full picture and coordination happens through them. It works, and it is invisible until it stops.

Somewhere between fifteen and thirty, the founder becomes a bottleneck: decisions wait for them, context lives in their head, and their absence stops things. This is usually the first genuine scaling problem, and it requires distributing decision rights rather than working harder.

Teams form and dependencies appear

At ten people there is one team. At forty there are four, and work regularly crosses between them.

Cross-team dependency is a fundamentally different problem from within-team coordination. It cannot be solved by talking more, because the people involved no longer sit in the same conversations.

Nobody can hold the whole picture

The point at which no individual can describe everything in flight arrives earlier than most expect — commonly around twenty-five to thirty-five people.

Beyond it, visibility has to come from a system rather than from a person. This is when the quality of your project tooling starts genuinely mattering rather than being a preference.

The Three Transitions

Transition Typical trigger What you add Risk of doing it early

Transition One: From One Team to Several

Team boundaries, dependency visibility Silos and handoffs before they were needed

Transition Two: From Informal to Explicit

Written decisions, defined decision rights Bureaucracy without benefit

Transition Three: From Doing to Measuring

Flow metrics, honest

Make capacity honest

Measuring an unstable process

Transition One: From One Team to Several Draw team boundaries around outcomes rather than functions, make dependencies between teams visible, and keep a single roadmap.

Draw team boundaries around outcomes

The most consequential decision in scaling. Teams organised by function — a frontend team, a backend team, a QA team — mean every piece of work crosses several boundaries.

Teams organised around outcomes or customer journeys can deliver something end to end.

This eliminates dependencies rather than managing them, and it is far cheaper than any coordination mechanism you would otherwise need.

Getting this wrong is the root cause of most scaling pain, and it is very expensive to correct later.

Make cross-team dependencies visible

Where dependencies genuinely exist, they need to be explicit: what one team needs from another, by when, and who owns it.

Invisible dependencies surface as surprises — a team discovers in week three that something they assumed was coming is not. A shared view where dependencies between projects are recorded as links rather than as verbal understandings prevents most of that.

Keep one roadmap, not several

Each team maintaining its own roadmap produces four documents that disagree and no organisational picture.

One roadmap with team views derived from it. The moment separate roadmaps exist, reconciling them becomes someone's recurring job and the reconciliation is always slightly out of date.

Transition Two: From Informal to Explicit Write down what was previously shared understanding, define who decides what, and introduce process one piece at a time.

Write down what was previously understood

At ten people, everyone knows how things work because they were there. At forty, half the company joined after the decisions were made.

The things that need writing first: how work enters the system, what your definition of done is, how priorities get decided, and what the current strategy actually is. Not a handbook — four short documents that answer questions new joiners keep asking.

Define who decides what

Ambiguous decision rights are the main cause of slow decisions at this size. Something needs deciding, three people could plausibly decide it, and it waits.

Write down which decisions sit with team leads, which with function heads, and which genuinely need the founder. Most organisations discover the founder is in far more decisions than necessary.

Introduce process one piece at a time

Add a practice, run it for a month, and check whether the problem improved.

Adopting a framework wholesale means you cannot tell which part helped, and the aggregate overhead arrives before any benefit. Sequential introduction is slower to describe and considerably faster in effect.

Transition Three: From Doing to Measuring Start measuring flow rather than activity, make capacity figures honest, and check whether changes actually worked.

Start measuring flow, not activity

Cycle time, throughput, work in progress and committed-versus-completed. These describe delivery, require no estimation, and resist gaming.

Hours, task counts and utilisation measure activity and produce the wrong behaviour when used as targets. At this size, where you can no longer observe the work directly, choosing the right measures matters more than it did.

Tools that report these natively — cycle time and throughput on a dashboard rather than assembled manually — are what make the practice sustainable, since a metric requiring a weekly spreadsheet exercise stops being produced within two months.

Make capacity honest Plan against measured capacity rather than headcount. Most teams deliver 60 to 75 percent of nominal availability once meetings, support and interruptions are counted.

Scale-ups routinely commit against headcount, then treat the resulting shortfall as a delivery problem when it is arithmetic.

Review whether changes worked

You will change process repeatedly at this stage. Most organisations never check whether a change helped.

Before making a change, name the measure that should move. Check it a month later. This single habit is what separates organisations that improve from those that simply keep reorganising.

Common Scale-Up Mistakes

The three errors are adding process ahead of need, copying a large company's operating model, and letting teams diverge on tooling.

Adding process faster than it is needed

A new head of engineering arrives from a 2,000-person company and introduces the operating model they knew.

At sixty people that model is mostly overhead. Introduce practices in response to problems you can name, not in anticipation of scale you have not reached.

Copying a big-company operating model

Large-company process exists to coordinate hundreds of people who cannot talk to each other.

At eighty people, most of them still can.

Take the specific practices that solve problems you have. Adopting the whole model imports coordination cost designed for a scale you are not at.

Letting teams diverge on tooling

Each team picking its own tool is locally reasonable and collectively expensive: no organisational view, no comparable metrics, and painful handoffs.

Standardise on the platform and let teams vary their process within it. That preserves autonomy where it matters — how a team works — while keeping the visibility that scaling requires.