What builders see that others don't

Founding manifesto for the Think Like a Builder section.

A few years ago, I sat in a leadership meeting where a large organization was trying to understand why employee turnover was rising. The diagnosis was clear: people were leaving for higher salaries at competitors. The solution seemed obvious: raise salaries.

They did. Turnover dropped for six months, then resumed its climb. Two years later, it was higher than before the intervention.

What the company had fixed was a symptom. The real causes lay elsewhere: an opaque promotion system, undertrained managers, a culture where feedback only existed in annual review forms. Higher salaries had simply delayed the signal.

I wasn't watching this mechanism from the outside. I had lived it. Between 2017 and 2021, I ran Hitotec, an offshore development company I had founded in Benin, West Africa. We grew to twenty developers. On paper, everything worked: consultants trained on cutting-edge technologies, satisfied clients, a young and talented team. In reality, I spent enormous energy rebuilding. Every time one of my managers left, I was back to square one: recruiting, retraining, rebuilding trust with clients. And the more we trained our consultants, the more employable they became, and the faster they resigned for better salaries.

For a long time I believed it was a compensation problem, exactly like that leadership team. It was a structural problem. Without seeing it, I had built a machine that trained talent for the market, not for the company. The system I had built reliably produced the very outcome I feared most.

This pattern repeats across almost every organization. Not because leaders are incompetent. Because they were trained to solve problems, not to read systems.

The solution trap

From school onward, we learn to decompose. A problem has a cause, a solution, an end. This logic works remarkably well for simple systems: fixing an engine, calculating a budget, correcting a bug.

It fails in almost every context that actually matters to a leader.

An organization is not an engine. It is a living system, made of people, incentives, stories, formal and informal structures. Acting on one part changes the others, often in unpredicted ways, sometimes after a delay of months or years.

History is full of examples. Hanoi, 1902: the French colonial administration, overrun by rats, offered a bounty for every rat tail brought in. A few months later, the streets were full of living, tailless rats. Hunters were cutting off the tail, then releasing the animal so it could breed. Some had even started farming rats. By the time the program was abandoned, the rat population had grown. The intervention was well executed. It rewarded proof of hunting, not the disappearance of rats.

A century later, the same forces play out in our companies. A call center measured on average conversation time watches its agents hang up faster, and customers call back more often. A development team evaluated on tickets closed learns to split tickets. The system always responds to the real incentive, never to the stated intention.

Donella Meadows, who spent her life studying these dynamics, put it with rare precision:

"You cannot understand a system's behavior from its parts."

That sentence deserves a pause, because it explains most of the failures told above. Most interventions fail not because they are poorly executed, but because they act on the wrong lever. Meadows ranked levers by power: adjusting a parameter (a salary, a budget, a bonus) is the weakest lever; changing information flows (who knows what, and when) is already more powerful; changing the goal the system pursues is the most powerful of all. Reread the opening story with that grid: raising salaries was adjusting a parameter. Making the promotion system transparent would have changed the information flows. Same budget, different levers, effects that aren't remotely comparable.

What builders do differently

When you study organizations that managed to transform themselves durably, Singapore under Lee Kuan Yew, Toyota in the 1970s, ASML since its founding, you notice something consistent: their leaders weren't trying to solve problems. They were trying to build systems capable of solving problems.

Lee Kuan Yew didn't ask how to reduce corruption. He asked how to design a civil service where corruption wasn't worth the risk. When he took charge of Singapore in 1959, corruption was endemic, as it was everywhere in the region. His answer came down to three structural decisions: senior civil servant salaries aligned with the private sector, so that honesty cost nothing to those who practiced it; an anti-corruption bureau (the CPIB) reporting directly to the Prime Minister, so that no ministry could smother it; and simplified administrative procedures, because every discretionary approval is an opportunity to sell a signature. The difference with an anti-corruption campaign seems subtle. It isn't: a campaign fades when attention moves on, a well-designed institution holds itself together.

Toyota didn't ask how to reduce defects. The company designed a production system where every employee had the ability and responsibility to stop the line when they spotted an anomaly. The mechanism has a name: the andon, a cord hanging above every workstation. A worker who spots a problem pulls the cord, the line stops, and the supervisor comes to help understand, not to punish. In the short term, every stop is expensive. But every stop is treated as information about the system, and the defect is fixed at the source instead of spreading across thousands of vehicles. The result wasn't better defect detection: it was a self-reinforcing culture of continuous improvement.

ASML didn't set out to sell more machines. The Dutch company, the only one in the world producing the EUV lithography machines that the most advanced chips depend on, built an ecosystem of suppliers so interdependent that no competitor could replicate them one by one: the optics come from Zeiss, the lasers from TRUMPF, and each machine assembles more than 100,000 parts from hundreds of specialized partners. In 2012, the company went further: Intel, Samsung and TSMC, its own customers, took equity stakes to fund the development of EUV. Customers and suppliers became co-investors in the same system. The question wasn't commercial: it was architectural.

In each case, the question wasn't "how do we fix this problem?" but "what structure reliably produces the outcomes we want?"

Why this is counter-intuitive

The trouble with systems is that they're slow. A well-designed system produces its effects over years, sometimes decades. In a world that measures results by the quarter, this timescale is uncomfortable.

An example to make this tangible. Take two decisions the same executive committee could vote on the same day. The first: freeze hiring. Visible effect by the next quarter, straight in the cost line. The second: reform how managers are selected and trained. Real effect on decision quality, team engagement and retention, but measurable in two or three years, at best. The quarterly dashboard will see the first decision. It will never see the second. Yet the second is the one that will determine what the company looks like in ten years.

There is also something deeper: our organizations reward visible problem-solving. A manager who puts out a fire is immediately valued. A manager who designs a system where fires don't start is invisible, until the day their absence is felt.

Systemicists call this "fixes that fail": quick solutions create dependency, mask root causes, and make the system more fragile with each intervention. Many digital transformations look exactly like this: an accumulation of visible corrections that never touched the structure.

What this section is for

I am not a historian, philosopher, or economist. I am someone who works daily to transform complex organizations with technologies that evolve faster than the institutions designed to govern them. That work has forced me to develop one habit: looking for mechanisms behind phenomena, not just the phenomena themselves.

This is the habit I want to cultivate here.

Each article in this section will work through four questions: what problem are we trying to understand? What is the central idea? Why is that idea counter-intuitive? How can a leader use it tomorrow morning?

Topics will range from great thinkers to organizational case studies, from technological geopolitics to the decisions that built or destroyed entire institutions. The thread will always be the same: understanding systems to make better decisions.

And so this way of seeing doesn't remain a posture, I want you to leave with a reflex. Before your next important decision, take five minutes to answer four questions, in this order:

1. What symptom am I observing?
2. What structure produces this symptom?
3. What will my intervention reinforce, and what will it mask?
4. What will I look at in six months to know whether I acted on the structure or only on the signal?

This is the builder's reflex. It doesn't replace fast action when fast action is needed. It keeps you from mistaking relief for a cure.

This is not management advice. This is not technology. It is a way of seeing.

The builder's question

What decision have you made recently thinking you were fixing a problem, one that might, in eighteen months, have created another?

To go beyond reflection, a three-step exercise, in writing, twenty minutes is enough.

1. List the last three decisions you made to "fix a problem": a reorganization, a bonus, a new tool, a replacement.
2. For each one, write down two things: the symptom the decision targeted, and the structure it left intact. If the structure is hard to name, look for the incentive: who gains what when the symptom appears?
3. Pick the decision that feels most fragile and write down the indicator you will check in six months to see whether the problem returns in another form. Put a date in your calendar.

If one of the three decisions fails the second question's test, you already have the topic for your next leadership meeting.