I See a Company as One Giant IT System

Spend enough years designing, building, and running systems and the failures start to rhyme. At some point I couldn't unsee it: the things that break inside a company look an awful lot like the things that break inside a distributed system. Occupational damage, probably.

I'm not saying employees are servers. I'm not saying run your company like a computer.

But: cram every function onto one box and you're fragile. Have exactly one developer who understands that box and you're worse off. Skip the contracts between services and complexity eats you. Skip monitoring and you learn about outages from your users. Traffic grows, you can't add capacity, everything stalls.

Companies do all of this too.

One person makes every decision. One employee is the only one who can do that task. No agreed handoff between departments. You find out something was wrong after revenue drops. The business tripled and the headcount and processes are still the ones from three years ago.

In IT we'd look at that system and say it's broken. In a company, somehow, the same picture gets shrugged off.

Is a company where the CEO does everything well actually a good company?

You see this constantly at small companies.

Quotes go to the CEO. Contracts get checked by the CEO. Purchasing decisions, the CEO. Customer blows up, the phone rings at the CEO. Hiring, the CEO. Money going out the door, the CEO.

Early on it's fast. The CEO knows the most, so routing everything through them is the right call.

Then the company starts to grow.

Anyone who's drawn an architecture diagram already has the word queued up.

SPOF. Single point of failure.

One node stops, everything downstream feels it.

The CEO takes a vacation and decisions freeze. The CEO gets sick and contracts slip. The CEO gets busy and the whole staff sits waiting for an answer.

From the outside: a company with a capable CEO. From a systems view: a company with a scary dependency graph.

Is the CEO running the company, or is the company running on one server that happens to be the CEO? Worth knowing which.

I can't pretend this is somebody else's problem. On a platform I owned a while back, I held sole release-approval authority for months. I once took a 2 a.m. call on vacation and opened my laptop in the dark. I thought that was accountability. It was a bottleneck. Writing the approval criteria down and handing them off took me another six months, and it should have happened long before.

If someone keeps making mistakes, is it really that person?

Say the same outage hits three times.

If your response each time is to call in the developer and say "be more careful next time," that isn't operations.

Engineers don't usually do that. They go find out why. Read the logs, trace the process, nail down the repro.

Then they ask the real question.

"What has to change so this can't happen again?"

Add validation. Automate the step. Wire up an alert. Cut the permission. Change the process.

In a company the reflex bends somewhere else.

"Kim screwed up again." "Nobody takes ownership anymore."

Sometimes it really is the individual — skill, attitude, effort. Blaming the system for everything a person does is its own lazy diagnosis. But when the same class of mistake shows up across multiple people, the question needs rewriting.

From "why did Kim make that mistake" to "why is our company built so that Kim can make that mistake?"

One word changes and you're standing somewhere completely different when you look at the problem.

Departments need APIs too

When you design microservices, the interface is what you spend the longest on.

What does A ask of B. What data crosses. What does a normal response look like. What happens when it fails.

That's an API.

Companies run on the same thing.

Sales hands an order to production. Production requests materials from purchasing. Purchasing asks finance to pay. Something goes wrong on the floor and information has to reach QA and sales.

Every one of those is an interface.

The problem is that none of them are written down.

So a person becomes the API.

"Ask Park about that." "Lee's always handled that one." "That's just how we've always done it."

Translate that into IT terms and it gets uncomfortable fast. Undocumented, unofficial APIs whose only implementation lives in someone's head. The day they quit, the API leaves with them.

Lots of numbers isn't observability

Companies already have plenty of numbers.

Revenue. Operating profit. Inventory. COGS. Bookings. Defect rate. Output.

Easy to look at that and conclude you're running on data.

In operations, nobody says a system has good observability because it emits a lot of data. The bar is whether you can explain what's happening inside the system right now.

"Revenue dropped 20%" is an outcome

What you actually want to see is upstream of it.

Did quote requests fall? Are quotes flat but the close rate slipped? Did production lead time stretch? Did raw material prices move? Did one customer segment stop ordering?

Catching the anomaly on the way up through 70%, 80%, 90% beats discovering the outage when CPU pegs at 100.

Business metrics should be sensors wired into the company, not a report you read after the fact.

Manufacturing makes this obvious

A factory that's been running for decades has a thick layer of know-how. Most of it is stored in people, not in systems.

"When this machine starts sounding like that, go look at it." "Call this supplier first or they'll sit on the order." "Don't build that drawing as-is, you have to shave about 2mm here."

Genuinely valuable knowledge. Also a liability.

In IT terms, it's critical business logic that lives in a developer's head instead of in the source tree.

Which is why I don't think manufacturing DX ends with handing out tablets and installing an MES. The first job is finding the business logic hiding inside people. Then you move it into data and process.

I call it legacy refactoring for factories.

This is not "run your company like Kubernetes"

There's a trap in all of this.

A company is not a system.

Servers don't have feelings; people do. You can delete a pod and reschedule it; you cannot do that to an employee. A computer executes exactly what you told it. A person swings on meaning, motivation, and who they sit next to.

Drop IT logic straight onto humans and you get a pretty grim organization. I've watched a few of those.

I'm not arguing for managing people like machines. The opposite.

I want the system to take over the work where humans are forced to behave like machines. Judgment, negotiation, creativity, relationships — leave those with people. Repetitive checking, forwarding, calculating, recording — push those into the system.

That's how people get to do the part only people can do.

And then AI showed up

There's a new variable.

AI.

An executive who was weak in some area used to have exactly two moves: hire someone, or bring in a consultant. Experts still matter as much as they did. What changed is the cost of an executive exploring a problem. That's come way down.

Strong on technology, shaky on accounting? Have your reasoning stress-tested from an accounting angle. Weak on marketing? Have your plan attacked from the customer's point of view. Stuck on a clause in a contract, get it broken down. Want three business scenarios side by side, generate them and compare.

AI isn't going to be the CEO.

The framing I've settled on is this: AI is a copilot that fills in the executive's missing modules.

The edge an executive has is going to shift away from knowing everything. Toward spotting the problem, structuring it, decomposing it, pulling the information you need, filtering out what's wrong, and making the final call. Less volume of knowledge, more eye for architecture.

The best executive might not be the busiest one

Here's the system I want. It runs when a given server is gone. It detects failure fast. It scales when traffic grows. The interfaces between services are explicit. The operational state is visible from outside. When something breaks twice, you fix the structure before you go looking for someone to blame. Repetitive work gets automated where it can be.

A good company probably isn't that different.

It runs when the CEO steps away. Work continues when a person changes roles. Problems surface before they're large. The org grows as the business grows. Responsibility and interfaces between departments are clear. When the same mistake repeats, the process changes.

I've stopped thinking of management as purely people management. An executive looks a lot more like the architect of a system that happens to be made of people.

A good architect's goal isn't to handle every request personally. It's to design things so the system stays up without them touching it.

I want to ask companies the same question.

"Is this company designed as a good system right now?"

That question is where I want to start Running a Company Like a System.

Next up: why a company where the CEO decides everything becomes a SPOF. I don't have all the answers written down before I start.