Being able to say stop before it is too late

Imagine a client demonstration in three days. Everyone has been working on it for weeks. One person notices a problem. It is not directly in their scope. It may not even make the demonstration fail. But it could reveal a much more serious risk.

What should they do?

In an ideal organisation, the answer looks obvious. Report it. In a real organisation, the calculation is often more complicated.

Reporting the problem means slowing others down. Perhaps calling the demonstration into question. Becoming the bearer of bad news. Creating extra work for several colleagues. And possibly contradicting someone more senior.

Organisations rarely discover problems too late because no one had seen them. They often discover them too late because the people who had seen them had good reasons to stay silent.

We want to make that silence as irrational as possible.

Anyone can stop the line

At Cercle, anyone can flag a problem serious enough to request that an activity be stopped or arbitrated. Employee, manager, founder or software agent. And the first answer is always the same: thank you for flagging it.

The expected first reflex is not “is this really necessary?”. The rule can sound almost childish. It is in fact structural.

If flagging a problem immediately triggers a discussion about having overreacted, the next person will hesitate longer. Then they will wait until they have stronger proof. Then they may simply wait for someone else to take the risk.

A right of interruption that requires exceptional courage every time it is used is not a real safety mechanism.

The bigger the commitment, the stronger the mechanism must hold

Stopping a secondary topic is easy. The real test comes when an important client is waiting. When a lot of money is committed. When the founder has personally announced the date. When everyone sincerely wishes the problem would disappear for just three more days.

That is precisely where the rule matters.

A date announced by leadership does not become more realistic because it was announced by leadership. The founders’ commitments therefore go to arbitration exactly like everyone else’s.

We even audit this type of situation. If a team finally holds a milestone that someone seriously considered untenable, we do not settle for celebrating the delivery. We want to understand why that person did not ask for arbitration.

A system can look extraordinarily high-performing for a while simply because bad news has stopped circulating.

Fixing the incident is not enough

When a problem appears, the immediate priority is obviously to solve it. But if the same problem keeps coming back, fixing it again is no longer a sufficient answer.

We then look for whatever in the system allows the repetition:

• a poorly defined dependency;
• a missing control;
• an ambiguous procedure;
• a fragile structural decision;
• knowledge held by a single person.

An improvement only really exists once it changes something durable. A standard, a tool, an automation, a rule, a piece of documentation.

A meeting conclusion that says “we will have to be more careful next time” improves nothing. The system has stayed the same.

We do not want a culture of heroes

Companies love rescue stories. The person who stays up all night to bring the platform back. The engineer who single-handedly unblocks an impossible delivery. The salesperson who lands a signature at the last second.

These stories are sometimes genuinely admirable. But when they become repetitive, they often signal something far less admirable. A system that continually depends on exceptional people to survive is a fragile system.

We therefore want to give more value to the person who durably prevents the fire than to the one who becomes indispensable for putting it out every week.

This directly shapes how we evaluate contributions. Maintenance counts. Prevention counts. Stopping a bad direction counts. Refusing an unrealistic promise counts.

A good dashboard should not reassure

We keep a deliberately limited view of the health of the business:

• a few key economic metrics;
• the main client milestones;
• the commitments in progress;
• the open stop signals;
• the main risks.

The goal is not to obtain the greenest possible board. It is to make problems visible early enough to act.

A perfectly green board for several weeks therefore strikes us as almost suspicious. A real organisation runs into difficulties. It discovers risks. It learns. It gets things wrong. If none of that shows, you have to ask whether the system is working exceptionally well or whether bad news has simply learned to stay off the board.

For someone working at Cercle, all of this should produce a healthier environment. Saying that a date no longer holds is not a weakness. Flagging a risk is not a way of slowing the team down. Discovering you were wrong is not something to cover up.

The real organisational fault begins when we know a problem exists and prefer to maintain the appearance that everything is fine.