Your company has operations — the work that gets done, the people doing it, the tools they use. Think of this as your operating system: the foundational layer your company runs on top of. It came into being the moment the company had more than one person, the inevitable consequence of people coordinating themselves.
In the earliest phase, 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.
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. And that system can be examined.
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. 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.
The team didn't get worse. The context changed, and the system didn't change with it.
The system lives in the 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.
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.
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. 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.
What the company has to become
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 grow into the size the new capital is meant to support.
This is a small, focused intervention. It isn't about fixing what's broken. It's about designing what the company has to become next, and then redesigning the relevant layer of the operating system to produce it.
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 question the company can ask of itself, in the right room, at the right time, is this: what does this company need to become, and what would the operating system have to be in order to produce that?