Sign in Get started

Free course · 20 lessons · Intermediate

The Tech Lead Handbook

A practical course for new and experienced tech leads: what the role owns, the first 90 days, balancing code and leadership, setting technical direction, design docs and ADRs, design reviews, decision speed, build vs buy, code review standards, technical debt, slicing work, probabilistic delivery forecasts, incident command, SLOs with product, delegation, cross-team dependencies and stakeholder updates — with real scenarios, scripts, templates and runnable models.

Start the course

1. The Tech Lead Role

What a tech lead is accountable for, how to start in the role, how to split time between code and leadership, and how to set technical direction.

  1. What a Tech Lead Owns — The tech lead is accountable for how the team builds, not for doing all the building. Here is what that covers, and how it differs from team lead, engineering manager and staff engineer.
  2. Your First 90 Days as a Tech Lead — A practical plan for the first three months: listen, map the system and the risks, pick one visible improvement, then set direction.
  3. Coding vs Leading: Where Your Time Goes — How much a tech lead should code, which work to keep and which to give away, with a small model of how a lead's time disappears.
  4. Setting Technical Direction — Turn a pile of opinions into two or three written technical priorities that the team, product and management all understand and actually follow.

2. Technical Decisions

Design docs and RFCs, architecture decision records, design reviews that help, decision speed, and build vs buy.

  1. Design Docs and RFCs That Get Read — How to write a design document that surfaces trade-offs early, gets useful feedback, and doesn't become a 30-page formality.
  2. Architecture Decision Records (ADRs) — Keep a short, searchable log of significant decisions, so the team stops re-arguing them and new people understand why the system looks the way it does.
  3. Running Design Reviews That Help — Design reviews should find problems early and spread knowledge, not gatekeep or become theatre. How to run them as a tech lead.
  4. Decision Speed: One-Way and Two-Way Doors — Match the decision process to the cost of being wrong: move fast on reversible choices, slow down on irreversible ones, and use 'disagree and commit' to end stalemates.
  5. Build vs Buy — A structured way to decide whether to build a capability or use a vendor or open-source product, including the costs that are usually forgotten.

3. Quality and Delivery

Code review that is fast and useful, managing technical debt deliberately, slicing work so it ships, and forecasting delivery honestly.

  1. Code Review Standards and Speed — Make code review fast and useful: what reviewers should look for, how quickly to respond, and why slow reviews cost more than they save.
  2. Managing Technical Debt Deliberately — Make technical debt visible, decide which debt to pay down, and protect a steady budget for it — with a model of how debt 'interest' eats delivery capacity.
  3. Slicing Work So It Ships — Break large projects into thin vertical slices that each deliver something usable, to cut risk and get feedback early.
  4. Forecasting Delivery Honestly — Replace single-date guesses with probabilistic forecasts from the team's own throughput, using a Monte Carlo simulation you can run.

4. Leading Across the Team and Beyond

Incident command and postmortems, agreeing reliability targets with product, growing engineers through delegation, managing cross-team dependencies, and keeping stakeholders informed.

  1. Leading Incidents and Blameless Postmortems — Run incidents with clear roles instead of everybody debugging at once, and turn them into learning with blameless postmortems.
  2. Agreeing Reliability Targets with Product — Use SLOs and error budgets to turn 'reliability vs features' from an argument into a shared rule.
  3. Mentoring and Delegation — Grow the team by delegating real ownership at the right level, instead of keeping hard problems for yourself.
  4. Managing Cross-Team Dependencies — Find dependencies early, agree interfaces and dates explicitly, and reduce dependencies over time instead of just coordinating them.
  5. Status Updates Stakeholders Trust — Write short, regular updates that make progress, risk and decisions visible, so stakeholders stop interrupting the team for status.

5. Capstone Case Studies

Rescue a slipping migration, and make and defend a rewrite-or-refactor decision.

  1. Capstone: Rescue a Slipping Migration — You take over as tech lead of a migration that is six weeks late. Diagnose, re-plan and communicate.
  2. Capstone: Rewrite or Refactor — Make and Defend the Call — Engineers want to rewrite a legacy service; product wants features. Decide, document and communicate.