Your company has operations. The work that gets done, the people doing it, and the tools they use. Think of this as your operating system — the foundational layer your company runs on top of. It sprang into being the moment the company had more than one person, the inevitable consequence of people coordinating themselves.
In the earliest phase of the company, the team itself is the operating system. Three people in a room don't need a decision architecture; they need to be in the room — proximity is the architecture. Everyone knows what everyone else is working on because they can see it a few feet away. Decisions aren't really made so much as arrived at — someone says something, no one disagrees, and that becomes the plan. Customer problems, product problems, money problems all get solved in the same conversation, often in the same hour.
This works well enough, for long enough, that no one notices the operating system already taking shape.
As the team grows, the arithmetic turns against the original arrangement. Six people working together have fifteen possible pairs of coordination. Twenty-five people have three hundred. Each new hire doesn't add one connection — it adds one connection per existing employee, and the number of relationships the system has to manage compounds with every addition.
The team responds by inventing standing meetings, designating points of contact, writing things down that didn't need to be written down before. These are the first deliberate operational moves the company ever makes — workable solutions to the problem of getting work done across more people than a single conversation can hold. The fact that business is getting done at all is proof of a working operating system in place. No one decided to build it. No one noticed it forming. By the time it exists, the company is already running on top of it.
What started as the team itself has become something separate from the team. The operating system now has mechanics of its own — patterns of who decides what, who talks to whom, what gets escalated, what gets dropped. It carries the DNA of the people who built it: their working styles, their tolerances, the conversations they happened to have, the conflicts they happened to avoid. It persists when people leave. New hires inherit it before they understand it.
The company is no longer just doing operations. It has an operating system.
That system can be examined and modeled.
Here's the move that most companies never make: the operating system isn't just something the company runs on. It's a distinct system that the company can look at. Its parts can be identified. The connections between them can be traced. The patterns that produce its outputs can be made visible.
In other words, it can be reverse-engineered.
The first operating systems a company has form organically, out of necessity. To the extent that the business is doing what it set out to do, the operating system is doing what it evolved to do. As long as the conditions that produced it still hold, the system works. The problem isn't that the original system was wrong — it was correct for the company that built it.
The problem is that conditions change. Companies grow, acquire, restructure, prepare for exit, transition leadership, move into new markets. When the conditions that produced the operating system are no longer the conditions the operating system has to operate inside, the system drifts out of fit with reality. It also drifts out of fit just by getting bigger. Even before a transition arrives, the OS is usually carrying more load than it was shaped for.
When a transition does arrive, the mismatch becomes visible. Decisions that used to take an afternoon start taking a week, then stall, then resurface as conflicts no one can quite trace. New hires arrive expecting a system to onboard into and find instead a set of habits no one can explain. The CEO becomes the bottleneck for decisions that should never have reached them. Sales-to-implementation handoffs that used to be a single conversation now require three meetings and an apology. Sometimes the mismatch shows up more quietly — as a sense among the leadership team that the next phase is going to require something the current system isn't going to produce.
The team didn't get worse. The context changed, and the system didn't change with it. The same people who built the company are now navigating a transition the original system wasn't shaped for. The OS that worked at one scale is being asked to do work it wasn't designed to do, and it's struggling — not because anyone is failing, but because the system has reached the edge of its fit.
The system is about interfaces,
When companies do try to change the operating system, they almost always target the components directly. A new org chart. A new tool. A new reporting line. A new VP. The intervention is named, announced, installed — and six months later the system is producing the same outputs it was producing before, with different labels attached.
The reason is that the components aren't the system. The system lives in the interactions between them — the moment a decision changes how work gets routed, the moment a tool shapes what information gets seen, the moment a communication pattern determines which decisions ever get made at all. Each component meets the others at specific points: the interfaces where information passes from one part of the system to another, where a decision becomes work, where work becomes a hand-off, where a hand-off becomes a result.
Change the component without redesigning its interfaces, and the system absorbs the change and continues producing the same outputs. A new VP of Sales who plugs into the same information flows the previous one had makes the same kinds of decisions on the same kinds of inputs. A new project management tool that maps onto the same hand-off patterns the team already had produces the same hand-offs with a different UI. A component changed. The OS didn't.
What this means in practice is that changing the operating system requires identifying which interfaces a given change actually touches — and redesigning those interfaces deliberately, rather than leaving them to self-correct. The people sitting at those interfaces are not incidental to this work. They are its primary data source. They know, better than anyone, what actually passes between components — what information arrives late, what decisions stall, where work disappears into a hand-off and comes back wrong. That intelligence doesn't live in the org chart. It lives in the people doing the work.
This also bounds the scope of any operational change. The future state the company is moving into doesn't change everything about how the company runs — it changes specific things. A delivery model shift reorganizes warehousing and shipping. It doesn't reorganize marketing. A leadership transition reshapes decision authority and information flow. It doesn't necessarily reshape the work itself. The discipline is in identifying the actual surface area of the change — which interfaces have to be redesigned to produce the future state, and which don't — and scoping the work to match. Everything else stays as it is.
Backward analysis vs. forward design
The instinct, when something stops working, is to look at what's broken and try to fix it. That instinct is the foundation of an entire industry. Traditional organizational consulting is built around backward-facing analysis: examine the current state, diagnose what's wrong, produce findings, deliver recommendations. The consultant's authority lives in the diagnosis. The deliverable is, in essence, a verdict on the past with implications attached for the future.
Forward design inverts this. The work begins not from what's broken but from where the company is going. The engagement is commissioned against a future state — the company on the other side of a scaling phase, an integration, a leadership transition, a capital event, an exit. The deliverable is an architecture of the operating system that fits that future state, and an implementation path the company's existing team can execute on its own.
The question forward design starts from is not what's wrong here? but what does this company need to become? That single shift reorganizes everything downstream — what gets investigated, what gets built, what the deliverable looks like, how the team relates to the work. It also changes what the team is being asked to do. A backward audit asks the team to admit. A forward design asks the team to imagine. Those are different invitations, and they get different responses.
Operational design is the practice of doing this work at the level of the operating system itself. It's design work in the architectural sense — a blueprint for how the company should run, drawn with enough specificity that the company can be built toward it. The questions it asks are concrete: What decisions will need to be made, by whom, with what inputs, on what timeline? What information will need to flow, to whom, in what form, on what cadence? What work will need to move through the company, with what hand-offs, with what governance over the exceptions?
Naming the future state first is what makes the rest possible. The current state then gets examined not to be judged, but to be understood as a starting point.
Two examples
Consider a founder-led company that has just closed a Series B. Twenty people on the team, growing to fifty over the next year. The founder has been the decision center since day one — every commercial decision, every product call, every hire ran through them, and that worked because they could absorb the context in real time. With the new capital comes two senior hires, a VP of Sales and a Head of Product, both more experienced operators than anyone currently on the team. The expectation is that they'll take significant decisions off the founder's plate.
Three months in, decisions are queuing worse than before. The new hires want to make calls in their domains, but they don't yet have the context the founder has been carrying for years — the customer commitments, the partnership constraints, the half-finished commercial conversations. So they bring decisions to the founder for context, the founder gives the context, and then the founder makes the call anyway, because at that point they're already in the conversation. The senior hires are starting to wonder why they were brought in. The founder is more bottlenecked than ever.
A backward analysis would look at this and conclude the founder needs to delegate more. A forward design starts somewhere else: what does this company need to be in twelve months, and what would the decision architecture have to look like to produce it? The work isn't about delegation. It's about specifying which decisions belong at which level, what context each level needs in order to make those decisions well, and what information flows have to exist for that context to reach the right people without the founder relaying it. The interface between the founder and the senior team is the part of the system that has to be redesigned — not the people on either side of it. Once the decision architecture is right, the senior hires become useful, the founder's time gets unlocked, and the company can actually grow into the size the new capital is meant to support.
Consider a different case. A services company has acquired a smaller competitor, and the integration is six months in. The two companies' tools have been merged, the org chart has been redrawn, the comp bands have been harmonized. On paper, the integration is complete. In practice, work is getting stuck in the seams between the two former organizations.
The reason isn't tools or org structure. It's that the two companies ran on incompatible information cadences. The acquirer ran on weekly all-hands and a strong oral culture — important things got said in the room, and absent people were caught up by their managers. The acquired company ran on dense written async updates — nothing was said that wasn't also written, and people consumed information on their own schedule. Both systems had worked, in their own contexts, for years. The merged company is now running both, and information that originates in either culture only reliably reaches half of the combined organization. People are working from different facts and don't know it.
The forward design here doesn't pick a winner between the two cultures. It asks what the integrated company needs to be — what it's selling, to whom, with what kind of delivery model — and what the information architecture has to look like to support that. The result is a single information system, designed against the integrated company's actual coordination needs, that may borrow from both prior cultures but doesn't preserve either intact. The interfaces between teams that used to belong to different companies are the part of the operating system being redesigned. Once that architecture is in place, the work that was getting stuck in the seams starts moving again.
Both of these cases involve a small, focused intervention. Neither of them is about fixing what's broken. Both of them are about designing what the company has to become next, and then redesigning the relevant layer of the operating system to produce it.
Why the components have to be designed together
It might be tempting to read these examples as cases of process improvement, or org design, or change management. They aren't. Each of those disciplines works on one component of the operating system at a time, and the components don't function independently.
A new decision-rights structure that doesn't have an information flow underneath it produces faster decisions made on worse information. A new org chart that doesn't change the work routing produces the same hand-offs with different titles attached. A change management program that doesn't address the underlying coordination architecture produces a workforce that has been carefully prepared to keep running the same broken system.
The OS is a system. It has to be designed as one. Decisions, information, and work flow are not three separate problems — they're three views of the same problem, joined at the interfaces, and the design has to hold them together.
What the founder eventually realizes
The thing the founder eventually realizes — sometimes after a hire that doesn't land, sometimes after an integration that won't integrate, sometimes after a quarter where everyone worked harder for less output — is that the company is being shaped by its operating system more than the operating system is being shaped by the company. The system the team inherited from the early days is now running them rather than the other way around.
To scale, in any meaningful sense, is to stop being shaped by the system you inherited and start shaping the system you'll need. The company that does this stops being at the mercy of its own emergence. It becomes, deliberately, what it intends to be.
Where to start
Operational design begins with a question the company can ask of itself, in the right room, at the right time.
The question is: what does this company need to become, and what would the operating system have to be in order to produce that?
Ask it together. Have the people who run the affected interfaces draft against it — not what's broken, but what the next version looks like, and what would have to be true operationally for the company to run as that next version. The act of designing forward, collectively, is itself the beginning of the design. The plan that emerges will be theirs, which means it will be implementable in a way no plan handed down from above ever is.
This is also why most operational change fails at the same point. Leadership decides what the new state should be, an outside party produces the plan, the plan gets installed, the workforce is brought along. The people expected to execute the new arrangement don't recognize their own work in it, and they resist or quietly route around it. Operational design avoids this failure by producing the design with the people whose work it will govern. The design process itself, done properly, is what aligns the people to the new context. By the time the implementation begins, the alignment has already happened.
The catch is that operating systems are mostly made of communication between people, and so a design for one can't be drawn from the outside. It has to be assembled out of the actual coordination patterns the company runs on — what people actually do, who they actually talk to, where information actually gets stuck, which decisions actually take longer than they should and why. That intelligence lives in the people doing the work, distributed across the organization in pieces no single person holds. Gathering it, synthesizing it, and composing it into a coherent forward design is the work. The schematic is the easy part. Running the conversations that produce the schematic is what takes practice.
The shift starts the moment the question changes. The company stops being at the mercy of its own emergence the moment its people start designing what comes next, instead of arguing about what's wrong with what came before.