When the Same Business Problem Keeps Coming Back

Systems thinking is an established way of understanding a system by looking at the relationships among its parts—not only the parts themselves.

In an operating business, that means resisting the urge to isolate a problem from the conditions around it. A missed handoff may not be only a communication problem. A delayed decision may not be only a leadership problem. An unused process may not be only a compliance problem.

Each may be connected to how information moves, where authority sits, what people can see, what they are expected to own, and how the work itself has been designed.

Systems thinking in business asks you to look beyond the immediate symptom. What else is connected to it? What conditions make it possible? What patterns keep reinforcing it? What changes when pressure, volume, or uncertainty increases?

The goal is not to make every problem more complicated. It is to understand the actual shape of the problem before deciding what to do about it.

Not every recurring problem is structural. Sometimes someone needs a skill they do not yet have. Sometimes the timing is wrong. Sometimes an isolated mistake is simply an isolated mistake.

But recurrence deserves attention.

If the same symptom keeps returning after reasonable efforts to solve it, the recurrence may be telling you that the visible problem is not the whole problem.

That shift matters. It moves the conversation away from repeated correction and toward understanding.

Recurrence gives you information. It can reveal something about the system around the work: what it makes clear, what it leaves ambiguous, what it supports, and what it quietly requires people to compensate for.

These may be six separate problems.

They may also be different expressions of one connected operating problem.

Decision authority may be unclear. Knowledge may live in people's heads rather than somewhere others can reliably access it. Ownership may be assigned in principle but poorly defined in practice. Workflows may depend on tacit knowledge. Information may be fragmented across tools and conversations. The founder may still function as the routing layer through which context, decisions, and exceptions must pass.

When that is the case, asking people to “take more ownership” does not resolve the conditions that make ownership difficult.

The people may be capable. The business may be asking them to operate inside a structure that does not give them enough clarity, access, or authority to do what is being asked.

Systems thinking does not assume that this is the answer. It makes the relationship visible enough to ask whether it might be.

When a business problem is painful, the impulse to act quickly makes sense.

A new tool may create visibility. A new SOP may preserve knowledge. A new hire may add capacity. A direct conversation may correct an expectation. Any of those may be the right intervention.

But the usefulness of the intervention depends on the problem it is actually solving.

A project-management tool cannot clarify decision rights unless someone defines them. Documentation cannot create ownership if responsibility remains ambiguous. Another operations hire cannot remove the founder as the routing layer if the role still depends on the founder for context and approval.

When a fix addresses the symptom but not the conditions producing it, the problem may reappear. Sometimes it moves. Sometimes it becomes less visible. Sometimes the new solution becomes one more layer that people have to work around.

The issue isn't that tools, documentation, hiring, or coaching are the wrong interventions. It's that they work best when they're connected to an accurate understanding of the system.

My work often begins before the answer is clear.

I start by trying to understand what is actually happening—not only what the problem has been called, but how the work moves, where it slows down, what people rely on, and what the current structure requires them to carry.

Then I notice. I look for repetition, friction, exceptions, contradictions, and the places where capable people keep compensating for something the business has not made explicit.

From there, I connect. A process problem may be tied to an information problem. An ownership problem may be tied to unclear decision authority. A strategy may be sound but difficult to execute because the operating structure does not support it.

Once the relationships are visible, I structure. I determine what needs to be clarified, organized, documented, separated, or brought together.

Then I build: the workflow, framework, decision structure, knowledge system, operating mechanism, or other form that makes the thinking usable.

1. 01Understand
2. 02Notice
3. 03Connect
4. 04Structure
5. 05Build

Those aren't always sequential steps. In complex systems, understanding changes as new patterns become visible. Connecting two pieces may change the way I understand the original problem. Building something may expose a gap that sends me back to look again.

So this isn't a formula I impose on every business. It's a description of the work: understand enough to notice, notice enough to connect, connect enough to structure, and build enough to learn whether the structure actually holds.

Depending on the question, that work may draw on Research and Strategic Analysis, IP and Framework Development, or the design of operational structure. The format changes because the problem changes. The way of seeing it remains consistent.