How I Think About Systems

The clearest way I can state how I think about systems is this: the output of a system is almost never explained by any individual component. It is explained by the interaction between components — the feedback loops, the delays, the incentive structures that determine how each part responds to the others.

This seems obvious when stated directly and is apparently very hard to hold in practice, because most of the interventions I see — in organisations, in policy, in my own business — treat problems as if they are locatable in a single component and solvable by fixing that component. They rarely are.

How I spot a systems problem

The most reliable indicator that I'm looking at a systems problem rather than a component problem is when:

The problem keeps returning after it's been fixed. If you address a component — replace a person, fix a process, change a policy — and the same problem resurfaces in a different form, you haven't fixed the system. You've addressed a symptom. The structure that produces the symptom is intact.

Everyone involved is behaving rationally but the system is producing bad outputs. When you look at each individual and each step in a process and none of them look obviously broken, but the output is consistently worse than it should be, the problem is almost always in the interaction — in the gaps between components, in the incentive structures that make individually rational behaviour collectively destructive.

The same type of problem appears in multiple places. If three different parts of an organisation are experiencing what looks like three different problems, and those problems share a structural pattern, they are probably manifestations of the same underlying system property rather than independent failures.

The leverage question

In any system, some interventions have much higher leverage than others. The same amount of effort applied in different places produces dramatically different outcomes. Finding the high-leverage intervention requires understanding the structure of the system well enough to identify where force amplifies rather than dissipates.

In hiring systems — which is where I have spent most of my professional life — the high-leverage point is almost always the intake. Not the sourcing, not the evaluation, not the offer. The intake: who is the role actually for, what does success look like, what are the real criteria versus the stated ones. Get this wrong and every subsequent step is working toward the wrong target with great efficiency. Get it right and the rest of the process becomes substantially more tractable.

I know this is the high-leverage point because I have seen it fail more than any other component, and because fixing it produces outsized results relative to the effort. That's the signature of a high-leverage intervention: small effort, large output shift.

Feedback loops and delay

The two features of systems that most consistently trip people up are feedback loops and delay.

Feedback loops: outputs from a system become inputs to the same system. This creates self-reinforcing dynamics — both positive (virtuous cycles where early success generates the conditions for more success) and negative (vicious cycles where early failure generates the conditions for more failure). The feedback loop is why small differences in starting conditions can compound into large differences in outcomes over time. It is also why the same starting conditions can produce dramatically different outcomes depending on which feedback loop gets activated first.

Delay: in most systems, cause and effect are separated in time. A decision made today produces consequences six months or two years from now. A problem that manifests today was caused by decisions made six months or two years ago. This delay means that by the time you see the output of a decision, the decision is old and the connection between the two is non-obvious. Most organisational learning fails here: the feedback arrives too late to be attributable to the cause, so it doesn't update the decision-making process that produced it.

Both of these — feedback loops and delay — make it genuinely hard to reason about systems with the kind of linear logic that works for component-level problems. The sequential thinking that works in a spreadsheet doesn't work in a system with feedback and delay. You need a different cognitive mode.

What systems thinking doesn't do

Systems thinking is not a substitute for component-level work. The fact that the system is the problem doesn't mean the components don't matter — it means that fixing the components without fixing the structure produces temporary improvement at best.

It also doesn't resolve ambiguity about what the right system structure is. Understanding that a system is broken is not the same as knowing how to design a better one. Systems are complex enough that interventions produce unexpected consequences, and the honest position is often: I understand why this system is producing bad outputs better than I understand what would reliably produce better ones.

What systems thinking does: it tells you where to look, what questions to ask, and which interventions are likely to be high-leverage. It prevents the most common mistake — addressing symptoms while the structure that produces them stays intact. That is already a significant contribution.

How this has shaped the businesses I build

Majhi OS is built on a systems view of hiring failure. The conventional view is that searches fail because of candidate supply — not enough good people, too much competition. The systems view is that searches fail because the process has structural failure modes that produce bad outputs even when the supply is adequate. Fix the structure and the same candidate pool produces dramatically better results.

This is counterintuitive enough that it requires sustained explanation to clients who are accustomed to the supply view. But once they see it — once they trace a specific failed search to the intake that was ambiguous rather than the candidates who were absent — the explanation sticks. Because it matches their experience, which the supply view never quite did.

I build systems around insights that are counterintuitive but durable. The durability comes from the structural explanation, which is more stable than the surface-level pattern it explains.