15. Build Legacy, Not Dependency¶

The previous principle was about the organization depending on rescue. This one is about the organization depending on you.

For a long time, every important meeting started the same way.

"Erick, what is happening here?"

It did not matter which initiative was on the table. Regional tech, engineering, CRM, product, app, marketing, something from the CEO Office. Before any real discussion could start, the room would stop and wait for me to reconstruct the story. What the initiative meant. Who actually owned it. Where the blocker sat. Whether the urgency was real or just noise that had picked up volume on the way up.

If I was not in the room, the conversation went vague. The update came in incomplete. The decision waited until I could be looped back in.

The role had grown past its original shape. What started as a growth function had expanded into a scope that crossed almost every function in the building. That kind of expansion has one practical effect — everything routes through one person. Questions. Context. Framing. Escalation. All of it.

I had become the glue of the organization.

But glue is not always a compliment.

And if I am honest, part of me liked it.

Not the exhaustion. Not the constant escalation. But the usefulness. The fact that when the room got stuck, people looked for me. The fact that I could connect the missing context faster than anyone else. The fact that my presence made the room feel safer, clearer, more controlled.

That feeling is dangerous because it looks like service from the outside.

It is easy to tell yourself you are carrying the system because the system needs you. Sometimes that is true. But sometimes you are also protecting the version of yourself that feels valuable only when everything still has to pass through you.

That was the uncomfortable part. The dependency was not only the organization's habit. It was also something my ego could quietly benefit from.

What bad leadership usually does¶

The default move is to stay indispensable.

Almost nobody does this on purpose. Most leaders who create dependency are not trying to. They stay central because it is faster. Because they know the context better than anyone. Because being the one people turn to feels like being useful.

On the surface, it looks like leadership. The person is engaged, responsive, present in every important conversation, fast at unlocking decisions.

Underneath, the system is not learning. The knowledge is not transferring. The team is not growing into the decisions they should already own.

And there is a quieter version of this trap. Being needed feels meaningful. It feels like service. It can also be ego protection wearing the costume of service. If I am the only one who can answer the question, my position is safe.

That is ego disguised as responsibility.

When the leader eventually leaves — or gets pulled into the next priority — the system does not hold. The collapse looks sudden, but it was built quietly, one shortcut at a time.

The principle¶

Leave the system stronger than the one you walked into. Not just better results. Better thinking, better ownership, better clarity — held by people other than you.

Why it matters¶

If everything collapses when the leader leaves, that was not leadership. That was control.

Dependency feels productive in the short term. Decisions move quickly because they all route to one place. Context is consistent because it lives in one head. Nothing gets lost because the same person is in every conversation.

The cost arrives later. When that person is pulled into something else, the team slows down on basic things they should already be able to handle. When that person leaves, the institution forgets what it was doing and why. The team has been trained to ask, not to think.

The damage is not in the moment of departure. The damage was already done, every day, in the small decision to carry the context personally instead of putting it somewhere the team could reach without me.

What better leadership looks like¶

The response was not dramatic. No announcement. No transformation program.

The team started building structure into how initiatives were reviewed. Clearer owners. Visible dependencies. Risk status that lived in writing instead of in my head. A monthly rhythm. We started calling it the leadership review doc. The initiative tracker was one piece inside it. Nothing exotic. Just a place where the information could live other than in one person's memory.

The shift came quietly. In one of the review sessions, the conversation did not start with "Erick, what is happening here?" Someone pointed to the doc. They identified which initiative was at risk, traced the dependency, and the group worked out the next step.

Nobody clapped. There was no milestone moment.

I knew it was starting to work when the conversation no longer depended on my memory. It depended on the structure we had built.

But I also knew the dependency was not fully broken. People still needed me for judgment. Anything involving CEO expectations, cross-functional tension, product-tech trade-offs — those calls still routed through the same person.

The system had caught up to the tasks. The culture had not yet caught up to the judgment.

That is the honest version. The basic dependency had loosened. The deeper one had not.

The first sign of progress is not that people stop needing you completely. The first sign is that they stop needing you for the same basic things over and over again.

The tool — document the reasoning, not just the task¶

Tasks are the easy part to write down. What needs to happen, who is doing it, by when.

The harder part is the thinking behind the call. Why this direction and not the other one. What we were willing to give up. What would make us change our mind.

That is the part that usually stays in one person's head, and that is the part that the next person actually needs.

Decision Reasoning Template

Decision: What did we decide?
Why: Why did we choose this direction?
Trade-offs: What did we knowingly sacrifice or deprioritize?
Risks: What could go wrong?
Change trigger: What new information would make us revisit this decision?
Owner / next step: Who owns the follow-up?

Keep it short. A few lines per field. The point is to help the next person understand the reasoning, not just inherit the task.

This is also where legacy can quietly turn into over-documentation. Writing everything down is not the goal. Writing down what matters — ownership, judgment, reasoning, standards — is. The test is whether the team can act on it without you reconstructing the story every time.

Simple rules¶

Being needed is not the same as being effective.
If everything routes through you, you have not built a team. You have built a dependency.
The first sign of progress is not that people stop needing you. The first sign is that they stop needing you for the same basic things over and over again.
Move context out of your head and into a place the team can reach without you.
Document the reasoning, not just the task.
Be honest about where the dependency still exists. Naming it is the first step to closing it.
Build legacy in the daily work, not in the exit.

Reflection questions¶

What questions does my team only ask me, and why?
If I were pulled away for a month, which decisions would stall?
Where does judgment in my team still depend on my memory instead of a shared structure?
Am I documenting the task or the reasoning behind it?
Is the system I am building strong enough to run without me — or only strong enough to look organized while I am still standing here?
What part of my value to this team would I be afraid to give away, and what does that fear tell me?

Reminder¶

The point is not to become irreplaceable. The point is to make the system stronger.

A leader who is needed for every decision has built a bottleneck and called it leadership.

What the organization can actually keep is clearer thinking, clearer ownership, and clearer reasoning — held by people other than you.

That is the standard.