Lead Engineer to Technical Team Lead

🎯 Focus Areas

The Identity Shift

The hardest part of becoming a TTL is not learning new skills - it is unlearning the identity of the engineer who solves the hard technical problems. Your success is now measured by your team's output, not your own. If the team is struggling and you are heads-down coding, you are doing the wrong job. This transition takes deliberate, sustained effort.

Running a High-Performing Team

High-performing teams do not happen by accident. They require clear goals, psychological safety, effective processes, visible work, and regular feedback loops. A TTL actively designs the conditions for performance rather than assuming a competent group of people will naturally work well together.

Giving Effective Feedback

Feedback is the TTL's primary growth tool for their team. This means regular one-to-ones that are genuinely useful rather than status updates, specific and timely feedback on both performance and behaviour, and the courage to have difficult conversations before small issues become large ones.

Delivery and Technical Credibility

The TTL still writes code - not as the primary contributor but enough to stay technically credible, to understand what the team is dealing with, and to make well-grounded technical decisions. The balance is roughly 60-70% leadership activity, 30-40% technical work, depending on team size.

Managing Performance

TTLs are accountable for their team's performance, which means addressing underperformance directly and early. This is uncomfortable for engineers who have spent their careers in collegial technical relationships. Avoiding difficult conversations does not make them go away - it makes them harder and damages team performance in the meantime.

⚡ Skills & Behaviours to Develop

Skills to Develop

Run effective one-to-one meetings with each team member - establishing a consistent cadence, making them two-way conversations, and tracking actions and growth over time.
Give specific, timely behavioural feedback - separating observation from interpretation and focusing on impact rather than personality.
Set clear, measurable goals with team members and track progress without micromanaging the execution.
Facilitate effective team ceremonies - sprint planning, retrospectives, and technical design discussions - that produce outcomes rather than consuming time.
Identify and address team delivery risks early, distinguishing between velocity issues that require coaching and systemic issues that require process change.
Build a team operating model - ways of working, communication norms, decision rights - that the team genuinely owns and follows.
Make staffing and work allocation decisions that develop people's skills while meeting delivery commitments.
Communicate team capacity, progress, and risks to stakeholders in a form they can act on.

Behaviours to Demonstrate

Spends more time enabling team members than personally solving technical problems, even when the personal solution would be faster.
Gives feedback frequently enough that performance reviews contain no surprises for team members.
Creates genuine psychological safety - team members raise risks and mistakes early rather than hiding them.
Advocates for team members' development, recognition, and working conditions as a primary responsibility.
Addresses underperformance directly and early, rather than managing around it or waiting for it to resolve itself.
Keeps the team shielded from unnecessary organisational noise while making relevant context and direction visible.
Makes technical decisions transparently, inviting input rather than relying purely on personal technical authority.

🛠 Hands-On Projects

1 Run a structured team retrospective that actually changes how the team works, then follow up four weeks later to assess whether the changes stuck.

2 Have a difficult feedback conversation with a team member about a performance or behaviour issue you have been putting off, then reflect on what made it hard and what you would do differently.

3 Build a six-month growth plan with each team member - identifying their goals, the gap to get there, and the specific actions you will take to support them.

4 Define the team's ways of working document collaboratively, covering decision-making, communication, code review standards, and on-call responsibilities.

5 Track your team's DORA metrics for a quarter - deployment frequency, lead time, change failure rate, and recovery time - and use the data to facilitate a focused improvement conversation.

6 Shadow your engineering manager for a month, noting the decisions they make and the conversations they have that you are not yet having as a TTL.

⚡ AI Literacy for This Transition

AI in team processes and responsible adoption leadership

Develop your team's position on AI coding tool adoption - run the conversation explicitly, establish shared norms, and document them rather than letting ad-hoc individual usage create inconsistency.

Use AI to help you prepare for difficult conversations by describing the situation and asking for frameworks or language - while recognising that the human judgment in the room is yours, not the AI's.

Evaluate how AI coding tool adoption is affecting your team's delivery metrics and code quality - build the habit of measuring before and after rather than assuming it is net positive.

Teach your team to review AI-generated code with the same rigour they apply to any code review - the TTL sets the standard here through their own review behaviour.

Use AI to accelerate the administrative side of your leadership work - drafting communications, summarising meeting notes, generating performance review templates - freeing time for the human work of leadership that AI cannot do.

Model critical AI evaluation behaviour for your team - visibly questioning AI-generated outputs, flagging when AI tools are wrong, and creating space for scepticism alongside enthusiasm.

📚 Recommended Reading

The Manager's Path

Camille Fournier

The clearest practical guide to the technical management track from first-time lead to CTO - the TTL chapter alone is worth the read, and knowing what comes next is equally useful.

An Elegant Puzzle: Systems of Engineering Management

Will Larson

Deeply practical on the mechanics of running engineering teams - hiring, performance, team design, and the systems thinking that separates good engineering managers from mediocre ones.

Radical Candor

Kim Scott

The most practical framework for giving honest feedback while genuinely caring about the person - the tension at the heart of the TTL role.

The Five Dysfunctions of a Team

Patrick Lencioni

A narrative model of what makes teams fail and what makes them succeed - useful for diagnosing your own team dynamics and knowing where to intervene.

Accelerate

Nicole Forsgren, Jez Humble, and Gene Kim

The research behind high-performing engineering teams gives you the evidence base for the delivery practices you want to build into your team's operating model.

🎓 Courses & Resources

Engineering Management Fundamentals

Pluralsight

Covers the practical skills of technical leadership - one-to-ones, feedback, goal setting, and delivery management - in the context of engineering teams.

Coaching Skills for Managers

Coursera / Various

Coaching is a distinct skill from managing and directing - learning it deliberately changes how you develop people and accelerates their growth.

Giving and Receiving Feedback

LinkedIn Learning

A short, focused course on the mechanics of effective feedback that most people skip because they think they already know how to give feedback.

Agile Team Leadership

Scrum Alliance or ICAgile

Running effective agile ceremonies and creating self-organising team dynamics is a learnable skill set that separates effective TTLs from ones who just attend the meetings.

📋 Role Archetypes

Review the full expectations for both roles to understand exactly what good looks like at each level.

→ Lead Engineer Archetype → Technical Team Lead Archetype