How to Find a Lead in Your Team

The question is often framed like this:

Who should we promote to Team Lead?

I would start with a different question:

Who is already acting as a leader — and what kind of leadership are they actually providing?

Leadership often appears before the title does. You can appoint someone as a manager, but you cannot make them an authority by decree. And the opposite is also true: someone may have no Lead in their title, yet the team still waits for their opinion, invites them into difficult discussions, and trusts their judgment.

So the first step is not assigning titles. It is observing how the team already works.

What kind of leader are you looking at?

Imagine a team of eight people.

Whenever a difficult technical question appears, everyone looks at Max. Neighboring teams also come to him for advice and treat his answer almost as the technical position of the whole team.

Formally, Max may be a Senior Developer. In practice, he is already performing the role of Technical Lead.

John may not be the strongest engineer in the team, but he notices blockers, organizes discussions, knows when something should be escalated, finds help, and makes sure work does not silently stall.

That is Team Leadership.

I roughly separate the two roles like this:

Technical Lead is responsible for technical direction, difficult engineering decisions, technical risk, and the growth of technical expertise inside the team.

Team Lead is responsible for the movement and outcome of the team: delivery, coordination, dependencies, blockers, escalation, and representing the team externally.

Sometimes one person can perform both roles extremely well. But treating that as the default is risky. You may end up with half of a technical expert and half of a manager.

A Team Lead does not have to be the strongest engineer

In one feature team of roughly eight people, I appointed a Middle QA engineer as Team Lead instead of choosing the strongest backend developer.

He was not an expert in PostgreSQL, Kubernetes, or networking. But he understood how the work moved through the team: who was blocking us, where approval was needed, when a problem had to be escalated, who needed help, and who could provide it.

He could not solve every problem himself.

But he could create an environment in which the problem would be solved.

For me, that is one of the core responsibilities of a Team Lead.

A leader does not need to know every answer

In another project, Elasticsearch was an important part of the product, but I was not a strong Elasticsearch engineer myself.

Instead of trying to become the main expert, I solved a different problem: I found a Senior Developer inside the team who could grow in that area, sent him for additional training, and connected the team with stronger Elasticsearch specialists elsewhere in the company for reviews and difficult decisions.

After some time, other teams were already coming to us for Elasticsearch advice. People often came to me directly and were surprised when I redirected them to an ordinary Senior Developer.

But I did not need to be the strongest specialist.

A leader does not need to know every answer. A leader needs to make sure the team has access to the right answers.

Team Lead and Technical Lead are roles, not necessarily job titles

It is useful to think about Team Lead and Technical Lead not only as formal positions.

A Middle Java Developer may perform the Team Lead role, while a Senior .NET Developer next to them performs the Technical Lead role.

For a Team Lead, formal authority is especially important. If someone is expected to represent the team, change priorities, resolve conflicts, and escalate problems, the organization should explicitly give them that authority.

Technical authority can remain informal for much longer:

For this module, listen to Max.

Having several Technical Leads or technical authorities in one team is usually fine. Having several competing Team Leads is much more dangerous because it quickly becomes unclear who sets priorities and who is ultimately accountable for delivery.

Team Lead and Technical Lead should reinforce each other

A Technical Lead may say:

Technically, MongoDB is the better choice here.

The Team Lead may answer:

I agree with the technical arguments, but we cannot support another production database right now.

Both may be correct.

The Team Lead may have additional organizational context: budget changes, an upcoming DevOps reduction, a future reorganization, or other constraints that cannot always be shared publicly.

So not every controversial technical decision is evidence of technical incompetence. Sometimes the decision space is larger than the context available to a particular engineer.

At the same time, disagreement from the Technical Lead should not simply disappear. It can be recorded in an ADR together with the reasons behind the final decision. Six months later, the team should be able to understand not only what was chosen, but why.

The Team Lead is accountable for the team’s decisions

This is where expertise and accountability become different things.

Suppose Max, as Technical Lead, strongly recommends PostgreSQL for document storage. The Team Lead prefers MongoDB, but after discussion agrees with the PostgreSQL approach.

A year later, the decision turns out to be painful.

This is a bad answer from the Team Lead:

I was against it. Max wanted PostgreSQL. He is the Technical Lead — ask him.

No.

If the decision was made by the team under your leadership and you allowed it to proceed, externally it is your team’s decision.

The Team Lead could have requested a spike, a second opinion, more data, or even vetoed the Technical Lead’s recommendation. But once the decision has been accepted and the team starts implementing it, accountability cannot later be handed back to the person who proposed the idea.

Internally, the team can analyze the mistake during a retrospective. Externally, the position is simpler:

I am accountable for the decisions my team made under my leadership.

This does not mean the Team Lead should always force their own preference. Quite the opposite: they should allow specialists to be stronger than them and make full use of their expertise.

But:

Delegation of expertise is not delegation of accountability.

Authority can also get in the way

A strong Technical Lead has another problem: their opinion influences everyone else before the discussion even starts.

If, during planning poker, the Tech Lead says first:

This is 8 points.

A Middle engineer who was thinking 3 may immediately start doubting their own estimate.

Authority creates an anchor.

That is why, in group estimation or technical decision sessions, I prefer the strongest technical authority to speak last. First collect independent opinions, then hear the Technical Lead, and only then discuss the differences.

Expertise should help the team think, not replace the team’s thinking.

Bus factor applies to Team Leads too

Bus factor is usually discussed in terms of technical knowledge:

Only Max understands Elasticsearch.

A good Technical Lead should reduce that dependency through mentoring, reviews, documentation, and knowledge sharing.

But there is also a management bus factor:

Only John understands how this team actually works.

If the Team Lead gets sick and the team suddenly does not know who makes decisions, removes blockers, or coordinates with other teams, that is the same kind of organizational risk.

A Team Lead should therefore also have a successor.

Sometimes you can delegate an entire role

At one point, I was performing both Team Lead and Technical Lead responsibilities in the same team. A difficult technical problem appeared that, at that moment, only I could solve.

I could not delegate the technical task.

But I could delegate something else:

the entire Team Lead role.

For one sprint, I told the team:

For coordination, priorities, and delivery questions, go to my successor. For this sprint, he is the Team Lead.

I focused almost entirely on the technical problem and quickly lost part of the operational context of the team.

An unusual situation emerged: my successor effectively had Team Lead authority over me as well. If he said that something was not the current priority or that he needed a result from me by a certain time, I had to treat that exactly as any other engineer on the team would.

And it worked.

That was when I clearly realized that delegation does not have to mean handing over individual tasks. You can temporarily delegate an entire role together with its authority.

Test a successor with real responsibility

The same approach is useful for evaluating a future Team Lead.

Instead of relying only on theoretical assessment, give the person the real role for a limited period: one sprint, the current Team Lead’s vacation, or a specific release.

Not:

Paul is helping the Team Lead.

But:

For this period, Paul is the Team Lead.

You quickly learn whether the team trusts them, whether they can make decisions, escalate problems, identify blockers, say no, and work with engineers who are technically stronger than they are.

That is much closer to the real job than another competency matrix.

It should not be the first step in someone’s development, but it can be a very useful final test before promotion.

How to find leaders inside your team

You do not need a complicated assessment to start. Observe:

• who people go to when they are stuck;
• who gets invited into difficult discussions;
• whose opinion neighboring teams ask for;
• who notices blockers first;
• who helps others make decisions;
• who already speaks on behalf of the team.

Then ask the next question:

Is this technical leadership or organizational leadership?

Do not start with:

Who wants a promotion?

Someone may strongly want the title while not yet demonstrating leadership behavior. Another person may already have been leading part of the team for six months without considering it unusual.

Start with behavior. Discuss the title later.

For a team of around ten people

If a team approaches ten people, I would ideally want something close to this:

Team Lead
├── Team Lead successor
└── Technical Lead / strong technical authority

These do not have to be three formal positions. They are three roles.

The Team Lead is accountable for the team’s movement and outcome. The successor reduces management bus factor. The Technical Lead — or several strong technical authorities — provides technical direction and prevents the Team Lead from becoming the single source of every technical decision.

Grow internally or hire externally?

The future Team Lead does not always have to come from inside the team. Sometimes bringing in someone from another team or another company is the better decision.

The obvious advantage is speed: instead of spending months developing someone internally, you may get a person with the required experience almost immediately.

But external hiring has an important risk.

If the team already has a de facto leader whom you decided not to promote, the new Team Lead is not entering an empty space. Formally, there is now one manager, but the team’s social authority may still belong to someone else.

That can easily create exactly the situation you wanted to avoid:

two Team Leads — one formal and one de facto.

This does not necessarily mean either person is ambitious or difficult. The team simply already trusts someone, while the new leader still needs to earn that trust.

Before hiring externally, understand:

• whether a de facto Team Leader already exists;
• why you are not promoting that person;
• how they feel about the decision;
• what role they will have after the new Team Lead arrives;
• how authority and accountability will be divided.

An external Team Lead may still be the right decision. They can bring experience that does not exist inside the team, challenge established habits, and close a leadership gap much faster.

But appointing someone does not erase the social structure that already exists.

You can assign a management title in one day. Leadership and trust still have to be earned.

First identify the leadership that already exists inside the team. Only then decide how to name it, grow it, or formalize it.