The Golden Triangle of Human System
Throughout my career, whenever I joined a new team or faced a challenging situation, my instinct was never to propose solutions immediately, but to understand the underlying complexity.
I’ve always been driven to understand complexity, regardless of the domain. In fact, the more complex the problem, the more motivated I became to understand it deeply before trying to solve it.
In the later stages of my leadership journey, I realized that the greatest source of complexity was no longer technology or processes, but the people and the interactions between them.
How did the system behave? Why were certain patterns emerging? Which problems belonged to the people, and which were a consequence of the system itself?
That search led me to explore organizational psychology, where I discovered the Golden Triangle—a framework that helped me organize and better understand the complexity I had been observing in teams for years.
People. Process. Technology.
But are they really three different problems?
Or are we observing different symptoms of the same system?
People, Process and Technology
The idea that an organisation cannot be understood by looking only at its people, processes or technology is not new.
Throughout the twentieth century, different schools of management and organisational theory began to challenge the idea that one part of a system could be optimised without affecting the others.
In 1965, Harold J. Leavitt proposed a model of organisational change based on the interdependence of People, Task, Structure and Technology. Over time, different interpretations and evolutions of this thinking contributed to the popularisation of simpler models based on People, Process and Technology, often referred to as the Golden Triangle.
The formulation may change, but the fundamental idea remains:
When we change one part of the system, the others are affected too.
Throughout this journey, I will use these three dimensions as a foundation:
People represents the people who think, learn, decide, collaborate and build.
Process represents how we organise our collective behaviour: our habits, practices, decision-making mechanisms and feedback loops.
Technology represents the capabilities and constraints of the systems we build: architecture, tools, automation, quality, complexity and technical debt.
Together, they form the Golden Triangle.
But I do not see this triangle as three independent pillars that can be optimised separately.
I see it as a living system.
When we change one part, sooner or later, we change the others.
People at the Centre
In my interpretation of the model, people occupy the central position. This does not mean that every problem is a people problem, but rather that people are the ones who ultimately experience the consequences of the system around them.
A person may appear unmotivated because every small change requires fighting against a fragile system. A developer may appear slow because the architecture turns a simple modification into a complex task, or a team may seem to lack autonomy because the process requires approval for every important decision.
Looking only at the person can therefore lead us to solve the wrong problem: trying to motivate someone who is exhausted by the system, asking for more accountability while removing autonomy, or demanding more speed while complexity continues to increase.
People create processes and technology, but they also work within the conditions those processes and technologies create.
People create the system, and the system continuously shapes people.
This is why people are at the centre of the Situational Awareness Management Model: not because every problem begins with them, but because people create, experience, and ultimately transform the system.
The Expert Trap: When Experience Becomes a Single Hammer
Organisations turn to experts, quite rightly, to solve complex problems. Experience helps us recognise patterns, anticipate risks and avoid mistakes, but it can also become a limitation when every problem is interpreted through the discipline we know best.
A process expert may see a process problem, while a technology expert sees a technology problem. An Agile expert may identify a need for greater agility, an architecture expert may focus on technical debt, and a leadership expert may interpret the same situation as a leadership problem. Each may be observing something real, but seeing one part correctly does not mean understanding the whole system.
This is closely related to the law of the instrument: when we have a hammer, we tend to see nails. Organisations repeat this pattern when they reproduce practices, frameworks, maturity models, structures or leadership styles simply because they worked somewhere else.
But no two teams are exactly the same system. Even with the same technology, processes, product or organisation, their people bring different knowledge, experience, confidence, motivation, relationships, shared history and tolerance for frustration.
These variables are not noise surrounding the system. They are part of the system.
The emotional dimension influences how people collaborate, make decisions, learn and respond to uncertainty. A process that gives one team safety may suffocate another; autonomy may liberate one person and leave another feeling abandoned; the same challenge or leadership style can produce very different responses depending on the person and the situation.
This is why one of the greatest risks of experience is confusing:
“This worked before.”
with:
“This will work here.”
Experience should expand our ability to interpret a situation, not reduce every new problem to patterns we already know. The expert’s role should not be to arrive with a prepared answer, but to observe deeply enough to discover what question this system actually needs to answer.
Otherwise, when we always use the same hammer, we risk not only choosing the wrong solution, but also ignoring everything that does not fit our tool — especially what is hardest to measure:
the human and emotional depth of the people who make up the system.
Relationships Matter as Much as the Components
Imagine a team whose delivery speed has been decreasing over time. We might initially assume that the team needs to improve its process, but the underlying cause could be somewhere else in the system.
Perhaps the technology has become increasingly difficult to change. Technical complexity creates uncertainty, which can lead to a greater fear of breaking things and, consequently, to more controls and approvals. Delivery becomes slower, pressure increases, and the team has less time to address the technical problems that contributed to the situation in the first place.
The result is a reinforcing cycle: technical complexity increases uncertainty, uncertainty introduces more control, more control slows delivery, and growing pressure leaves even less space to improve the technology.
The problem is therefore not located in a single component. It emerges from the relationships between people, process, and technology.
Where is the problem now?
In Technology?
Yes.
In Process?
Also.
In People?
Also.
Perhaps the right question is not:
“Who owns the problem?”
But:
“What is happening in the system?”
A Team Is More Than the Sum of Its Parts
A team is not simply the sum of its developers, Product Owners, QA engineers, managers or Tech Leads.
It is also the relationships between them, the knowledge they share, their habits, their trust, their conflicts, their processes, the technology they work with and the context surrounding them.
This is why improving one part without observing its impact on the others can sometimes make the overall system worse.
A new process may increase control while reducing autonomy.
A new technology may increase capabilities while also increasing complexity.
A decision made to accelerate delivery today may create technical debt that affects the people working with the system for years.
The whole is more than the sum of its parts.
From Optimising Work to Adapting to Change
The way we manage work has also evolved.
From early attempts to optimise and standardise industrial work, through Lean, continuous improvement and, later, Agile, we have gradually incorporated new ways of understanding quality, feedback, learning and adaptation.
The growth of knowledge work made it even clearer that not all work could be managed as a completely predictable sequence of tasks.
In software development, the Agile Manifesto made one particularly important idea explicit: responding to change can be more valuable than following a plan.
But even the best ideas can become dogmas when we forget the problems they were originally designed to solve.
Scrum, coaching, autonomy, or control can all be useful responses, but none of them is universally the right answer. A practice that helps one team in a particular situation may become an obstacle for another team facing a completely different context.
Rather than starting with a predefined solution, we should first understand the situation in front of us.
And that leads to a more important question:
How do we know what the system actually needs right now?
The Golden Triangle Is Not Enough
People, Process and Technology help us understand what we need to observe, but a much harder question remains:
What does this system need now?
The answer depends on context. The same process may help one team and block another; the same person may feel completely capable in one situation and overwhelmed in another; and technical debt that represents a reasonable strategic decision today may become a critical problem tomorrow.
Systems are not static. They exist within a context, move through different situations, and continuously evolve over time. Understanding their components is therefore only the beginning.
The Golden Triangle gives us the system we need to observe. Situational Awareness helps us understand what that system needs now.
Perhaps the next step in the evolution of management is not another universal solution, but developing the ability to understand which response each situation actually requires.
And that is where the next step of this journey begins.