The Golden Triangle — Understanding the System Before Trying to Improve It
In the first article of this journey, I introduced a question that has followed me for years:
How can we help a team continuously evolve without making it permanently dependent on the leader?
But before trying to answer that question, we need to understand what exactly we are trying to improve when we talk about “improving a team.”
Motivation is falling.
Delivery is getting slower.
Technical debt keeps growing.
We usually tend to separate these problems:
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.
But this does not mean that every problem is a people problem.
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.
A team may appear to lack autonomy because the process requires approval for every important decision.
If we look only at the person, we may try to solve the wrong problem.
We may try to motivate someone who is exhausted by the system.
We may ask for more accountability while removing autonomy.
We may demand more speed while complexity continues to increase.
People create processes and technology, but they also live with their consequences.
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 allows us to recognise patterns, anticipate risks and avoid mistakes that others have already made.
But experience can also become a limitation.
When we know a discipline deeply, we tend to look at problems through its lens.
The process expert sees a process problem.
The technology expert sees a technology problem.
The Agile expert sees a need for greater agility.
The architecture expert sees technical debt.
The leadership expert sees a leadership problem.
Each of them may be seeing a real part of the problem.
But seeing one part correctly does not mean understanding the whole system.
There is a well-known idea, often expressed through the law of the instrument: when we have a hammer, we tend to see nails.
The same thing happens constantly inside organisations.
We find a practice that worked for one team and try to reproduce it in another.
We create a maturity model and expect different teams to follow the same path.
We apply the same framework, transformation, organisational structure or leadership style because it produced good results before.
But no two teams are exactly the same system.
They may use the same technology.
Follow the same process.
Work on the same product.
They may even belong to the same organisation.
And yet, they can be in completely different situations.
Because the people are different.
Their knowledge is different.
Their experience is different.
Their level of confidence is different.
Their motivation is different.
Their shared history is different.
Their tolerance for frustration is different.
And so are their fears, expectations, relationships and emotional states.
These variables are not noise surrounding the system.
They are part of the system.
The emotional dimension of people affects how they collaborate, how they make decisions, how they learn, how they respond to uncertainty and how they use the processes and technology available to them.
A process that provides safety to one team may feel suffocating to another.
The autonomy that liberates one person may leave another feeling abandoned.
A challenge that activates and motivates one person may create anxiety in someone with a different level of experience or knowledge.
The same leadership style may help one person grow and make another increasingly dependent.
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 role of the expert should not be to arrive with a prepared answer.
It should be to observe deeply enough to discover what question this system actually needs to answer.
Because when we always use the same hammer, we do not only risk choosing the wrong solution.
We may also end up ignoring everything that does not fit our tool.
And too often, the first thing to disappear from our analysis is precisely 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 assume that the team needs to improve its process.
But perhaps the technology has become increasingly difficult to change.
Technical complexity creates uncertainty.
Uncertainty creates fear of breaking things.
Fear creates more controls and approvals.
More controls make delivery slower.
Pressure increases.
And as a consequence, there is less and less time available to improve the technology.
The cycle begins again.
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 trying to solve.
Scrum is not always the answer.
Coaching is not always the answer.
More autonomy is not always the answer.
More control is not always the answer either.
A practice may help one team in one situation and block another team in a different one.
And this leads us to a different 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?
Because the same process may help one team and block another.
The same person may feel completely capable in one situation and overwhelmed in another.
The same technical debt may be a strategic decision today and become a critical problem tomorrow.
The system is never static.
It exists within a context.
It moves through different situations.
And it evolves over time.
Understanding the system is therefore only the beginning.
The Golden Triangle gives us the system we need to observe.
Situational Awareness should help us understand what that system needs now.
Perhaps the next step in the evolution of management is not to find another universal solution.
Perhaps it is to develop the ability to understand which response each situation actually requires.
And that is where the next step of this journey begins.