There is a particular kind of organizational problem that is difficult to explain because, when you look closely at any individual part, nothing appears obviously broken.

The CRM works. The data warehouse works. The finance system works. The people are competent. The teams have processes, the dashboards exist, and everyone can explain what they are responsible for.

And yet the organization itself feels strangely difficult to operate.

Information has to be reconstructed every time someone needs it. Decisions take longer than they should. Teams disagree about things they are all technically correct about. People build spreadsheets beside systems that were supposed to eliminate spreadsheets. Someone becomes indispensable because they are the only person who understands how three different parts of the company fit together.

Eventually, the organization concludes that something needs fixing, so it fixes a part. It buys another tool, redesigns a workflow, creates a new field, adds an approval, reorganizes a team, or hires someone to own the process. Sometimes all of those things are perfectly reasonable.

They just don't solve the problem.

Because sometimes there is nothing particularly wrong with the individual pieces.

The problem is in the relationships between them.

Organizations don't fail one box at a time

We tend to describe organizations as collections of things: people, teams, processes, technologies, policies, data, goals. That makes them easier to manage because things can have owners. Sales owns this. Finance owns that. Operations owns the process. IT owns the system. Someone owns the metric.

But an organization isn't simply the sum of those things. It is also what happens between them.

A customer becomes an account. An account becomes a contract. A contract becomes revenue. A strategy becomes a decision, a decision becomes work, and work performed by one person becomes information another person needs.

Those transitions cross boundaries constantly—between people, systems, teams, definitions, incentives, and forms of authority—and those boundaries are often where the organization actually lives.

You can have a perfectly reasonable sales process and a perfectly reasonable finance process that produce an unreasonable order-to-cash system when connected. You can have accurate data in five systems and still have no trustworthy answer to a basic business question. You can have talented people making locally rational decisions that collectively create something nobody intended.

Every piece can work. The system can still fail.

Local optimization can create global incoherence

Organizations are very good at improving things they can see. A team is overloaded, so its work gets automated. A process is slow, so steps are removed. A platform is expensive, so it gets consolidated. A role seems redundant, so it disappears.

Individually, each decision may improve a measurable thing. But systems contain relationships that don't always appear on the balance sheet or dashboard. The person who looked redundant may have been translating between two teams. The manual step may have been where someone noticed exceptions. The duplicated process may have provided a second path when the first failed. The unused capacity may have been what allowed the organization to absorb something unexpected.

Remove enough apparent inefficiency and something strange happens: the organization becomes extremely efficient at operating under the conditions it expected, and increasingly fragile under the conditions it didn't.

This is one reason I am suspicious when redundancy, slack, or overlap are treated as inherently bad design. Sometimes they are waste. Sometimes they are capacity.

The interesting question isn't simply whether something is redundant. It's what function that redundancy performs in the larger system.

People become the integration layer

When systems don't cohere, people usually make them cohere. This can hide the problem for a surprisingly long time.

Someone remembers which customers are exceptions. Someone knows the spreadsheet has to be updated before the report runs. Someone messages another team because the official workflow doesn't quite work. Someone recognizes that two fields with different names actually mean the same thing. Someone knows who can make the decision even though the org chart says someone else owns it.

These people are often described as exceptionally valuable, and they are. But sometimes their indispensability is also diagnostic.

The organization is borrowing coherence from a person.

Their memory becomes infrastructure. Their relationships become integrations. Their judgment becomes exception handling. Their attention becomes quality control. Their willingness to compensate for the system becomes part of the system itself.

This can work remarkably well until that person gets promoted, leaves, gets tired, or the organization doubles in size. Then what looked like a people problem suddenly becomes a systems problem.

It was a systems problem all along.

This changes where I look

When someone brings me a problem, I rarely assume the problem is located where it first appeared.

Low sales productivity might be a sales problem. It might also be an information problem, an incentive problem, a capacity problem, a decision-rights problem, or a system that asks a salesperson to reconstruct context that already exists somewhere else in the organization.

The visible problem tells me where someone experienced the system. It doesn't necessarily tell me where the system is producing the problem.

So I start looking at relationships. What has to happen before this can happen? Who knows something another person needs? Where does information change meaning? Where does authority actually live? What happens when the normal path fails? What are people doing manually to make the designed system work? Where is the organization depending on someone remembering something?

And one of my favorite questions:

What are we asking individual parts of the system to solve that can only be solved between them?

That question has changed the way I approach technology architecture, operations, organizational design, and increasingly almost everything else, because it changes the unit of analysis.

Instead of asking What's wrong with this thing?

I can ask What is happening between these things?

The system is producing something

This is also why I don't find “broken system” particularly useful as a diagnosis. A system producing a bad outcome isn't necessarily failing to operate. Sometimes it is operating exactly according to the conditions we created.

If information is difficult to access, people with strong informal networks will have an advantage. If every team is measured locally, people will optimize locally. If there is no spare capacity, unexpected work will become someone's personal burden. If authority and information live in different places, decisions will become slow or political. If the easiest path through a process only works for people who already understand the institution, the institution will disproportionately work for people who already know how to navigate it.

The outcome isn't separate from the design.

The system is producing it.

That doesn't mean someone intended it. In complex systems, nobody has to intend the whole. Each person can make a reasonable decision from where they sit and still participate in producing an unreasonable result.

Which is why blame is usually a fairly uninteresting place to begin.

Architecture is much more interesting.

Seeing differently changes what becomes possible

There is a practical reason I care about all of this: how we describe a problem determines what kinds of solutions we can imagine.

If the problem is Salespeople aren't updating the CRM, the imaginable solutions are training, enforcement, automation, or better salespeople.

But suppose we describe the same situation differently:

The CRM requires salespeople to repeatedly recreate information the organization already knows, while offering very little useful information back to them.

Now we have an entirely different design problem.

Likewise, if the problem is People resist change, we can work on communication and adoption. But if instead we ask, Who has enough agency to imagine a different system but not enough authority to change this one?, we may discover something else entirely.

The reframe isn't semantic. It changes the intervention.

Sometimes the reframe is enough. Someone sees the system differently and knows what to do next. Other times, what becomes visible is a structural problem involving architecture, incentives, roles, information, decision rights, capacity, technology, or operating rhythms.

Those are the problems I like working on—not because I have a proprietary framework that can be applied to every organization, but because I have spent a long time learning to notice what happens between the boxes.

Once you can see that, a surprising number of problems stop looking like isolated failures.

They start looking like systems.