A company is software running in production

Most people think of companies as machines. Inputs go in. Outputs come out. Add more resources, get more results.

But the closer analogy is software running in production.

Not software that was just shipped — software that has to stay running, reliable, and evolving while the environment around it constantly changes.

Markets shift. Teams grow. New initiatives launch. Assumptions break. New tools and technologies reshape how work gets done.

The real job of leadership isn’t just building the product. It’s operating the system.

One way to think about this is as an organizational stack — similar to the layers of a software system. Strategy sets direction, decisions translate intent into action, humans and AI execute the work, and outcomes emerge from the system.

Strategy is the architecture

In software, architecture determines what the system can do and how easily it can evolve.

It defines things like:

• What services exist
• How they communicate
• What dependencies are allowed
• Where constraints live

Strategy plays the same role inside organizations.

Strategy answers questions like:

• What markets we serve
• What problems matter most
• What tradeoffs we accept
• Where teams have autonomy versus constraint

When architecture is unclear in software, engineers create workarounds. Over time the system becomes tangled and fragile.

When strategy is unclear in a company, teams create local optimizations that slowly fragment the organization.

The result looks surprisingly similar.

Teams are services

Modern software systems are built from services.

Each service owns a domain and communicates with other services through defined interfaces.

Organizations behave in much the same way.

Product teams, marketing teams, sales teams, and operations teams are essentially organizational services.

Each owns a piece of the system.

But just like software services, problems appear when:

• Interfaces are unclear
• Dependencies are hidden
• Assumptions drift over time

At first this shows up as coordination overhead.

Eventually it becomes system fragility.

Employees and agents are the compute layer

In software systems, compute nodes execute instructions. They take inputs, apply logic, and produce outputs. Employees (and now agents) play this role inside organizations.

They:

• Write code
• Close deals
• Launch campaigns
• Design products
• Resolve customer issues

In other words, organizations are starting to run on a hybrid workforce of humans and AI agents that act as the compute layer of the organization. They convert strategic intent into real-world outcomes.

These nodes are decision engines

But employees are not just executing instructions. They are decision engines.

Every day, across the organization, thousands of small decisions get made:

• How to interpret a priority
• Which tradeoff to accept
• What risk is tolerable
• What work matters most right now

These decisions act like local commits to the company’s operating system.

Each one seems small in isolation. But collectively they determine how the organization actually behaves.

Two companies can have identical strategy documents and still operate completely differently because the system is shaped by how its nodes make decisions.

Humans make the system non-deterministic

There is one major difference between organizations and traditional software systems. Humans and AI agents are non-deterministic components.

Given the same information:

• People interpret context differently
• Incentives shift behavior
• Priorities evolve
• Politics emerges

In distributed systems engineering, unpredictability is assumed.

Engineers design systems expecting that:

• Nodes will fail
• Messages will arrive late
• Information will be incomplete

Organizations rarely operate with this assumption. Instead they expect alignment to persist automatically.

But a company behaves less like a deterministic program and more like a distributed system with partially reliable nodes.

AI adds scale and complexity

AI agents introduce another layer. Unlike humans, AI systems can operate at massive scale and speed. But they still rely on the context they are given.

If the system feeding them context is incomplete or inconsistent, AI agents can amplify misalignment faster than humans ever could.

They become extremely efficient nodes executing uncertain reasoning.

Which means the rise of AI makes something else more important, not less: clear direction and visible reasoning inside the organization.

Decisions are commits

Software systems evolve through commits.

Each commit records:

• The change
• The author
• The time it occurred
• The reasoning behind it

You can inspect a codebase and understand how the system evolved.

Organizations evolve the same way. But their commits are decisions.

Every hiring choice, product change, pricing shift, or market pivot modifies the company’s operating system. The problem is most companies don’t maintain a clear commit history.

Decision reasoning ends up scattered across:

• Slack threads
• Meetings
• Half-updated documents
• Someone’s memory

Over time the organization loses the ability to answer a critical question: Why does the system look like this?

Processes are APIs

In software systems, APIs define how components interact. They make collaboration predictable. Without APIs, every interaction becomes a custom integration. Organizations face the same problem.

Processes act as the APIs of the company.

They define:

• How decisions are proposed
• How work moves between teams
• How information flows

When processes are unclear, teams rely on informal channels. Slack messages replace systems. Meetings replace documentation.

The organization becomes a network of manual integrations held together by people remembering things.

Incentives are the system’s hidden configuration

In software, configuration files quietly shape how a system behaves. Small configuration changes can dramatically alter outcomes. In organizations, incentives act like hidden configuration parameters.

They determine:

• What teams prioritize
• What information gets surfaced
• Where attention flows

If incentives diverge from strategy, the system starts behaving in ways leadership never intended. Just like misconfigured infrastructure can make an otherwise healthy application behave erratically.

Information degrades as it moves

In distributed systems, information rarely travels perfectly.

Messages can arrive:

• Late
• Out of order
• Missing context

Organizations face the same problem.

Strategic intent originates with leadership but spreads through:

• Meetings
• Documents
• Conversations
• Slack threads

Each hop introduces interpretation. By the time intent reaches the edges of the organization, it often no longer resembles the original signal.

What started as a small misunderstanding can compound into system-wide drift.

Observability is the difference between stability and chaos

In software systems, observability tools exist for one reason: You can’t fix what you can’t see.

Production systems rely on:

• Logs — what happened
• Metrics — how the system is performing
• Traces — how events propagate

These tools allow engineers to diagnose issues before they become catastrophic. Most organizations operate without equivalent visibility.

They measure business outcomes like:

• Revenue
• Pipeline
• Customer growth

But these are lagging signals. They reveal problems after the system has already broken.

What organizations rarely see is the underlying layer where problems actually start:

• Decision chains
• Strategic drift
• Conflicting assumptions between teams
• Small misalignments that compound over time

Without visibility into this layer, companies often discover problems months later when the symptoms finally appear.

Refactoring is organizational change

Every long-lived software system accumulates technical debt. To maintain velocity, engineers periodically refactor the system. They simplify architecture, remove obsolete components, and realign the system with current goals.

Organizations go through the same cycles.

Reorgs, strategy resets, and product pivots are essentially organizational refactors.

But unlike software engineers, leaders rarely have a clear map of:

• Dependencies
• Assumptions
• Decision history

So refactors happen partially blind. Which is why they’re often painful.

Leadership is site reliability engineering

In large software companies, there’s a role called Site Reliability Engineering (SRE). SRE teams don’t build features.

They ensure the system remains:

• Stable
• Observable
• Resilient
• Capable of evolving safely

Leadership increasingly looks like the same role. The job is not just deciding what to build.

It’s maintaining organizational uptime.

Ensuring that:

• Decisions propagate correctly
• Humans and AI agents stay aligned with strategy
• The system adapts without breaking

Without this, companies slowly drift into organizational outages:

• Missed launches
• Conflicting initiatives
• Endless rework
• Strategic confusion

The missing layer

Modern software systems rely on an entire ecosystem of infrastructure:

• Version control to track changes
• CI/CD pipelines to manage releases
• Observability tools to detect issues early
• Incident management systems to recover quickly

These tools exist because complex systems need infrastructure around them to stay healthy.

Companies have tools for execution:

• Jira or Linear
• CRM systems
• Collaboration tools

But they rarely have infrastructure for the reasoning layer of the organization. The decisions. The intent behind work. The evolving constraints shaping the system.

Which means companies are effectively running complex organizational software in production without version control or observability for decision-making.

A business is a complex system

A company isn’t just a collection of people. It’s a living distributed system of humans, AI agents, decisions, incentives, and evolving architecture.

And like any complex system, its long-term health depends not just on what it builds, but on the infrastructure that helps it:

• Preserve reasoning
• Detect when the system begins to drift
• Adapt safely as conditions change

In software, we learned this the hard way. You don’t keep a system healthy just by writing code.

You keep it healthy by building the operational infrastructure that surrounds it.

‍