Your Internal Operating System Was Built for a World That No Longer Exists

We have seen the numbers. AI-native companies running at $3 million revenue per employee. Your best year was $400,000. The competitive pressure is no longer theoretical; it is daily, and it is getting harder to explain away.

Meanwhile, inside the company, decisions take longer than they should. Strategy gets announced, then progress against it feels impossible to track. The same conversations happen in every meeting. The same problems resurface every quarter.

The instinct, when this happens, is to reach for a people diagnosis. We need better leaders. We need clearer communication. We need a stronger culture. Sometimes those things are true. But underneath almost every case I have worked on, the deeper problem is structural. And structure is what determines whether your people can actually perform at the level you hired them for.

Your operating system was built for a world that no longer exists.

This piece is an attempt to name what is actually going on when a company feels like it is running in place. Not to offer a playbook, I am genuinely suspicious of playbooks applied to systems as context-dependent as organizations, but to make the problem legible enough that the right conversation can start.

What do I mean by internal operating system?

Not your software stack or your project management tool. The collection of structures, processes, and norms that determine how decisions get made, how work gets prioritized, how people are measured and developed, and how the organization responds to new information.

Every company has one, whether it has been designed or not. In most companies, it was not designed. It accumulated. A planning cadence inherited from an early investor's reporting requirements. A performance review process brought in by the first "professional" HR hire. An org chart drawn to solve a specific conflict and then never redrawn. Annual planning started three months before the year even begins, then treated as authoritative long after the circumstances that produced it have changed.

Organizations adopt formal structures, annual reviews, quarterly OKRs, org charts, committee processes, not primarily because those structures drive performance, but because they confer legitimacy. They signal to investors, boards, new hires, and the market that this is a professional organization. The formal structure and the operational reality then drift apart, because the formal structure was never really about operations. It was about appearance.

Your company has an org chart, but real decisions happen through informal networks. You have annual OKRs, but teams follow quarterly emergencies. You have a performance review system, but managers give real feedback in 1:1s. This is not hypocrisy. It is what happens when a company builds legitimacy infrastructure on top of operational reality and then mistakes one for the other.

The invisible cost is not the wasted time, though that is real. Gallup's 2026 research puts the cost of disengagement at approximately $10 trillion in lost productivity annually, around 9% of global GDP. That number is not produced by bad strategy or weak product. It is produced by the distance between what organizations formally require of their people and what their people are actually able to do inside the systems they are given. The deeper cost is the confusion between what is formally true and what is operationally true, and the energy burned navigating it every single day. That is where performance is lost, not because people are incapable, but because the system makes their capability unusable.

When I walk into an organization, this gap is usually visible within the first week. The question I am trying to answer is not whether it exists; it almost always does. The question is how wide it has gotten, and whether the people running the company are aware of it.

Why the gap exists

There are contexts where cause and effect are predictable in advance and contexts where they are not.

Spoiler: your company is one of those environments where cause and effect are not known in advance.

Outcomes emerge through experimentation rather than expert prescription. The environment shifts faster than any plan can track. In that context, the planning tools designed for a stable world become a liability. By the time you have codified a best practice, the environment has already moved.

The markets we operate in are genuinely complex, the pace of change is only getting faster, and the competitive environment is unpredictable. And yet the operating systems most of us run on were designed for a predictable world, one where you could plan a year in advance, set goals in the prior year, evaluate people every six to twelve months, and trust that the operating model you built last year would still be the right one this year.

Annual planning is a tool built to be used in a predictable environment. The plan becomes authoritative at precisely the moment it is most likely to be wrong.

This is not a criticism of the people who designed these systems. It is an observation about the world those systems were designed for. The question worth sitting with is whether the world your operating system was built for is still the world your company is operating in.

Why it persists: the forces keeping legacy systems alive

If the problem were just a design mismatch, it would be relatively simple to fix. The reason it is not simple is that legacy operating systems are held in place by overlapping forces, structural, institutional, and psychological, that are each independently difficult to move.

Start with the structural. Annual reviews, quarterly planning, fixed org charts, level-based compensation became institutional standards through a process of mimicry, not evidence. When enough companies adopt a practice, it becomes what "professional management" looks like, and the pressure to conform is real. New executives arriving at scaling companies have internalized these practices as the baseline. They are not experienced as choices. They are experienced as the definition of a well-run company.

Add investor and board governance. VCs and boards do not typically mandate specific HR processes but their governance structures make calendar-based operating rhythms almost structurally inevitable. Quarterly board meetings require quarterly reporting. Quarterly reporting requires quarterly budgeting. Quarterly budgeting locks in a planning cadence that then becomes the clock everything else runs on. By the time a company reaches 80 to 150 people, it typically has three to five years of quarterly planning data, investor relationships built on quarterly momentum narratives, and a finance function trained around quarterly close cycles.

The switching cost is not the new system. It is everything that grew around the old one.

Then add the psychology. In my experience, this is the layer most often underestimated.

When a CEO announces a new operating system, even a better one, it triggers the same threat response the brain reserves for physical danger. Before anyone has had time to evaluate the change rationally, people are already reacting: Am I still valued? I don't know how I will be evaluated. I have less control over my day. This was decided without me. It does not feel fair.

The threat response is so strong and immediate that it overwhelms the reward signal before anyone has had a chance to experience whether the new system is actually better. Most organizations interpret the discomfort of the transition as evidence that the new system is wrong. They revert.

The research on habit formation makes this concrete. A new behavior takes an average of 66 days to begin feeling automatic. During that entire window, the new process will feel slower, more effortful, and less reliable than the old one, not because it is worse, but because the old one was running on automatic and the new one requires conscious attention every time. For a company under board pressure to show quarterly results, that three-month window is often all the time the experiment gets before the verdict comes in. You revert, the old patterns re-emerge, and you lose more time than you would have if you had held the line.

And then there is the layer I find most important and hardest to talk about: the contradiction between what leaders say they believe and what their behavior reveals they actually believe. Science shows that most people are completely unaware this gap exists. They genuinely believe they are doing what they say they believe in.

In organizations, this plays out in ways that are immediately recognizable. A CEO says they want more distributed decision-making, then gets involved in decisions their team should be making. They say they want faster iteration, then slow down every significant choice with approval cycles. They say performance is about impact, then promote based on tenure and visibility. The operating system does not change because the behavior of the leader has not changed, and the behavior of the leader will not change until they can see where their behavior diverges from what they say they believe.

This is why the conversation about operating system change ultimately has to start with the CEO. Not with the org chart, not with the planning process, not with the compensation structure. With the question of whether the person at the top is genuinely willing to examine their own role in maintaining the system that is not working.

Five of the most broken systems in scaling companies right now

These are not the only things that need rethinking. They are the ones I see most consistently, and the ones where the evidence is clearest that the design is wrong for the environment companies are now operating in.

1. Calendar-based goal setting

Goals are set on a fixed calendar date and treated as authoritative regardless of what happens next. A customer crisis lands in month two; the team does the right thing and responds, but none of that work maps to the goals on the slide. By quarter end, everyone is behind on objectives that stopped reflecting the business weeks ago. An opportunity identified in week ten rarely gets started. There is not enough time before the reset, so it waits, and sometimes it never comes back. Nobody changes their goals mid-quarter because it looks like moving the goalposts, so everyone keeps writing updates against targets that stopped being relevant. The goal-setting process becomes a compliance exercise. The plan that was supposed to be the floor has become the ceiling.

2. The org chart as the operating system

When something feels slow or misaligned, the reflexive response is to redraw the reporting lines. Reorganize. Restructure. Put different boxes in different places. The problem is that the org chart reflects how the company reports, not how value is actually created. We apply machine logic to living systems, and then wonder why they behave like living systems rather than machines. The actual work, the decisions, the relationships, the informal coordination that gets things done, happens in the network underneath the chart. Changing the chart without changing the network is expensive and mostly cosmetic.

3. Performance as an event

The annual or semi-annual performance review was designed for a world where contribution was stable enough to assess in retrospect, twice a year. More than 90% of HR managers believe reviews do not yield accurate information. 58% of executives acknowledge their performance management drives neither engagement nor high performance. These are not fringe findings. They are the mainstream view within the profession that administers these systems.

There is no federal or state law in the United States requiring annual performance reviews for private sector employees. Most organizations treat them as legally mandated when they are not. They persist because they confer legitimacy, not because they drive performance.

4. Fixed roles and tenure-based progression

The job description as a fixed document. Levels tied to time served. Compensation structures that move in linear steps. In a world where AI is reshaping what every role does faster than any job description can track, and where a person who joined six months ago may be driving more value than someone who has been there three years, the entire architecture is wrong. It optimizes for continuity in a world that rewards adaptation.

5. The calendar as an operating discipline

The meeting that exists because it is on the calendar. The review that happens because the quarter ended. The check-in that runs whether or not there is anything new to discuss. Calendar-based operating rhythm was designed for predictable work, work where the passage of time was a reasonable proxy for the accumulation of decisions and outcomes that needed review. When the work is unpredictable, when signal comes in unevenly, when some weeks produce more decisions than others, running on the calendar means reviewing things when they are scheduled rather than when the information is ready. The organization becomes responsive to time rather than to what the work is actually telling it.

What AI is actually changing, and why it is not the same for every company

The generic version of this argument is that AI is changing everything and companies need to adapt. That framing is not wrong, but it misses something important. AI has not created the problem of broken operating systems but it has accelerated the urgency of fixing them. Systems that have been wrong for decades are now facing their greatest test. And the actual experience of that test is radically different depending on what kind of company you are.

The numbers that are putting pressure on every scaling company right now come from a set of AI-native businesses that have grown revenue faster than headcount. Midjourney at roughly 150 people generating $500 million in annual revenue. Cursor at over $2 billion ARR with a team that numbers in the dozens. These figures are real, and the competitive pressure they create is real. But the revenue-per-employee numbers are a product and market moment, not an organizational design proof point. These companies have so much demand, so early, that headcount has not caught up with revenue yet. Perplexity, often cited as a lean AI-native benchmark, has grown its headcount to over 1,200 people in the past year. The organizational challenge is coming. It is just deferred, because the revenue cushion is large enough that the friction has not become visible yet.

The technology alone is not the differentiator. The structure is, and that pressure lands differently depending on what kind of company you are.

For AI-native companies, the organizational reckoning is a future problem. For scaling companies with legacy infrastructure, it is a present one. They are being asked to match the output of companies that never had to build the overhead they are now trying to dismantle, while also running the business, managing the board, and keeping the team intact. The result is that most of the pressure falls on the operating system at precisely the moment it is least equipped to handle it.

The data on what is actually happening inside organizations that have implemented AI makes this concrete. 65% of employees say AI has improved their personal productivity. Only 12% strongly agree it has transformed how their organization works. A 2025 MIT study found that despite roughly $40 billion in enterprise AI investment, 95% of organizations have seen zero measurable impact on profits. And yet headcount is falling.

The most visible organizational response to AI so far is not restructuring. It is reduction. The uncomfortable read is this: if AI is not yet showing up in profits, the case for workforce reduction may be less about genuine efficiency gain and more about needing to show investors something. Cost reduction is immediate and visible on a quarterly basis. Operating system redesign is not.

Some reduction is real. There are functions, customer support being a strong example, where AI is genuinely handling work that previously required headcount. But cutting broadly before understanding what the new ways of working actually require is a different problem. Companies that reduce roles before they understand what they need will find themselves rehiring into gaps they created. The cycle of reducing, figuring it out, and hiring again carries its own costs in institutional knowledge, in trust, and in time.

The companies under the most pressure are the ones caught in the middle: not AI-native, not large enough to absorb the cost of a long transition, facing competitors in both directions with a structure built for neither. This is where the urgency is highest and the decision window is shortest. These companies need an operating system redesign more urgently than either of the other two groups. McKinsey found that of five to seven hours per week saved by AI per employee, only 1.7 hours were redirected to work that improved business outcomes. 70% of AI implementation challenges stem from people and process issues. 20% from technology. 10% from the algorithms. Most companies spend their resources in inverse proportion to where the actual difficulty sits.

What it actually takes to change

What I have observed, and I am careful to say observed, not proved, because the evidence base for what definitively works is still accumulating, is that the companies that genuinely transform their operating systems share a few things that are not structural. They are about the conditions that make structural change possible.

The first is a CEO who is genuinely willing to examine their own behavior, not just their company's. Founders/CEOs are often the last to see the operating system as the problem, because the operating system is an expression of their own judgment and their own way of working. Changing it requires not just solving the problem but examining the assumptions that produced it in the first place. That is hard work, and it is personal in a way that most organizational consulting is not designed to reach.

The second is realistic expectations about the transition. It takes an average of 66 days for a new behavior to begin feeling automatic at an individual level. At an organizational level, the timeline is longer, and the discomfort is greater, because the change is simultaneously happening across many people navigating the same threat response at the same time. The companies that make it through this window are the ones where the CEO understood in advance that the transition period would feel like things were getting worse before they got better, and had enough board alignment and personal conviction to hold the line. External pressure, specifically quarterly return expectations, cuts these experiments short before they have had time to produce a fair result. Most organizations give operating model changes six months max.

The third is the cascade. Operating system change cannot be delegated to a people function and then expected to hold. The CEO changes their own behavior first. Leadership observes and adjusts. Teams have enough safety and enough evidence to follow. Skip any layer and the change stalls at that layer. I have seen this happen from the leadership level: a CEO buys in genuinely, but the leadership team does not understand the change well enough to hold it under pressure, and it unravels because the layer below the CEO does not have a clear answer when employees push back. Leaders don't just set direction. They define the conditions under which people either can or cannot do their best work.

None of this is a playbook, it is a set of conditions. The specific form that a redesigned operating system takes in any given company depends on what that company is, what its strategy requires, and what its people are capable of now and can develop into. The work of designing the right system for a specific company is genuinely custom.

Most Founders/CEOs I have spoken with can feel that their operating system is not fit for purpose. What they do not know is what a fit-for-purpose operating system looks like for their specific company, or how to sequence the shift: where to take the revenue hit, how to test before scaling, and how to hold stakeholder confidence through a transition that will affect the numbers before it improves them.

A note on self-selection

Not every CEO is ready for this conversation in the same way, and I think that is worth being explicit about.

Some are already doing the work and need a thinking partner, not a diagnosis. Some know something needs to change and are looking for a framework to name it and start the work. And some are focused on a symptom: the attrition problem, shipping velocity, the communication breakdown. But they are open to the idea that the system is producing it. All three are good candidates for this work.

There is one prerequisite. The change required starts with the CEO's own willingness to examine their role in the current system. Those who find it hard to take that step will find that any structural change layers on top of the problem rather than relieving it. The old system wins. It always does.

What I find compelling about this moment is that the external pressure from AI may finally be forcing the internal work that should have happened sooner. Not just because the competitive case is now undeniable, but because people deserve systems in which they can actually do their best work. The data is clear: employees who feel they can do their best work have a measurable positive impact on profit. Pair that with AI used well, and the advantage is real. The question is whether the urgency of the moment is enough to make the harder work feel worth doing.