When You Step Away, What Breaks?

What chaos engineering taught me about leadership, control, and my habit of saving everything.

For a long time, I had a convincing explanation for why I needed to be involved in everything. Conveniently, it also fed my ego. “If I’m not there, nothing happens.” I usually said it with frustration, though I also liked being the person everyone needed. Decisions waited for me. Problems found their way onto my calendar. When something went sideways, I could step in, fix it, and play the hero.

That skill helped me get promoted and made me look productive. Eventually, my calendar filled with problems I already knew how to solve. The same escalations. The same decisions. The same meetings that somehow needed me in the room to move forward. My involvement kept solving the immediate problem, which gave everyone another reason to involve me the next time.

The Super Hero Trap

We had just landed what was probably our biggest deal to date, and the implementation was going badly. I knew the buyer personally, so their frustration came directly to me. My instinct was immediate: step in. I had a perfectly reasonable case for doing it. The relationship mattered. The stakes were high. This was one of our biggest customers. I told myself I only needed to get involved until things stabilized. I had accumulated an impressive number of situations where my ego said it could only be me step in to solve the problem.

Then two major fires erupted at the same time, and I physically couldn’t stay close to both. My preferred leadership model had finally encountered the inconvenient fact — I had to choose. That forced me to ask what the customer actually needed. We put someone else in charge who could give the account sustained attention, and they handled it better than I could have. I would have been squeezing the customer between a dozen other emergencies. They had the time to stay close to the details, build the relationship, and keep the work moving. I had spent weeks defending my involvement while delaying the decision that helped the customer most (and save my own sanity).

The dependencies I couldn’t see

Chaos engineering gave me language for what had happened. In complex distributed systems, engineers deliberately introduce controlled disruption to see how a system responds. They might remove a server, introduce a network partition, or create some other failure and then watch what happens. The experiment has boundaries. The team decides what it expects to happen, monitors the system, and defines when to stop the test. The goal is to uncover dependencies while the disruption is still controlled.

I understood that idea in software years before I recognized the same pattern in leadership. Teams accumulate hidden dependencies too. One person knows information nobody else has. One leader approves every meaningful decision. One person prepares for every meeting and drags everyone else toward an outcome. I had become several of those dependencies. As long as I kept stepping in, the system appeared to work. My involvement patched the gaps quickly enough that nobody had to examine why the gaps existed. Stepping away gave me information I could never get while standing in the middle of everything.

Sit back and observe

I started by observing what happened when I stepped away for a week. The hard part was leaving. I wanted to check messages, offer suggestions, and keep things from going off the rails. Every intervention would have contaminated the observation (it seems obvious to say, but “doing” is obviously not observing).

When I came back, plenty of work had continued without me. People had made decisions. Problems I expected to inherit had already been handled. A few things had even gone better because nobody had waited for my opinion. I had spent a lot of energy staying involved in work that had learned to function around me.

Other things had stalled, which gave me something more useful than another rescue mission: a chance to examine why. Did someone know they owned the decision? Did they have the authority or skills to execute? Had I explained the outcome clearly enough? Had I created a process that required information only I possessed? Had people learned to wait because history taught them I would eventually take over? A stalled decision became evidence about the system instead of another invitation for me to save it.

Some of the trust problem belonged to me

I kept a tight grip on one direct report’s work because I told myself I didn’t trust him. When I tried to explain exactly what he had done to lose my trust, I struggled to come up with much. I mostly wanted the reassurance of knowing what he was doing, why he was doing it, and whether I agreed with how he planned to do it. Eventually, I gave him room to run, and he surprised the hell out of me. He made decisions I would not have made, solved problems without involving me, and handled the work well. I had been judging his ability while giving him very little room to demonstrate it.

A poor result would have given us something useful to work on. We could have compared expectations, identified a skill gap, clarified ownership, or changed the support around him. Hovering gave me less information. It consumed his time and mine while preserving my belief that I needed to stay close. I still feel the urge to step in. I have gotten better at waiting long enough to learn whether the urge comes from an actual risk or from my own discomfort with losing control.

What happens after I leave

The benefits spread beyond my calendar. The customer got someone who could give them sustained attention. My direct report got enough space to prove what he could do. Other people started making decisions they previously would have handed back to me. I also gained better information about the team. Once I stopped automatically filling every gap, I could see where ownership was unclear, where someone needed coaching, where a process depended on one person, and where I had simply trained people to wait for me.

There is also a strange emotional adjustment in watching people succeed at work you used to consider yours. I could be proud of them and still notice the small sting that came from being less necessary. For years, I had partly measured my contribution by how often people needed me. Every escalation validated my role. Every dependency reinforced the idea that I mattered. I use a different test now. I want to know what keeps working when I leave the room.

Make it safe to try

When I tell leaders to “let it fail,” I usually get the appropriate facial expression from someone who thinks I have temporarily lost my mind. I mean something much more controlled. Choose work where you can afford to learn. Pick a meeting, a decision, or a piece of execution where a delay or mistake can be corrected without creating serious harm. Make the ownership explicit. Define the expected outcome. Give the person the information and authority required to act. Decide when you will check in and what conditions would justify stepping in earlier. Then leave enough space for something to happen without you.

If the work stalls, investigate before taking it back. Someone may need training. Two people may need to coordinate differently. A decision may lack a clear owner. A process may depend on information that lives in one person’s head. Sometimes you will need to intervene. When you do, fix the immediate problem and then figure out what would prevent the same dependency from pulling you back in next time. Otherwise, the rescue quietly becomes part of your job.

Sometimes you will need to intervene. When you do, fix the immediate problem and figure out what would prevent the same dependency from pulling you back in next time.

Your job is not to stay indispensable. Your job is to make your absence survivable.