Have you built a team? Or have you made yourself indispensable?

There is a question almost no leader asks early enough, and that almost everyone is forced to confront too late: if you stopped working tomorrow, what would survive? The answer says everything about what you have actually built.

A team is not a group of people who depend on you. A team is a system of people who function together — with or without your direct presence. The difference seems subtle until you try to take a week off and discover that the phone does not stop ringing.

Almost every leader I know has built, over time, not a team but a network of personal dependencies. Every person on the team has a direct line to the leader. The leader is the central node of every piece of information, every decision, every problem. The system works — as long as the leader works.

This is not leadership. It is a bottleneck with a good personal brand.

The absent week test

Want to know exactly where you stand? Do this mental test — or, if you are brave enough, try it in reality.

Take a week. No replies to team messages, no operational calls, no intervention on day-to-day problems. Only real emergencies, not perceived urgencies.

At the end of the week, count three things:

• How many decisions were made without you
• How many problems were solved without you
• How many people kept working as if you were there

If the number is high, you have a system. If the number is low, you have a dependency.

There is no objectively right or wrong answer — it depends on how long you have had to build. But it is the most honest snapshot of where you are. And knowing where you are is the first step towards going where you want.

The interesting thing is that almost every leader who does this test is surprised. Not always because the result is worse than they thought. Sometimes because it is better. The system already has more autonomy than the leader realises — because the leader is so used to intervening that they do not notice when things resolve themselves.

The three types of dependency to recognise

Not all dependencies have the same origin. Before building the system that resolves them, it is worth understanding which one you are feeding.

Informational dependency.
People come to you because you are the only one who knows where to find things. Procedures are in your head. Materials are scattered or only accessible to you. New members do not know where to look and so they ask. This is the easiest dependency to break: it dissolves by building a single source of truth — documented, organised, accessible to everyone.

Decision-making dependency.
People come to you because they do not know how far their autonomy extends. Not because they are incapable — because it has never been defined what they can decide on their own and what requires your validation. Every time you make a decision that someone else could have made, you are reinforcing this dependency. It breaks by explicitly defining autonomy levels for every role and every type of situation.

Emotional dependency.
The most subtle and most difficult to recognise — also because we often feed it consciously. People come to you not for information or decisions, but for reassurance. To be told they are doing well, that they are on the right track, that the leader believes in them. This need is real and legitimate. The problem is when you are the only one who meets it, and every team member needs this reassurance directly from you every time they get stuck.

The solution is not to eliminate emotional support — it is to distribute it in the system. Collective celebrations, public recognition between peers, a culture of mutual feedback. When the team learns to support itself, your emotional energy concentrates where it truly matters: difficult conversations, crisis moments, strategic choices.

Documentation is the work nobody wants to do. And it is the work that makes the difference.

If there is a single activity that separates leaders who scale from those who stay stuck, it is documenting the method.

I am not talking about three-hundred-page company manuals that nobody reads. I am talking about something much simpler and much more useful: making visible how you do what you do, so that someone else can do it without having to ask you.

This means:

• A five-minute video showing how you handle a first conversation with a potential team member
• A document with answers to the ten questions you receive most often
• A checklist of the steps to take in the first week of activity
• A collection of messages that work, with a note on why they work

Nothing sophisticated. Nothing that requires weeks of work. But every piece of documentation you create is an hour of explanations you will never have to give again. Every process you make explicit is a decision the team can make without you.

The problem is that documenting feels less urgent than answering messages, solving immediate problems, supporting whoever needs support right now. And in absolute terms it is right: it is not urgent. But it is important. And that distinction — between urgent and important — decides whether in a year you will have more freedom or less.

With Squad.Win, documentation becomes part of the system rather than a separate project. The materials you upload, the videos you record, the paths you build for new members — all of this lives in one place, accessible to all team members, updatable as the method evolves. It is not a static archive. It is the leader's living method, always available.

The second level is where you truly win

There is a concept that is often cited in network marketing but rarely applied with the depth it deserves: the second level.

I do not mean the second level in the technical sense of the compensation structure. I mean something more important: the moment when your direct collaborators start building their own teams using the same method you use.

This is the true multiplier. Not because it brings you more volume — but because it creates structural autonomy. When your first level knows how to do onboarding, knows how to support their own new members, knows how to solve recurring problems — they stop bringing those problems to you. And you can focus your energy on what only you can do: vision, strategy, the growth of the overall structure.

To get here, though, transferring the method is not enough. You also have to transfer the mindset with which the method is maintained. Because a system works as long as someone takes care of it. And that someone cannot always be you.

The most effective way to transfer this mindset is to show it in action. Do not explain to your team members how important it is to document — show them how you do it. Do not tell them they need to build systems — involve them in building the team's system, so they understand from the inside how it works and why it is worth investing in.

When letting go of control is a strategic choice

The hardest part of building a system that works without you is psychological, not technical.

Allowing someone to do something differently from how you would do it — and not intervening — is counterintuitive for anyone who has built something from scratch. You have standards. You have a way that works. You have proof that your approach produces results.

The problem is that applying your standards to everything and everyone does not scale. Not because your standards are wrong — but because they require your presence to be maintained, and your presence is finite.

The mathematics of control is this: if you control everything, your team can grow exactly as much as you can control. If you build a system that maintains standards without your direct supervision, your team can grow without limit.

Letting go of control does not mean lowering standards. It means transferring them into the system instead of keeping them in your head.

The first time you let something go — and it goes wrong — is the most difficult moment. The temptation to take back control is very strong. Resist. Analyse what went wrong. Fix the system. Try again.

Every mistake the system makes without you is a mistake that teaches you how to improve the system. Every mistake you make in place of the system is a missed opportunity to grow something bigger than yourself.

The team that works without you is not the final result. It is the starting point for building something you could never have built alone.