You delegated the project months ago.

Someone else owns the roadmap. Your Team Leads run the daily work. You are no longer assigning tasks or checking every pull request.

Still, the important decisions pause until you join…

Questions arrive with a familiar ending: “Can you take a quick look?” Documents come to you for a final review. Meetings can happen without you, but they often end with, “Let’s confirm with you first.” When a deadline starts slipping, you somehow become part of the execution again.

Nothing looks seriously broken. The work moves. Your people are capable. You may even have delegated far more than you did a year ago.

Yet you are still part of the machinery required to keep everything moving.

This kind of dependency can be difficult to see because it rarely looks like control. It usually looks like responsibility, helpfulness and high standards.

At Engineering Manager level, one team waits for your judgment. At Director level, several managers bring their hardest decisions to you. At VP or founder level, priorities, cross-functional conflicts and strategic bets keep travelling upward.

The shape changes as your scope grows. The pattern stays remarkably similar.

The FITS framework

FITS is the framework I use to help tech founders and senior engineering leaders get out of the dependency loop:

• F: Find the Dependency. Map where and why work keeps returning to you.

• I: Interrupt the Pattern. Change the reactions and routines that keep reinforcing it.

• T: Transfer Ownership. Move decisions and responsibilities to the right level, with clear boundaries and accountability.

• S: Stay Out of the Loop. Maintain visibility and standards without taking ownership back under pressure.

This first phase is deliberately diagnostic.

Before changing your calendar, cancelling meetings or delegating more work, you need to understand where the dependency actually lives. Otherwise, you can easily move the same loop into a different meeting, tool or management layer.

What counts as dependency?

Your role will always contain decisions that genuinely belong to you. Organization design, budgets, leadership appointments and certain high-stakes strategic choices should not be pushed down simply to make your calendar lighter.

Temporary dependency can also be healthy. A new manager may need more context. Someone taking responsibility for an unfamiliar domain may need short feedback loops while developing judgment.

The problem begins when decisions, responsibilities or problems repeatedly return to you even though someone else should be learning to own them.

A useful test is:

Where does the work stop when you stop?

Imagine that you become unavailable for two weeks without time to prepare everyone first.

What decisions would wait? Which meetings would lose their purpose? Who would become uncertain? Which stakeholder relationships would immediately require a replacement version of you?

Those answers reveal more than an org chart ever will.

Step 1: Map where the dependency lives

When I work through this phase with a leader, we do not start with a general question such as, “What should you delegate?” That usually produces a list of tasks the leader already knows about.

We examine what actually happened during the previous couple of weeks.

We look at the calendar, important decisions, Slack conversations, reviews, escalations and moments when the leader unexpectedly re-entered the work. We are looking for repeated movement toward the leader.

Dependency commonly hides in several places.

Decisions

• Which decisions repeatedly wait for your opinion or approval?

• What can your managers decide in theory but rarely decide without checking with you?

• Where have you said, “You own this,” while remaining the real decision-maker?

Problems and escalations

• Who brings you problems without a recommendation?

• Which risks are escalated because they require your authority?

• Which ones are escalated because your involvement makes everyone feel safer?

Reviews and quality control

• What still needs your final check?

• Where do you regularly rewrite, correct or improve work after delegating it?

• Which standards live mainly in your head?

Meetings and communication

• Which recurring meetings would become unclear without you?

• Where are you translating between teams or stakeholders who should communicate directly?

• Which conversations do you attend mainly because people make better decisions when you are present?

Confidence

• Where does the team already have enough knowledge, but still seeks your reassurance?

• Which managers can make the decision but want you to share the emotional risk?

• When does “keeping you informed” quietly become asking for permission?

The last category is easy to miss. A person may technically own the decision while depending on you for the confidence to make it.

Once we have the examples, we sort them into three groups:

1. Only I should own this. The decision belongs to the leader’s role.

2. They could own this with better context, capability or boundaries. The dependency is temporary and can be developed.

3. They should already own this. The leader’s continued involvement is maintaining a loop that should have ended.

That distinction protects us from two bad conclusions: that every escalation is a failure, or that every problem should be pushed down.

The goal is to put ownership at the right level.

Step 2: See how the loop is reinforced

Finding a dependency requires more than identifying what the team does. We also reconstruct what the leader does next.

Consider a common sequence.

A Team Lead sends a message about a risky decision. The context is incomplete and the recommendation is vague. You see the consequences quickly, ask several questions and propose a direction. The Lead leaves with clarity. Work continues and a potential delay is avoided.

Your intervention worked.

It also taught everyone something.

The Team Lead learned that uncertainty can be resolved by bringing the decision to you. You learned that stepping in creates speed and relief. The next uncertain decision is even more likely to follow the same route.

This is why dependency can grow between capable, well-intentioned people. Both sides receive an immediate benefit:

• The team gets speed, certainty and shared risk.

• The leader gets control, usefulness and relief.

The long-term costs remain hidden because the short-term reward arrives first.

To make this visible, we take one real situation and map the full sequence:

1. Trigger: What happened immediately before you stepped in?

2. Interpretation: What did you tell yourself the situation meant?

3. Pressure: What risk, discomfort or emotion appeared?

4. Response: What did you do?

5. Immediate result: What became easier or faster?

6. Team learning: What did your response teach people to do next time?

7. Repetition: How did the same pattern return?

The leader may enter through different roles.

The Rescuer sees someone struggling and removes the difficulty.

The Expert sees the answer and finds it wasteful to watch others take longer.

The Quality Protector anticipates rework, client dissatisfaction or reputational damage.

The Responsible Leader believes that remaining accountable means remaining involved.

None of these roles begins with bad intent. They often helped the leader become successful. The difficulty appears when a useful strength becomes the default response to every uncertain situation.

During Find the Dependency, we observe this pattern without trying to change it yet. The next phase, Interrupt the Pattern, deals with the moment in which the leader feels pulled back in.

Step 3: Calculate what the dependency costs

Leaders usually notice the personal cost first: too many meetings, constant context switching and very little uninterrupted time.

That matters, but the organizational cost is larger.

The team borrows your judgment instead of developing its own

Every answer can solve the current problem. Repeated answers reduce the number of opportunities people have to form a recommendation, weigh trade-offs and live with a decision.

Your management layer becomes thinner than it looks

You may have Team Leads and Engineering Managers reporting to you, but their authority stays limited if the difficult decisions continue travelling upward. The structure appears distributed while judgment remains centralized.

Decisions become slower as the organization grows

Your involvement may create speed for one team. Across several teams, the same involvement creates a queue. People learn to wait for access to the person with the most context.

Strategic work keeps losing to operational certainty

Roadmap thinking, modernization, organizational design and stakeholder alignment rarely create the same urgency as a problem happening today. The dependency loop fills the calendar with work that feels immediately useful and leaves the future for whatever time remains.

The organization becomes fragile around your availability

Time off requires preparation. Slack stays within reach. A promotion creates anxiety because nobody is ready to absorb what you still carry.

We therefore measure the cost across several dimensions:

• hours and recurring meetings;

• delayed decisions and approvals;

• rework and repeated reviews;

• team confidence and judgment;

• strategic work that keeps moving;

• energy and attention;

• what happens during the leader’s absence.

Step 4: Choose the first dependency to work on

Once leaders see the map, they often want to fix everything at once. That creates another large transformation project and makes it difficult to learn what actually changes the pattern.

Instead, we choose one or two dependencies with enough repetition to observe and enough importance to matter.

A good starting point usually has four qualities:

• It happens frequently.

• Someone else should reasonably be able to own it.

• The current loop has a visible cost.

• Changing it does not create an unacceptable business risk.

For one leader, that may be a weekly delivery meeting that still depends on their presence. For another, it may be architectural decisions that senior engineers bring up without a recommendation. At a higher level, it may be managers escalating stakeholder conflicts they have enough authority to resolve.

The output of this phase is concrete:

• a map of where work and decisions return to the leader;

• a clear view of how the leader’s own response reinforces the pattern;

• the cost of maintaining it;

• one or two priority loops;

• a baseline against which progress can be measured.

Only then do we begin changing behavior.

A short dependency audit

You can start this process without designing a new delegation system.

Review your previous ten working days and write down every moment when work unexpectedly moved back toward you. Include decisions, approvals, reviews, meetings, questions and escalations.

For each one, answer:

1. What did the person bring to me?

2. What did they explicitly ask for?

3. What did they actually need: authority, context, skill, confidence or shared risk?

4. What did I do?

5. Where did I add value that only I could add?

6. What did I take over that they could have owned?

7. What did my response make more likely next time?

Then ask the uncomfortable question:

If this dependency disappeared, what would I lose along with it?

Perhaps you would lose a sense of control. Perhaps you would feel less technically valuable. Perhaps you would have to watch someone make a decision differently from you. Perhaps you would lose the immediate satisfaction of being the person who can resolve the problem.

Finding that answer does not make you a bad leader. It explains why a rational intention to delegate often loses against a five-second impulse to help.

What comes next

Seeing the dependency does not automatically stop it.

You can understand the entire loop on Monday and repeat it on Tuesday when a deadline slips, a client escalates or a Team Lead makes an uncertain recommendation.

The second part of FITS focuses on that moment: the trigger, the pressure and the habitual response that pulls you back into the work.

That is where we begin to Interrupt the Pattern.

I work 1:1 with tech founders and senior engineering leaders who want to build stronger ownership without losing visibility or lowering their standards.

In one coaching engagement, a leader removed three recurring meetings, reclaimed more than six hours a week and created space for roadmap and modernization work. The change began by identifying what still depended on him before changing his calendar or delegating more tasks.

If decisions, escalations and responsibilities keep finding their way back to you, reply with LOOP. We can identify the first dependency worth breaking.

Think about the last time you started a new job.

You probably got a job description, some expectations from your manager, a bunch of meetings on your calendar, projects you were supposed to contribute to, and problems that somehow belonged to your role.

And then you started working.

Trying to keep up with everything.

Doing your best in every meeting. Responding to every message. Staying on top of every project. Helping whenever someone needed you.

At some point, there was more work than you could comfortably fit into your day.

So you started looking for ways to become more productive.

But there is one question we almost never ask:

Who told us we had to do all of this in the first place?

Seriously.

Did your manager explicitly tell you that all of these things deserve your time and maximum effort?

Or did you just assume they do?

Because I think we make one huge assumption when we start a job:

If something falls within our responsibilities, we should probably do it. And do it well.

And I’m not sure anyone ever asked us to.

The invisible contract we create ourselves

The interesting part is that most jobs are far less defined than we pretend they are.

Sure, you have a job description.
Maybe your manager gives you a few goals.
You know roughly what you’re responsible for.

But nobody tells you:

This deserves 40% of your attention.
This one only needs 10%.
For this, good enough is perfectly fine.
You should delegate this one.

And honestly, nobody really cares about that last one.

There is a huge amount of ambiguity.

And we need to fill that ambiguity somehow.

Especially when we’re new.

We don’t yet know what really matters. We don’t know what our manager actually values. We don’t know which expectations are real and which ones simply exist because they’ve always been there.

But we do want to prove ourselves.
We want to be seen as reliable, capable and proactive.

So when we’re unsure whether something deserves our attention, what do we do?
We usually include it.

When we’re unsure how much effort something deserves?
We give it more.

When someone asks for our help and we’re not sure whether we should get involved?
We get involved.

Psychologically, this makes a lot of sense.

When expectations are ambiguous, doing too much feels safer than doing too little. Especially for conscientious people who care about doing a good job.

Nobody wants to hear three months into a new role:

“Why weren’t you doing this?”

So we protect ourselves by doing more.

And without realizing it, we create an invisible contract with our company.

A contract nobody actually asked us to sign:

Everything that could reasonably be considered my responsibility is something I should take care of.

And once we start operating that way, something interesting happens.

People start noticing.

The trap works… at first

And the dangerous thing is that this approach actually works.

At least in the beginning.

You respond quickly.
You show up prepared.

When someone needs help, you’re there.
When your team gets stuck, you jump in.
When a project starts slipping, you take a bit more ownership.

People quickly learn that they can rely on you.

Your manager sees someone proactive.
Your colleagues see someone helpful.
Your team sees someone who can get things moving.

And you see results.

So naturally, you conclude:

This is what being good at my job looks like.

But something else is happening at the same time.

Every time you solve a problem, you make it slightly more likely that the next similar problem will come to you.

Every time you make a decision for someone, you make it easier for them to ask you for the next one.

Every time you say yes to another responsibility, it quietly becomes part of what people expect from you.

Nobody is trying to overload you.

They’re simply adapting to the way you work.

And because you’re still managing to keep everything together, there is very little reason for anyone to question it.

Including you!

So the reward for being reliable is often...

more things that rely on you.

And this can continue for quite a while.

Until eventually, the amount of work around you starts growing faster than your ability to handle it.

But your cognitive capacity doesn’t scale with your workload

And here we hit a very simple constraint.

Your responsibilities can keep growing.
Your day can’t.

You still have roughly the same eight or nine hours.

More projects means more context to hold.
More people relying on you means more decisions.
More meetings mean less uninterrupted time to think.
More messages mean more switching between completely different problems.

So we try to compensate.

We become faster.
We answer messages during meetings.
We skim documents instead of reading them properly.
We squeeze decisions into the five minutes before the next call.

We jump from a people problem, to a technical discussion, to a budget question, to a Slack notification, and somehow expect our brain to perform equally well every time.

But it doesn’t work that way.

Switching between tasks has a cognitive cost. Part of our attention stays attached to what we were doing before, even after we’ve moved to something else.

And as the number of things competing for our attention grows, the quality of that attention naturally drops.

At first, it’s difficult to notice.

You don’t suddenly become bad at your job.

You become slightly less thoughtful.
A little more reactive.

You miss a detail you normally wouldn’t.

You give someone a quick answer instead of asking the question that would help them figure it out themselves.

You make a decent decision instead of taking the time to make a great one.

And that’s the irony.

We take on more work because we want to be better at our job.

But eventually, the amount of work we carry starts making us worse at it.

Maybe the solution was never to figure out how to handle more.
Maybe we should have asked a different question much earlier.

The question we should have asked at the beginning

Instead of asking:

“How can I fit all of this into my day?”

Maybe we should ask:

“Why is all of this in my day in the first place?”

Not every responsibility deserves the same amount of you.

There are probably a few areas where your involvement makes a huge difference.

A decision only you can make.
A person who needs your coaching.
A problem where your experience can save the team weeks of going in the wrong direction.
A strategic topic where one hour of thinking might be worth more than ten hours of execution somewhere else.

And then there are things you do simply because you can.

Meetings where your presence is useful, but not necessary.
Decisions someone else could make.
Projects you keep following because you’ve always followed them.
Problems you could help someone solve, but perhaps shouldn’t.

What if, instead of accepting all of these things as your work, you actually allocated yourself?

Maybe one area deserves 40% of your attention.
Another deserves 30%.
A few things deserve 10%.
And some deserve none.

The exact percentages don’t matter.
The decision does.

Because your time and attention are limited resources.

And once you start looking at your work this way, delegation becomes something different too.

It’s not just a way to get tasks off your plate when you’re overwhelmed.
It’s a deliberate decision about where you should and shouldn’t be needed.

Some things can be delegated today.

For others, you might need to coach someone for the next three months until they can own them.

And some things should probably stay with you.

But at least now that’s a choice.

Not an assumption.

Doing less isn’t laziness. It’s leadership.

This is where I think we often get leadership wrong.

We still measure our contribution by how much we personally do.

How many problems we solve.
How many decisions we make.
How many projects we are involved in.
How busy our calendar looks.

But as a leader, your job isn’t to maximize your own output.
It’s to maximize the impact of the team and the system around you.

And those are very different things.

Sometimes the highest-impact thing you can do is get deeply involved.
Sometimes it’s making the difficult decision nobody else can make.
Sometimes it’s spending three hours thinking about a problem instead of producing anything visible.
And sometimes it’s deliberately staying out of something you could easily solve yourself.

That last one is particularly difficult.

Because doing something yourself often feels productive immediately.
Coaching someone else to own it can feel slower.

Not joining a discussion can feel like you’re not contributing.
Having an empty hour in your calendar can even feel wrong when everyone around you looks busy.

But perhaps that’s exactly the point.

The goal isn’t to fill your capacity.
The goal is to use it where it creates the most value.

A good leader shouldn’t only ask:

“What should I do?”

They should constantly ask:

“What should stop depending on me?”

Because every responsibility you successfully move away from yourself creates capacity for something more important.

And sometimes, the best evidence that you’re doing your job well isn’t that you’re doing more.

It’s that fewer things need you in order to work.

Maybe nobody is asking this much from you

So maybe the pressure we feel at work isn’t always coming from our manager, our company, or the role itself.

Maybe some of it comes from a contract we wrote ourselves.

We assumed that more responsibility means more value.

That being busy means being needed.
That being needed means we’re doing a good job.

And then we spent years trying to become more productive so we could keep that contract alive.

But maybe nobody is asking you to carry all of this.

Maybe your manager doesn’t expect you to attend every meeting.
Maybe your team doesn’t need you in every decision.
Maybe some things can be done at 70%.
Maybe some can be owned by someone else.
And maybe some don’t need to be done at all.

The point isn’t to work less for the sake of working less.

It’s to stop treating your capacity as something that should always be full.

Because if you choose carefully where you’re actually needed, you might create more impact while carrying much less.

And yes, you might even have twenty minutes for a game of foosball with a colleague.

Or lunch with your family when you’re working remotely.

Without feeling guilty about it.

Because perhaps the goal was never to do as much work as you possibly could.

It was to make sure the work that actually needs you gets the best of you.

And if you’re reading this thinking, “Yeah, but I’ve already made myself responsible for too many things. How do I actually get out of them now?”… that’s a different problem.

And honestly, it’s much harder than simply deciding to do less.

That’s exactly what I work on with founders and engineering leaders in my coaching. So if you’re somewhere in that situation, just reply and tell me what’s going on.

We can take it from there.

A deadline is getting close and the team is falling behind.

You join a few meetings, make a couple of decisions and help move things forward. The project gets back on track and everyone feels relieved.

The next time something similar happens, people involve you a little earlier. It makes sense. Your involvement worked the first time.

After a while, difficult decisions regularly find their way to you. People ask for your opinion before committing to an idea. You attend meetings just in case the team needs context or someone has to unblock the discussion.

None of this looks particularly problematic.

You are helping the team deliver. You are protecting the quality of the work. You are doing what a responsible leader is expected to do.

The consequences only become visible later.

Your calendar is full. Strategic work keeps getting postponed. People formally own projects, but important decisions still wait for you. When you finally try to step away, progress slows down or the quality drops, confirming your suspicion that the team is not ready yet.

This is how the leadership dependency loop is created.

It rarely comes from one conscious decision to control everything. It develops through hundreds of small interventions that solve an immediate problem while quietly teaching the team to rely on the leader.

The team gets faster answers and less exposure to risk. The leader gets more certainty that the outcome will be protected. Both sides have a reason to maintain the arrangement, even when neither is satisfied with it.

Leaving the loop is therefore more complicated than delegating additional tasks or removing a few meetings from your calendar.

You can reduce your involvement for weeks and still return to the old pattern as soon as a critical deadline approaches, an executive asks a difficult question or an important project starts drifting.

That moment tells you whether the dependency has actually changed.

To understand how to leave the loop, we first need to understand the different ways leaders enter it.

Four Ways Leaders Enter the Loop

Dependency can develop through different leadership habits.

Some leaders enter the loop by solving problems. Others enter it by protecting quality, sharing expertise or carrying too much responsibility.

The result often looks similar, but the reason behind it matters. You cannot change the pattern properly if you do not understand what keeps drawing you into it.

1. The Rescuer

A project is in trouble and the leader steps in.

They reorganize the work, resolve a disagreement or take over a difficult stakeholder conversation. The intervention works, which makes stepping in feel like the responsible choice the next time pressure appears.

Eventually, the team starts escalating problems earlier. There is little reason to struggle with something for hours when the leader can resolve it in twenty minutes.

The leader may complain that people do not take enough ownership, while the team has learned from experience that ownership ends when the situation becomes difficult.

2. The Expert

This pattern is common among leaders who were promoted because they were excellent at the work their team now performs.

They have more context, recognize risks earlier and can often reach a good decision faster than the people around them. Sharing that knowledge seems useful, so they continue contributing to technical discussions, reviewing decisions and suggesting solutions.

The team gradually stops developing its own judgment.

People still do the work, but they look to the leader to confirm that they are heading in the right direction. The leader remains the most knowledgeable person in the room partly because every important question continues to pass through them.

3. The Quality Protector

Some leaders are comfortable delegating tasks, but struggle to accept an outcome they would have approached differently.

They ask more questions, request another revision or add one final improvement before something is considered finished. Their feedback is usually valid. Each individual correction may genuinely improve the result.

The dependency develops when people begin optimizing for the leader’s approval instead of making and defending their own decisions.

Ownership remains limited because the team knows that the final standard is still defined inside the leader’s head.

4. The Responsibility Carrier

This leader believes they will ultimately be held accountable for everything the team does.

When a deadline is missed, they feel they should have noticed the risk earlier. When someone makes a poor decision, they question whether they provided enough guidance. When senior leadership asks for reassurance, they personally verify the details before answering.

They may delegate the work, but they continue carrying the mental responsibility for every possible outcome.

That responsibility keeps pulling them back into updates, reviews and meetings. Being informed never feels sufficient. To feel confident, they need to be involved.

These patterns often overlap.

An expert can become a rescuer when a deadline approaches. A quality protector can carry too much responsibility because they expect to answer for every mistake. The exact combination matters less than recognizing the exchange that keeps the loop in place.

Every intervention gives the team something useful in the moment. It also gives the leader something, which is where the psychological side of dependency begins.

Why Being Needed Is Difficult to Give Up

It is easy to see what the team receives from the dependency loop.

They get quick answers, protection from mistakes and access to someone with more experience. Difficult decisions feel safer when a senior leader confirms them. Under pressure, involving the leader can also reduce the personal risk of being wrong.

The leader receives something too.

Solving a problem creates an immediate sense of progress. Joining a struggling project restores a feeling of control. Being asked for advice confirms that your experience is valuable and that your role matters.

Psychologists Edward Deci and Richard Ryan describe competence as one of three basic psychological needs, alongside autonomy and relatedness. In their Self Determination Theory, competence refers to our need to feel effective and capable of producing meaningful results.

This offers a useful lens for understanding the dependency loop.

Strategic leadership often provides weak and delayed evidence of competence. You can spend weeks improving an operating model, developing someone’s judgment or aligning stakeholders without seeing a clear result.

Solving a concrete problem provides that evidence immediately.

The decision gets made. The incident gets resolved. The team moves forward. You can clearly see the connection between your involvement and the result.

There is also a second psychological mechanism at work.

In behavioural psychology, negative reinforcement occurs when removing an unpleasant experience makes a behaviour more likely to be repeated. It is frequently confused with punishment, but it describes something much simpler: a behaviour becomes stronger because it provides relief.

A project starts drifting and the leader experiences uncertainty. They step in, make a decision and the uncertainty decreases.

The next time pressure appears, stepping in becomes even more attractive.

The team goes through a similar learning process. Escalating the problem removes the discomfort of making a difficult decision alone. Each successful escalation makes the next one more likely.

Both sides are rewarded by immediate relief, even though the long term dependency becomes stronger.

There is also an identity problem.

Many engineering leaders built their careers by being dependable. They understood the system, stayed calm during incidents and found solutions when others were stuck. Their ability to step in earned them trust and eventually helped them move into leadership.

The same behaviour becomes less useful as their scope grows.

Stepping away can feel like a loss of value. You attend fewer discussions, make fewer visible decisions and no longer have detailed answers to every question. Meanwhile, other people begin doing the work that previously demonstrated your importance.

Even when this is exactly what the organization needs, it can feel as if you are contributing less.

This is why advice to delegate more often changes very little.

Delegation describes the visible action. It does not address the need for competence, the relief created by regaining control or the discomfort that appears after the work has been delegated.

The real test begins when the team chooses a different approach, progress becomes harder to observe or the first mistake happens.

At that point, the leader has to choose between removing the immediate uncertainty and allowing the team to develop the judgment required to operate independently.

Repeated often enough, choosing immediate relief creates a team that escalates and a leader who cannot step away.

The Cost of Holding Everything Together

The first cost of the dependency loop is usually visible in the leader’s calendar.

There are too many meetings, too many decisions and too many conversations that cannot move forward without them. Strategic work is postponed until things become quieter, although things rarely become quieter for a person who sits inside every important workflow.

The larger cost is harder to see.

When leaders repeatedly provide answers, teams lose opportunities to develop judgment.

Judgment is not built by watching an experienced person make good decisions. It develops through making decisions, defending the reasoning behind them and experiencing the consequences.

A team protected from poor decisions is also protected from the learning required to make better ones.

This creates a misleading cycle.

The leader steps back and the quality temporarily drops. They interpret the drop as proof that their involvement is still necessary, so they return. The team gets fewer opportunities to practise independent decision making, which makes the next attempt to step back equally difficult.

The gap in capability remains, partly because every attempt to expose it is quickly interrupted.

Ownership also becomes unclear.

Someone may own a project on paper, but ownership means little if the important decisions still require approval. People learn how far they can move independently and where the invisible boundary begins.

Before long, they stop approaching that boundary altogether.

They bring recommendations instead of decisions. They wait for feedback before committing. They learn to predict what the leader wants rather than developing and expressing their own point of view.

This can create the appearance of alignment while hiding a lack of real ownership.

The loop also changes how the organization sees the leader.

Being present in every critical situation can make someone look indispensable. They know what is happening, people rely on them and important work moves faster when they are involved.

Indispensability feels like evidence of value, but it can also reveal that leadership has not scaled.

As the team grows, the leader’s capacity stays roughly the same. More people create more questions, more decisions and more coordination. If all of that continues to flow through one person, growth makes the system slower instead of stronger.

Eventually, the leader reaches a ceiling.

They cannot take on a broader role because the current one still requires their constant presence. They cannot focus on longer term problems because immediate issues always appear more urgent. They cannot fully develop future leaders because those people never receive enough real authority.

The team becomes dependent on the leader.

The leader becomes dependent on being involved.

The organization becomes dependent on a system that cannot scale.

Is It Okay to Want to Work Less?

Some leaders feel uncomfortable admitting that they want fewer meetings, fewer operational decisions and fewer problems following them home.

Wanting that can sound selfish.

Leadership is associated with responsibility. As your role grows, it seems reasonable to expect more pressure, more difficult decisions and more demands on your time.

This can lead to a quiet assumption that exhaustion is evidence of commitment.

If your calendar is full and everyone needs you, you must be carrying an important role. If the team can operate without you, perhaps you are no longer adding enough value.

That assumption deserves to be challenged.

A leader whose team can operate independently has not escaped responsibility. They have distributed it successfully.

Reducing your involvement can be a legitimate leadership goal. The way you achieve it determines whether it represents progress.

You can work less by avoiding difficult conversations, lowering standards or transferring your workload to already overloaded people. That creates distance without creating capability.

You can also work less by building clearer ownership, improving how decisions are made and helping people develop enough judgment to solve problems without waiting for you.

The second version makes the organization stronger.

The goal is not an empty calendar.

A senior leader should still be involved where their perspective, authority or context creates meaningful value. They should help define direction, navigate ambiguity, develop people and address problems that cannot be resolved at a lower level.

Their time should reflect the scope of their role.

When a leader spends most of the week answering questions that someone else could learn to answer, their calendar is revealing a design problem.

The same applies to meetings.

Fewer meetings are useful only when decisions continue to be made, information still travels and people know how to coordinate without the leader acting as the connection between them.

Removing meetings before changing those conditions simply moves the confusion elsewhere.

This is why working less cannot be separated from building capability.

If your absence causes everything to slow down, the system is still dependent on you. If work continues, decisions get made and standards remain clear, your reduced involvement is evidence that your leadership has scaled.

The ambition to work less is therefore entirely reasonable.

A better question is whether your way of working less leaves the team more capable than before.

Getting Out of the Loop

Leaving the loop requires more than deciding to become less involved.

If you simply stop attending meetings and answering questions, the dependency remains. The team loses access to the person around whom the system was built, but it does not automatically gain the context, authority or judgment needed to operate independently.

The work begins by identifying where dependency actually exists.

Look for decisions that repeatedly return to you, meetings that struggle to progress without you and problems people escalate before exploring them fully.

Your calendar can be useful evidence.

For each recurring meeting, ask what would happen if you stopped attending. If decisions would no longer be made, identify what people currently receive from your presence. It may be authority, context, conflict resolution or confidence that someone will take responsibility for the outcome.

Once you understand that function, you can transfer it deliberately.

Transfer decisions, not only tasks

Delegating work while retaining decision authority creates limited ownership.

Someone can manage an entire project and still depend on you if they need approval for every meaningful tradeoff. The project belongs to them operationally, but the judgment still belongs to you.

Clarify which decisions they can make, which outcomes they are responsible for and which conditions require escalation.

The goal is not to eliminate escalation. It is to make escalation a deliberate response to defined risk rather than a habit created by uncertainty.

Replace answers with thinking

When someone brings you a problem, providing the answer is often the fastest option.

It also keeps the thinking with you.

Ask what they have already considered, which option they recommend and what tradeoffs shaped their recommendation. If their reasoning is sound, let the decision remain theirs.

This will feel slower at first.

That additional time is part of building capability. Without it, the same category of problem will continue returning to you.

Make standards visible

Quality dependency often develops when the team has to predict what the leader will accept.

If expectations live only inside your head, people have little choice but to involve you. They need your reaction to discover whether their decision meets the standard.

Turn repeated feedback into explicit principles, constraints and examples. Let people challenge those standards and apply them without requiring your approval each time.

The objective is shared judgment, not accurate imitation of the leader.

Allow different decisions

Independent teams will make choices you would not make.

Intervening whenever their approach differs from yours teaches them that autonomy exists only while they reach the same conclusion.

Evaluate the quality of the reasoning, the size of the risk and whether the decision can be reversed. A different approach does not automatically require correction.

Some decisions will produce weaker results. Those moments create the information needed to improve judgment, as long as the cost of learning is understood and contained.

Change your own measure of progress

If your sense of productivity still comes from solving visible problems, stepping away will continue to feel unsatisfying.

Start noticing a different set of outcomes.

Which decisions were made without you?

Who handled a difficult conversation independently?

Where did the team maintain quality without your review?

Which recurring problem stopped returning to your calendar?

These are less visible than resolving an incident or rescuing a delivery. They are stronger evidence that your leadership is scaling.

Getting out of the loop happens gradually.

You transfer context, decision authority and opportunities to learn. You remain available while resisting the habit of taking the work back.

Then pressure rises, and the entire arrangement is tested.

Why Leaders Return When Pressure Rises

A team can appear independent while conditions are stable.

Deadlines are realistic, progress is visible and mistakes are affordable. The leader has enough time to ask questions, tolerate a slower decision and allow people to work through uncertainty.

Pressure changes that calculation.

A critical deadline approaches. An important client complains. Senior leadership asks for reassurance. The cost of a poor decision suddenly feels much higher.

The leader becomes more involved.

They ask for additional updates, join working sessions and review decisions that the team previously made independently. It is usually presented as temporary support until the situation stabilizes.

The team understands the message differently.

They learn that their authority applies when risk is low. Once the outcome becomes important enough, control returns to the leader.

This is how a few weeks of pressure can rebuild a dependency that took months to reduce.

The leader also receives immediate confirmation that returning was necessary. Communication becomes faster. Decisions feel more controlled. Problems may get resolved sooner.

What remains invisible is the capability that the team could have developed by handling the situation itself.

Staying out of the loop does not mean watching passively while a project fails.
It means resisting the automatic assumption that greater risk always requires greater control.

Sometimes direct intervention is necessary. A team may lack critical information, a decision may be irreversible or the potential damage may exceed a reasonable learning cost.

The difference lies in whether intervention is a considered response to the risk or the leader’s default response to discomfort.

Before stepping back in, ask:

1. What specific risk requires my involvement?

2. Does the team lack authority, context or capability?

3. Can I provide what is missing without taking ownership back?

4. Is this decision difficult to reverse?

5. What will the team learn about ownership from the way I respond?

These questions create enough distance to choose your role deliberately.

You may still decide to become involved. If you do, make the boundary explicit.

Explain why the situation requires a temporary change, which decisions remain with the team and when the previous ownership model will resume. Once the pressure passes, return authority deliberately rather than allowing temporary involvement to become the new operating model.

The aim is not to prove that the team never needs you.

It is to build a team that can use your support without transferring the entire problem back to you.

Pressure reveals whether ownership has genuinely moved.

If the leader takes control every time the stakes rise, the team has received responsibility without real authority. If the team continues making decisions while the leader provides context, removes external obstacles and helps contain risk, the system has started to change.

Getting out of the loop during calm periods creates space.

Staying out when the outcome matters creates independence.

What Changes When You Stay Out

The first sign of progress is not an empty calendar.

It is what happens without you.

Decisions continue to be made. People disagree and resolve the disagreement. Problems reach you with clearer thinking and a specific request for support. A difficult week does not automatically pull every important decision upward.

Your role changes too.

You spend less time providing answers and more time improving the conditions in which good answers are found. You work on direction, decision quality, leadership capability and the obstacles that people within the team cannot remove themselves.

You may know less about the daily details.

At first, that can feel uncomfortable. Detailed knowledge previously gave you confidence that the work was under control. Over time, confidence begins to come from somewhere else: clear ownership, capable people and a system that exposes meaningful risk without requiring your presence everywhere.

The team will still need you.

They will need context, coaching, protection from organizational noise and support when the situation exceeds their current authority or experience. The relationship becomes healthier when needing support no longer means giving ownership back.

This is the real shift behind getting out of the loop.

The leader stops being the place where work, decisions and responsibility accumulate. Their value moves into the system they create around the work.

That shift takes more than delegation.

It requires examining what repeatedly pulls you in, what your involvement provides to the team and what being needed provides to you. It also requires staying with the discomfort long enough for a different pattern to develop.

If your team still relies on you for too many decisions, problems and meetings, this is exactly what I work on with founders and engineering leaders.

Over 10 to 12 weeks, we identify where dependency has formed, redesign ownership and help you step back without losing visibility, quality or control of outcomes.

Reply with LOOP if you want to explore whether the program fits your situation.

Last week, I shared a LinkedIn post about something I’ve been noticing inside engineering teams.

A few years ago, engineers had options everywhere.

If they didn’t feel respected, they left.
If they didn’t feel heard, they left.

If a manager consistently created a bad environment, the market made that failure visible very quickly.

The post reached more than 180,000 impressions.

But what caught my attention wasn’t the number.
It was how many engineers and engineering leaders recognized the same shift.

People are staying quieter.
They are challenging fewer decisions.
They are accepting things they would have pushed back on a few years ago.

From the outside, this can look like alignment.

The team seems calmer.
Decisions move faster.
There is less conflict.

People appear more committed.

And if you’re the leader of that team, it can be tempting to believe that you’ve become better at your job.

But there is another possible explanation.

Maybe your team didn’t become more aligned.
Maybe disagreeing with you simply became more expensive.

That distinction matters.

Because layoffs didn’t only change the job market.
They changed the balance of power inside engineering teams.

And in doing so, they created an environment where bad leadership can look surprisingly effective.

When the market forced leaders to be better

The hiring market of a few years ago had plenty of problems.

Engineers sometimes left too quickly.
Companies competed with increasingly unrealistic salaries and benefits.
Managers spent enormous amounts of energy on retention.

And sometimes people confused psychological safety with never feeling uncomfortable.

I don’t want to romanticize that period.
But it did create one useful pressure.

Leaders couldn’t rely only on authority.

If people didn’t trust you, they had options.
If you ignored them long enough, they left.
If you treated experienced engineers like interchangeable resources, another company was waiting to hire them.

That forced many engineering leaders to become better.

We had to think seriously about autonomy.
Career growth.
Psychological safety.
Healthy disagreement.
The quality of 1:1s.
The way decisions were explained.
The way feedback was delivered.

Not always because every company suddenly became deeply human.
Sometimes simply because losing good engineers was expensive.

But regardless of the motivation, leaders had to earn more of their influence.

Then the market changed.

When leaving stopped feeling easy

After repeated rounds of layoffs, hiring freezes, and long job searches, changing jobs started carrying more risk.

People saw strong engineers lose their jobs.

They saw respected leaders disappear during reorganizations.
They saw colleagues spend months searching for their next role.

And naturally, people adapted.

They became more careful.

Not only about leaving.
About speaking.

A disagreement that once felt like a normal part of engineering discussion can now feel like unnecessary exposure.

Pushing back on an unrealistic deadline can feel risky.

Questioning a senior leader’s decision can feel less like intellectual honesty and more like making yourself visible for the wrong reason.

Even when nobody explicitly says:

“Don’t challenge this.”

The environment can still teach people to stay quiet.

That is how power works inside organizations.

It doesn’t always need to be announced.
People notice what is rewarded.

They notice what creates tension.
They notice who gets described as “difficult.”

And when the external market feels unsafe, they become much less willing to test the boundaries of the internal one.

When fear starts looking like alignment

This is where things become dangerous for leaders.

Because fear rarely arrives in a meeting and introduces itself.

It looks professional.

People nod.

They say:

“I guess that’s fine.”

They stop reopening decisions.
They stop raising the same concern after it has already been dismissed once.
They accept the deadline.
They take the work away and try to make it happen.

From a manager’s perspective, this can feel like progress.

Less resistance.
Fewer debates.
Faster meetings.
More execution.

And slowly, a dangerous story starts forming:

“The team finally trusts my judgment.”
“They’ve become more mature.”
“We used to overanalyze everything. Now we just move.”

Maybe.

But perhaps people have simply learned that disagreement is no longer worth the emotional or professional cost.

Silence and trust can look almost identical from the leader’s chair.

That is why positional authority is so psychologically deceptive.

The higher you go, the easier it becomes to mistake the absence of resistance for the presence of support.

Compliance is easier to lead than trust

There is a reason authoritarian leadership can feel effective in the short term.

Compliance is fast.

You make a decision.
People follow it.

There is less negotiation and less visible conflict.

Trust is slower.

People question assumptions.
They introduce information you didn’t have.
They make decisions messier before they make them better.
They sometimes tell you that your idea won’t work.

That can feel inefficient.

Especially under pressure.

But engineering work depends on information flowing upward.

The engineer closest to the system often sees a risk before the manager does.

The person implementing the decision understands constraints that were invisible in the leadership meeting.

The quiet doubt someone carries today can become the production incident everyone discusses next month.

When people stop challenging decisions, leaders don’t suddenly become right more often.

They simply receive less evidence that they might be wrong.

And that creates a dangerous feedback loop.

The team challenges less.
The leader experiences less resistance.
Less resistance feels like stronger leadership.
The leader becomes more confident and more directive.
The team becomes even quieter.

Eventually the leader is operating with less real information while feeling more certain than ever.

That isn’t alignment.

It is organizational blindness.

Not every disagreement is psychological safety

There is another side to this conversation that I think matters.

Psychological safety does not mean every decision needs endless debate.

It doesn’t mean leaders should avoid being directive.
And it doesn’t mean every employee who disagrees should get their way.

Some situations require a clear decision.
Some teams need more structure.
Some conversations have already happened, and execution needs to begin.

I have led teams where too much discussion became its own form of avoidance.

People kept asking for more clarity when the real problem was discomfort with committing.

Good leadership sometimes means saying:

“I’ve heard the concerns. This is the decision, and we are moving forward.”

But there is a huge difference between ending a discussion after people have spoken honestly...

...and creating an environment where they decide not to speak at all.

The goal is not permanent consensus.
The goal is access to the truth before the decision is made.

The test leaders need now

So how do you know whether your team is aligned or simply careful around you?

I don’t think another anonymous engagement survey will answer that.

Watch what happens in real conversations.

When was the last time someone changed your mind in a meeting?
When was the last time an engineer openly said your deadline was unrealistic?

Do concerns appear early, when they can still help, or late, when the decision is already failing?
Do people disagree with you in a group, or only privately after the meeting?

When someone challenges you, do you become curious... or immediately start explaining why they’re wrong?

And perhaps the hardest question:

What would my team say if disagreeing with me carried absolutely no cost?

You may never know the complete answer.

The power difference between a manager and an employee can’t be removed entirely.

But your behavior teaches people how safe that difference is.

Every time someone challenges you, the room watches what happens next.

Do you explore the concern?
Do you ask questions?
Do you acknowledge when they see something you missed?

Or do you become colder, more defensive, and slightly less inclusive afterward?

Culture is built in those small moments.
Not in the value written on the company website.

Culture has a long memory

The current market will not last forever.

At some point, opportunities will increase again.

Changing jobs will feel less dangerous.

Engineers will have more leverage.

And when that happens, companies may suddenly discover that the calm they were seeing was never loyalty.

It was waiting.

People may not remember every roadmap decision.
But they will remember what leadership felt like when they had fewer options.

They will remember who continued investing in trust.
Who invited disagreement.
Who protected people under pressure.

And who saw a difficult market as permission to stop trying.

That is why I believe this period is such an important leadership test.

It is relatively easy to care about psychological safety when retention depends on it.
It is much harder to keep creating it when people are less likely to leave.

But that is exactly when it reveals what your culture was built on.

Trust...

or market conditions.

Final thought

The real test of leadership is not how people behave when they can easily leave.

It is how you lead when they feel they can’t.

Because authority becomes easiest to abuse precisely when nobody feels safe enough to resist it.

And one day, the market will change again.

But culture has a very long memory.

P.S. This essay expands on the LinkedIn post that reached more than 180,000 impressions.

Last week, I shared a LinkedIn post about leading engineering teams without having hands-on experience in their tech stack.

I expected some debate.

I didn’t expect over 110,000 impressions, hundreds of comments, and dozens of private messages from Engineering Leaders around the world.

What surprised me wasn’t that people agreed or disagreed.

It was how many admitted, privately, that they were living this exact reality.

Some were leading .NET teams after spending their careers in Java.

Others had moved into AI, Data Engineering, or Mobile without ever writing production code in those domains.

And almost every message carried the same emotion.

Not curiosity.

Not excitement.

Fear.

“What if they realize I’m not technical enough?”

That question resonated.

Because a few years ago, I was asking myself the very same thing.

I thought I had to prove I belonged

The first time this really hit me was about five years ago.

I was asked to lead an Android team.

Up until that point, my entire career had been built around Java and web apps. I had never developed Android applications professionally.

The moment I accepted the role, I felt a responsibility to prove I deserved it.

So I did what I thought a good Engineering Manager should do.

I spent evenings reading Android documentation.
Weekends watching conference talks.
I tried to understand every architectural decision, every framework, every library the team was using.

At the time, I was leading only a handful of engineers, so it felt achievable.

I genuinely wanted to contribute as much as I could.

And if I’m honest...

Part of me believed that the more technical I became, the more credible I would be as their leader.

And I thought it worked… for those 5-6 months I was responsible for that team.

But a few years later, it happened again.

This time with a .NET team.

My first instinct was exactly the same.

Open the documentation.
Buy another course.
Learn the framework.
Catch up as quickly as possible.

Then, halfway through that journey, I stopped.

This time, I asked myself a simple question.

“What exactly am I trying to achieve, here? I know how this goes...”

Even if I spent every evening learning .NET, I would never catch engineers who had spent ten years building production systems with it.

And honestly...

Why was I trying to?

That was the moment I realized I had been playing the wrong game all along.

Instead of becoming a better Engineering Manager, I was trying to become another senior engineer.

Those are two very different jobs.

So this time, I chose a different path.

Focusing on the right question

Looking back, I don’t think my biggest challenge was leading technologies I didn’t know.

It was managing my own insecurity.

I wasn’t learning .NET because the team needed me to.
I was learning it because I needed to feel worthy of leading them.

That’s an important distinction.

Emotional Intelligence isn’t just about understanding other people.
Sometimes it’s about recognizing the stories we keep telling ourselves.

Mine sounded something like this:

“A good Engineering Manager should always have the answers.”

The problem with that belief is that it quietly changes your behavior.

You stop asking questions because you’re afraid they’ll expose what you don’t know.
You speak sooner than you should.
You challenge decisions just to prove you’re engaged.
You spend your energy trying to look technical instead of trying to understand.

Ironically, the more I tried to protect my credibility, the less effective I became as a leader.

Everything changed when I gave myself permission to stop pretending that my value came from being the smartest engineer in the room.

Because it didn’t.

My value came from something entirely different.

• Helping smart engineers make better decisions.

• Creating an environment where people challenged each other respectfully.

• Removing obstacles.

• Connecting technical decisions to business outcomes.

• Helping people grow.

• Making sure the team stayed aligned when the pressure increased.

None of those things required me to write the best .NET code.

They required something much harder.

The confidence to admit what I didn’t know... and the curiosity to ask better questions.

So what did I actually do Instead?

When I joined my .NET team, I made a conscious decision.

I wasn’t going to compete with my engineers on technical depth.

Instead, I focused on creating an environment where their expertise could actually flourish.

I stopped asking questions to test people.
I started asking questions to understand.

Instead of asking:

“Why didn’t you use this framework?”

I’d ask:

“What options did you consider, and what trade-offs led you to this decision?”

I wasn’t looking for the “correct” technical answer.

I was looking for the quality of the thinking behind it.

Because that’s what ultimately matters.

As a leader, I’m rarely making the architectural decision myself.

But I am responsible for making sure the team is making good architectural decisions.

There’s a big difference.

I also stopped feeling uncomfortable when someone knew more than I did.

In fact, I started seeing it as a requirement.

If my Senior Engineers don’t know more than me in their domain, then something is probably wrong.

My job isn’t to replace them.

It’s to create the conditions where they can do their best work.

That means understanding who should be involved in a decision.

Making sure different perspectives are heard.

Recognizing when someone is defending an idea because it’s technically better... or simply because it’s their idea.

Helping the team separate facts from opinions.

Keeping discussions focused on the problem we’re trying to solve instead of the technology people are emotionally attached to.

Most engineering decisions don’t fail because people lack technical knowledge.

They fail because of poor communication.
Unclear ownership.
Egos.
Fear of challenging each other.
Misaligned incentives.
Or simply because nobody asked the uncomfortable question.

And that’s where I believe Emotional Intelligence becomes a technical advantage.

Not because it replaces technical excellence.
But because it allows technical excellence to emerge.

Don’t misunderstand me

None of this means technical knowledge isn’t important.

It is.

If you’re leading engineering teams, you need enough technical understanding to ask good questions, recognize weak reasoning, and follow architectural discussions.

You can’t lead effectively if every technical conversation sounds like a foreign language.

But there’s a huge difference between understanding enough to lead...

...and believing you must become the strongest engineer on the team before you deserve to.

I think that’s where many Engineering Managers get stuck.

Especially those transitioning from Senior Engineer or Tech Lead.

For years, their identity was built around having the answers.
Being the person everyone turned to.
Solving the hardest technical problems.

Leadership quietly changes the rules.

Suddenly, your value is no longer measured by the quality of the code you write.
It’s measured by the quality of the environment you create.

How well your team collaborates.
How quickly people grow.
How effectively decisions are made.
How safe people feel challenging each other.
How often your team succeeds without depending on you.

That’s a very uncomfortable transition.

Because unlike writing code...

...you don’t get immediate feedback.

You don’t ship a pull request.

You don’t see a green checkmark.

You simply watch other people succeed.

And if your identity is still tied to being the smartest engineer in the room...

That can feel surprisingly empty.

The leadership test I use today

Today, I ask myself a very different question.

Not:

“Did I have all the answers?”

But:

“Did my team make better decisions because I was in the room?”

Sometimes the answer is yes because I challenged an assumption.
Sometimes because I asked a question nobody else asked.
Sometimes because I helped two engineers understand each other.
Sometimes because I decided not to speak at all.

Ironically, the less I tried to prove my technical value...

The more trust I earned.

Not because my engineers suddenly thought I knew everything.
But because they knew I was there to help them think better… not to compete with them.

And looking back...

That’s probably the biggest lesson those Android and .NET teams taught me.

Leadership isn’t about becoming the smartest engineer in the room.
It’s about making the room smarter.

P.S. Here’s the link to my viral post. :)

“What’s your leadership style?”

I’ve been asked that question in interviews, leadership programs, and conversations with other managers more times than I can remember.

For years, I thought there had to be a good answer.

Servant leadership.

Transformational leadership.

Coaching leadership.

Democratic leadership.

The more books I read, the longer the list became. It felt like every great leader had found their label, and I was supposed to find mine.

Today, I honestly don’t know how to answer that question.

The way I lead a brand new team isn’t the way I lead a mature one.

The way I lead during a production incident isn’t the way I lead when we’re exploring a new product.

The way I lead a junior engineer isn’t the way I lead someone who’s spent fifteen years building software.

Even within the same team, my approach changes over time. A team that needs structure today may need autonomy six months later.

If you watched me across those situations, you could easily think you were looking at different leaders.

Sometimes I’m very direct.

Sometimes I spend most of the meeting asking questions.

Sometimes I slow everything down.

Sometimes I push the team to move faster than they’re comfortable with.

Years ago, that bothered me.

I thought good leaders were supposed to be consistent.

Eventually I realized I had been trying to answer the wrong question.

The real question isn’t:

“What’s your leadership style?”

It’s:

“How do you decide what your team needs right now?”

That changed the way I think about leadership.

Leadership is problem-solving

If leadership were mostly about expressing your personality, having one fixed style would make sense.

But leadership isn’t self-expression.

Leadership is problem-solving.

That’s why I’ve never been comfortable introducing myself as a servant leader, a coaching leader, or any other label.

Those labels describe behavior.

They don’t explain how someone thinks.

Imagine asking a surgeon about their surgical style.

You probably wouldn’t feel comfortable if they answered:

“I’m a minimally invasive surgeon. That’s just who I am.”

You’d expect something different.

“It depends on the patient, the diagnosis, the risks, and the outcome we’re trying to achieve.”

Leadership works the same way.

Every team has different constraints.

Some teams don’t trust each other.
Some trust each other but avoid difficult conversations.
Some move too slowly because every decision needs another meeting.

Others move so fast that quality starts falling apart.

Treating all of those teams the same in the name of consistency doesn’t sound authentic.

It sounds like someone applying the same solution to different problems.

The same team changes over time.

The manager they need during their first month together is rarely the manager they’ll need a year later.

Looking back, I don’t think I ever had one leadership style.

I had a habit of trying to understand the problem before deciding how to respond.

It took me years to realize those are two very different things.

The team that changed my mind

One experience made this painfully obvious.

I joined a team after leading another one that responded really well to a coaching approach.

I spent a lot of time asking questions.

Helping people arrive at their own conclusions.

Creating space for discussion.

It worked.

So naturally, I walked into my next team assuming I’d lead the same way.

Within a couple of weeks, something felt off.

The team wasn’t lacking ideas.

They weren’t lacking ownership.
They weren’t lacking technical ability.
They were lacking decisions.

People had spent months discussing the same topics without moving forward.

Everyone was waiting for someone else to create clarity.

The team didn’t need another coach.

They needed someone willing to make decisions, remove ambiguity, and accept the responsibility that comes with it.

So my behavior changed.

Meetings became shorter.

Decisions became faster.

I became much more directive than I had been with my previous team.

A few months later, once the team found its rhythm, I slowly stepped back again.

If someone had observed me in those two teams, they probably would have described two completely different leadership styles.

The interesting part is that I wasn’t trying to change my style.

I was trying to solve a different problem.

The mental model that gave me a language for it

A few years later, I came across a way of thinking that finally gave me a language for what I had been doing.

It’s called first principles thinking.

The idea is more than two thousand years old.

Aristotle described first principles as the most fundamental truths you can’t reduce any further. They’re the foundation everything else is built upon.

Scientists have relied on this approach for centuries.

When physicists study the world, they don’t begin with tradition.

They begin with fundamentals.

They ask what they know to be true before building explanations on top of it.

The concept became widely known in business because Elon Musk often talked about it while building SpaceX.

People asked him how a new company could possibly compete with an industry where rockets cost hundreds of millions of dollars.

Most people accepted the assumption that rockets were simply expensive.

He didn’t.

Instead, he broke the problem apart.

What materials make up a rocket?
How much do those materials actually cost?
Which part of today’s price comes from physics?
Which part comes from manufacturing?
Which part comes from assumptions the industry had accepted for decades?

Once the problem was reduced to its basic components, it became possible to question almost everything else.

That story stayed with me.

Because leadership is full of assumptions too.

Weekly one-on-ones.
Daily stand-ups.
Career ladders.
Performance reviews.
Delegation frameworks.
Feedback models.

Most of us inherit these practices from previous managers, books, podcasts, conferences, or companies we admire.

Very few of us stop and ask:

What problem is this practice actually solving?

That question changed the way I make leadership decisions.

Asking better questions

Today, whenever I’m facing an important leadership decision, I try to slow myself down.

Instead of asking:

“What’s the best practice?”

I ask:

What problem am I actually trying to solve?

Why does this problem exist?
What would success look like?
Which constraints are real?
Which ones am I accepting simply because they’ve always existed?

Only after answering those questions do I start thinking about solutions.

Sometimes the answer looks almost identical to the conventional advice.
Sometimes it’s completely different.

Take one-on-ones…

People often say every manager should have weekly one-on-ones with every engineer.

That’s reasonable advice.

Until you ask one more question.

Why?

What problem are those meetings solving?

For one engineer, they’re building trust.
For another, they’re providing coaching.
For someone new, they’re creating psychological safety.
For someone who’s been consistently delivering for years, they may become repetitive status updates that nobody enjoys.

The meeting was never the goal.

The outcome was.

The same thing happens with delegation.

Managers ask:

“Should I delegate more?”

Again, that’s a solution pretending to be a problem.

The real questions are different.

What’s preventing this person from owning this independently?
Do they lack confidence?
Context?
Experience?
Or am I the bottleneck because I keep stepping in?

Each answer leads somewhere completely different.

Even feedback changes.

Some people need direct feedback immediately.
Others need time to process.
Some lose trust if you’re too soft.
Others shut down if you’re too blunt.

Trying to behave consistently across all those situations isn’t leadership.

Understanding the problem is.

Maybe leadership styles are conclusions

This is the part I keep coming back to.

Leadership styles are useful descriptions.

They’re just poor starting points.

They’re conclusions.

The thinking that produced them matters much more than the label itself.

If you copy someone else’s conclusion without understanding how they arrived there, it’ll work for a while.

Eventually you’ll run into a team, a company, or a situation where the same approach quietly stops working.

For a while now I’ve stopped trying to build a recognizable leadership style.

I’d rather build a reliable way of thinking.

One that starts with understanding the problem before reaching for the solution.

A different answer

If someone asks me about my leadership style today, I’ll probably disappoint them.

I don’t have a short answer.

Some days I’m highly directive.
Some days I mostly listen.
Some days I spend hours coaching.
Some days I make a difficult decision in five minutes because clarity matters more than consensus.

If you watched me for a week, you might put one label on me.

If you came back six months later, you’d probably choose another.

And you’d probably be right both times.

The consistency isn’t in my behavior.

It’s in the questions I ask before deciding how to behave.

So if someone asks me:

“What’s your leadership style?”

My honest answer is this.

I don’t start with a style.

I start with the problem.

The style reveals itself after that.

A few months ago, I finally picked up Thinking, Fast and Slow by Daniel Kahneman.

It’s one of those books that gets recommended so often that it almost becomes background noise. You hear people mention it in podcasts, leadership circles, startup communities, and executive coaching conversations. Eventually, I decided it was time to see what all the hype was about.

What surprised me wasn’t the psychology.

It was how much of the book felt like a leadership book.

Because at its core, Thinking, Fast and Slow isn’t really about cognitive science.

It’s about decision-making.

And leadership is, fundamentally, a decision-making profession.

Every day leaders make decisions about people, priorities, promotions, strategy, hiring, delegation, conflict, communication, and risk.

The challenge is that most of us assume we’re making those decisions rationally.

Kahneman’s work suggests otherwise.

His central message is uncomfortable:

Intelligent people are not immune to bad decisions. In many cases, they’re simply better at justifying them.

The good news is that understanding how our minds work gives us a chance to lead more effectively.

Let’s explore a few of the ideas from Thinking, Fast and Slow that I believe every modern leader should understand.

System 1 and System 2: The Two Minds Behind Every Decision

One of the most famous concepts in the book is the distinction between System 1 and System 2 thinking.

System 1 is:

• Fast

• Automatic

• Emotional

• Intuitive

• Effortless

System 2 is:

• Slow

• Analytical

• Deliberate

• Logical

• Effortful

Neither system is good or bad.

In fact, we need both.

If you had to consciously analyze every step while walking, driving, or speaking, you would never get anything done.

The problem is that leadership often requires System 2 thinking while our brains default to System 1.

Imagine a senior engineer challenges your proposal during a meeting.

System 1 immediately reacts:

“They’re questioning my authority.”

“They’re being difficult.”

“I need to defend my position.”

System 2 asks different questions:

“What information might they have that I don’t?”

“Could their concern improve the outcome?”

“Am I reacting to the content or to the challenge itself?”

Leadership mistakes don’t happen because leaders lack intelligence.

They happen because leaders don’t notice which system is currently driving their behavior.

The best leaders know when to slow down.

They understood that their first reaction wasn’t always their best one.

WYSIATI: What You See Is All There Is

Kahneman introduces a concept called WYSIATI:

What You See Is All There Is.

It’s one of the most powerful ideas in the entire book.

Our brains are constantly constructing stories from incomplete information.

The problem is that we rarely realize the information is incomplete.
We mistake our interpretation for reality.

This happens constantly in leadership.

An employee misses a deadline.
You conclude they’re disorganized.

A team member is quiet during meetings.
You assume they’re disengaged.

A project falls behind.
You decide someone isn’t performing.

But what if you’re only seeing a tiny fraction of the story?

Maybe the employee is blocked by another team.
Maybe the quiet team member is processing information before speaking.
Maybe the project is suffering from unclear requirements.
Maybe there are organizational constraints nobody has surfaced yet.

The danger isn’t that leaders make assumptions.
The danger is that assumptions quickly start feeling like facts.

Once that happens, we stop investigating.
We stop asking questions.
We stop gathering information.

And we start making decisions based on stories rather than reality.

One of the most valuable leadership habits I’ve developed over the years is asking myself a simple question:

“What information might I be missing?”

It’s amazing how often that question changes the entire situation.

Because leadership is rarely about managing what you know.
It’s about recognizing what you don’t.

The Substitution Heuristic: When Your Brain Answers the Wrong Question

This might be my favorite concept from the book because once you see it, you can’t unsee it.

Kahneman explains that when our brains encounter a difficult question, they often replace it with an easier one without telling us.

The difficult question disappears.
The easier question gets answered.

And we believe we’ve solved the original problem.

Consider a promotion decision.

The difficult question is:

“Is this person ready to lead others?”

That’s a complex question.

It requires evaluating emotional intelligence, communication skills, influence, coaching ability, judgment, and self-awareness.

Instead, our brains often answer:

“Do I like working with this person?”

Or:

“Are they technically strong?”

Or:

“Have they been here a long time?”

Those are much easier questions.
They’re also different questions.

The same thing happens in hiring.

The real question is:

“Will this person perform successfully in this environment over the next several years?”

The substituted question becomes:

“Did they impress me during the interview?”

It happens in strategy too.

The real question is:

“Does this initiative solve a meaningful business problem?”

The substituted question becomes:

“Do I like this idea?”

Many poor leadership decisions are not the result of bad intentions.

They’re the result of answering easier questions than the ones that actually matter.

Great leaders learn to pause and ask:

“What is the real question here?”

That single habit can dramatically improve decision quality.

Regression to the Mean: Why Leaders Often Misinterpret Performance

This concept doesn’t get nearly enough attention.

Regression to the mean sounds complicated, but the principle is simple.

Extreme outcomes are often followed by more average outcomes.

In other words, unusually great performances tend to move closer to normal.
Unusually poor performances tend to move closer to normal too.

Yet leaders constantly misinterpret this phenomenon.

Imagine a high performer has an exceptional quarter.

They exceed every target.
Deliver every project.
Receive praise from stakeholders.

A leader may start assuming this level of performance is the new standard.

Then the next quarter is merely good instead of exceptional.

The leader feels disappointed.

Nothing actually went wrong.
The performance simply moved closer to its typical level.

The opposite happens too.

A team member has a terrible sprint.

The leader delivers strong feedback.

The next sprint improves.

The leader assumes the feedback caused the improvement.

Maybe it did.
Maybe it didn’t.
Maybe the previous sprint was simply an unusually bad outlier.

The lesson isn’t that feedback doesn’t matter.

The lesson is that leaders should be cautious about drawing sweeping conclusions from isolated events.

One great month doesn’t tell you everything.

One bad month doesn’t either.

Strong leaders look for patterns.

Weak leaders react to episodes.

That’s a critical distinction.

Base Rates: The Leadership Skill Nobody Talks About

Humans love stories.

We naturally gravitate toward narratives.

Statistics are less exciting.
Unfortunately, statistics are often more useful.

Kahneman highlights our tendency to ignore base rates.

A base rate is simply the underlying probability of something happening.

Leaders ignore base rates all the time.

A startup founder believes their company will become a unicorn.
A hiring manager believes they’ve found a guaranteed star performer.
A leadership team believes their transformation initiative will succeed.

The question isn’t whether those outcomes are possible.

The question is whether the decision-makers have considered how often similar efforts actually succeed.

Let’s look at hiring.

A candidate gives an incredible interview.

They’re confident.
Articulate.
Charismatic.

The story sounds compelling.

But what’s the base rate?

How many candidates who performed similarly in interviews actually became top performers?

Most leaders never ask.

They trust the narrative.

Base rates force us to balance optimism with reality.

They don’t eliminate ambition.
They simply anchor it.

The next time you’re evaluating a major decision, ask yourself:

“What usually happens in situations like this?”

Not what you hope happens.
Not what happened once.
What usually happens.

That question alone can prevent countless leadership mistakes.

Intuition: When Should Leaders Trust It?

This is another area where Kahneman is often misunderstood.

Many people think his work argues against intuition.

It doesn’t.

It argues against blind trust in intuition.

Kahneman makes an important distinction.

Intuition becomes reliable when two conditions exist:

1. The environment contains predictable patterns.

2. The person receives regular, high-quality feedback.

Think about an experienced engineering leader.

After years of leading teams, they may develop strong intuition about:

• Team morale

• Emerging conflicts

• Communication breakdowns

• Delivery risks

• Stakeholder dynamics

Why?

Because they’ve seen hundreds of examples.

And they’ve received feedback on whether their judgments were correct.

But now consider predicting:

• The next major technology shift

• Market behavior five years from now

• The success of a new organizational structure

• The long-term outcome of a strategic bet

These environments provide far less reliable feedback.

Patterns are weaker.
Uncertainty is higher.

Intuition becomes much less trustworthy.

This distinction matters.

Because leaders often become successful in one domain and then assume their intuition is equally reliable everywhere.

That’s a dangerous trap.

Experience creates confidence.
It does not automatically create accuracy.

The best leaders I know trust their intuition enough to form a hypothesis.
Then they seek evidence before turning that hypothesis into a decision.

The Leadership Lesson Behind the Entire Book

After finishing Thinking, Fast and Slow, I don’t think the biggest lesson is that humans are irrational.

The bigger lesson is that we’re predictably irrational.

We make the same mistakes.
We jump to the same conclusions.
We trust the same shortcuts.
We become overly confident.
We ignore probabilities.
We see patterns that aren’t there.
We create stories from incomplete information.

And we do all of this while believing we’re being objective.

Leadership doesn’t magically protect us from these tendencies.

If anything, leadership amplifies them.

The more authority we have, the easier it becomes to mistake our assumptions for reality.
The more experience we gain, the easier it becomes to overestimate the accuracy of our intuition.
The more pressure we face, the more likely we are to rely on mental shortcuts.

That’s why great leadership isn’t about becoming perfectly rational.

That’s impossible.

Great leadership is about becoming aware of how your mind works.

It’s about recognizing when you’re reacting instead of thinking.

When you’re assuming instead of investigating.

When you’re telling yourself a story instead of examining the evidence.

The leaders who consistently make better decisions are rarely the ones with the highest IQ.

They’re the ones who have learned to question their own thinking.

And perhaps that’s Kahneman’s most important lesson for leaders:

The quality of your leadership is often determined by your ability to challenge the conclusions your brain wants you to accept automatically.

For years, engineering leadership in tech followed a relatively predictable formula.

Grow the team.
Add more processes.
Increase coordination.
Hire more managers as the organization scales.

And for a long time, that model worked.

Software was expensive to build.
Engineering capacity was limited.
Execution speed was the bottleneck.

Now the ground is shifting underneath that entire system.

Over the last year alone, the industry has been flooded with statements that would have sounded absurd just a few years ago.

Founders talking about teams of 5 engineers doing the work of 50.
Executives openly questioning whether companies still need large engineering organizations.
Engineers publicly wondering if management roles are becoming obsolete.
Leaders quietly asking themselves if they should go back to being ICs before it’s too late.

At the same time, AI coding tools are improving at a pace that feels difficult to mentally absorb.

What used to take days can sometimes take hours.
Prototypes appear overnight.
Entire products are being built by tiny teams with almost no operational overhead.

And naturally, panic follows speed.

The conversation across tech has become increasingly extreme:

“Management is dead.”
“Everyone needs to code again.”
“One AI engineer will replace entire departments.”
“Middle management is finished.”

Underneath all of this noise sits a much more important question.

What actually happens to engineering leadership when software itself becomes abundant?

Because this is the part many people still misunderstand:

AI is not just changing how software gets built.

It is changing where organizational bottlenecks exist.

And that changes leadership entirely.

For years, companies were constrained primarily by engineering execution.

Now many companies are slowly becoming constrained by something else:

decision quality,
organizational clarity,
prioritization,
alignment,
emotional stability under pressure,
and the ability to operate coherently while speed keeps increasing.

The irony is that AI may not reduce the importance of leadership at all.

It may simply expose which parts of leadership were never truly high leverage to begin with.

AI Already Changed the Shape of Software Organizations

One of the biggest mistakes people make right now is talking about AI as if it’s still a future disruption.

For many engineering organizations, it’s already operational reality.

The shift may not look dramatic from the outside yet.
Most companies still have org charts.
Managers still run meetings.
Teams still plan roadmaps.

But underneath the surface, the economics of software creation are quietly changing.

And once economics change, organizational structures eventually follow.

We are already seeing signals everywhere.

Shopify publicly pushed internal expectations around AI adoption and productivity.
Microsoft heavily integrated AI copilots into developer workflows and positioned AI-assisted development as a core part of engineering productivity.
Google continues investing aggressively into AI-native development tooling and automation across software workflows.

At the same time, founders and AI leaders are making increasingly aggressive predictions about software development itself.

Sam Altman has repeatedly talked about software becoming dramatically cheaper to create.
Dario Amodei discussed worlds where small groups of highly leveraged people can produce enormous output with advanced AI systems.

Whether those timelines are optimistic or not is almost secondary now.

Because the psychological effect on organizations is already happening.

Boards expect higher efficiency.
Founders expect smaller teams to move faster.
Investors increasingly question bloated organizational layers.
Engineering leaders feel pressure to justify headcount in ways they didn’t before.

And perhaps most importantly:
the bottleneck is slowly moving away from writing code itself.

That doesn’t mean software engineering suddenly becomes easy.
It means code generation is becoming less scarce than good judgment.

Today, a reasonably strong engineer with AI assistance can already:

• prototype faster

• debug faster

• explore ideas faster

• onboard into unfamiliar codebases faster

• automate repetitive work faster

Which creates a strange new organizational problem.

When execution speed increases dramatically, companies can accidentally create chaos at unprecedented speed too.

More prototypes.
More experiments.
More partially finished systems.
More competing directions.
More technical inconsistency.
More local optimization.

Without strong alignment, organizations can start fragmenting faster than they scale.

And this is where many companies may realize something uncomfortable:
the future bottleneck is not simply “building faster.”

It’s deciding:

• what deserves to be built

• what should be ignored

• what creates long-term leverage

• what introduces hidden complexity

• what aligns with the company’s direction

• and what quietly creates organizational debt

Software is becoming increasingly abundant.

Clarity is not.

The Part Nobody Wants to Admit: Some Management Roles Were Never Truly High Leverage

AI is not only disrupting engineering.

It is exposing organizational theater.

For years, many companies unintentionally created management structures that optimized for coordination overhead instead of actual leverage.

More meetings.
More reporting layers.
More sprint ceremonies.
More status synchronization.
More dashboards explaining why work is delayed instead of reducing the causes of delay.

And when software delivery was slower and more fragmented, a lot of this looked necessary.

Now AI enters the picture and suddenly:

• meetings get summarized automatically

• tickets get generated automatically

• documentation gets drafted automatically

• updates become searchable instantly

• coordination friction starts shrinking

• information routing becomes cheaper

Which creates an uncomfortable question:

If most of your value disappears when AI automates administrative coordination, was that actually leadership?

This is the part the industry is still emotionally resisting.

Because many organizations quietly confused management activity with organizational impact.

There is a massive difference between:

• coordinating work
  and

• increasing the effectiveness of an entire system

One is operational maintenance.

The other is leverage.

And AI is starting to separate those two categories very aggressively.

The lowest leverage management roles often revolve around:

• forwarding information

• tracking timelines

• updating stakeholders

• maintaining process compliance

• facilitating ceremonies

• escalating problems upward

• translating between departments without changing outcomes

Those tasks still matter.

But they are increasingly compressible.

Especially in organizations where leaders were never deeply involved in:

• technical direction

• organizational design

• prioritization quality

• decision-making frameworks

• talent calibration

• conflict resolution

• cultural stability under pressure

This is why some leaders currently feel existential anxiety.

Not because leadership itself is disappearing.
But because AI is forcing organizations to ask a harder question:

“What is the actual leverage of this role?”

And to be fair, some management layers may genuinely shrink over the next several years.

Particularly in environments where:

• teams become smaller

• seniority density increases

• AI boosts individual output

• communication overhead drops

• cross-functional tooling improves

But there is another side to this story that many people completely miss.

As organizations become faster, more AI-native, and more compressed…
the cost of poor leadership may actually increase.

Why Engineering Leadership May Become Even More Important

One of the most dangerous assumptions in tech right now is this:

“If AI makes execution faster, leadership becomes less necessary.”

In reality, the opposite may happen.

Because speed does not remove organizational problems.
It amplifies them.

A mediocre decision inside a slow organization creates damage gradually.

A mediocre decision inside a high-speed AI-enabled organization can spread through systems almost instantly.

This is the part many people underestimate.

AI increases execution leverage.
But leverage magnifies both intelligence and dysfunction.

A highly aligned organization becomes dramatically more effective.
A chaotic organization becomes dramatically more chaotic.

And when companies move faster, leadership weaknesses stop staying hidden.

Poor prioritization becomes visible faster.
Emotional overreactions spread faster.
Technical debt accumulates faster.
Conflicting directions collide faster.
Team confusion compounds faster.

In slower environments, organizations often had time to recover from leadership inconsistency.

In high-speed environments, recovery windows shrink.

That changes the role of engineering leadership entirely.

The future challenge is not simply getting engineers to produce more output.

AI will increasingly help with that.

The challenge becomes:

• preventing fragmentation

• maintaining strategic coherence

• protecting long-term system quality

• reducing organizational noise

• keeping teams aligned under uncertainty

• making clear decisions while information constantly changes

This is where leadership starts becoming less about “managing work” and more about stabilizing systems under pressure.

And ironically, AI may make emotional regulation inside leadership more valuable than ever.

Because speed increases psychological pressure too.

Leaders now operate in environments where:

• expectations change weekly

• tooling evolves monthly

• teams fear replacement

• executives demand more efficiency

• everyone feels urgency simultaneously

Under those conditions, reactive leadership becomes extremely expensive.

An impulsive prioritization shift can redirect entire teams unnecessarily.
A pressure-driven roadmap decision can create months of technical instability.
A leader operating from fear can unintentionally spread anxiety through an entire organization.

And this is why many AI discussions still feel incomplete.

Most conversations focus on:

• productivity

• automation

• coding speed

• headcount reduction

But fewer people talk about what happens psychologically to organizations operating at this pace.

Because the companies that survive long term may not be the ones that simply build fastest.
They may be the ones that remain coherent while moving fast.

That is a leadership problem far more than a coding problem.

The Return of the Technical Leader… But Not in the Way People Think

One of the strongest reactions to the AI shift has been the growing belief that leaders need to “go back to coding.”

And to some extent, that reaction makes sense.

Engineering leaders who completely detached from technology for years are entering a much more dangerous environment now.

Because AI changes the speed of technical evolution itself.

Leaders who:

• do not understand modern AI workflows

• cannot evaluate AI-generated output

• cannot reason about architecture tradeoffs

• cannot distinguish demos from sustainable systems

• rely entirely on others for technical judgment

…become increasingly vulnerable.

Technical credibility matters more again.

But this is where the conversation often becomes too simplistic.

The future is probably not:
“Directors spending 8 hours per day shipping tickets.”

Nor is it:
“Managers disappearing entirely while everyone becomes an IC.”

Instead, the role itself is evolving into something more hybrid.

The future engineering leader likely becomes:

• more technically aware

• more AI-native

• more systems-oriented

• more strategically involved in architecture and leverage decisions

• more capable of contributing directly when necessary

But not necessarily through constant hands-on execution.

Because while AI increases individual technical leverage, it also increases organizational complexity.

Smaller teams with stronger tooling can suddenly:

• launch more initiatives simultaneously

• experiment faster

• rewrite systems faster

• create infrastructure faster

• accumulate hidden complexity faster

Which means the hardest problems increasingly move upward into:

• tradeoff decisions

• system coherence

• technical direction

• long-term maintainability

• organizational focus

This is why the future leadership profile may look very different from both:

• the traditional people manager
  and

• the pure senior IC

The highest leverage leaders will likely operate somewhere in between.

Deep enough technically to:

• understand what is happening

• challenge assumptions

• evaluate quality

• identify risk

• guide architecture direction

But elevated enough organizationally to:

• optimize the entire system

• reduce friction

• align functions

• stabilize priorities

• protect long-term clarity

In other words:

the future may not belong to “managers” or “ICs.”

It may belong to high-leverage operators who can understand both technology and human systems simultaneously.

And that combination is far rarer than most companies realize.

The Psychological Side Nobody Talks About

Beneath all the AI optimism, productivity charts, and viral demos, there is another reality quietly spreading across tech leadership:

a growing identity crisis.

Many engineering leaders will never say it publicly.

But privately, the questions are already there.

“Am I still valuable?”
“Should I go back to being an IC?”
“What happens if organizations need fewer managers?”
“Am I falling behind technically?”
“What if smaller AI-enabled teams eliminate roles like mine entirely?”

And these fears are not irrational.

The industry is genuinely changing.

But what makes this moment psychologically difficult is that it challenges something deeper than job security.

It challenges identity.

For years, many leaders built their professional confidence around:

• team size

• organizational scope

• headcount growth

• operational complexity

• managerial responsibility

Now the industry is increasingly signaling that:

• smaller teams may outperform larger ones

• leaner organizations may move faster

• AI can compress execution layers

• technical leverage may matter more than organizational scale

That creates enormous internal tension.

Especially for leaders who slowly drifted away from technical depth over time.

But there is another layer to this conversation that rarely gets discussed.

Some leaders may not want to return to IC work purely because the market demands it.

Some may want to return because coding feels emotionally safer than leadership.

Coding often provides:

• clearer feedback loops

• more visible progress

• less interpersonal ambiguity

• fewer political dynamics

• a stronger sense of personal control

Leadership, especially in uncertain environments, is psychologically heavier.

You make decisions with incomplete information.
You absorb organizational anxiety.
You manage conflicts without clean solutions.
You carry responsibility for systems you cannot fully control.

And AI amplifies that uncertainty even further.

Because nobody fully knows:

• what organizations will look like in 5 years

• how quickly roles will evolve

• what skills will become dominant

• how much automation actually changes team structures

Which means many leaders are now operating under a constant background pressure:
the pressure of becoming obsolete.

And ironically, this is where emotional maturity inside leadership becomes critically important.

Because fear-driven leaders tend to react in predictable ways:

• micromanaging teams

• chasing every AI trend impulsively

• forcing premature transformations

• overcompensating technically

• creating organizational instability from their own anxiety

The future may not belong to leaders who panic fastest.

It may belong to leaders who can remain clear while everyone else is psychologically speeding up.

What Future-Proof Engineering Leaders Will Actually Look Like

The AI era will probably not reward leaders who simply manage process.

And it likely won’t reward leaders who retreat entirely into technical individual contribution either.

The highest leverage leaders of the next decade may look more like organizational multipliers than traditional managers.

People who increase the effectiveness of entire systems.

Because when software creation becomes dramatically cheaper and faster, the real differentiator becomes:

• clarity

• judgment

• adaptability

• prioritization

• emotional stability under pressure

• and the ability to keep organizations coherent while complexity explodes

The future-proof engineering leader will likely combine several capabilities that historically existed separately.

Technical credibility

Not necessarily because they write the most code.

But because they understand:

• modern development workflows

• AI-assisted engineering

• architecture tradeoffs

• technical risk

• scalability implications

• long-term system quality

They can challenge assumptions intelligently.
They can evaluate whether something is genuinely robust or simply an impressive demo.

And most importantly:

they stay intellectually close enough to technology to understand where the industry is actually moving.

Systems thinking

Future organizations may become smaller but more interconnected.

That means local decisions can create massive downstream effects very quickly.

Strong leaders will think beyond:

• individual tickets

• isolated teams

• short-term velocity metrics

They will think in systems.

How does this decision affect:

• technical debt?

• organizational focus?

• operational load?

• team cognition?

• long-term adaptability?

• cross-functional friction?

The leaders who survive will likely optimize for overall system health, not just short-term output.

Organizational clarity

As execution accelerates, noise accelerates too.

AI can help teams build faster.
It cannot automatically ensure everyone moves in the same direction.

This is where clarity becomes a competitive advantage.

Future engineering leaders will increasingly act as clarity engines inside organizations.

Reducing:

• confusion

• unnecessary complexity

• competing priorities

• reactive decision-making

• organizational fragmentation

Because in fast-moving systems, confusion compounds aggressively.

Emotional regulation under pressure

This may become one of the most underrated leadership skills of the AI era.

As uncertainty increases, leaders set the emotional tone for entire organizations.

A reactive leader spreads instability quickly.
A grounded leader stabilizes decision-making across teams.

And this matters more than many technical leaders realize.

People do not only absorb strategy from leadership.

They absorb emotional state too.

Especially during uncertainty.

Future-proof leaders will not necessarily be the loudest, fastest, or most aggressively optimistic people in the room.

They may simply be the people who:

• remain clear under pressure

• avoid impulsive decisions

• regulate urgency before it spreads

• create psychological stability during rapid change

That becomes enormous leverage in environments where everyone else is emotionally accelerating.

Adaptability without panic

The strongest leaders will not blindly resist AI.

But they also will not worship every new tool or trend emotionally.

They will stay adaptive without becoming reactive.

That balance matters.

Because organizations can destroy enormous amounts of value by:

• chasing hype cycles

• rebuilding systems impulsively

• constantly reorganizing

• forcing premature transformations

• optimizing for speed without understanding consequences

Future-proof leadership requires enough flexibility to evolve…

without losing strategic coherence in the process.

The future engineering leader may ultimately become something closer to:

part technologist,
part systems designer,
part organizational architect,
part pressure stabilizer.

Not someone who simply manages execution.

But someone who helps entire organizations think clearly while moving fast.

Final Reflection

AI will likely automate large parts of software creation.

But it won’t automatically solve:

• poor decisions

• organizational chaos

• reactive leadership

• misalignment under pressure

• or the human side of complexity

In many ways, AI may actually amplify those problems.

Because when speed increases, unclear thinking becomes far more expensive.

That’s why I don’t believe the future belongs purely to managers or purely to ICs.

It belongs to leaders who can:

• think clearly under pressure

• combine technical understanding with systems thinking

• create alignment in fast-moving environments

• and stabilize organizations while uncertainty keeps growing

Software is becoming abundant.

Clarity is not.

And that may become one of the most valuable leadership skills of the next decade.

Most leaders say they want honest feedback.

Until it actually arrives.

Not the polished kind.
Not the “quick thought” wrapped in corporate diplomacy.

I mean the real kind.

The kind that questions your judgment in front of other people.
The kind that subtly challenges your authority.
The kind that makes the room go quiet for half a second longer than usual.

That’s usually where emotional intelligence stops being philosophy… and starts becoming biology.

Your chest tightens.
Your jaw locks.
Your brain starts preparing a defense before the other person even finishes speaking.

And suddenly the meeting is no longer about strategy.

It becomes about protection.

Protection of your credibility.
Your competence.
Your status.
Your identity.

What’s fascinating is how quickly intelligent people can become emotionally primitive under pressure.

Especially leaders.
Especially founders.
Especially CEOs.

Because the higher you go, the more conflict starts feeling personal… even when it technically isn’t.

And most leadership advice completely misses this.

It talks about communication styles.
Frameworks.
Listening skills.
Executive presence.

But very little is said about what actually happens internally when someone publicly resists you, challenges you, or makes you feel exposed.

That’s the real work.

Not communication.

Regulation.

Because the most dangerous conflicts at work rarely start from logic.

They start from identity protection.

Where Conflict Actually Comes From

Most workplace conflicts are not about the thing people are arguing about.

The roadmap is rarely the roadmap.
The deadline is rarely the deadline.
The disagreement about priorities is rarely about priorities.

Usually underneath it sits something much older and more emotional:

“I don’t feel respected.”
“I don’t feel heard.”
“I feel threatened.”
“I feel controlled.”
“I feel dismissed.”
“I feel invisible.”
“I feel unsafe.”

But nobody says that part out loud.

So instead people debate Jira tickets with the emotional intensity of a divorce negotiation.

Especially in leadership environments.

Because leadership compresses pressure.

Everyone is overloaded.
Everyone feels responsible.
Everyone believes they’re protecting the company.

And when intelligent, driven people feel pressure, they often become more rigid… not more open.

You can actually watch this happen in leadership teams.

• A founder starts defending an idea harder than necessary.

• A VP becomes territorial over decisions.

• A technical leader becomes emotionally attached to being “right.”

• Someone interrupts more aggressively than usual.

• Someone withdraws completely and calls it “staying professional.”

On the surface it looks strategic.

Underneath it’s emotional self-protection.

And ironically, the more responsibility someone carries, the harder it becomes to separate disagreement from identity.

Because eventually the company stops feeling like something you work on.

It starts feeling like an extension of you.

That’s why conflicts at the top are often so emotionally loaded.

Not because leaders are weak.

Because pressure magnifies ego attachment.

One of the Most Brilliant CEOs Ever Was Also Known for Conflict

Steve Jobs was famous for intensity.

People who worked with him described meetings that could swing from inspiring to brutal within minutes.

He challenged people aggressively.
Rejected ideas publicly.
Pushed teams emotionally hard.

And yet what’s interesting is that many former employees also described him as strangely magnetic during conflict.

Why?

Because underneath the intensity there was often clarity.

He wasn’t avoiding tension.
He wasn’t pretending disagreement didn’t exist.
He wasn’t using politeness to hide frustration.

The problem wasn’t conflict itself.

The problem was emotional regulation inside conflict.

And that distinction matters.

Because many leaders today swing too far in one of two directions:

They either:

• avoid conflict to preserve harmony

or

• escalate conflict to preserve ego

Both eventually damage trust.

One creates hidden resentment.
The other creates fear.

Neither creates psychological safety.

And psychological safety does not mean “everyone feels comfortable.”

It means people feel safe enough to tell the truth without fearing emotional punishment.

That becomes incredibly difficult when leaders unconsciously turn every disagreement into a personal threat.

I Used to Avoid Conflict Completely

When I first became a leader, I thought emotional intelligence meant staying calm by avoiding tension.

I wanted people to like working with me.
I wanted to be perceived as collaborative.
Reasonable.
Easy to work with.

So I overexplained.
Softened feedback.
Delayed hard conversations.
Ignored small tensions until they became large ones.

I confused temporary comfort with leadership.

And eventually it backfired.

Because avoided conflict doesn’t disappear.

It mutates.

Small frustrations become passive aggression.
Misalignment becomes politics.
Unspoken tension becomes emotional distance.

Then later, something else happened.

I swung too far in the opposite direction.

As I became more confident technically and organizationally, I started attaching more of my identity to being competent.

And that created a new problem.

Now when someone challenged my decision publicly, I didn’t experience it as curiosity.

I experienced it as resistance.

I would defend my thinking too hard.
Hold my position too rigidly.
Try to “win” the conversation instead of understanding it.

Not because I was evil.
Not because I lacked intelligence.

Because my ego had quietly fused itself to my ideas.

That’s the trap many leaders never notice.

The more capable you become, the easier it becomes to mistake your perspective for reality.

Especially under pressure.
Especially when people rely on you.
Especially when your nervous system is exhausted.

And this is where emotional intelligence becomes much deeper than communication tactics.

Because the real question in conflict is not:

“How do I respond professionally?”

The real question is:

“What inside me feels threatened right now?”

That question changes everything.

The Framework That Changed How I Handle Conflict

Over time, I realized most emotionally destructive conflicts happen because people react before they regulate.

So I started using a very simple framework internally during difficult conversations.

Not as manipulation.
Not as a communication trick.

As regulation.

The framework is:

Pause. Validate. Reframe. Invite.

Simple.
But incredibly hard under pressure.

1. Pause

Most leaders dramatically underestimate how dangerous immediate reactions are.

Especially intelligent leaders.

Because intelligent people can rationalize emotional reactions extremely quickly.

The pause interrupts that.

Not externally.

Internally.

Sometimes the most emotionally intelligent thing you can do in a tense meeting is simply:

nothing for three seconds.

Breathe.
Let the adrenaline settle slightly.
Notice the urge to defend yourself.

That pause alone changes the quality of the next sentence.

And often the entire room can feel it.

Because calm nervous systems regulate rooms.

Reactive nervous systems infect them.

2. Validate

This does not mean agreement.

This is where many leaders get stuck.

Validation simply means acknowledging the emotional reality of the other person.

For example:

“I can understand why this feels frustrating.”

That sentence sounds simple.

But psychologically it’s powerful because people calm down when they feel seen.

Most humans escalate when they feel emotionally erased.

Validation lowers defensiveness because it removes the need for the other person to fight for recognition.

Ironically, many conflicts intensify not because people disagree…

but because neither side feels understood.

3. Reframe

Once emotional intensity lowers slightly, the conversation can return to reality instead of identity protection.

This is where reframing matters.

You shift the discussion away from:

• ego

• blame

• territory

• control

and back toward:

• context

• shared goals

• constraints

• outcomes

Something like:

“We may be optimizing for different risks here.”

or

“I think we’re both trying to protect delivery, just from different angles.”

That subtle shift changes the emotional structure of the conversation.

Now it’s no longer:
me vs you.

It becomes:
us vs the problem.

That’s leadership.

4. Invite

This is probably the most underrated step.

Most leaders unconsciously try to regain control after tension.

But invitation creates trust faster than control ever will.

Especially at senior levels.

Something as simple as:

“What do you think I might be missing here?”

can completely change the room.

Because confident leaders don’t need dominance to feel safe.

And people can feel the difference immediately.

Invitation transforms conflict from confrontation into collaboration.

Not always.
Not magically.

But often enough to change entire team dynamics over time.

The Real Reason This Matters

Most companies don’t collapse because people disagree.

They collapse because people stop telling the truth.

And people stop telling the truth when conflict becomes emotionally unsafe.

That usually starts at the top.

A founder becomes reactive.
A CEO punishes challenge without realizing it.
A leader unconsciously weaponizes defensiveness.
A room learns that honesty carries emotional cost.

So people adapt.

They become careful.
Political.
Filtered.

And eventually leadership teams lose something incredibly valuable:

real information.

That’s why emotional regulation is not “soft skills.”

It directly impacts decision quality.

Because your emotional state shapes:

• what people tell you

• what they hide from you

• how much challenge survives inside the culture

• and whether the room optimizes for truth or comfort

The irony is that many leaders think they need more control under pressure.

Usually they need more awareness.

Final Thought

Anyone can appear emotionally intelligent when everything is smooth.

The real test comes when your authority feels challenged.
When tension enters the room.
When your nervous system starts demanding protection.

That’s the moment leadership stops being conceptual.

And becomes visible.

Not through perfection.

Through regulation.

Because the strongest leaders are not the ones who never feel triggered.

They’re the ones who notice the trigger… without handing it the microphone.

Most leaders eventually run into the same frustrating moment.

You prepare carefully for a difficult conversation.

You stay calm.
Measured.
Respectful.

You explain the issue clearly.
You focus on observable behavior.
You avoid blame.
You genuinely try to help.

And somehow…

the conversation still leaves tension behind.

The person becomes defensive.
Withdrawn.
Cold.

Or maybe even worse:

They nod through the whole conversation…

…but nothing actually changes afterward.

And now you’re left sitting there thinking:

“I handled that well.”

So why did it feel so bad?

Why didn’t it land?

This is one of the hardest parts of leadership that almost nobody prepares CEOs for:

Sometimes feedback fails even when it was delivered correctly.

And the higher you climb, the more emotionally expensive that becomes.

Because at your level, feedback is not an occasional thing.

It’s constant.

You’re trying to improve:
communication,
ownership,
decision-making,
alignment,
execution,
culture.

You’re carrying pressure from every direction.

And eventually you realize something uncomfortable:

Giving feedback properly does not guarantee it will be received properly.

That realization changes how you lead.

The Leadership Advice That Sounds Right… But Feels Incomplete

Most leadership advice focuses heavily on delivery.

Stay calm.
Be specific.
Use frameworks.
Avoid judgment.
Focus on behavior, not personality.

And honestly?

That’s good advice.

But I think it misses something deeper.

Because feedback is not just information.

It’s emotional interpretation.

People don’t receive feedback logically first.

They receive it emotionally first.

Especially under pressure.

Especially inside fast-moving companies.

Especially when uncertainty already exists underneath the surface.

And that’s where many leaders unknowingly struggle.

Not because they communicate badly.

But because they underestimate the emotional environment surrounding the conversation.

A Founder Conversation I Still Think About

I remember speaking with a founder who was frustrated with one of his senior leaders.

The complaint itself was valid.

The leader had become increasingly reactive during meetings.

Interrupting people.
Defending ideas too quickly.
Creating subtle tension whenever someone challenged him.

The founder approached the conversation thoughtfully.

Private meeting.
Calm tone.
No public embarrassment.

And he said something close to:

“I’ve noticed that when someone pushes back on an idea, your response becomes very fast and defensive. I think it’s starting to affect how openly people speak in meetings.”

Honestly?

That’s fairly emotionally intelligent feedback.

But the reaction came immediately.

“That’s not true.”
“I’m just trying to move things forward.”
“If people can’t handle direct conversations, that’s not my problem.”

The atmosphere changed instantly.

And the founder’s first instinct was the same instinct most leaders have:

Explain harder.

Clarify intent.
Give more examples.
Convince him.

And this is the exact moment where many leadership conversations quietly collapse.

Because once someone feels psychologically threatened, they stop listening for insight.

They start listening for danger.

The Mistake Nobody Notices in Real Time

One of the biggest mistakes leaders make is assuming defensiveness means the feedback was unclear.

So they push harder.

More explaining.
More examples.
More persuasion.

But here’s the problem:

The more emotionally pressured someone feels, the less reflective they become.

And this gets amplified even more when companies are moving fast.

Which honestly is where many companies are right now.

AI is accelerating expectations everywhere.

Faster shipping.
Faster decisions.
Faster iteration.
Faster comparison.

Everyone feels it.

Founders feel pressure from the market.
Leadership teams feel pressure from founders.
Teams feel pressure from leadership.

And eventually all of that pressure leaks into communication.

Sometimes very subtly.

Through tone.
Pacing.
Interruptions.
Impatience.
Micro reactions.

You think you’re simply giving “clear feedback.”

But the other person may already feel:
overwhelmed,
replaceable,
behind,
or afraid of disappointing you.

So even calm feedback lands emotionally heavier than you intended.

The Hard Truth About Feedback

I think this is one of the hardest truths for leaders to accept:

You cannot force self-awareness into someone.

No matter how correct you are.
No matter how calm you are.
No matter how thoughtful your delivery is.

You can invite reflection.

You can create safety.

You can plant a seed.

But you cannot force readiness.

And trying to force it usually damages the relationship faster than the original issue itself.

That’s the paradox.

The stronger your need for them to understand immediately…

…the less likely understanding becomes.

What I Personally Got Wrong Earlier in My Career

Earlier in my leadership career, I believed clarity solved defensiveness.

If someone resisted feedback, I thought I simply needed to explain it better.

And honestly?

Sometimes that worked.

But many times, I was unknowingly increasing emotional pressure while believing I was improving communication.

Because once people feel cornered, something shifts internally.

They stop reflecting.

They start protecting identity.

You’ll notice it immediately:

More justification.
More intellectualizing.
More subtle blame shifting.
More defensiveness.

Or complete emotional shutdown.

And ironically, the harder you push…

…the further insight moves away.

Especially with highly intelligent people.

Especially with founders, senior engineers, and leaders.

Because smart people are very good at defending internal logic.

Very good at explaining themselves.
Very good at protecting self-image without realizing it.

Which means feedback can accidentally become identity conflict instead of discussion.

And identity is emotional territory.

Not rational territory.

Sometimes They’re Not Resisting the Feedback

This is the part I think changed my leadership the most.

Sometimes people are not resisting your feedback.
They’re resisting the pressure surrounding it.

That distinction matters enormously.

Because once you understand that, your goal changes.

You stop asking:

“How do I make them understand?”

And start asking:

“How do I create conditions where understanding becomes possible?”

That creates a completely different conversation.

Less force.
More space.
More patience.

Ironically, that’s usually what increases reflection.

Why Leaders Keep Pushing Anyway

I think many leaders, especially at the top, unknowingly carry a hidden fear into feedback conversations:

“If they don’t understand this right now, nothing will improve.”

So they keep pushing.

Not because they’re controlling people.

Because internally they’re trying to reduce uncertainty.

Trying to regain clarity.

Trying to fix tension quickly.

But growth rarely happens under emotional compression.

Reflection needs psychological space.

Especially for strong personalities.
Especially for high performers.
Especially for leaders.

One of the Most Emotionally Intelligent Things a Leader Can Do

Pause.

Not withdraw.
Not avoid accountability.
Not become passive.

Pause.

Because timing matters.

Sometimes insight arrives later.

Hours later.
Days later.
Weeks later.

I’ve had situations where someone resisted feedback completely in the moment…

…and later came back saying:

“I’ve actually been thinking about what you said.”

That only happened because the conversation was allowed to breathe.

Not because pressure forced the realization.

What Emotional Intelligence Actually Looks Like at the Top

A lot of people think emotional intelligence means saying things gently.

I don’t think that’s true.

At the CEO level, emotional intelligence is much more about emotional regulation.

Can you stay grounded when someone reacts badly?
Can you tolerate not being understood immediately?
Can you resist the urge to force alignment?
Can you create safety instead of pressure?

That’s the real work.

Not communication tricks.

Not memorized frameworks.

Not perfect phrasing.

Those things help.

But leadership conversations are emotional environments first.

Information second.

AI Is Quietly Making This Harder

I don’t think AI is replacing leadership.

But I do think it’s amplifying leadership psychology.

Because speed changes emotional dynamics.

Everything moves faster now.

Pressure accumulates faster.
Expectations rise faster.
Decisions happen faster.
Tension spreads faster.

And when leaders operate under constant acceleration, they become more vulnerable to emotional reactivity without realizing it.

Not because they’re weak.

Because they’re human.

Which means the ability to regulate yourself under pressure becomes even more valuable now.

Not less.

The Shift That Changed How I Think About Feedback

The older I get, the more I believe leadership is deeply connected to nervous systems.

Not just strategy.
Not just execution.
Not just intelligence.

Nervous systems.

A regulated leader creates openness.

A reactive leader creates protection.

And protection changes how people communicate.

That’s why some organizations slowly become politically filtered over time.

People stop speaking honestly not because they’re dishonest…

…but because emotionally they no longer feel safe risking friction.

And that can happen even under good people.

Even under thoughtful founders.
Even inside successful companies.

A Simple Reminder I Think More Leaders Need

Sometimes you can do everything “right”…

…and the feedback still won’t land immediately.

That does not automatically mean:
you failed,
they’re impossible,
or the relationship is broken.

Sometimes people simply aren’t ready yet.

And one of the most emotionally intelligent things you can do in that moment is stop trying to force insight.

Not forever.

Just long enough for the conversation to breathe.

Because leadership is not about winning the interaction.

It’s about building enough trust for truth to eventually be heard.

And honestly?

That’s much harder than giving feedback correctly in the first place.

I used to walk into work like I had something to prove.

Not in an obvious way.
Not loud. Not arrogant.

Quietly.

Every decision carried weight.
Every reaction felt like it mattered more than it should.
Every piece of feedback lingered longer than it deserved.

When things went well, I felt sharp.
Capable. In control.

When they didn’t…

Something in me tightened.

Not because the outcome was bad.
But because it said something about me.

And that’s the part most people don’t talk about.

The Hidden Equation

At some point, without realizing it, you start running this equation:

My performance = My worth

It doesn’t show up as a belief.
It shows up as a reaction.

You overthink decisions.
You replay conversations.
You take tone personally.
You feel the need to prove yourself… even when no one asked you to.

And the higher you go, the more subtle it becomes.

Especially if you’re leading.

Especially if you’re a founder.
A CTO.
A CEO.

Because now it’s not just your work.

It’s your company.
Your people.
Your decisions.

Your identity expands…
…and traps you at the same time.

AI Didn’t Create Pressure

It Exposed It

Everyone is talking about AI replacing engineers.

But very few are talking about what it’s doing to leaders.

Because the pressure didn’t start with AI.

AI just removed the illusion of stability.

Every few weeks:

A new model.
A new capability.
A new expectation.

Faster decisions.
Less certainty.
Higher stakes.

And suddenly…

You’re not just leading a company.

You’re leading in an environment where:

• Information is infinite

• Opinions are louder

• And “being wrong” is more visible than ever

So what do most leaders do?

They tighten their grip.

They try to be more certain.
More decisive.
More in control.

But underneath that…

There’s something else.

Fear of being exposed.

Not as incompetent.

But as not enough.

The Subtle Trap of Over-Identification

It doesn’t start as ego.

It starts as pride.

• “I care about my work.”

• “I take responsibility.”

• “I want to do this right.”

And that’s good.

Until it becomes identity.

• “I’m the one who always delivers.”

• “I’m the calm one under pressure.”

• “I’m the leader people trust.”

Now you’re not just doing the role.

You’re protecting it.

And that’s where things shift.

Because now…

When something goes wrong,
you don’t just feel frustration.

You feel threatened.

What It Looks Like in Real Life

You don’t notice it immediately.

It shows up in moments.

• You get feedback and instantly defend it internally

• Someone challenges your decision and you feel irritation, not curiosity

• A project slips and you feel embarrassment, not analysis

• You avoid certain conversations because they might shake your image

From the outside, you still look composed.

From the inside…

You’re managing your identity.

Not the situation.

You Are Not Your Team’s Performance

This one hits hard.

Because good leaders care.

They take ownership.
They feel responsible.

But there’s a difference between:

Ownership
and
Identification

Ownership says:
“This is mine to improve.”

Identification says:
“This says something about me.”

And once you cross that line…

Everything becomes heavier.

Your team misses a deadline → You feel exposed
Someone underperforms → You question your leadership
Results dip → You start doubting yourself

But here’s the reality most leaders avoid:

There are always variables you don’t control.

• Market timing

• Product direction

• Hidden tech debt

• Personal struggles inside your team

• Misalignment above you

• Random chaos you didn’t see coming

And now, with AI in the mix?

Add to that:

• Shifting expectations overnight

• Teams experimenting without clarity

• Pressure to “use AI” without understanding how

• Strategic decisions made on incomplete signals

So if you tie your identity to outcomes…

You’re signing up for instability.

Labels Are Just Comfortable Prisons

People start describing you.

“The calm one.”
“The strategic thinker.”
“The empathetic leader.”
“The one who always knows what to do.”

And it feels good.

Because it gives you certainty.

But here’s the problem:

You start living up to the label…
instead of responding to reality.

You avoid conflict because you’re “the nice one.”
You hesitate to admit uncertainty because you’re “the confident one.”
You overextend because you’re “the reliable one.”

You become predictable.

Rigid.

Safe.

And leadership is none of those things.

Leadership Requires Range

Some days require empathy.
Some require decisiveness.
Some require saying “I don’t know.”
Some require making a call without full information.

And in today’s environment?

That range matters more than ever.

Because AI didn’t simplify leadership.

It removed the luxury of slow thinking.

You still need clarity.

But now you need it faster.
With less data.
And more consequences.

Which means:

You don’t need a fixed identity.

You need adaptability.

The Myth of “Arriving”

There’s a quiet belief many leaders carry:

“I’ll feel confident once I reach the next level.”

Once the company stabilizes.
Once the team performs.
Once decisions get easier.

But that moment never comes.

Because every level introduces:

• More ambiguity

• More responsibility

• More visibility

And now with AI?

More unpredictability.

There is no finish line.

There’s no version of you that becomes immune to:

• Doubt

• Mistakes

• Feedback

• Pressure

What changes isn’t the environment.

It’s your relationship to it.

What Actually Improves

Not perfection.

Not certainty.

Not control.

What improves is:

• Awareness

• Recovery speed

• Emotional stability

• Decision clarity under pressure

You still feel things.

You just don’t become them.

Your Leadership Is Affected by Everything

This is the part most frameworks ignore.

You are not a static leader.

You are affected by:

• Sleep

• Stress

• Personal life

• Energy levels

• Context switching

• Information overload

And now:

Constant exposure to AI-driven noise.

You read something.
You question your strategy.
You feel behind.
You react faster than you should.

Not because you’re weak.

Because you’re human.

The Real Shift

Letting go of identity doesn’t mean:

Not caring.
Not being responsible.
Not aiming high.

It means:

You stop attaching your self-worth to outcomes.

And that changes everything.

Because now:

• Feedback becomes information

• Failure becomes signal

• Conflict becomes useful

• Uncertainty becomes manageable

You lead differently.

Cleaner.

Lighter.

More precise.

How to Let Go Without Letting Down

This is where most people get stuck.

“If I detach… will I lose my edge?”

No.

You lose the noise.

Here’s what actually helps:

Hold things lightly
Care deeply. But don’t cling.

Separate feedback from identity
It’s data. Not judgment.

Stop needing to be right
Focus on getting it right.

Recover faster
Mistakes matter less when you don’t drag them.

Ask better questions
Instead of defending, get curious.

Protect your energy
Not every situation deserves full emotional investment.

A Simple Practice

When something triggers you, pause.

Run this:

Recognize
What am I feeling right now?

Reframe
Am I making this about who I am?

Redirect
What actually helps this situation?

It sounds simple.

But under pressure?

It changes everything.

Why This Matters More Now

Before, you could hide behind process.

Behind time.
Behind hierarchy.
Behind slow cycles.

Now?

AI compresses everything.

Decisions are faster.
Feedback loops are tighter.
Mistakes surface quicker.

So if your identity is tied to being:

• Right

• Certain

• In control

You will feel it.

Constantly.

But if your identity is grounded in:

• Learning

• Adapting

• Responding

You stay stable.

Even when everything else isn’t.

Closing

You are not your job.

You are not your company.
You are not your team’s performance.
You are not your last decision.
You are not your best moment.
You are not your worst one either.

You are someone navigating complexity.

Sometimes well.
Sometimes imperfectly.

But always learning.

And in a world that’s moving faster than ever…

That’s the only thing that actually compounds.

So keep building.
Keep deciding.
Keep leading.

Just don’t confuse the role…

with who you are.

We like to believe we see people clearly.

That when someone delays, reacts a certain way, or behaves “off,” our interpretation is grounded in facts.

But it rarely is.

Most of what you think about someone is not truth.
It’s interpretation.

Filtered through your own expectations, pressure, past experiences, and internal state.

And at your level — as a CEO or senior leader — that becomes dangerous.

Because your interpretation doesn’t stay in your head.

It turns into decisions.

Why This Matters More Now Than Ever

A few years ago, a misjudgment might affect one conversation.
One person. One decision.

Today?

In an AI-driven environment, everything moves faster.

• Decisions are made quicker

• Information is processed at scale

• Outputs get amplified across teams instantly

Which means:

👉 Your internal state doesn’t just influence a moment. It scales across your entire company.

A wrong interpretation today can:

• derail a strategic decision

• create tension at the leadership level

• shift how entire teams align and execute

Not because of data.

But because of how you interpreted it.

The Leadership Trap No One Talks About

As leaders rise, something subtle happens.

They stop questioning their own perception.

They trust their judgment more.
They rely on experience.
They move faster.

Which is necessary.

But it also creates a blind spot.

You stop being curious.
You start labeling.

• “He’s slow.”

• “She’s not engaged.”

• “They don’t get it.”

And from there, decisions follow.

Distance grows.
Trust erodes.
Performance drops.

Not because your people are wrong.

But because your interpretation was incomplete.

A Moment That Changed How I Lead

Early in my leadership career, I had a team member who always delivered work at the last minute.

I interpreted it quickly:

Careless. Disorganized. Not serious enough.

I was ready to confront him.
But something made me pause.

Instead of reacting, I asked:

“What’s going on?”

He looked at me and said:

“I review everything three times before I send it. I’m afraid of delivering something that’s not perfect.”

Same behavior.
Completely different reality.

It wasn’t carelessness.
It was pressure. Fear. Responsibility.

That moment stayed with me.

Because it made something very clear:

What you see is rarely the full story.

Now Scale That to a CEO Level

At your level, the stakes are different.

You’re not interpreting one team member.
You’re interpreting:

• your leadership team

• co-founders

• board dynamics

• strategic signals

And you’re doing it fast.

Often under pressure.
Often without full context.

Now add AI into the mix.

You have more data than ever.
More dashboards. More signals. More inputs.

But here’s the paradox:

👉 More information doesn’t remove bias. It amplifies it.

You still choose what to focus on.
You still interpret what it means.
You still decide how to act.

AI doesn’t replace judgment.

It scales it.

The Hidden Cost of Misjudgment

Most leaders don’t realize how expensive this becomes.

Not immediately.

But over time.

A misinterpreted behavior leads to:

• unnecessary tension in leadership meetings

• hesitation in decision-making

• erosion of authority

• loss of trust at the top

And here’s the hardest part:

You rarely connect the outcome back to the original assumption.

You just see:

• “alignment issues”

• “execution problems”

• “team not stepping up”

When in reality:

👉 it started with how you read the situation

The Projection Trap

Carl Jung said:

“Everything that irritates us about others can lead us to an understanding of ourselves.”

In leadership, this shows up constantly.

• If you value speed, reflection looks like hesitation

• If you value structure, flexibility looks like chaos

• If you value autonomy, collaboration can feel like dependency

You’re not seeing the person.
You’re seeing your own values — projected onto them.

And under pressure, this intensifies.

Because you don’t have time to question it.
You react.

Where AI Makes This Worse

AI doesn’t introduce bias.

It accelerates the consequences of it.

You make a call based on your interpretation.
That decision gets implemented faster.
Communicated wider.
Executed at scale.

There’s less friction. Less delay.

Which sounds efficient.

Until the decision was based on a misread.

Then you’re not just wrong.

👉 You’re wrong faster, and at scale.

What Leadership Actually Requires Now

At this level, leadership is not about being right.

It’s about seeing clearly under pressure.

Which means:

• questioning your own interpretation

• slowing down at the right moments

• staying curious when your instinct is to conclude

Not all the time.
But in the moments that matter.

A Simple Shift That Changes Everything

Instead of asking:

“What’s wrong with them?”

Ask:

👉 “What might I be missing?”

That single question:

• reopens curiosity

• reduces reactivity

• changes the tone of the conversation

You stop trying to fix people.
You start trying to understand them.

And that’s where real leadership begins.

How This Plays Out in Real Situations

A CEO I worked with was frustrated with his leadership team.

He felt they weren’t stepping up.

Meetings were tense.
Decisions were revisited.
Progress felt slow.

His interpretation:

“They lack ownership.”

But when we slowed down and looked deeper:

• expectations weren’t fully clear

• tension wasn’t addressed directly

• some team members were operating under silent pressure

Once he saw that, everything shifted.

He changed how he approached conversations.

Clarity improved.
Tension surfaced and got resolved.
Ownership followed.

Not because the team changed first.

👉 Because his interpretation did.

Leading Without Projection

This doesn’t mean you avoid accountability.

It means you build it on top of understanding.

Great leaders:

• ask before they assume

• clarify before they correct

• reflect before they react

And most importantly:

👉 they question their own perception

A Practical Framework to Pause Judgment

Next time something triggers you, pause for a moment.

Run this internally:

1. What are the facts?
   (What actually happened — not what I think it means)

2. What am I assuming?
   (What story am I adding on top)

3. What else could be true?
   (Alternative explanations)

4. Have I asked them directly?
   (Or am I operating on interpretation alone)

This takes less than a minute.
But it can prevent weeks of misalignment.

The Real Work at the Top

At this level, the game changes.

It’s no longer about:

• knowing more

• working harder

• optimizing processes

It’s about:

👉 how you think under pressure

Because that’s what shapes every decision.
And today, those decisions travel faster than ever.

Final Thought

Your judgment feels real.

It feels accurate.

It feels justified.

But it’s not the truth.

It’s your perspective — shaped by pressure, experience, and state.

And in an AI-driven world, where everything moves faster and scales wider:

that perspective becomes one of the most expensive variables in your business

So before you react, decide, or label:

Pause.

And ask yourself:

“Am I seeing the full picture — or just my version of it?”

Empathy is one of the most misunderstood concepts in leadership.

Most people hear the word and think:

Be nice.
Be understanding.
Avoid conflict.

That’s not empathy.

That’s avoidance.

And it’s one of the fastest ways to lose respect as a leader.

The real problem with how leaders think about empathy

Early in my career, I made a mistake I see many leaders still making.

I thought empathy meant:

• Making people feel good

• Keeping conversations smooth

• Avoiding unnecessary tension

So I did what many “empathetic” leaders do:

I softened feedback
I avoided pushing too hard
I said “I understand” even when I didn’t fully agree

It worked.

At least on the surface.

People felt comfortable.
Meetings were calm.
There was no visible conflict.

But underneath…

Decision quality was dropping.

Slowly.
Quietly.

Because something important was missing:
Truth.

Empathy without truth is not leadership

Teams don’t need you to be agreeable.
They need you to be accurate.
They need clarity.
They need someone who can hold both:

Understanding people
and
challenging their thinking

At the same time.

Most leaders can’t do both.
They swing.

Either:

They prioritize truth and ignore people
→ which creates resistance

Or:

They prioritize people and avoid truth
→ which creates mediocrity

Real empathy sits in the tension between those two.

What empathy actually is

Empathy is not about agreeing.
It’s about understanding how someone arrived at their thinking… before you evaluate it.

That’s it.

Simple.

But very uncomfortable in practice.
Because it requires you to pause when your instinct is to react.

Think about the last time someone on your team proposed something you disagreed with.

Your brain likely went straight to:

“That won’t work.”
“We’ve tried that.”
“This is not the right direction.”

That reaction feels rational.
But it’s incomplete.

Because you’re evaluating the idea…
without fully understanding the reasoning behind it.

And this is where most leaders lose information.
Critical information.

The kind that improves decisions.

The hidden cost of reacting too fast

When you respond too quickly, three things happen:

1. You cut off exploration
   The conversation narrows immediately.

2. You signal that your perspective carries more weight
   Even if you don’t say it directly.

3. You train the team to self-censor
   People start filtering before they speak.

Over time, this compounds.

You don’t just lose ideas.
You lose perspective.

And when perspective drops…
decision quality follows.

Empathy is not emotional. It’s strategic.

This is where most people get it wrong.

Empathy is not a personality trait.
It’s a decision-making advantage.

Because better understanding leads to:

Better problem framing
Better trade-off awareness
Better risk identification

Which leads to:
Better decisions.

The best leaders I’ve worked with are not the nicest people in the room.
But they are the most curious.

They don’t rush to prove a point.
They slow down to understand the full picture.

What this looks like in real conversations

Instead of saying:

“We should do X.”

They ask:

“What are you optimizing for here?”
“What constraints are you seeing?”
“What would make this fail?”
“What trade-offs are we accepting?”

These questions do something powerful.

They surface thinking.
Not just opinions.

And once you understand the thinking…
you can actually evaluate it properly.

A moment that changed how I lead

There was a situation where a junior engineer proposed a completely different way of solving a recurring issue.

My first instinct?

Dismiss it.

It felt naive.
Incomplete.
Not thought through.

But instead of shutting it down, I asked:

“Walk me through how you got there.”

And as she explained…
I realized something uncomfortable.

She was seeing a pattern we had missed.

Not because she was more experienced.
But because she was looking from a different angle.

We implemented her idea.
And it worked.

That moment forced me to accept something:

Understanding comes before evaluation.
Always.

Why this gets harder as you grow

The more senior you become, the harder empathy gets.

Not because you care less.
Because your thinking gets faster.

You’ve seen more.
You recognize patterns quicker.
You can jump to conclusions with high confidence.

And that confidence becomes dangerous.
Because it feels like accuracy.

But it’s often just:

speed + experience

Not necessarily truth.

At the same time…
your words carry more weight.

Even when you try to soften them.
Even when you say:

“I might be wrong.”

The room shifts.
People adjust.
Some challenge.
Most don’t.

And this is where leaders unknowingly create a problem:

They believe they’re open.
But the environment says otherwise.

The difference between listening and waiting to speak

Most leaders believe they’re listening.

They’re not.

They’re waiting.

Waiting for their turn to respond.
Waiting to correct.
Waiting to steer the conversation.

Real empathy requires a different mode:

Listening to understand.
Not to reply.

A simple test:

If you can’t clearly explain the other person’s reasoning…
you’re not ready to respond.

The discipline behind empathy

Empathy is not natural.

It’s trained.

It requires:

• Slowing down your reactions

• Separating ego from evaluation

• Staying in curiosity longer than feels comfortable

This is why most leaders don’t do it.
Because it feels inefficient.

But what feels slower in the moment…
is faster over time.

Because you avoid:

Bad decisions
Rework
Misalignment
Hidden resistance

A simple framework I use with leaders

When conversations get tense or unclear, I use a simple structure.

Not to control the discussion.
To deepen it.

1. Understand before evaluating

“Walk me through your thinking.”

No interruptions.
No corrections.
Just clarity.

2. Surface context

“What are you optimizing for?”

This reveals priorities.
Not just solutions.

3. Explore trade-offs

“What are we giving up with this approach?”

Every decision has a cost.
Most teams don’t articulate it.

4. Expand perspective

“What might we be missing?”

This invites better thinking.
From everyone.

5. Decide with clarity

Now you decide.

But not from ego.
From understanding.

People don’t need you to agree.
They need you to be fair.

What changes when you lead this way

Three things happen:

1. Thinking improves
   Because ideas are explored, not shut down.

2. Ownership increases
   People support what they help shape.

3. Trust deepens
   Even when you say no.

And this is the paradox:

You don’t lose authority by being empathetic.
You strengthen it.

Bonus: The real role of empathy at the top

At senior levels, empathy is not about relationships.

It’s about signal quality.

The higher you go, the more filtered reality becomes.

People soften feedback
They avoid tension
They protect you from discomfort

If you don’t actively create space for real thinking…
you operate on incomplete information.

Empathy is how you break that.

Not by being nice.

But by being:

Curious enough to explore
Calm enough to listen
Disciplined enough to not react too fast

A simple challenge

In your next conversation, try this:

Before you respond…
Summarize the other person’s thinking.

Not your interpretation.
Their actual reasoning.

Then ask:

“What did I miss?”

Most leaders skip this.
That’s why most leaders operate with partial information.

Final thought

Empathy is not about making people comfortable.
It’s about making thinking visible.

And once thinking becomes visible…
better decisions follow.

If you’re leading at any serious level, this is not optional.

Because the cost of misunderstanding…
is almost always higher than the cost of slowing down.

Early in my leadership career, I believed my job was simple:

Have the best ideas.

I was wrong.

As an engineer, that belief made perfect sense.

I was used to being the person who:

• solved the hardest problems

• optimized systems

• saw patterns others missed

• moved things forward when they got stuck

That’s how I built trust.

That’s how I got recognized.

And eventually, that’s how I became a leader.

So when I stepped into leadership, I didn’t question that model.

I just scaled it.

Push for the best solution.
Challenge weak thinking.
Make sure the team goes in the right direction.

It felt like leadership.

It looked like leadership.

But over time, I started noticing something uncomfortable.

Even when my ideas were objectively better…
pushing them often made things worse.

The moment that forced me to rethink everything

There was one situation I still remember clearly.

We were working on a critical project.

A major performance issue came up, and the team was debating how to solve it.

I had already analyzed the problem in depth.

In my mind, the answer was obvious.

My solution was:

• more efficient

• more scalable

• technically cleaner

The team, however, had a different approach.

And honestly, I didn’t think it was as good.

My instinct kicked in immediately.

Push.
Override.
Move forward.

After all, that’s what I had always done.

But something made me pause.

And I asked myself a question I hadn’t asked before:

Am I trying to get the best outcome…
or prove that I’m right?

That question slowed me down just enough to choose a different path.

Instead of shutting the discussion down, I leaned in.

I asked them to walk me through their thinking.

We explored:

• what they were optimizing for

• where they saw trade-offs

• how they planned to handle risks

And somewhere in that conversation, something shifted.

I noticed a trade-off I had completely missed.

Not a perfect solution.

But a valid one.

We went with their approach.

And yes — it wasn’t flawless.

But it worked.

And more importantly…

The team owned it.

The lesson that changed how I lead

That moment stuck with me.

Because it revealed something I hadn’t fully understood before:

Being right is not the goal of leadership.
Building a team that can think is.

That’s the shift.

And it’s not an easy one.

Because for most of your career, being right is exactly what got you here.

The leadership dilemma nobody prepares you for

At some point, every leader faces this situation:

You see what you believe is the best solution.

But your team wants to go in a different direction.

So what do you do?

You usually have two options.

Option 1: Push your idea

You ensure the strongest technical outcome.

But there’s a cost:

• the team feels overruled

• people hesitate to challenge you next time

• ownership slowly decreases

Option 2: Let the team decide

You accept the risk of a suboptimal solution.

But you gain something else:

• trust

• ownership

• learning

And this is where leadership becomes uncomfortable.

Because the real question is not:

“What is the best solution?”

It’s:

What am I optimizing for right now — correctness or capability?

Because those two don’t always align.

The trap I didn’t see at first

I used to believe something that felt very rational:

“If I’m confident, I’m probably right.”

But over time, I realized something much more uncomfortable:

Confidence is often just perspective.

Not truth.

And when you’re in a leadership position, your confidence becomes even more dangerous.

Because it carries weight.

Even when you don’t intend it to.

The hidden pressure leaders create

One thing I underestimated early on was how much influence a leader’s opinion carries.

Even when you say:

“I might be wrong.”

Even when you invite feedback.

Even when you genuinely want discussion.

The moment you share your idea, the room shifts.

People start adjusting.

Some will still challenge you.

But many will:

• soften disagreement

• hesitate to push back

• wait to see your reaction

Over time, something subtle happens.

The team stops exploring.

Not because they don’t have ideas.

But because they’ve learned that the direction is already set.

And this is how leaders accidentally create:

teams that execute well… but don’t think deeply.

The identity shift most leaders struggle with

Part of the difficulty is identity.

For years, your value was tied to:

• having strong opinions

• defending your thinking

• being decisive

That identity doesn’t disappear when you become a leader.

It follows you.

So when someone challenges your idea, it can feel like:

• your competence is questioned

• your authority is weakened

• your relevance is at risk

And that’s when ego quietly enters the conversation.

Not in an obvious way.

But in subtle thoughts like:

• “They don’t see what I see.”

• “I need to steer this back.”

• “We’re going in the wrong direction.”

And suddenly, you’re no longer facilitating thinking.

You’re protecting your idea.

The shift that changes everything

At some point, leadership stops being about answers.

And starts being about environments.

Your job is not to have the best ideas.
Your job is to create the conditions where the best ideas emerge.

And the simplest way to do that is:

Lead with questions, not answers.

What that looks like in real life

Instead of saying:

“Here’s what we should do.”

Try:

• “What trade-offs do you see?”

• “What might we be missing?”

• “How would this fail?”

• “What would make this approach stronger?”

These questions do something powerful.

They shift ownership.

The conversation becomes collective.

Not directional.

And when that happens, the quality of thinking improves.

A real-world example of this mindset

One leader who embodies this approach well is Satya Nadella.

When he became CEO of Microsoft, he didn’t focus on having all the answers.

He focused on changing how people think.

He moved the culture from:

know-it-all

to:

learn-it-all

That shift alone changed how teams operated:

• more curiosity

• more openness

• more experimentation

And ultimately, better outcomes.

What kind of leader are you becoming?

Over time, I started noticing a pattern.

There are two very different types of leaders.

The “always right” leader

• decisions are fast

• execution is strong

• but contribution is limited

Why?

Because people learn:

“My ideas don’t really matter here.”

So they stop offering them.

The “thinking environment” leader

• discussions are richer

• ideas evolve

• ownership spreads

Because people feel:

“My thinking is valued here.”

And that changes everything.

A simple framework I use with teams

When discussions get stuck or ideas start clashing, I use something simple:

Guided Decision Canvas

It removes ego.

And brings clarity.

1. What problem are we really solving?

You’d be surprised how often teams are misaligned here.

Ask:

“Can someone describe the problem in one sentence?”

2. What does a great solution need?

Define success first.

For example:

• scalable

• maintainable

• aligned with business goals

Now you have shared criteria.

3. What options do we have?

Only now compare ideas.

But instead of:

“Which idea is better?”

Ask:

“Which idea best fits our criteria?”

Why this works so well

Because it changes the dynamic from:

my idea vs your idea

to:

what actually works best

It:

• encourages quieter voices

• aligns the team

• builds ownership

And most importantly:

It removes you from the center of every decision.

Which is exactly what leadership requires.

Your next leadership challenge

Try this once.

The next time your team proposes an idea:

Pause.

Don’t jump in.

Don’t correct immediately.

Lead with questions.

Let them explore.

Let them think.

Let them own it.

You might be surprised by what they come up with.

Final thought

Letting go of your ideas doesn’t mean lowering your standards.

It means raising the standard of thinking around you.

Great leaders are not remembered for their ideas.
They are remembered for the people they helped grow.