What Change Management Looks Like When Nobody Can Follow You

Every leadership book assumes you have followers.

Kotter's eight steps, the coalition-building frameworks, the "create urgency, enlist your volunteer army" playbook. All of it assumes you're standing in front of people who have the option to follow or not. That's a reasonable assumption for most organizational change work. But it taught me almost nothing about how change actually happens in your bones, because I learned change management in a context where none of those conditions existed.

My mother had strokes. Multiple. She developed aphasia, which is a language disorder that strips a person's ability to find words, form sentences, communicate what they need. You can see the thought behind their eyes. The sentence never arrives. There is no coalition to build when you're the only person in the room who can make a decision. There is no volunteer army. There are no short-term wins to celebrate and post on a progress dashboard. Urgency isn't manufactured to drive adoption. It just exists, constant, relentless, and indifferent to your readiness.

I managed that change for years while building a career in cybersecurity. And when I finally stepped into rooms where people actually could choose to follow, I realized I had learned something that the frameworks don't teach: which parts of change leadership actually matter, and which parts are scaffolding you use when conditions are favorable.

Here is what I learned.

Urgency doesn't need to be created. It needs to be understood.

Kotter tells you to create a sense of urgency. Most CISOs interpret that as permission to wave threat intelligence like a fire alarm. Fear, uncertainty, and doubt as a change catalyst. The problem is that manufactured urgency evaporates. People calibrate to it. If everything is urgent, nothing is.

Real urgency is discovered, not manufactured. It already exists in every organization. Someone's regulatory deadline is three months out. A system that holds sensitive data on millions of people is running on hardware that the vendor stopped patching. A business line is moving to the cloud with or without security's involvement. That urgency is already there. Your job is to recognize it and connect your initiative to it honestly, not to fabricate a crisis.

When you've lived with real urgency, the manufactured kind feels hollow immediately. You stop reaching for it. You get comfortable saying "here's what's true, here's why it matters now, here's what we lose if we wait." That's a different conversation than a threat briefing designed to scare a board into approving a budget line.

The coalition is the goal, not the starting point.

The frameworks treat coalition-building as step two. You create urgency, then you go find your allies. But in practice, if you need allies before you can move, you're already in trouble. Real change leadership means being willing to move without them, building trust through action, and letting people attach to momentum you've already created.

I didn't have a coalition when my mother's health shifted and every routine had to be rebuilt. I had to make decisions, execute them, learn from the ones that didn't work, and adjust. By the time I had enough working to explain to anyone what I was doing, I had already done it. The coalition, such as it was, came because the work was credible, not because I enlisted it first.

In enterprise security, this plays out when you're trying to shift culture in agencies that have their own mandates, their own politics, their own definition of what security means to their mission. You can't wait for consensus. You move on what you can control, you make it visible, and you create something real enough that others want to be part of it. Coalition is a consequence of credibility, not a precondition for action.

Short-term wins matter, but not for the reasons the books say.

The frameworks say celebrate short-term wins to maintain momentum. That's true, but it misses something. Short-term wins matter most because they test your assumptions. They tell you whether your model of the problem is correct before you've committed the whole organization to a direction.

When I was figuring out care protocols that actually worked, the small things that succeeded told me where my instincts were calibrated correctly. The small failures told me where I was wrong before the stakes got higher. I didn't celebrate them so that I would feel motivated to continue. I studied them so I would know what was true.

Apply that to security program development. When a small piece of your initiative lands well, don't just mark it green on a dashboard. Ask why it worked. Was it because the approach was right, or because the context was favorable? That answer changes everything about what you do next.

The step Kotter underweights is the one that actually sustains change: removing yourself as the dependency.

Every step in the model is about driving change. The part nobody talks about enough is engineering conditions where the change continues without you driving it constantly.

When you're the only person holding something together, you learn fast that systems which depend entirely on your presence are fragile. The moment you step away, everything drifts. Real change is institutional. It lives in process, in expectation, in the way people make decisions when you're not in the room.

This is why governance matters more than most technical security leaders want to admit. Policies aren't bureaucracy. They're the mechanism by which your decisions outlive your tenure. Standards, documented expectations, cross-agency frameworks: these are how you stop being the single point of failure for the work you care about.

I have watched programs collapse the moment a strong leader moved on, because the leader had been the program. The work had never been transferred to the institution. Everything Kotter describes about sustaining acceleration and instituting change is really about this: stop being the hero and start being the architect.

What the frameworks give you, and what they can't.

Kotter's model is genuinely useful when you're operating in conditions where people can choose. When you have a room full of stakeholders who could go either direction, having a structured approach to change gives you repeatability and discipline. I don't dismiss it.

But the leaders who have only ever worked inside favorable conditions have a blind spot. They mistake the scaffold for the building. They think the framework is the skill, when the framework is just a description of what skilled change leadership looks like when circumstances cooperate.

The actual skill is doing it when they don't. Carrying the initiative alone until it's credible enough to attract allies. Generating urgency from honest assessment instead of manufactured fear. Treating wins as data instead of motivation. Designing for your own obsolescence.

I learned that in a context that had nothing to do with enterprise security. But I use it every single day.