I've been leading engineering teams in startups and scaleups for over 16 years, and if there is one lesson that repeats in every company —Farfetch, Creditas, RD Station, Reby, Enterticket, Venturest— it is this: the way you introduce a change matters just as much as the change itself.
There are two schools of thought when managing organizational change. The disruptive one, which breaks everything at once and expects the team to adapt by force. And the evolutionary one —kaizen— which moves in small, measurable, and reversible steps. After years of seeing both in action, I have a clear stance: kaizen almost always wins, and not out of conservatism. It's because of how human learning actually works within an organization.
The core problem: cause and effect
Disruptive change often comes packaged as "transformation." A new structure, a new process, a new tool are announced all at once. The problem isn't ambition: it's that it breaks the chain of cause and effect.
When you change ten things at once, no one —not the team, nor you as a leader— can isolate which change produced which result. If something improves, you don't know why. If something gets worse, you don't either. And without that traceability, collective learning becomes almost impossible. The team doesn't internalize the "why", they only memorize the "what": a new way of doing things imposed on them that they will defend or abandon depending on the tide, not on evidence.
Kaizen addresses this problem right from the design phase. A small change, applied to a concrete problem, makes it possible to observe the effect clearly. The team sees the symptom, understands the cause, tests a targeted solution, and verifies whether it worked. That sequence —symptom, cause, hypothesis, result— is the minimal unit of organizational learning. And it is precisely what disruptive change eliminates.
The hidden cost of disruptive change: stress without purpose
There is a cost of disruptive change that is rarely measured in management reports: the stress generated when people don't understand why things are changing. It is not just temporary discomfort. It is the constant feeling of reacting to top-down decisions without a clear narrative connecting them to a real problem they could observe themselves.
This stress is not collateral noise, it's a signal. When a team cannot explain why something was resolved in a specific way, they also cannot defend, improve, or replicate it in the future. It becomes just another arbitrary rule, and arbitrary rules break at the first opportunity.
I have seen this firsthand in technical restructurings: architectures redesigned all at once, decision-making processes replaced overnight, tools imposed without transition. The result is almost never what was intended. Apparent speed is gained during the announcement, only to be lost months later to silent resistance, turnover, and rework.
Why kaizen builds understanding, not just results
The real advantage of the evolutionary approach is not that it's "gentler." It's that it builds genuine understanding within the team about why things work the way they do.
When you iterate in small steps:
- The problem becomes visible before the solution. The team participates in diagnosis, not just execution.
- Each iteration is a hypothesis that gets validated or discarded. If something doesn't work, it is reverted at low cost and without drama.
- The "why" remains documented in team experience, not in a document no one reads again.
- Trust is built on accumulated evidence, not on the authority of whoever decided the change.
This doesn't mean moving slow for the sake of moving slow. Well-executed kaizen can move fast, because every step validates ground before taking the next one. What it avoids is the worst-case scenario: moving quickly in the wrong direction and realizing it too late, without knowing which of the ten simultaneous changes was responsible.
When disruption actually makes sense
It would be dishonest to say the evolutionary approach always applies. There are situations —an existential crisis of the company, an imminent regulatory change, a technical migration with a hard deadline— where the time to iterate simply does not exist. In those cases, disruption is a legitimate tool, but even then, the difference between a good and a bad executor lies in how much effort is invested in reconstructing the narrative of cause and effect after the fact, so that the team isn't left only with the scar of the change, but also with the learning.
The question I ask myself before any change
Before introducing a change in a team or organization, I ask myself a simple question: will every person on the team be able to explain, in three months, why things are done this way now?
If the answer is yes, I'm probably facing a well-designed change, whether big or small. If the answer is no —if the change relies on people simply "trusting the process" without understanding it— then no matter how urgent it seems: the real cost is being paid upfront, in the form of stress, disconnection, and an organization that executes without understanding.
Kaizen is not slow. It is traceable. And in change management, traceability between cause and effect is the only thing that turns change into real learning.
