Why Systems, Not Processes

When something goes wrong in a company, the first instinct is to fix the process.

Add a step. Remove a step. Create a template. Schedule a meeting. Write a policy. The logic is straightforward: if the output is wrong, adjust the procedure that produces it.

Sometimes this works. If the problem is genuinely procedural — a missing approval, an unclear handover of information, a forgotten notification — then a process fix is the right tool.

But most of the problems I described on the previous page aren’t procedural. They’re structural. And there’s a fundamental difference.

A process describes a sequence: do this, then this, then this. It assumes the components are fixed and the path between them needs optimization.

A system describes far more than relationships. It sees what the elements are and how they differ in quality. How they’re connected — their architecture. What they interact through — not just exchange, but mutual transformation, where each element spends part of its own resource and receives something from the others. And where the system’s boundaries lie. Together, all of this produces properties that no single element has on its own.

When you fix a process, you’re optimizing a path. When you understand a system, you’re seeing the whole landscape.

The missing human

There’s a deeper issue with process thinking that rarely gets named.

A process doesn’t see people. It sees roles. Step one: the analyst gathers requirements. Step two: the architect designs the solution. Step three: the developer writes the code. Step four: QA verifies.

The analyst, the architect, the developer, the QA engineer — in the process diagram, they’re interchangeable. Swap one analyst for another, and the process doesn’t change. That’s the whole point: processes are designed to be person-independent.

This works on a production line. When the task is repetitive, predictable, and the output is standardized, you want a system that doesn’t depend on who’s operating it.

But when the work is creative — when you’re building something that didn’t exist before, solving a problem nobody has solved, integrating systems across boundaries that nobody has crossed — the person is not interchangeable. Their specific way of thinking, their perception, their experience, their ability to see connections that others miss — these aren’t noise to be filtered out by the process. They’re the signal. They’re what produces the value.

A process that ignores the human factor can be efficient. But it cannot be inventive. It cannot adapt. It cannot produce anything genuinely new.

This isn’t just my observation. In the theory I’ll introduce in the next chapter, there’s a formal principle for this — the principle of homocentrism. It states that any system involving humans must explicitly account for their specific properties: their perception, their limitations, their unique qualities. If you build a model of a system — a team, an organization, a workflow — and the human element is treated as a generic, replaceable component, the model is incomplete. It will fail precisely at the moments when it matters most — when the situation is new, when the path is unclear, when you need a person to think, not just execute.

Production lines don’t need homocentrism. Creative, cross-functional work cannot survive without it.

The multi-quality problem

Here’s the next layer: every real system is multi-quality. A person is not one thing. They’re simultaneously a programmer, a mentor, a communicator, a domain expert, a fast executor, an analyst. Some of these qualities are visible in their job description. Most aren’t.

A department is not one thing either. Finance is simultaneously a control function, an information source, a decision-making bottleneck, and a strategic partner — depending on who’s looking and what they need.

When we treat people and departments as single-quality entities — “she’s a backend developer,” “they’re the finance team” — we lose most of the richness that actually determines how well the system works. We build teams by matching job titles to requirements, not by composing complementary spectrums of qualities into a complete whole.

Three brilliant backend developers with identical experience and identical thinking patterns are not a super-team. They’re a fragile system. Their spectrums overlap completely. When a threat comes from an unexpected direction — a UX problem, a security concern, a communication breakdown with another team — they all have the same blind spot.

A team with complementary spectrums — different but interlocking qualities — is resilient. Each person’s weakness is another’s strength. Together they cover more ground than any of them could alone. Together they form something that didn’t exist before: completeness.

In Ukrainian there’s a word for this: цілісність. It means wholeness, integrity, completeness. Not in the moral sense — in the structural sense. A system that has all the qualities it needs to function, with no critical gaps.

Building цілісність is the core challenge of organizational design. And you can’t do it with processes. You can only do it by understanding the system — and the people within it.

Ludwig von Bertalanffy had it right

In 1968, an Austrian biologist named Ludwig von Bertalanffy published General System Theory. His key insight: any complex system — a living organism, a company, a software product — follows common principles of organization. A system is not just the sum of its components. It’s the way those components interact.

This idea influenced dozens of disciplines. But in most companies, it remained academic. Managers kept optimizing processes while the system — the actual structure of relationships and interactions — evolved on its own, unobserved and unmanaged.

Bertalanffy opened the door. But the theory I want to share with you walks through it much further — into territory that’s directly applicable to how we build and measure teams. A theory that takes the human factor not as an afterthought, but as a founding principle.

It was developed in Lviv, Ukraine, in 1989, by a radio physicist named Oleksandr Malyuta. And it gives us something that general systems theory never quite achieved: a formal, implementable framework for understanding multi-quality systems — including teams of people.

That’s the next page.