Skip to content

Start here

Introduction#

Many Tech Leads step up from engineering roles with little preparation. Overnight, the job expands from writing good code to leading people, shaping how the team works, and owning the technical direction. Many don’t find the advice available in books and elsewhere easy to find or put into practice.

This handbook brings practical guidance on the whole role together in one place. It is written for aspiring, new, and established Tech Leads, and also aims to be useful for Senior Engineers, Product Managers, Scrum Masters, Architects, Testers, and others who work alongside them.

A Tech Lead is accountable for the technical outcomes of their team and for how effectively it works, and achieves both mainly through the team. The specifics vary widely between organisations, as What is a Tech Lead? explains.

The approach#

  • Opinionated defaults. Rather than surveying every option, each page recommends an approach that is a good default and explains why it works. Adapt it to your context, but it’s worth understanding the reasoning first.
  • Grounded in practice. The advice comes from leading real teams, and is illustrated with concrete examples and scenarios.
  • Mistakes as well as methods. Each page highlights the common mistakes, because knowing what to avoid is often as useful as knowing what to do.
  • The whole role. People, ways of working, and technical practices are closely connected, so the pages link to each other rather than treating each topic in isolation.

What you’ll find#

The handbook answers questions like these:

  • How do I stay technical without getting in the way? Take work off the critical path, and don’t take the hardest story. See Staying technical without getting in the way.
  • How do I represent a decision I disagree with? Disagree in the right forum, then commit and represent the decision honestly. See Representing decisions you did not make.
  • How do I make one-to-ones worth having? Focus on the person, not the work. The meeting belongs to them, not to you. See One-to-ones.
  • How do I hand work over without losing sight of the outcome? Set clear objectives, clarify the guardrails, and check you share an understanding. See Delegation.
  • What do I do when someone in my team is underperforming? Seek first to understand, then agree goals and a clear process. See Performance improvement.
  • How do we break features down so they deliver value early? Slice vertically through the functionality, not horizontally by technology layer. See Feature slicing.
  • How do we make retrospectives actually change things? Hold them every two weeks without fail, and turn every discussion into an action, a change, or a conscious decision. See Retrospectives.
  • Who should write the tests, and when? Mostly the developers, as part of implementation, with specialist testers focusing where their skills add most. See Testing.

Where to begin#

  • New to leading, or thinking about it? Start with What is a Tech Lead? for what the role involves, then Starting to lead for how it differs from the one you had before and how to approach your first few weeks.
  • Already leading a team? Dip into whichever section addresses what you are facing. Each page ends with key points and mistakes to avoid, which support making a quick check against how your team works today.
  • Not a line manager? Most of the People section still applies. One-to-ones, delegation, and feedback are leadership skills rather than management ones, and most Tech Leads use them whether or not anyone reports to them.
  • Trying to improve how disciplines work together? Ways of working and Practices describe how a team can plan, build, and improve, and how practices like Testing and Product design fit together. They set out who does what, and how each discipline’s work connects to the others’.

Using it with your team#

The pages are written to be shared, and work well as a common reference for the whole team:

  • Introducing a technique. Point the team to the relevant page before discussing it, so everyone starts from the same understanding.
  • Reviewing how you work. Use a page as a reference point in a retrospective, to compare how the team works today with a good default.
  • Onboarding. Give new joiners the pages that describe how the team works, so they can get up to speed without relying on word of mouth.

About the author#

The handbook is written by Ivor Caldwell ↗, who has led engineering teams and functions in Tech Lead, Principal Engineer, Head of Engineering and Technology Director roles. He now works with organisations to help them optimise their engineering culture and ways of working.

Work in progress#

By design, this handbook is a work in progress, and will be extended, updated, and improved over time.

If you have experiences to share, or if you find something confusing, wrong, or incomplete, please get in touch ↗.