role · tech lead

Tech Lead

The Tech Lead is the technical signature on the brief. They name the constraint before code is written, hold the ADR when a choice could not be undone, and make the pipeline the first reader of every change.

What good looks like

A competent TL produces three artefacts every cycle, all of them readable by a TL on a different team:

1. A Technical Design Brief that translates the Feature Brief into sequence, schema, and API — and names the ility that is not being chased this cycle.
2. An ADR for every choice that would cost more than a day to undo, written before the code, signed by at least one other engineer.
3. A release brief & runbook for the cycle's first release — what changed, what to watch in the first 48 hours, what to do if it isn't watched.

A TL who produces these three has the technical chain working. A TL who skips the brief writes code from a guess. A TL who skips the ADR makes choices the team cannot reconstruct six weeks later.

The TL's stance

The TL is responsible for	The TL is not responsible for
The technical feasibility of the brief	What problem the brief is solving
The shape of the change — sequence, schema, API	The shape of the cycle's calendar
The ility the team is investing in this cycle	All the ilities
The pipeline catching the right level early	The PR-by-PR review queue
The postmortem's chain-level fix	Naming the person to blame

The TL holds the chain by holding the artefacts that survive the cycle: ADRs and runbooks outlive the people who wrote them.

Three artefacts to read first

1. Technical Design Brief
2. Architecture Decision Records
3. Runbooks & Rollback

First 30 days

Six gated steps. Each one has an output someone else can verify.

Day 1–3 — Read the canon

Read What We Shape Parts 6–9 (ADR, sequence/schema/API, ilities, slicing). Read As We Build Parts 4–9. Read After We Build Parts 1, 4, 5.

Output: in three sentences, name the ility the team has been over-investing in and the one it has been under-investing in.

Day 4–7 — Read the last three ADRs

Find the team's last three ADRs. Read them. For each: what alternatives were considered, what would have been different if the third option had been picked, is the decision still standing.

Output: a one-page note for each ADR — still standing · drifting · should be re-opened.

Day 8–14 — Co-sign a Technical Design Brief

Pair with the existing TL or PO on the next Feature Brief. Write the Technical Design Brief together. Use the shape from the canon.

Output: signed Technical Design Brief, with one ility named as invested and one named as deferred.

Day 15–21 — Write your first ADR

Pick one technical choice the team is making this cycle. Write the ADR before the code lands. Get one other engineer to sign.

Output: committed ADR with at least two options, including do nothing.

Day 22–25 — Read the pipeline

Walk through the pipeline stage by stage. For each stage, name the chain level it catches. Pair with the previous on-call to read the last incident's timeline.

Output: a diagram or note showing each pipeline stage and the level it is responsible for.

Day 26–30 — Drive the first 48h watch

When the cycle's first release goes out, you drive the first 48 hours. Watch dashboards (not tickets). Hold the postmortem if anything breaks.

Output: a first-48h note, plus — if relevant — a postmortem with a chain-level fix that produces an ADR or pipeline change.

By day 30 you have witnessed one full cycle from the technical side. Foundations continue in the Skills hub.

Deepening — self-rate yourself

Rate 1–5 honestly. Below 3 in any dimension means that's where to invest next.

Design discipline

• I can identify, in 10 minutes with a Feature Brief, whether sequence/schema/API can be sketched on a whiteboard or whether the brief is still too vague.
• My Technical Design Briefs say what is deferred as clearly as what is being built.
• I can refuse to start coding when one of the ilities the brief assumes has not been named.

ADR discipline

• I write the ADR before the code, not after.
• My ADRs always have at least two options, including do nothing.
• I can re-open an ADR without it being a personal moment.

Pipeline & quality

• Every pipeline stage catches a different chain level. I can name them.
• Pre-merge is loaded toward fast, structural feedback; deploy gates are loaded toward release safety.
• My team's release gate is a state, not a meeting.

Postmortem discipline

• Every incident produces a postmortem. Every postmortem produces a chain-level fix.
• The fix is owned, dated, and testable.
• The blameless rule holds even under client pressure.

Mentoring & review

• My code reviews say why this convention, not just change it.
• A second developer could pick up an ADR I wrote and reason from it.
• I have at least one engineer growing into a more senior decision each quarter.

Stuck if…

…the team keeps rewriting the same area every cycle

Probable cause: a missing ADR. Three engineers are each fixing the symptom differently. Open Volume III · ADR — write the decision once, signed.

…postmortems list five fixes and the next incident matches the first one

The fixes weren't owned, dated, or testable. Re-read After We Build · Incidents & Postmortems. One change. Owned. Dated. Testable.

…the pipeline is slow and nobody knows why

The pipeline is doing the wrong work at the wrong stage. Walk it. For each stage, ask which chain level it is catching. Move the wrong stages.

…the brief was signed but the Technical Design Brief surprises everyone

Either the TL was not at the brief, or the brief was signed without an honest feasibility read. Don't fix the design brief; re-open the Feature Brief with the trio.

…a developer rewrote the architecture during a story

The story was too big, or the architecture had no ADR. Re-read Volume III · Slicing & Prioritization. A story that requires rewriting architecture is an epic in disguise.

…leadership asks "is this safe to ship?" and you don't have a one-line answer

The release gate is a state, not a meeting — your job is to make that state legible. If you cannot answer in one line, the gate is unowned.

See also

• Skill path — Tech Lead foundations
• Canon — What We Shape · As We Build · After We Build
• Practice — Writing Technical Design Briefs · Writing ADRs · Release gate · First 48 hours watch · Postmortem
• Templates — Technical Design Brief · Feature Brief · ADR · Release brief · Runbook · Postmortem
• Checklists — Trio sign-off · ADR · ≥2 options · Release gate · First 48 hours · Postmortem
• Clinics — An ADR with one option · A flag that never got cleaned up · A postmortem that produced a feeling · A runbook that doesn't run
• Areas — 5 · Architecture · 8 · Pipeline & Operations