Building a Strategic Scale Team

Welcome back to Built to Scale, the last episode in this run. We've covered the core ideas — growth versus scale, the Menu of Services, the ratio collapse, and the five-phase ladder from Incubate to Embed. Today's question is the organizational one: who actually owns moving a service up that ladder?

In most companies, the honest answer is nobody. Individual teams own their own slice of execution — support owns support, sales ops owns sales ops — but the job of deliberately advancing a service from a one-off custom fix toward a standardized, automated, self-service capability usually belongs to no one in particular. It happens by accident, when someone senior gets frustrated enough to fix it personally, or it doesn't happen at all, and the same ad hoc process just runs forever, absorbing more headcount every year demand grows.

This is the gap a dedicated Scale function closes. Not a team that does the execution work itself — support still handles tickets, sales still runs sales — but a team whose actual job is maintaining the Menu of Services, tracking where each entry sits on the five-phase ladder, and deliberately sponsoring the work of moving things up it. Think of it as the team that owns the system, while other teams own the output the system produces.

Where does this function come from, historically? The book's own account is instructive: the Menu of Services approach originated inside a real scaling effort, in a pre-MoS state that will sound familiar from episode two — blurred roles, duplicated work, growth stalling despite more hiring, senior people burning out. The turning point wasn't a new hire or a new tool. It was modularizing the execution, drawing clear roles across the whole delivery chain, and building the structured catalog — the Menu of Services itself. Once that existed, headcount growth started translating into actual market expansion again, instead of just absorbing more of the same chaos at a larger scale.

What does a Scale role actually look like day to day, if you're the kind of person who might want to build a career in this rather than just sponsor it from the top? It's part analyst — you need to be fluent in the KPIs at each phase, and honest about which services are stalled and why. It's part diplomat — moving a service up the ladder usually means asking multiple teams to change how they work, and that requires real influence, not just a mandate. And increasingly, it's part automation builder or at least automation-literate — because Amplify and Embed both depend on knowing what's realistically automatable versus what only looks that way in a vendor deck.

If you're a leader deciding whether this function is worth building as its own dedicated team, here's the test the book points toward, in the diagnostic sense: look at your own Menu of Services, if you've started one, and count how many entries have moved phases in the last twelve months. If the honest number is zero or close to it, that's not because nothing was worth advancing — it's because no one owned advancing it. That's the gap. A dedicated Scale team is the fix for that specific gap, not a generic reorganization for its own sake.

That's the last episode in this run of Built to Scale. Five ideas: growth is not scale, the Menu of Services is an API for your operations, the ratio collapse rewards the operations that were already well-defined, every service sits somewhere on a five-phase ladder, and someone needs to actually own moving things up it. The Scale Imperative, by Ioana Codoban, Andreas Huebner, and Rahul Jindal, is out now from Routledge. Thanks for listening.