Starting to lead

Introduction#

Stepping into a lead position for the first time is a change of role, not a promotion within the same role. The work you are judged on, the skills you rely on, and the way you know you are doing well all change significantly.

The skills that worked in your previous role are still valuable, but there are many new skills that you will need to develop to succeed in a lead role. These skills are learnable, and this page and others in the handbook, along with the linked resources, will help you learn them.

This page explains the difference between leadership and management, how the role changes as you progress, what success looks like, the skills you will need to build, how to represent decisions you did not make, the behaviours to let go of and take up, the mindset that helps, and how to approach your first few weeks.

Leadership and management#

Attributed to Grace Hopper

You manage things; you lead people.

Many people whose careers have been anchored in technical engineering roles have misgivings about moving into what they see as a management role. While Tech Lead roles do include an element of management, the emphasis is more on leadership, and you will still make use of your technical skills, just in somewhat different ways.

The differences between leadership and management are illustrated below.

Leadership	Management
Exists at all levels.	Mostly sits in specific roles.
Relies on creativity and problem solving.	Relies on consistency and predictability.
Sets and communicates direction.	Defines and applies processes.
Repeats the message until it lands.	Tracks progress.
Nurtures and guides the culture.	Ensures processes are followed.

The better you lead, the less you will have to manage. If your team members are clear on the goals, understand the rationale, and feel motivated and empowered, you will spend much less energy tracking progress and checking compliance.

As a senior engineer, you will have started to develop some of these leadership skills, while others will be less familiar. Leadership is not granted by title, and it exists at all levels. A senior engineer who spots a better approach and brings the team with them is leading. So is a tester who changes how the team thinks about quality.

A lead role gives you accountability, but it does not give you automatic influence. People follow you because of how you behave, not because of your job title.

The path to leadership#

Each step in your career typically increases the scale of your responsibility. But the step into team leadership sharply reduces your direct control over outcomes.

Journey to Tech Lead. The move to Tech Lead is marked by a dramatic reduction in direct control of outcomes.

From early career through mid-level to senior engineer, your scope grows and so does your direct control. A senior engineer can personally make a big difference to how a feature turns out. When you step into leading a team, your scope grows again but your direct control drops sharply, because most of what you are now responsible for is done by other people.

Role	Rough balance of skills	Success mostly depends on
Senior individual contributor	80% technical : 20% leadership	Implementing changes well and helping others do the same. Leadership focus is mostly on self-leadership, negotiating, and influencing.
Single team lead	40% technical : 60% leadership	The team’s delivery, health, and growth, alongside your own technical contribution.
Multi-team lead	25% technical : 75% leadership	Direction, alignment, and culture across teams, and the leads you support. Technical judgement still matters for technical leaders.

These splits are rough defaults. The size of the team, the maturity of the organisation, and how many other leaders are around you all shift the balance.

This transition is difficult for many, for several reasons:

You now act through others. Outcomes depend on the actions of people you can influence but not control.
Feedback loops lengthen. As an engineer, you get fast feedback and work in short cycles of implementing tickets. As a leader, you focus on much longer horizons of projects and team members’ careers.
Your contribution is harder to see. A lot of your time will be spent getting people unstuck, shaping work before it reaches a sprint, and meeting people from other teams, none of which is as visible as items moving across the board.

Reframe: your output is now your team’s output

Instead of judging yourself on the tickets you implement, focus on how effectively the whole team is operating.

Not the only path#

Many people find the progression to leading a team challenging but highly rewarding. But this is not the case for everyone, and it is not the only way to progress. Many organisations have Staff and Principal engineer roles for people who want to keep growing as technologists. These roles also demand leadership, such as influencing without authority, setting technical direction across teams, and mentoring, but with less responsibility for people.

The choice between the two paths is also reversible. Charity Majors’s post The engineer/manager pendulum ↗ argues that swinging between hands-on engineering and management can make you better at both. If you try leading and decide it’s not something you want to do at this time, that is useful learning, not failure, and switching back to a more technical role does not exclude you from trying leadership again in future.

What success looks like#

Success as a lead is less tangible and less immediate than success as an engineer. Some don’t enjoy this, but for others the increased scope of the role feels like a natural and rewarding way to have a greater impact.

A successful lead builds:

A happy team. People who enjoy their work, are motivated to go the extra mile, and want to stay in the team and with the organisation.
A resilient team. Single points of failure are minimised, including you, and the team copes well with absence, change, and pressure.
People who are developing. Individuals growing in skill, confidence, and the scope and scale of their contribution.
A process that works. The team delivering predictably and continuously improving how it works.
High performance with high support. Motivated people who stretch to achieve big things, with support to help them succeed.

Challenge and support#

To expand on the last point above, people do their best work when they are both stretched and supported. Take away either one and performance suffers, in different ways.

We can visualise this as a combination of two dimensions, challenge and support, using John Blakey and Ian Day’s ↗ model. (Similarly, Kim Scott’s Radical Candor ↗ says the most effective feedback combines caring personally [supporting] with challenging directly.)

	Low challenge	High challenge
High support	Comfort The team is pleasant to be in, but people stop growing and the most able get bored.	Growth People take on hard problems with the help they need to succeed.
Low support	Apathy Little is expected and little is delivered.	Stress People are stretched without help, so they cut corners, burn out, or leave.

New leads tend to lean one way or the other.

If you came to the role as a strong engineer, you may strongly challenge your team members without the necessary support, expecting others to work the way you do. Add support by agreeing clear goals, making time to help, and checking in before problems grow.
If you want to be liked, you may give excessive support without sufficient challenge, and avoid difficult conversations. Add challenge by setting stretching goals and giving honest feedback, even when it is uncomfortable.

Signals to watch#

Because the outcomes described in What success looks like take time to show, look for signals that tell you whether you are heading in the right direction.

Signal	What it tells you
Others volunteer good solutions and good decisions get made while you are away.	The team understands the goals and has the confidence and authority to act. See delegation.
Cycle time is moving in the right direction, towards short and stable.	Work flows without getting stuck, including waiting for you. See SDLC.
People take ownership of retrospective actions.	The team owns its process and improvement is real. See retrospectives.
People proactively raise problems early and constructively.	People feel safe raising concerns, and trust you to respond well.
People ask for stretch work.	They are growing and see a future in the team.

These signals:

Give you something real to measure. Without them, you will judge yourself by your commits and feel unproductive even when the team is thriving.
Stop you pulling work back. A lead who feels unproductive often starts taking on coding tasks to feel useful, which leads straight to the problems described in changing behaviours.

The skills you will need#

Most new leads haven’t yet developed all the skills the role needs, and that is normal. They are different from engineering skills, but they become easier with practice and experience.

Several are covered in depth elsewhere in the handbook.

Listening. Ask open questions, then leave space for others to speak. See one-to-ones.
Coaching to help people solve their own problems. Every problem you take away is a capability not built. See one-to-ones and delegation.
Laying the path. Much more of your time goes into shaping work so the team can move quickly. See feature slicing and walking skeleton.
Pastoral care. The wellbeing, development, and performance of the people in your team are now your concern, not purely someone else’s problem. Even where line management sits elsewhere, you will usually be the first to notice when something is wrong. See feedback, performance improvement, and neurodiversity.
Communicating. You will spend far more time talking and writing: explaining direction to the team, representing the team to stakeholders, coordinating with other teams, and writing things down so they don’t depend on you being in the room. Repetition is essential to build and maintain alignment, and by the time you are tired of saying something, people are often just starting to hear it. See delegation.

The rest of this section covers three skills not addressed elsewhere.

Resolving disagreement#

Disagreement in a team can be a healthy indication that people care and are thinking. But unresolved or unconstructive disagreement is not healthy: it festers, slows decisions down, and turns technical debates into personal grievances.

When two people or two camps disagree, work through it deliberately.

Facilitate, don’t dictate. Position your role as helping people find the best outcome, rather than defaulting to arbiter, which robs them of their agency.
Separate the people from the problem. Frame the discussion around the options and the goal, not around who proposed what.
Make sure each position is understood. Ask each side to explain the other’s view to their satisfaction. This sometimes dissolves the disagreement, because people realise they were arguing about different things.
Agree the criteria. What matters most for this decision, e.g. speed, cost, risk, or long-term maintainability? Disagreements about solutions are often really disagreements about priorities.
Agree how the decision will be made. A good default is that you will aim to achieve consensus, but that you will have the final say if consensus can’t be reached. Agree this before the discussion, not after. But beware jumping in too early. It is very rare that consensus genuinely can’t be reached if each camp fully understands the rationale behind the other’s starting position.
Decide, and then commit together. Once a decision is made, everyone supports it, including the people who argued against it. Record it, and the reasoning, so it does not get relitigated.

People can usually accept a decision they disagreed with if they felt heard and understood why it was made.

Judging when to dive in#

When becoming a team lead, you will need to step out of much of the detail — but not all of it. The skill is keeping enough awareness to know when work is at risk of stalling or going in the wrong direction, and stepping in at the right moment.

Common warning signs include:

An item that has been in implementation much longer than the team’s usual cycle time.
Reports that an item is “nearly done” at the daily meeting two days running.
A pull request with a long, circular review thread.
Someone who has gone quiet, or stopped asking questions.
A design that has grown much more complicated than the problem seems to warrant.

When you see a sign like this, start with a question rather than a solution: “How’s that going? Anything I can help with?” Often that is enough. If it isn’t, step in explicitly and in proportion, as described in delegation.

Staying technical without getting in the way#

As a Tech Lead you still need technical depth. It gives you credibility, keeps your judgement sharp, and helps you spot the warning signs mentioned above. But the way you contribute technically has to change.

Take work off the critical path. Tooling, small improvements, bug fixes, and spikes are ideal, because nobody is blocked if you get pulled into a meeting. Developing proofs of concept (PoCs) for future work can be a good option, though be careful not to become a blocker or hoard this interesting work, and make sure others get a chance to do it too.
Review code for insight, not as a gate. Reviewing a sample keeps you close to the codebase. Requiring your review on every change makes you a bottleneck.
Pair with people. It spreads your knowledge, lets you see how the team works, and builds their skills far faster than reviewing their output.
Don’t take the hardest story. You will be interrupted more than anyone else in the team, so you should avoid taking on the work that most needs sustained focus.

Let go

If a piece of work would block the team when you are called away, someone else should do it.

Example: a week before and after

Here is roughly how a week might look for someone before and after stepping up to lead a team of six.

Activity	Senior engineer (hours)	Team lead (hours)
Coding	24	8
Code review	5	4
Team meetings	5	6
One-to-ones	0.5	3
Stakeholders and other teams	1.5	7
Planning, design, and writing	3	7
Helping teammates and interruptions	1	5

The lead’s week produces much less that can be easily pointed at. But the hours in one-to-ones, planning, and conversations with other teams are what keep six people working on the right things without becoming blocked. That is a far bigger contribution than the sixteen hours of coding that were given up, even though it may not feel like it at first.

Representing decisions you did not make#

As a lead, you are now part of how decisions are communicated through the organisation. Some of them you will disagree with, but it’s important to disagree in the right forum, then commit to the decision and represent it honestly to the team.

The one-to-ones page already covers two related boundaries: don’t vent your frustrations downwards, and don’t promise what you cannot deliver. This section is about relaying decisions to the whole team, and raising your concerns upwards.

Either extreme in the way you do this causes problems:

Undermining a decision erodes trust in the whole chain. If you tell the team a decision is wrong but you have to go along with it, they learn that decisions happen to them and that leadership, including you, cannot be trusted.
Spin erodes trust with the team. If you pretend to agree with something you don’t, people can usually tell. Next time you say you support something, they may not believe you.

Avoid	Better
“Management have decided this. Don’t shoot the messenger.” distances you from the decision and tells the team that decisions are something that happen to them.	“The decision is X. As I understand it, the reason is Y. I raised a concern about Z, and here’s how we’ll handle that.” is honest about your view and about the reasoning.
“It’s a great decision and I fully support it.” when you don’t sounds hollow.	“It’s not what I’d have chosen, and I said so. But I understand why it was made, and we’re going to make it work.” is honest and still commits.
“Leave it with me, I’ll get it reversed.” creates false hope and a promise you probably cannot keep.	“I’ll pass on your concerns and let you know what I hear back. I can’t promise it’ll change.” keeps your credibility intact.

When you disagree with a decision, raise it early, in the right forum, and with evidence. Explain the consequences you expect, and offer an alternative if you have one. Then, once the decision is made, commit to it. Amazon’s leadership principles ↗ call this “disagree and commit.”

Committing never means being dishonest. If a decision crosses an ethical or legal line, it is not a matter of toeing the party line: escalate it, using your organisation’s formal routes if necessary.

Changing behaviours#

While your leadership skills are still developing, it is tempting to fall back on behaviours that have worked in the past but won’t help you succeed in your new role.

Holding on to old behaviours	Embracing new behaviours
Making most of the decisions yourself.	Helping the team make decisions, with your support.
Staying in all the detail, all of the time.	Being selective about when to get into the detail.
Enjoying the position of authority.	Enjoying the success of the team.
Becoming a bottleneck.	Acting as an enabler.
Hampering the development of others.	Promoting progression in the team.
Getting stuck in the role.	Creating the opportunity for your own progression.
Becoming frustrated and stressed.	Becoming comfortable with a changing role.

The old behaviours reinforce each other. If decisions and important work all go through you, you become a bottleneck. The team waits, so you work longer hours to keep up. You become stressed, and you have no time left to develop anyone, so nobody else becomes able to take things on. You become indispensable in the worst sense: stuck in your role because nobody can replace you.

This can happen because:

The new skills feel clumsy and the old ones feel good. Solving a technical problem gives you an immediate sense of achievement. A difficult conversation that went only moderately well does not have the same instant payback.
You are genuinely quicker yourself, in the short term. Doing it yourself is faster this time. Helping someone else learn to do it is faster longer term.
Your identity is tied to being a strong engineer. Letting go of the work can feel like letting go of part of who you are.

Being the best engineer on the team becomes a trap if you keep needing to prove it.

Letting go needs the new skills. You cannot simply stop making decisions and hope the team fills the gap. Stepping back safely depends on being able to set clear objectives, agree guardrails, verify understanding, and check in without taking the work back. Those are exactly the skills that take time to build. The delegation page explains them in detail, including how to step back one style at a time as the other person grows in confidence.

Example: holding on versus letting go

Sam has just been promoted to lead the team. The sprint’s most important story is an integration with a new payment provider, and Sam knows the old payment code better than anyone.

Holding on. Sam takes the story: “It’s quicker if I do it.” But Sam is also in sprint planning, two stakeholder meetings, and five one-to-ones that week. The story sits in implementation for six days. Meanwhile three pull requests wait for Sam’s review, and Ade, who said in a recent one-to-one that he wanted more integration work, spends the sprint fixing minor bugs. The story misses the sprint, the team is frustrated, and Sam is working evenings.

Letting go. Ade takes the story. Sam pairs with him for the first morning to share what they know about the old payment code, agrees the objective and one mid-sprint checkpoint, and asks another senior engineer to share the review load. The story is done in three days. Ade has learned the payment code, so Sam is no longer the only person who knows it, and Sam has been available to the team all week.

Letting go was uncomfortable for Sam and, uninterrupted, Sam might well have been quicker. But as a lead, Sam is never uninterrupted.

Mindset#

Having a skills gap is normal. What matters is how you respond to it. A growth mindset, the belief that your abilities can be developed through sustained effort and the right help from others, turns “I’m not good at this” into “I’m not good at this, yet.”

The feedback page introduces Carol Dweck’s work and applies it to how you see the people you lead. Here, apply it to yourself.

Fixed mindset	Growth mindset	For a new lead, that means…
Avoid challenges.	Embrace challenges.	Taking on the difficult conversation rather than retreating to the code.
Give up in response to obstacles.	Persist in the face of setbacks.	Treating a one-to-one that went badly as something to learn from, not proof that you are not cut out for this.
See effort as fruitless or worse.	See effort as the path to mastery.	Investing time in leadership skills, even when it feels less productive than coding.
Ignore or deny negative feedback.	Seek and learn from critical feedback.	Asking the team how you are doing as a lead, and acting on what you hear.
Feel threatened by others’ success.	Be inspired by others’ success.	Celebrating when someone in the team outshines you, and treating it as a success.

Investing in your leadership skills#

Leadership skills will not arrive on their own. Invest in them as deliberately as you previously invested in your technical skills.

Read. See further reading for a starting point.
Watch leaders you admire. Notice what they actually do in meetings, in difficult conversations, and when things go wrong.
Find a mentor who has made the same transition, ideally someone outside your reporting line.
Build a network of peer leads. Other people at the same stage are a source of ideas, reassurance, and honest comparison.
Ask for feedback on your leadership. A question like “What could I change in how I’m leading the team?” in your one-to-ones will give you valuable insights. See receiving feedback for how to take it well.
Reflect regularly. A few lines at the end of each week on what went well and what you would do differently builds self-awareness quickly.

A note on the ‘false’ growth mindset, and on impostor feelings

Dweck has warned against what she calls a “false growth mindset”: praising effort alone, or claiming a growth mindset without acting on it. Effort only helps when it leads to learning, which often means trying new strategies and asking for help rather than pushing harder in the same direction.

It is very common to feel like an impostor in your first lead role. That feeling often means you are stretched, not that you are in the wrong job.

Your first few weeks#

How you start depends on how you came to the role. There are three common scenarios, and each is easier in some ways and harder in others.

In every situation:

Agree expectations and decision rights with your manager. Management 3.0’s Delegation Poker works just as well between you and your own manager as between you and your team. Go through the decision areas that matter and agree a level for each. It surfaces mismatched assumptions before they cause friction, and being on the receiving end first is good preparation for using it with your team. While you are at it, agree how your success will be judged and how much coding is expected of you.
Set up regular one-to-ones with everyone in the team, including people you do not line manage. See who to have one-to-ones with.
Write down the process. For an existing team, write down how it works now, as a starting point for improving it. For a new team, write down a simple starting process. See SDLC.
Check that things are working after about three months, against the signals.

Example: agreeing decision rights with your manager

Leila’s manager, Dan, suggests a round of Delegation Poker in her first week as lead. They each pick a card for every decision area, then compare. The levels are seen from Dan’s side, from 1 (Dan decides and tells Leila) to 7 (Leila decides and Dan doesn’t need the details).

Decision area	Leila’s card	Dan’s card	Agreed
Technical approach within the team’s services	5	7	7
Changes to the team’s process	3	6	6
Changes affecting other teams’ services	4	4	4
Hiring into the team	3	4	4
Raising a formal performance concern	4	3	3

The biggest gap is on process. Leila had assumed she needed Dan’s approval to change how the team runs its retrospectives and daily meeting. Dan had assumed she would just get on with it. Without the conversation, Leila would have waited for approval Dan never knew he was expected to give.

Scenario 1: Stepping up within your team#

This is the most common route. You already know the people, the system, and the process. Trust exists, so you can make a quick start. But relationships shift, and someone else may have wanted the role. The pull to keep coding is strongest, and you may be changing a process you helped create.

Acknowledge the change openly, in a team meeting and again in each first one-to-one. Pretending nothing has changed doesn’t work, because it has.
Talk privately to anyone who also wanted the role. Do it early, and listen more than you talk.
Expect boundaries to shift. You will now hear things in confidence, and you may need to give feedback to people who were your peers last week. Treat everyone consistently, and see the boundaries of one-to-ones on professionalism and discretion.
Hand over the areas where you were the expert, deliberately and early. Otherwise you will stay the go-to person for them, and never have time to lead.
Don’t overcorrect into authority to prove that you are the lead now. The team already knows.
Take your old frustrations to a retrospective, rather than fixing them by decree. The things that annoyed you as a team member may not annoy everyone, and the team needs to own the change.

Example: talking to a colleague who also applied

Hannah has been promoted to lead the team she has worked in for three years. Nadia, a colleague she gets on well with, also applied for the role.

Avoiding it. Hannah hopes things will blow over and doesn’t mention it. Conversations between them become stilted, and Nadia says little in meetings. Others in the team notice the tension but don’t know whether to mention it. By the time Hannah realises how disengaged Nadia has become, Nadia is looking for another job.

Addressing it. In their first one-to-one, Hannah raises it directly.

Hannah: I know you went for this role too, and I’d rather we talked about it than pretended it didn’t happen. How are you feeling about it?

Nadia: Honestly, a bit gutted. And it feels a bit awkward between us.

Hannah: I feel that too. I think you’d have been good at it, and I’d really value your support. Is there anything that would make this easier?

Nadia: I suppose I want to know whether it’s still worth me going for a lead role at some point.

Hannah: It is. I can’t promise when a role will come up, but I can help you get ready for one. Shall we work out together what experience would strengthen your case next time?

Nadia: Yes, I’d like that.

The conversation costs Hannah an uncomfortable ten minutes. It clears the air, shows Nadia that her disappointment is taken seriously, and turns a possible source of resentment into a shared goal. Note that Hannah invites Nadia to talk, is honest about the awkwardness, and makes no promises about future roles.

Scenario 2: Stepping in to lead an existing team#

You have a clean slate and fresh eyes, with no history to overcome. But you have no credibility yet, you don’t know the system or the unwritten rules, and you inherit your predecessor’s legacy.

Listen and observe before changing anything. Sit in on the team’s meetings, read the board, and ask lots of questions.
Find out why things are the way they are before removing them. G. K. Chesterton’s advice, known as Chesterton’s fence, is not to take down a fence until you know why it was put up. A process that looks pointless may be guarding against a problem you haven’t seen yet.
Make one or two early improvements with the team, ideally through a retrospective. Small, visible wins build credibility faster than a grand plan.
Don’t criticise your predecessor. The team may have liked them, and even if not, it reflects badly on you.

Scenario 3: Forming a new team#

You can shape the culture and ways of working from day one. But there are no norms or process yet, people don’t know each other, and there is pressure to deliver while the team is still forming.

Agree working agreements early, and hold retrospectives from the first sprint.
Get the team delivering together quickly. A walking skeleton is a good way to do this, because it forces the team to agree how work flows from idea to production.
Keep the initial process light, and let the team shape it as they learn what works.
Expect friction as normal. Bruce Tuckman’s model describes teams moving through forming, storming, norming, and performing. Disagreement in the early weeks is a sign the team is working things out, not that it is failing.

Key points#

Leading is a change of job, and the skills it needs are different from the ones that got you there.
Leadership and management are different, and most lead roles need a blend of both.
Stepping into leadership increases your responsibility but reduces your direct control, because you now act through others.
Your output is now your team’s output, so measure your success by the team’s health, growth, and delivery rather than your own code commits.
Aim to create an environment in your team of high challenge with high support.
Build the new skills deliberately: listening, coaching, resolving disagreement, communicating, and knowing when to dive in.
Stay technical, but off the critical path.
Disagree with decisions in the right forum, then commit and represent them honestly.
Expect a skills gap at first, and resist falling back on old behaviours to fill it.
A growth mindset turns the skills gap into investment rather than retreat.
Agree decision rights with your own manager early, for example using Delegation Poker.
Adapt how you start to your situation: stepping up in your own team, joining an existing team, or forming a new one.

Mistakes to avoid

Assuming leadership skills will arrive on their own. You will likely fall back on what you already know.
Staying the lead developer. Work will become blocked waiting for you.
Leaving decision rights unclear with your manager. You either overstep or hold back, and both erode trust.
Changing everything in the first month. You lose trust before you have earned it.
Measuring yourself by your own output. You feel unproductive and pull work back.
Passing the buck on decisions. Trust erodes in both directions.
Ignoring the shift in relationships when leading former peers, letting resentment fester.
Going it alone. Stress builds with no outlet and no source of fresh ideas.