Skip to content

Tech Lead foundations

A six-week, ten-step path. By the end of it you have signed a Technical Design Brief, written an ADR with at least two options, watched a release through its first 48 hours, and driven one postmortem to a chain-level fix. You are not a senior TL. You are a TL whose first cycle produced artefacts the next TL can read.

How a skill works in this corpus

A skill is not a reading list. It is a scaffolded sequence of read → practice → check → reflect, anchored to your real cycle. Bring a real story from your sprint to each step that asks for it. The skill is doing its job when your work output this month is better than last month, not when you have ticked ten boxes.

Mastery looks like

When you finish this path, you can:

  • Translate a Feature Brief into sequence, schema, and API on a whiteboard in 30 minutes.
  • Write an ADR with two real options and a defensible do nothing.
  • Name the chain level each pipeline stage is responsible for.
  • Drive a first-48-hour watch that produces an honest timeline, not a heroic story.
  • Hold a postmortem that lands one chain-level fix — owned, dated, testable.

Self-rating before you start

1 — Never3 — Sometimes5 — Default
I sign a Technical Design Brief before code starts
My ADRs always have ≥2 options including do nothing
Each pipeline stage maps to a chain level
I write incident timelines during, not after
Postmortems produce one owned, dated, testable fix

Step 1 — Orient yourself in the chain

Read: Before We Build · Technical Design Brief · What We Shape · ADR · The Map.

Practice prompt: in three sentences, explain what a TL inherits from the PO's Feature Brief and what they hand to the developers.

Mini-check: if your sentences don't mention an ility you are not chasing this cycle, you are still thinking like an engineer with infinite time.


Step 2 — Read your team's last three ADRs

Read: What We Shape · ADR.

Practice prompt: open the team's last three ADRs. For each: what alternatives were considered, is the decision still standing, would a new TL be able to reason from it cold?

Output: still standing · drifting · re-open per ADR, written.


Step 3 — Co-sign a Technical Design Brief

Read: Before We Build · Technical Design Brief.

Practice prompt: pair with an experienced TL or PO on the next Feature Brief. Co-write the Technical Design Brief. Name one ility you are investing in this cycle and one you are deferring.

Mini-check: if you can't name what you are deferring, you are committing to all the ilities — which means none.


Step 4 — Write your first ADR

Read: What We Shape · ADR · What We Shape · Sequence, Schema, API.

Practice prompt: pick one technical choice the team is making this cycle. Write the ADR before the code lands. Two real options minimum, plus do nothing. Get one other engineer to sign.

Pair task: ask a more senior TL: "would you have picked the same option I did, and why?"


Step 5 — Walk the pipeline

Read: As We Build · The CI/CD Pipeline · As We Build · Testing Layers.

Practice prompt: for each pipeline stage, name the chain level it catches (L3 scope, L4 execution, L5 operation). Find one stage that is in the wrong place.

Output: a diagram or note showing each stage and the level it owns, plus the one stage you'd move.


Step 6 — Hold amigos with a developer and a QA

Read: What We Shape · Amigos & Gherkin.

Practice prompt: sit at amigos for the next story. Your job is technical feasibility — bring one risk the brief doesn't yet acknowledge. The amigos session should produce at least one negative-case Gherkin scenario from your risk.

Mini-check: if your risk was framed as "I'm worried about X", you brought a feeling. Reframe to "the data model assumes Y and we don't have Y."


Step 7 — Watch the first 48 hours

Read: After We Build · The First 48 Hours · As We Build · Observability.

Practice prompt: drive the watch on the cycle's first release. Watch dashboards (not tickets). Take a timestamped note of anything that moved.

Pair task: sit with the on-call. They watch system signals; you watch the change's signals. Compare notes at hour 2.


Step 8 — Drive a postmortem

Read: After We Build · Incidents & Postmortems.

Practice prompt: when the next incident fires (or in a game day), drive the postmortem. Walk the timeline. Identify the chain level. Land one change — owned, dated, testable.

Mini-check: if your fix is "more monitoring", you stopped at L5. Push one level up — was the brief missing a constraint? Was the ADR ever written?


Step 9 — Update a runbook

Read: As We Build · Runbooks & Rollback.

Practice prompt: find one runbook that has decayed since it was last used. Rewrite it so it reads at 2am, in adrenaline, in 30 seconds.

Pair task: have on-call read the rewritten runbook. If they can't follow it without you in the room, rewrite again.


Step 10 — Teach back, contribute back

Practice prompt: write a one-page guide for the next new TL joining your team. What I wish I'd known before my first cycle. Limit yourself to one page.

Authoring contribution: find one thing in this corpus that, after running your cycle, you now know is wrong, missing, or could be sharper. Open a PR.

Self-rating after: rate yourself again on the same five dimensions. Compare. Where did you move? Bring the gap to your next cycle.


After this path

You have run one cycle. Two more and foundational becomes practitioner.

  • TL · Practitioner (coming) — multiple parallel cycles, cross-team ADRs, mentoring a TL through their first.
  • TL · Advanced (coming) — platform-level decisions, the engineering function across the studio.

Stuck?

If you got stuck atRead
Step 3 — couldn't name what you were deferringIlities Selection
Step 4 — only had one real optionADRdo nothing is always a real option
Step 5 — pipeline stages all felt like the same levelThe CI/CD Pipeline
Step 8 — postmortem produced a list of fixesRe-read Retrospective — one change. owned. dated. testable.

200apps · How We Work · NWIRE