The Menu of Services: An API for Your Operations

Welcome back to Built to Scale. Last episode was about telling growth apart from scale. This episode is about the tool that makes scale possible to design on purpose, instead of stumbling into it: the Menu of Services.

Start with a picture most operators will recognize. A team with no formally documented services. No clear owner for any given piece of work. A new team member joins and has no way to find out who does what, so they ask around, get three different answers, and eventually just guess. Execution time creeps up. The same problem gets solved five different ways by five different people. Work gets duplicated in some places and dropped entirely in others. Growth stalls, not because demand stopped, but because nobody can tell what's actually being delivered anymore. Senior people burn out holding the whole picture in their heads, and when they leave, the picture leaves with them.

This is the state most operations are in before they build a Menu of Services, and here is the useful reframe: a Menu of Services is to your operations what an API is to your software. An API works because it defines a standard interface — this is what exists, this is how you call it, this is what you'll get back, and this is who's responsible on the other end if it breaks. Nobody has to reverse-engineer another team's internals to work with them. The Menu of Services does exactly that job for a team of humans instead of a team of services.

It has six building blocks. Service Level — the core information about each service: what it is, who owns it, what "done" looks like. Tracking — embedding that service into the systems you already use, so its status is visible without a status meeting. Insights — reporting on how the service is evolving, not just whether it ran. Governance and Maintenance — someone is accountable for keeping the definition current as the work changes. Enablement and Communication — new team members, and customers, can actually find and understand what's on offer. And the Framework itself — the rules for what qualifies to go on the Menu in the first place, so it doesn't become a junk drawer.

One thing worth being precise about: the Menu of Services is not a static document you write once and file away. It's a living interface. As a service moves through its lifecycle — and we'll cover that five-phase lifecycle in the next episode — its entry on the Menu changes with it. A service that's just a one-off custom fix for a single customer doesn't belong on the Menu at all yet. A service that's been standardized and automated looks completely different on the Menu than it did when it was a pilot.

Here's the part that matters most if you're trying to get real ROI out of AI in your operations, and not just a pilot that quietly dies in six months: AI-in-ops initiatives mostly fail without this substrate already in place. You cannot automate a process that has never been defined. You cannot measure whether an AI agent is actually helping if there was no baseline for what "correct" looked like before it showed up. Companies that skip straight to buying an AI tool and pointing it at undefined chaos get, predictably, automated chaos — just faster and harder to debug.

So if there's one action item from this episode, it's this: pick one service your team delivers repeatedly right now, without a written definition. Write down what it is, who owns it, and what "done" looks like, in plain language, today. That's the first Menu of Services entry. Everything else in this framework builds on having that artifact exist at all.

Next episode: the ratio collapse — the number behind why solo operators can now run what used to take an entire department. That's Built to Scale. The book is The Scale Imperative, out now from Routledge. See you next time.