The parts of your operating system you should build first

There is a specific moment in a company’s life when someone, a board member, an advisor, or the CEO themselves, says the words: we need to build out our operating system. It is good advice. The company has outgrown the version of itself that ran on the founder’s memory and a shared sense of urgency, and it genuinely needs structure. The trouble is that the advice almost never arrives with the only part that determines whether it works, which is the order. Build out the operating system, certainly. Starting with what?

Left to instinct, the answer is always the same. You start with whatever hurts most visibly, and you build from the top down: hire to relieve the overloaded team, add meetings to fix the misalignment, stand up dashboards to watch the numbers that keep slipping. Each move targets the layer you can see and feel. Each move is reasonable taken on its own. And the sequence as a whole is close to the exact inverse of the one that actually works.

Because an operating system is not a single thing you build. It is a stack of levels, and a stack has a load-bearing order. Build the levels in the wrong sequence and every layer you add has to be torn out and rebuilt the moment you finally get to the one underneath it that it was silently depending on. The order is not a detail of the project. The order is the project.

An operating system has a load-bearing order

A quick grounding, since everything after this depends on it. Picture the operating system as four levels, from the surface down to the foundation. Activity is the visible work: headcount, meetings, tickets, output. Cadence is the rhythm that organizes it: the planning cycle and the review loop. Architecture is the wiring underneath: where decisions actually get made, who owns which number, how authority truly flows. And capability, the deepest level, is whether the people and the system can run all of it without the founder standing in the middle. A companion note in this series is about diagnosing which of those levels is your binding constraint. This one is about the question that comes immediately after: once you know the stack exists, in what order do you build it?

The reason order carries so much weight is that the levels are not independent. Each one rests on the one beneath it. Cadence is only ever as good as the ownership it inspects. Activity is only ever as productive as the architecture it plugs into. Build a layer before the layer it depends on exists, and you have not built infrastructure, you have built scaffolding you will later have to dismantle. The levels also grow less visible as you descend and more determinative as you descend, which is the entire trap: the layer that matters most is the one you are least inclined to build first.

Why the intuitive order is backwards

The instinct is to build top-down, and the instinct is wrong for reasons worth understanding, because a reason you understand is far easier to resist than one you do not. Three forces push every founder toward starting at the top.

The first is visibility. The top of the stack is the only part you can see directly. Activity is concrete and countable. The foundation is invisible: there is no dashboard for decision rights, no chart that tells you whether the system can run without you. So you build where you can see, and where you can see is the top.

The second is pain. Drag presents itself as a surface symptom: the team is underwater, the meeting ran ninety minutes and decided nothing, the number got missed again. The symptom lives at the top even when the cause lives at the bottom, and pain is a persuasive argument for treating the place that hurts rather than the place that is actually broken.

The third is speed. Building at the top feels fast and reads as progress. You can hire someone this week and point to it in the next board update. Building the foundation looks, from the outside, like deceleration, because you are defining ownership and rebuilding accountability instead of putting fresh points on the board. Velocity gets rewarded, and the top of the stack is where velocity is easiest to manufacture.

You read the system from the top. You build it from the bottom. Confusing the two is the original mistake.

Here is the resolution to all three forces at once. The order in which you read the system and the order in which you build it are inverses. You read top-down, because symptoms surface at the top and that is where any honest diagnosis has to begin. You build bottom-up, because load belongs on a foundation and the foundation has to exist before you can set anything on it. Every founder who builds in the order the pain presents has quietly assumed that the reading order and the building order are the same. They are opposites, and that single confusion is the root of most operating-system rebuilds.

The order that actually holds

So here is the sequence, foundation first. It is not a rigid march in which each level fully completes before the next one begins; in practice the lower levels overlap as you build. But the priority order is firm, and it runs in this direction.

First, architecture. Define the wiring before anything else, because architecture is the most common binding constraint in a scaling company and every level above it assumes it is already in place. This is the unglamorous work of deciding where each decision actually gets made, who owns each critical number, and how authority moves when the founder is not in the room. The single most important move here is almost always the same one: get the founder out of the center of the decision graph, so the company stops routing every meaningful choice back through one person. Architecture is a blueprint, and a blueprint is where construction starts.

Second, capability. A blueprint nobody can operate is just a drawing, so the moment the architecture takes shape you build the muscle to run it without you: genuine ownership in the people who now hold those decisions, an operating function, often a chief of staff or a head of operations, to run the machine day to day, and enough documentation that the system lives outside of three people’s heads. Capability is the deepest level of the stack for a reason. It is the level that decides whether everything above it survives, and it is the one that converts an architecture from a diagram into infrastructure. You pour it as part of the same foundation, directly behind the wiring.

Third, cadence. Only once ownership is real does rhythm become worth installing. Now you add the planning cycle and the review loop, the weekly and quarterly heartbeat that keeps the architecture honest and makes progress visible. The order matters here more than anywhere else in the build. Cadence laid on top of real ownership is a decision engine: the reviews produce decisions because someone is genuinely accountable for each one. Cadence laid on top of nothing is theater: the same meetings, the same slides, the same unresolved arguments, now on a reliable schedule.

Fourth, activity. And now, last, you add the load. Hire into the roles the architecture defines. Scale the pipeline through handoffs that finally have owners. Add the tooling and the output. This is the part the company wanted to start with, and it is genuinely the right thing to do, in its proper place, which is on top of a foundation that can carry it. Activity added here compounds, because every new person and process plugs into wiring that works. Activity added first compounds as well, in the wrong direction.

Cadence on top of real ownership is a decision engine. Cadence on top of nothing is theater.

How to tell a phase is finished

The hardest part of building in order is not knowing the order. It is knowing when a phase is solid enough to build on, because the temptation is always to declare it done early and move up before the layer can actually bear weight. A few tests, one per phase, that are more reliable than the feeling of being finished:

• Architecture is solid when you can name, for every decision and every number that matters, the single person who owns it, and when the honest answer is no longer “it comes back to me.” If decisions still route through the founder, the architecture is not built, whatever the org chart claims.
• Capability is solid when the system keeps running through the founder’s two-week absence and nothing critical waits for their return. If the company holds its breath until you are back, you have a diagram, not capability.
• Cadence is solid when a new quarter’s priorities get set, sequenced, and tracked without re-litigation, and when the review loop reliably yields decisions rather than discussion. If goals are set with conviction and quietly abandoned by mid-quarter, the cadence is decorative.
• Activity is solid when a new hire becomes effective in weeks rather than quarters, because they joined a structure that explains itself. If onboarding a senior person still takes two quarters of mapping the system by trial and error, you added activity to an architecture that was not ready for it.

These are not abstractions. They are the line between a phase that can carry the next one and a phase that will buckle under it. When in doubt, assume the lower layer is less finished than it feels, and spend another week there. It is far cheaper than the rebuild that follows skipping ahead.

The two ways the order goes wrong

Build order fails in two opposite directions, and both are worth naming, because the fix for one is the cause of the other.

The first failure is skipping ahead: loading activity onto a foundation that does not yet exist. This is the common one, the top-down instinct in full force, and its signature is a company that hires and reorganizes its way through every problem and never gets relief, because it keeps adding weight to the layer that was already its constraint. The cost is not only the wasted spend. It is that every layer built too early has to be unbuilt and redone once you finally repair the one beneath it, now at higher headcount and higher stakes than if you had simply built in order the first time.

The second failure is the mirror image: never leaving the foundation. Some leaders, having absorbed that the foundation matters, then over-build it without end. The architecture gets endlessly refined, the documentation becomes a project unto itself, the system stays perpetually almost ready, and the company never adds the activity that growth actually requires. This is perfectionism wearing the costume of rigor, and it stalls a company just as effectively as the first failure, only more quietly. The foundation exists in order to be built on. A foundation you never load is not caution. It is a more respectable way of avoiding the work.

The discipline is to build each layer until it can bear weight, and then to move up. Not before, which is the first failure. Not never, which is the second.

Build it to be handed off

There is a test that sits above all of the phase tests, and it is the one that decides whether the entire build was worth doing. The point of building your operating system in this order is not to construct an elaborate machine that only its builder understands. It is to produce a system the company can run on its own.

Build the foundation to be handed off, or you have not built a foundation. You have become one.

This is why capability sits at the bottom of the stack rather than as an afterthought at the top. A system that works only while its architect is in the room is not infrastructure. It is a dependency wearing infrastructure’s clothes, and it makes no difference whether that architect is the founder, an indispensable operator, or an outside consultant who has quietly made themselves permanent. The good version builds toward its own handoff from the very first phase. The architecture is documented so others can hold it. The capability is built into the team rather than concentrated in a single hire. The cadence runs itself. The test of the whole effort is not whether it works this quarter. It is whether it still works after the person who built it steps away. The handoff is not the end of the build. The handoff is the specification.

Where to start

If the company has told you to build out its operating system, resist the urge to start building anything at all. Start by reading. Spend a week tracing your most painful symptom down through the stack, past the activity layer where it shows up, to the level where it actually originates. In the large majority of scaling companies, that trace ends at architecture, at a decision with no clear owner or a number nobody truly holds. That is your starting point, not because it is where the pain is loudest, but because it is the deepest unbuilt layer beneath the pain, and the foundation is always where building starts.

Then build upward from there, in order, each layer until it can bear weight: the wiring, the muscle to run it, the rhythm to keep it honest, and only then the load. That is the entire method. It is not more sophisticated than that, and the companies that scale cleanly are not the ones with the most elaborate operating systems. They are the ones that built the parts in the right order, foundation first, so that nothing they set on top ever had to come back down.

You are not, in the end, deciding whether to build an operating system. Every growing company builds one, deliberately or by accident. You are deciding the order you build it in, and that one decision is the difference between a system that holds and a rebuild you will be having this same conversation about eighteen months from now.

• • •

Levels Consulting helps growth-stage leaders see how their company actually operates, find the level where the real constraint lives, and build the operating system to fix it, then hand it off. Field Notes are short, practical pieces on organizational intelligence for the people running the machine.