When devs still depend on you after a year

Start by looking at your fears, not their skills.

If you have middle or senior developers who have been in the project for a year or more, and they still come to you for tickets, that is a signal.
The instinct is to look at them.
Look at their skills.
Look at their decisions.
Look at their speed.
But the real place to start is you.
Often, the dependency is not about capability.
It is about you, the Tech Lead, your internal patterns:

1. Attachment to deadlines

2. People pleasing toward the team or stakeholders

3. Fear of what it means if someone else delivers something imperfect

Not about the developers.
About you.

What Is This Really About

Ask yourself:
”If we don’t deliver on time, what does that say about me?”
Hidden beliefs often sound like:
I am not reliable.
I am not good enough as a Tech Lead.
I am the bottleneck.
I do not care enough.
My manager will see me as failing.

If you carry these beliefs, you will naturally take over. This is the impact.
You will answer every question.
You will jump in too fast.
You will protect them and rescue them.
And you will train them to depend on you.
Not because they cannot solve things.
Because the pattern keeps being reinforced.

This is why the inner work matters.

Communicate the change

Do not surprise them with a new way of working. Communicate it clearly in a 1:1:
”My intention is to help you become independent on tickets. I trust you and your experience. I want you to go directly to the right people for business questions and to reason through the technical side before coming to me. Or going to your colleagues before coming to me. You may make mistakes at first. That is part of growth.”

This gives clarity.
This gives psychological safety.
It shows you are not stepping back.
You are supporting their independence.

Start teaching independence

Your next job is to break the pattern you helped create.
When a developer comes to you:

1. If it is a business question
   Redirect them:
   ”This needs a BA or PO clarification. Please check with them.”
   Then add: “Next time, can you please go to them directly?”

2. If it is a technical question
   Do not give the answer. Your goal is to grow their thinking.

   Option 1. Ask: “What do you think?”
   They propose a direction. You guide if needed.

   Option 2. Create space for independent thinking
   ”Take 30 minutes to explore the options on you own, then come back and we will review together.”

   They learn to trust their mind before using yours.

   Option 3. Point them to resources, not solutions
   For example:

   “Check how we did it in module X.”
   ”Look at feature Y, the logic is similar.”
   ”Search the repo for Z. We solved something close last month.”

   This teaches them how to find answers.

The outcome

When you stop over-owning and stop pleasing everyone, you create space for others to rise.
You will see:

• More ownership

• Fewer interruptions

• Stronger problem solving

• Developers who know the system deeply

And you will no longer feel overwhelmed.
No longer carrying everything alone.

This is how they grow.
This is how you grow as a team.
And this is how you grow as a Tech Lead.

I believe in you,
Andra