Early in my career, long before I had heard of ITIL or any formal change framework, I wrote a script and deleted every cron job (task scheduled to run automatically at a set time or interval on Unix and Linux systems) in the environment. One mistyped command. One wrong option on a line I thought I understood. Ten engineers spent the better part of a day restoring what I had wiped out in a second.
That day taught me more than any certification did later. The four eyes principle, the rollback plan, the approval before rollout, all the discipline I would spend years learning to apply, made immediate sense to me after that afternoon. I had felt the cost of not having them.
You can read about change control in a manual and agree with its principles. It lands differently when you are the reason ten people lost their morning.
That was change 25 years ago, at least for me. Chaotic, fast, and unforgiving. The guardrails existed somewhere, but I had not yet learned why they mattered. Most of my early lessons came the same way, by breaking something and understanding, too late, the reason the rule was there.
How culture decides the pace of change
Then I started working across continents, and change stopped being only a technical discipline. It became a cultural one.
I have led change at both extremes. In some working cultures, the approach is close to fearless. People take the risk, push the change, and fix it if it breaks. Sometimes the risk is not even calculated. They just move. And here is the part that surprised me early on: in those environments, this is not seen as reckless. It is seen as normal, even admired. It is the closest thing I have found to what we now call a culture where learning is expected and mistakes are tolerated.
At the other extreme sits the highly regulated middle of Europe. Here every change is checked, checked again, and checked a third time. Rollback plans come in multiple layers, and each one needs approval from every technical leader in the building before anything goes live. Nothing moves until everyone has signed.
For years I assumed one of these had to be right and the other wrong. I no longer believe that. Neither is good or bad. The adventurous culture ships fast and learns fast, and it also breaks things it did not need to break. The regulated culture almost never suffers an avoidable failure, and it also moves slowly enough that opportunities pass it by. The only real question is what pace and agility your business actually needs. A payments platform and an early-stage product do not need the same relationship with risk. Matching the change culture to the business is the judgment, not picking a side.
The third lesson took me longest to understand, and it sits underneath the other two.
Change is done by people
Change is done by people, and people are the part most leaders underestimate.
The cron job disaster was not really a technology failure. It was a people failure with a technical face. There was no second set of eyes, no safety net, because the environment trusted individuals without giving them guardrails. The fix was never about being more careful. It was about building a system where a person could make a mistake without taking down the environment. That protects the people as much as the systems.
The cultural extremes are about people too. The adventurous engineer and the cautious European technical lead are not different in skill. They relate to risk, failure, and authority differently, because the cultures around them taught them to. A leader who walks into either environment expecting the other one will fail, not because the plan is wrong, but because the people were read wrong. I have watched capable leaders lose a room simply by pushing a pace the culture was not built for, or by slowing down a team that needed to move.
After 25 years, here is the thing I see leaders get wrong most often. They treat change as a process problem. They buy the framework, install the tooling, and assume discipline will follow. The framework matters. I learned that the hard way with the cron jobs.
The framework is the easy part. The hard part is judgment
how much process this business needs, how this culture relates to risk, and how to bring these specific people through a change without losing their trust. That judgment is the actual skill, and no certification hands it to you. You build it by leading change in enough places, breaking enough things, and paying attention to why each one broke.
The series I built from this
That is exactly what I have spent 25 years learning, and it is what I have built my next series around.
On 25 August, I am launching Digital Transformation for Leaders, a nine-episode video series that works as a course for leaders. It takes you through the nine steps I developed for leading digital transformation successfully, moving from insight to strategy to execution. The series treats transformation as a leadership challenge rather than a technology trend. It covers recognizing the pressure that forces change, choosing where to focus, testing your business model, redesigning how work actually happens, and leading the people through it. Each episode gives you one leadership challenge, one practical idea, and one tool you can use. It is built for executives, CIOs, senior technology leaders, and anyone who wants to lead transformation with clarity and discipline rather than hype.
The lesson under all of it is the one this article started with. Change is not a script you run. It is a thing you lead, through real people, in a real culture, at the pace your business can actually carry. Get that judgment right and the frameworks do their job. Get it wrong and no amount of process will save you.
I write more about these ideas in my book Life in the Digital Bubble, and the full series will be at tamerbadawy.com from 25 August.