Truong Phung

Posted on May 4

🧑‍💻 The Tech Lead Playbook: From Best IC to Multiplier 🚀

#ai #webdev #leadership #productivity

A deep, opinionated, practical guide for the engineer who has just been handed (or is about to be handed) a team. The tactics, mental models, decision frameworks, and anti-patterns that take you from "great individual contributor" to "the person who makes the team 3x more effective." Grounded in 2026 reality — small teams, AI-leveraged engineers, async distributed work, and a hiring market that demands you ship.

If you read only one section first, read §2 Mindset, §5 Technical Direction, and §9 The Operating Cadence. Everything else is the implementation of those three.

Companion to 🚀 The SaaS Template Playbook 📖 (how to build), 🤖 The AI SaaS Playbook (Practical Edition)📘 (how to add AI), 🦸 The Solo-Founder Playbook: Zero Hero 🚀 (operating alone), and 🏗️ Building High-Quality AI Agents 🤖 — A Comprehensive, Actionable Field Guide 📚 (agentic systems). This one is for the lead of a team of 3–10 engineers at a startup, a scale-up, or a fast pod inside a big company.

📋 Table of Contents

⚡ Read This First
🧠 The Tech Lead Mindset
🎭 Tech Lead vs Senior Eng vs Staff vs EM
🚪 The First 90 Days
🧭 Setting Technical Direction
🏛️ Architecture & Technical Decisions
📦 Project Execution: Planning → Delivery
👥 People: 1:1s, Coaching, Conflict
⏱️ The Operating Cadence
🔍 Code Review & Design Review
🔥 Incidents, On-Call & Quality
🤝 Stakeholders: PM, Design, EM, Exec
🤖 Leading in the AI Era (2026)
🧑‍🔬 Hiring & Calibration
📈 Performance, Promotion & Letting Go
🌱 Growing the Team Without Breaking It
💬 Communication: Writing, Speaking, Status
⚠️ The Tech Lead Anti-Pattern Catalog
🗺️ The Phased Roadmap (Day 1 → Year 2)
📋 Cheat Sheet & Resources

1. ⚡ Read This First

Five truths that will save you the first 18 months of mistakes every new tech lead makes:

Your job changed; your instincts did not. You were promoted because you ship. Now your job is to make other people ship. The IC reflex ("I'll just do it myself, it'll take 30 min") is the single most common failure mode of new tech leads. Every time you take a ticket your senior eng could have done, you stole a growth opportunity from them and starved your real job (direction, unblocking, design) of attention. Your output is now measured in team output, not your commits.
Influence > authority. A tech lead has almost no formal authority. You can't fire, can't change titles, often can't change comp. You lead by technical credibility (the team trusts your judgment), clarity (the team knows what to do and why), and care (people feel safer and saner when you're around). If you try to lead with "because I'm the lead," you have already lost.
The 70/20/10 rule. Roughly: 70% of your week is team enablement (design reviews, unblocking, planning, 1:1s, written docs). 20% is high-leverage technical work (the 5% of code only you can write, the spike, the migration plan, the hot path no one else has context on). 10% is learning and outside (reading, talking to other leads, looking at the market). New tech leads invert this and burn out in 6 months.
Boring is a feature. Most tech-lead failures aren't dramatic — they're slow drift. The team is "fine," velocity feels "okay," nothing is on fire, and 9 months later you realize you shipped half of what you should have. Predictable, weekly, unsexy operating rhythm beats heroic sprints every time. Set a cadence and protect it like infrastructure.
You are now a writer. The single highest-ROI skill of a tech lead in 2026 is writing: design docs, RFCs, decision records, async updates, escalations. Distributed teams, AI-augmented engineers, and async cultures all reward the person who can compress a complex idea into 600 well-structured words. If your writing is mediocre, fix it before anything else in this playbook.

The rest is implementation of these five.

Who this is for

You were just made tech lead (or about to be) of a team of 3–10 engineers.
You are an EM with deep tech roots running a similar-sized pod.
You are a senior/staff IC who has informal lead duties on a project and want to do them well.
You are a solo founder thinking about your first hires (read 🦸 The Solo-Founder Playbook: Zero Hero 🚀 §14 first, then this).

Who this is not for

You manage 30+ engineers across multiple teams. That's an engineering manager / director playbook — different game (career ladders, headcount planning, organizational design dominate).
You want pure people-management content (no code review, no architecture). This is for technical leads — the ones who still write code, own the system design, and also care for the team.
You want a single methodology (Scrum, SAFe, Shape Up). This is method-agnostic. Use whichever your org uses; the underlying principles don't change.

A note on context

The default voice assumes a product engineering team at a startup or scale-up, ~5 engineers, 2026 reality (AI-augmented coding the norm, distributed/hybrid, weekly shipping). Platform/infra/SRE leads will need to adapt cadence and metrics; the people, planning, and direction sections still apply. Big-co leads (BigTech, banks, regulated industries) should read everything but expect the political and process surface area to be 3x bigger — covered briefly in §12 and §16.

2. 🧠 The Tech Lead Mindset

The mindset shift is harder than the skill shift. Most failed tech leads were technically capable; they failed at the mental layer.

2.1 Identity reframe: from "best IC" to "force multiplier"

You used to be measured by what you shipped. Now you are measured by what your team ships, the quality of the system you steward, and the engineers who grew under you. That measurement window is also longer — months and quarters, not days. This breaks four IC instincts you must consciously rewire:

Old IC instinct	New TL instinct
"I'll just take this ticket, faster"	"Who on the team should own this, and what do they need to succeed?"
"I'll review the PR with nits"	"Is this person leveling up? What's the one thing to teach here?"
"Let me deep-focus on this for 4 hours"	"What's the minimum I need to ship myself to unblock 3 others?"
"I want to be in the build"	"I want the build to happen correctly, even if I'm not in it"

Practical: write a one-line role description and pin it to your monitor. "I am the tech lead of Team X. My job is to make the next 5 engineers on this team ship the right things, faster, and grow." If you can't articulate this, your team can't either.

2.2 The four hats — and how they fight

You wear four hats simultaneously and they actively interfere:

Hat	Mode	Time horizon	Output
Architect	Deep, abstract, system-level	Weeks–quarters	Design docs, RFCs, technical direction
Coach	Patient, high-empathy, slow	Continuous	1:1s, feedback, growth
Operator	Tactical, fast, decisive	Days	Unblocks, escalations, planning
IC	Deep focus, flow	Hours–days	The 5% of code only you write

Each demands a different brain state. A 90-minute IC deep-focus session and an emotionally heavy 1:1 cannot share the same hour. Batch by hat, not by topic. See §9 for the cadence.

The most common failure mode: defaulting to IC mode whenever uncomfortable. When 1:1 prep feels hard, you "just do a quick PR review." When the strategy doc is daunting, you "just take a ticket." You will always default to IC unless you actively force the other hats. Calendar discipline > willpower.

2.3 The three voices

Every tech lead has three internal voices. They lie in different ways.

The Hero Voice — "I'll just fix it myself." Lies upward — talks you into single-handed heroics that block the team's growth and burn you out.
The Imposter Voice — "Everyone else is more senior than me, I shouldn't push back." Lies downward — talks you out of necessary technical decisions, hard 1:1s, and saying no.
The Steward Voice — "What does the team need to ship the right thing safely? What does this engineer need to grow?" Lies the least. Cultivate this one.

When you catch the Hero or Imposter voice driving a decision, write the decision down and revisit in 24 hours. Most regretted TL decisions happen in the 60 minutes after a stressful trigger (a churn, a Sev-1, a heated thread).

2.4 The leverage hierarchy

Rank your time by leverage. Always work top-down:

Direction (what we should do, why, and what we won't). 1 hour here = 100 hours saved later.
Hiring & growth (who is on the team, what they're working on, what they're learning). 10x compounding.
System health (architecture, tech debt, on-call quality). The team's velocity ceiling.
Unblocking (the 5-minute Slack message, the design review, the data point). Cheap, high-impact.
Reviewing (PRs, designs, plans). Important but second-tier — not everything needs your eyes.
Building (your own code). Lowest-leverage of the six. Do only what only you can do.

When you feel busy but useless, you've inverted the stack. Reset by asking: "In the last 5 working hours, how much did I spend on items 1–3?" If the answer is "<2," that's the problem.

2.5 Reversible vs irreversible decisions

Bezos's two-way / one-way doors framing is critical for tech leads:

Two-way doors (reversible): which library to try, code style, sprint format, choosing a quick prototype direction, even some architectural micro-decisions early. Decide fast, reverse if wrong, do not run a 5-day RFC for these.
One-way doors (hard to reverse): public API shape, database choice, language runtime, hiring decisions, firing decisions, foundational data models, tenant model, identity provider. Slow down, write it up, get input, sleep on it.

New tech leads tend to over-deliberate two-way doors and under-deliberate one-way doors (because the one-way ones feel scary and they avoid them). Audit: of your last 10 important decisions, how many were one-way? If <2, you're avoiding the structural calls. If >7, you're moving too slow on reversibles.

2.6 The compounding loop

Your team's only sustainable advantage is compounding. You can't out-headcount a bigger team. You can compound:

Tribal knowledge → written knowledge. Every doc compounds — onboarding gets faster, decisions get easier to challenge, you can be away.
Team trust. Every hard conversation handled with care + every credit given publicly = a team that ships faster under stress.
Architectural integrity. Every clean boundary today saves 10 weeks of refactor later. Every shortcut compounds the other way.
Customer/domain knowledge. Every customer call, every metric reviewed, every postmortem read makes the next decision sharper.
Process simplicity. Every meeting killed, every approval flow trimmed, every doc template polished — compounds for years.

Anything that doesn't compound is rented: tribal context in one engineer's head, undocumented decisions, "that's just how we do it" rules. Convert rented knowledge to owned knowledge weekly.

2.7 The honest reality

Things you'll feel that the LinkedIn version of tech lead never mentions:

Days where your "output" is invisible. You spent 8 hours unblocking, reviewing, mentoring, deciding. You wrote zero code. You feel like you accomplished nothing. This is the job. Your dopamine rewiring will take 3–6 months.
The "should I just go back to IC?" temptation. Around month 4, when 1:1s feel heavy, the team has its first conflict, and a deadline is slipping, you'll romanticize being a senior IC again. Sit with it. The temptation passes; the lead skill compounds.
Lonely middle. ICs vent to the lead. The exec vents to the EM. The lead has no obvious place to vent. Find a peer-tech-lead group (internal or external Slack/Discord) early. Nonnegotiable.
The team doesn't say thank you. Especially when you're doing it well — clearing roadblocks, killing scope, handling politics behind the scenes. Your team's calm is your reward; learn to read it as success.

3. 🎭 Tech Lead vs Senior Eng vs Staff vs EM

The single most common confusion: collapsing these four roles. They overlap but reward different behaviors.

3.1 The role grid

Dimension	Senior IC	Tech Lead	Staff Eng	Eng Manager
Primary output	Code, designs	Team output, tech direction	Cross-team systems & influence	People, hiring, performance
People mgmt	None	Soft (unblocks, mentors)	Soft, often cross-team	Formal (1:1s, comp, PIPs)
Code time	70%+	20–40%	10–30%	0–15%
Scope	Project	Team	Multiple teams / domain	Team(s)
Career risk	Skills atrophy	Identity crisis	Becoming irrelevant	Politics burnout
Compensated for	Solving hard problems	Team velocity & quality	Multi-quarter bets	Org outcomes

A tech lead in a healthy startup is not a watered-down EM and not a staff IC with a meeting tax. It's a real, distinct role: the person responsible for what the team builds and how, while still close enough to the code to stay credible.

3.2 The TL/EM split

Three configurations exist:

TL = EM (player-coach). One person owns both technical direction and people management. Common in early-stage startups and small pods (3–6 engs). Works if the person genuinely enjoys both and can budget time. Breaks at ~7+ engineers.
TL + EM split. Common at scale-up and bigco. EM owns 1:1s, performance, hiring, comp. TL owns architecture, technical roadmap, design reviews. Both own delivery. Requires very clear interface — see below.
No TL, just EM. Smaller teams, EM has tech depth. Senior ICs share lead duties informally. Works at <5 engs; fragile beyond.

If you're in config 2 (TL + EM split), agree explicitly with your EM on these 7 questions in the first week:

Who runs sprint planning / roadmap planning?
Who decides architecture and tech direction?
Who owns hiring loop ownership for engineering candidates?
Who delivers performance feedback (technical vs growth)?
Who escalates engineering-impacting decisions to leadership?
Who is the visible face of the team to external stakeholders?
When you disagree, how do you resolve?

Write the answers down. Re-read every quarter. Misaligned TL/EM pairs are the #1 cause of team thrash in scale-ups.

3.3 TL ≠ Staff Eng ≠ Architect

Staff engineers and architects are more senior but less integrated with one team. A staff eng might attend your team's design review monthly; a TL leads it weekly. Architects produce strategy; TLs implement it on their team. A tech lead is deeper in one team; a staff eng is wider across teams.

Practical heuristic: if you spend most of your week on one team's plan, design reviews, and unblocks → TL. If you're consulting on three teams' designs and not in any single team's standup → staff. If you're 5+ years into "tech lead" and haven't grown the scope, you're probably ready to be a staff eng (or EM, depending on your taste).

3.4 Common mistakes in role identity

TL acting like senior IC — does all the hard tickets themselves, team stagnates.
TL acting like EM — runs 1:1s about feelings, never opens code, loses technical credibility in 6 months.
TL acting like staff — pontificates on architecture, ignores delivery, team misses deadlines.
TL acting like product manager — invents features, negotiates scope, causes friction with PM, abdicates the technical work.

The right vibe: "I am the most senior engineer who is still in the work, and I care about the people doing the work."

4. 🚪 The First 90 Days

Treat this like a structured plan, not vibes. Days 1–90 set the pattern for the next two years.

4.1 Days 1–14: Listen, don't change

The most damaging mistake a new TL makes is changing things in week 1 to look decisive. You don't have the context. You will undo your own decisions in week 6.

Goals:

Meet every team member in a 30–45 min 1:1. Ask, don't tell. (Questions in §8.2.)
Read the last 4 weeks of PRs, design docs, postmortems, slack threads.
Shadow the on-call rotation for one full cycle.
Sit in (silent) on the next 2 sprint plannings, design reviews, retros.
Talk to the PM, the EM, the design partner, and 2–3 stakeholders in adjacent teams.
Read 6 months of customer feedback, support tickets, and product analytics. (You are now responsible for what gets built — you need to understand the customer.)
Do not change a process. Do not announce a vision. Do not refactor anything.

Output by day 14: a private doc — your state-of-the-team note. Sections: people (strengths/risks/aspirations per person), system (what's working, what's risky), delivery (cadence, predictability, debt), stakeholders (relationships, expectations), open questions. This doc is for you. Update monthly.

4.2 Days 15–45: Diagnose & quick wins

By day 14 you've earned permission to act. Now diagnose.

Pick 1–3 small, visible improvements that are unambiguously better and don't require buy-in. Examples: kill a redundant meeting, write the missing onboarding doc, add a CI check the team has been wanting, set up a definition-of-done template, fix the alert that pages everyone at 3am.
Run a "team health" survey or workshop (anonymous, 5 questions). Use it as conversation fuel, not a verdict.
Build a 90-day team plan: what we'll ship, what we'll improve, what we won't. Share it. Iterate it with the team. (Not a roadmap from on high — a draft you co-edit.)
Start writing weekly written updates (see §17). Even if no one asks. Especially if no one asks.

Quick wins build social capital you'll spend in days 46–90 on the harder calls.

4.3 Days 46–90: Set direction & operate

By now you have the context to make calls.

Publish a team technical direction (1–2 pages). What we own, what we're optimizing for, the 3 big bets for the next 6 months, what we're explicitly not doing. (See §5.) Get input first; commit second.
Make 1 hard call. New TLs avoid hard calls and the team smells it. Examples: change the on-call structure, kill a project, raise a quality bar, give a senior IC harder feedback. Pick one and do it well — it sets precedent.
Establish your operating cadence (§9). Weekly TL→team update. Weekly review of metrics. Monthly retro. Quarterly plan.
Calibrate with your manager. Schedule a 90-day retro 1:1 with your EM/director. "Here's what I see. Here's what I'm doing. Here's what I need from you."

Output by day 90: a clear team plan, a known cadence, 2–3 visible improvements, 1 hard call made, your manager aligned on what success looks like. Don't try to ship more than this in 90 days.

4.4 The 90-day exit interview (with yourself)

At day 90, write a short retro to yourself: what did I learn about the team, the system, my own gaps? What did I expect that turned out wrong? What does the team need from me in the next 90? File it. Re-read at day 180.

5. 🧭 Setting Technical Direction

The job most new tech leads dodge. "We don't really have a technical direction, we just ship features." Saying that out loud should make you uncomfortable. A team without direction makes every decision from scratch, drifts toward path-dependent legacy, and burns out engineers who can't see the point.

5.1 What "direction" actually means

Direction is the answer to four questions, written down:

What are we for? What is this team's mission, in one sentence, and how does it map to the company's? "We make billing reliable enough that finance never has to call us."
What are we optimizing for? Pick 2–3 of: speed, scale, reliability, security, developer experience, cost. You can't optimize for all six at once. Most teams pick implicitly and lie about it.
What are we betting on technically? The 3–5 architectural bets that shape the next 6–12 months. Examples: "We're going all-in on event sourcing for the audit trail." "We're moving auth to a vendor; we're not building it." "We're standardizing on Postgres + a single Redis; no new datastores."
What are we explicitly not doing? The list of things that look reasonable but we are saying no to. This is the most powerful section. Without a "not doing" list, every shiny new framework gets a serious discussion.

Write this in 1–2 pages. Living doc. Date it. Update quarterly.

5.2 How to write the direction doc

Format that works:

# <Team> Technical Direction — Q3 2026

## Mission (one sentence)
## Customers (who, what they need from us)
## What we own (services, schemas, areas of code)
## What we're optimizing for (ranked, with brief why)
## Architectural bets (3–5, each with rationale + alternatives considered)
## Explicit non-goals (5–10 items)
## Risks & open questions
## How we'll know it's working (metrics)

Length: 1–3 pages. Anything longer is a strategy memo, not a direction doc. Read by the entire team in <15 minutes.

5.3 How to get team buy-in without watering it down

Direction-by-committee produces mush. Direction-by-fiat produces resentment. The right pattern:

Write the v0.1 yourself, alone, in 2 hours. Be opinionated. Mark every decision as "draft."
Share with 2–3 trusted team members for raw feedback. Listen, take notes, do not defend yet.
Rewrite as v0.2.
Run a 60-min team review. Goal: surface objections, not consensus. Lead with: "My job is to be wrong in writing so you can correct me. Tell me where I'm off."
Take the strong objections, rewrite v1.0. Publish.
Anything you didn't change despite objection — explain why in writing in the doc itself ("Considered alt: X. Decided against because Y.")

Buy-in comes from being heard, not from getting your way. Most engineers will accept a decision they disagree with if they see their concern addressed in writing.

5.4 The 3 horizons

A useful frame to keep direction healthy:

Horizon 1 (now → 1 quarter): keep the lights on, ship the committed roadmap, fix the 3 most painful debts.
Horizon 2 (1–3 quarters): the major bets — re-architecture, platform shifts, new capabilities. Should consume ~20–30% of capacity.
Horizon 3 (3+ quarters): exploration, prototypes, learning. ~5–10% of capacity. Don't promise outcomes; promise reports.

Most teams accidentally allocate 95% to H1 and complain that they "never get to do real work." Some teams flip and allocate 60% to H2 and miss every quarter. The TL's job is to defend the split.

5.5 The "not doing" list as a weapon

Every quarter, publish 5–10 things the team is not doing. Examples:

"We are not building our own feature flag system. We use vendor X."
"We are not migrating to GraphQL this quarter. The cost > value."
"We are not refactoring the legacy reporting module. It works, no one is touching it."
"We are not adopting framework Y, even though it's trendy."

This unlocks 3 things: engineers stop spending energy lobbying for these; PMs stop expecting them; new hires understand what not to suggest in week 2. The list is the most under-used tool in tech leadership.

6. 🏛️ Architecture & Technical Decisions

The artifacts and rituals that produce sane systems over years.

6.1 The Architecture Decision Record (ADR)

Every decision that's expensive to reverse — language choice, datastore, auth provider, API style, module boundary, deployment target — gets a 1-page ADR. Format:

# ADR-NNN: <decision>
Date: 2026-MM-DD
Status: Proposed | Accepted | Superseded by ADR-XXX
## Context (what's the problem? what constraints?)
## Decision (what did we decide? in one paragraph)
## Alternatives considered (each with 1–3 sentences why we didn't pick it)
## Consequences (positive, negative, neutral)
## Open questions

Rules:

Numbered, immutable once accepted (you supersede with a new one, never edit).
Lives in the repo (/docs/adr/), not Notion. Code and decisions evolve together.
Reviewable in <10 minutes.
The TL is the final accept; team comments are inputs.

ADRs are the highest-leverage written artifact a TL produces. In year 3, the new hire reads ADR-007 and understands why you chose Postgres over DynamoDB instead of asking the same question for the 11th time.

6.2 The Design Doc (RFC)

Bigger than an ADR — a design for a feature/system/migration. Used before significant code. Format:

# Design: <feature/system>
Author, reviewers, status, target ship date
## Background & motivation (problem, why now)
## Goals / non-goals
## Proposal (architecture, data model, API, UX touchpoints)
## Alternatives considered
## Trade-offs (perf, cost, security, complexity)
## Migration & rollout plan
## Risks & how we'll mitigate
## Open questions

Rules:

3–10 pages. If longer, it's two designs.
1 author, 2–4 named reviewers (mix of senior, adjacent team, junior).
Inline comments, not threads.
Async first; meeting only if >10 unresolved threads.
Author drives to "decided" — TL is final reviewer if author isn't.

6.3 When to write a design doc (and when not)

Write one when:

Touches >1 service or >1 team.
Affects public APIs, schemas, contracts.
Migration with data movement.
New external dependency (vendor, library category).
Estimated >2 weeks of engineering work.
Reversibility is hard.

Skip when:

Feature inside an established module, no API change, <1 week of work.
Bug fix, even big ones.
Spike / prototype that's explicitly throwaway.

The TL's job is to raise the bar for "I'll just code it" and lower the bar for writing things down. Default toward writing.

6.4 Decision-making frameworks

Three frames you'll use weekly:

1. The "expensive-to-reverse" test. Cheap to reverse → just do it. Expensive → ADR or design doc. Don't equate "important" with "irreversible" — many important decisions are reversible.

2. The 80/20 design. Design for 80% of the cases. The remaining 20% gets workarounds, follow-ups, or is explicitly out of scope. Engineers love designing for 100%; it produces over-engineered systems and missed deadlines.

3. The "what would change in 1 year?" frame. When evaluating a design: imagine you shipped it. In 12 months, what have you regretted? What surprised you? What did you have to redo? Most surface-level designs survive this question. Most over-clever designs do not.

6.5 How to handle architectural disagreements

The most political part of the job. Default rules:

Disagreement on the facts → run a spike, generate evidence. Most "religious" arguments are actually empirical and the data hasn't been collected.
Disagreement on trade-offs → write them down. Usually the engineers are arguing different priorities (one optimizing for read perf, the other for write simplicity). When trade-offs are explicit, the disagreement often dissolves.
Genuine taste disagreement → TL decides. Explain in writing. Move on. Disagree-and-commit is a skill you must teach the team.

Never: let an architectural disagreement drag for 3+ weeks. Never: avoid the call because you're afraid of offending the senior engineer who disagrees. Never: agree publicly and roll back privately. All three corrode trust faster than a wrong call.

6.6 Tech debt: the silent killer

Every team has it. Most teams talk about it wrong.

Categorize debt into 4 buckets:

Painful daily — every dev hits it weekly. Slow tests, flaky CI, broken local setup, repeated boilerplate. Pay first, always. Fund 10–15% of every sprint.
Painful occasionally — the migration that has 5 known traps, the legacy module touched once a quarter. Schedule deliberately, 1 per quarter.
Latent — known design issue that hasn't bitten yet (e.g. tenancy not properly isolated, no rate limiting). Track and watch. Pay before you can't.
Folklore debt — "the X module is bad" but no one can articulate why or what's broken. Diagnose before fixing. 30% of folklore debt is actually fine.

Maintain a public team debt registry (a markdown file or a Linear board). Triage monthly. Engineers can propose entries; TL accepts. Visible debt is debt you can pay; invisible debt is debt that pays you (with interest).

6.7 The architecture review ritual

Once every 2 weeks, 60 minutes, the whole team:

Anyone with a design or major decision presents (10 min max each).
Team asks questions, raises concerns.
TL summarizes outcome ("approved", "needs revision", "rejected", "let's spike").
Action items written and assigned.

The point isn't approval — it's shared mental model. After 6 months of this ritual, every engineer on the team understands the system 3x better. You'll see it in PR quality.

7. 📦 Project Execution: Planning → Delivery

The unsexy mechanics of "we shipped what we said we'd ship, when we said we'd ship it."

7.1 The rule of estimation

Engineering estimates are wrong. The TL's job is to make them less wrong, not to demand precision.

Practical rules:

Estimate in T-shirt sizes (S/M/L/XL) for anything beyond a sprint. Numbers feel precise and aren't.
For a sprint, sum the estimated work and divide by 1.5 to get realistic capacity. The 1.5 is from years of data; you may calibrate but the multiplier is rarely <1.3 or >2.0.
For multi-quarter work, decompose into 1–2 week chunks. If you can't, you don't understand it well enough yet.
Track actual vs estimated over 3–6 sprints. Use the ratio for calibration, not for blame.
Always include a "discovery" line item for anything novel. 20–30% of the estimate. Engineers hate it; product loves it; reality vindicates it.

The TL never lets the team commit to dates without understanding what they're committing to. "We'll ship the feature" is not a commitment. "We'll ship the feature with X, Y, Z behaviors, observed via metrics A, B, C, with these caveats" is.

7.2 Decomposing work

A senior engineer can pick up a 1-week task and run. A junior cannot. The TL's decomposition skill scales the team.

The "ladder" decomposition:

Goal — outcome statement, business-meaningful, not engineering jargon. ("Customers can export their reports to CSV.")
Workstreams — 2–5 parallel tracks. ("Backend export service. Frontend trigger UI. Async job infra. Observability. Docs.")
Tasks — 1–5 day chunks. Each has owner, acceptance criteria, dependencies.
Subtasks — only for the most complex. Most don't need this.

Rule: a task with no acceptance criteria is a wish, not a task. "Implement export" is not actionable. "Backend route POST /reports/:id/export returning a job ID; job runs in <30s for reports up to 10MB; error path returns 4xx with reason" is.

7.3 The "definition of done" template

Every project has one. Pre-agreed before starting. Example:

## Definition of Done — <project>
- [ ] Code merged with passing CI
- [ ] Unit tests cover the happy path + 2 edge cases
- [ ] One integration test for the end-to-end flow
- [ ] Observability: structured logs, 1 metric, 1 alert (if applicable)
- [ ] Feature flag in place (if user-visible)
- [ ] Docs updated (README, ADR if applicable)
- [ ] Manually tested in staging
- [ ] PM/Designer signoff (if applicable)
- [ ] Rollout plan documented
- [ ] On-call notified of new component

Tailor per team. Print it. Refer to it every sprint review. The most common cause of slipped projects is unwritten DoD — every engineer has a different idea of "done."

7.4 The escalation framework

When something is at risk, escalate early, in writing, with options.

Bad escalation: "The project is slipping, we need help."
Good escalation:

Project: Stripe migration
Status: At risk for 06-15 ship
Cause: Webhook idempotency layer is harder than estimated; current eta 06-25
Impact: 10-day slip. Affects Q2 OKR for finance team.
Options:
  A) Slip 10 days, ship full scope. (Cost: Q2 miss; recommend if reliability matters more.)
  B) Cut idempotency layer for v1; ship 06-15 with a known limitation; follow up next sprint. (Cost: 1 known incident class; recommend if Q2 commitment is binding.)
  C) Pull 1 engineer from project Y to help. (Cost: Y slips by ~1 week.)
Recommendation: B, because PM signaled Q2 timing is hard.
Need decision by: 06-08 EOD.

This is the format that gets respect. It's also how you train the team to escalate the same way to you.

7.5 Standups, retros, and other rituals

Standups. 10 minutes max, 3 questions: what shipped since yesterday, what's blocking me, what I'm doing today. Not status reporting — synchronization. Skip if 3 days/week pattern works for the team. Async standups in a Slack thread are fine for distributed teams.

Sprint planning. 60 min max. Goal: pick committed scope; agree owner per item; identify risks. Not the place to design or estimate from scratch — that work is done in advance.

Retrospectives. Every 2 weeks. Format that works: what went well / what didn't / what we'll change next sprint. Pick 1–2 concrete changes. Don't write a list of 10 you'll never act on. The single most valuable retro question: "What did we learn this sprint that we didn't know last sprint?"

Demos. Every sprint, 30 min, anyone on the team can present 5 min of what they shipped. Invite stakeholders. Demos are more motivating than retros and 5x cheaper than docs.

Don't: quarterly OKRs that nobody reads, weekly health-check meetings with no agenda, planning meetings that turn into design meetings, retros that turn into venting sessions.

7.6 The "scope is a knob" mental model

Every project has 4 levers: scope, time, quality, people. You can change at most 2 without breaking the project. The TL's job is to make the trade-off explicit and visible to PM, EM, and team.

Time fixed + people fixed + quality fixed → only scope is adjustable. Cut features.
Scope fixed + quality fixed → either ship later or add people (with all the costs of onboarding mid-project — see Brooks's law).
Scope fixed + time fixed → quality drops. Quality drops are loans you'll repay with interest in incidents.

Never silently eat scope or quality drops. Document the call. Make the PM and EM co-sign in writing. "We agreed to skip retry logic on the export job for v1; we'll add it in v1.1."

8. 👥 People: 1:1s, Coaching, Conflict

The skills that scared you when you took the job. They get easier with practice and never become trivial.

8.1 The 1:1 — your highest-leverage meeting

Weekly or biweekly, 30 min, 1:1 with each team member. Their agenda, not yours. This is the most under-rated tool a tech lead has.

Default structure:

5 min: anything urgent on their mind.
10 min: their priorities, blockers, decisions they want input on.
10 min: growth — "what are you learning, what do you want to learn next?"
5 min: feedback (both directions). Even small feedback. Especially small feedback.

Rules:

Never cancel two in a row. Reschedule, but not skip.
They drive the agenda. Maintain a shared running notes doc per person.
Two ears, one mouth. If you talked >50% of the time, you missed the point.
Take notes during, not after. Engineers feel heard when they see you write things down.
End with one specific commitment (you to them, or them to themselves).

1:1 anti-patterns:

Status reporting (you should already know status from standups/Slack).
Skipping when you're busy. The "busy" weeks are exactly when 1:1s matter most.
Doing them all on the same day. Energy collapse — schedule 2/day max.
"How are you?" / "Good" / awkward pause / "any blockers?". Have 5 stock questions ready (§8.2).

8.2 Stock questions for 1:1s

When the conversation stalls:

"What's the most frustrating thing about your work right now?"
"If you could change one thing about how this team works, what would it be?"
"What did you learn this week?"
"Where are you blocked, including by me?"
"What's the most interesting thing you read/saw recently?"
"What does success look like for you in 6 months?"
"What's one thing I could do differently that would help you?"
"What's an opinion you have about the codebase that you've been hesitant to share?"
"What's something you're proud of from the last 2 weeks that I might have missed?"
"If you were me, what would you be focused on?"

Rotate. Don't ask the same question twice in 4 weeks.

8.3 The coaching ladder

Every engineer is at a level. Coach to the level above, not 3 levels above:

Level	What they need most
Junior	Frequent specific feedback, scoped tasks, pairing, psychological safety
Mid	Stretch projects with safety net, design exposure, ownership, written feedback
Senior	Hard problems, autonomy, broader scope, peer-level conversations
Staff	Cross-team challenges, strategy input, less from you, more from each other

Common mistake: treating everyone like a senior IC because you're scared of micromanaging. Juniors need more scaffolding — that's not micromanaging, that's responsible. Conversely, micromanaging a senior is corrosive.

8.4 Giving feedback: the formula

Most tech leads give feedback poorly because they're nervous. The fix is mechanical: a formula you can rehearse.

SBI (Situation, Behavior, Impact):

Situation: "In yesterday's design review for the export feature..."
Behavior: "...you cut off Marie three times when she raised concerns about the schema..."
Impact: "...and as a result two issues she had context on didn't get discussed, and I noticed she stopped engaging in the second half."

Then: "What's your read on it?"

Rules:

Specific situation, not "always" or "you tend to."
Observable behavior, not interpretation. ("cut off" not "were dismissive")
Real impact, not hypothetical.
Ask their read before lecturing.
Praise in public (in #team-wins channel, in standups, in retros). Critique in private. Always.

Cadence: small feedback weekly, in the moment or in 1:1. Annual feedback that surprises someone is a failure of weekly feedback.

8.5 Hard conversations

The conversations you'll dread:

"Your code quality is consistently below the bar."
"You missed the last 3 sprint commitments."
"Your behavior in code review is making people uncomfortable."
"I don't think you're ready for promotion this cycle."
"We need to talk about your manager / our PM / a peer."

The rule: the conversation gets harder every week you delay it. Most "performance" issues at month 6 were obvious at month 2 and could have been corrected. By month 6, the issue has compounded, the team has noticed, you are now defending an avoidable PIP.

The script:

State the issue specifically and observably. SBI format.
State the impact on the team / project / them.
State your expectation, with a measurable change.
Ask their perspective. Listen.
Agree on a 2–4 week experiment with a checkpoint.
Document it (in your notes, not theirs).
Follow up at the checkpoint. Course-correct.

Most hard conversations resolve in 2–6 weeks if started early. The minority that don't move into formal performance management — at which point your EM/HR are involved.

8.6 Conflict between team members

Two engineers can't agree on architecture. Two engineers can't stand each other. A junior feels micromanaged by a senior. These will happen.

The rule: never let a conflict run >2 weeks without intervention.

Steps:

Talk to each privately. Listen for the interest, not the position. ("I want X" is a position. "I'm worried about being on-call again" is an interest.)
Find the shared interest. (Both engineers want a maintainable system.)
Bring them together with that frame: "You both care about Y. You disagree on how to get there. Let's make the trade-offs explicit."
If trade-offs don't resolve it, the TL calls the decision and explains in writing. Both engineers commit.
Watch for residue. Most conflicts resolve at the technical level; a minority leave interpersonal residue you'll need to address separately.

Anti-pattern: treating conflict as a personality issue when it's a process issue (no clear ownership, no decision-maker, no DoD). 70% of "interpersonal" conflict is actually missing process.

9. ⏱️ The Operating Cadence

The single highest-leverage thing you'll do is set and protect a weekly rhythm. Without it, every week is reactive and you ship 30% of what you could.

9.1 The default weekly cadence

Adapt to your team, but start here:

Day	Time	Activity
Monday AM	30 min	Personal week plan; review last week's metrics
Monday	30 min	Team standup or async equivalent; team weekly kickoff
Mon–Fri	2× 30 min	1:1s spread across the week (~2 per day)
Tuesday	60 min	Architecture / design review
Wednesday	90 min	TL deep-work block (your IC contribution)
Thursday	60 min	Sprint demo (every other week)
Friday	30 min	Written team weekly update; manager 1:1 prep
Friday	30 min	Retrospective (every other week)

Total: ~6–8 meeting hours/week. Anything more, and IC time evaporates. Anything less, and the team drifts.

9.2 The monthly cadence

First week of month: review last month's metrics; check direction doc; talk to PM about roadmap; check tech debt registry.
Mid month: skip-level 1:1 with your manager's manager (if you have one); cross-team sync with adjacent TLs.
Last week: team retro (longer-form, monthly themes); update direction doc if needed; celebrate shipped work publicly.

9.3 The quarterly cadence

Plan: 1–2 days dedicated. Review last quarter, set 3–5 outcomes, align with PM and EM.
Mid-quarter check-in: are we on track? what changed? course-correct.
End-quarter retro: what shipped, what didn't, what we learned, what we'll change.
Direction doc revision: rewrite, even if mostly unchanged. Forces you to re-question.
Compensation/promotion calibration: with EM if applicable.

9.4 Protecting deep work time

Default: your calendar fills with meetings. Defense:

Block 2–3 deep-work mornings per week. Treat them as untouchable.
Decline meetings without an agenda. Yes, even from senior people. Politely: "Happy to join — could you share the agenda? I want to make sure I bring the right context." This filters 30% of meetings.
One "no-meetings" day per week if your org allows. Even 1 day moves the needle.
Protect engineers' deep work too. Make it cultural that 2–3 hours of uninterrupted work is normal. The TL who sets this norm gives every engineer 5–10 hours/week back.

9.5 Async-first defaults

In 2026, default to async for almost everything that isn't:

A hard conversation (1:1, conflict, hiring debrief).
A decision with >5 stakeholders that has lingered for >1 week.
A high-bandwidth design exploration in genuine ambiguity.

Everything else: a written doc, a Slack thread, a recorded Loom. The async-first culture compounds: fewer interruptions, better records, more thoughtful decisions, better for hires across timezones.

9.6 Office hours

Hold a weekly 30-min "TL office hours" — open slot anyone can drop into for ad-hoc questions. Filters async questions that don't quite fit Slack and reduces 1:1 pressure. Bonus: gives juniors a low-friction way to ask "stupid" questions they'd hesitate to bring to a formal 1:1.

10. 🔍 Code Review & Design Review

Review is the most public way you set technical culture. Everyone watches how you review.

10.1 The PR review philosophy

Three goals, in this priority:

Correctness: does this work? does it not break X?
Maintainability: will the next person understand this? does it match codebase conventions?
Growth: is this a teaching moment? for the author or for future readers?

Style/taste is a distant fourth. Adopt automated formatters and linters; never spend a code review on whitespace.

10.2 The TL's review behaviors

Speed. Same-day for blocking reviews; <24h for non-blocking. A team's velocity is bounded by review latency.
Bias toward approve. If the change is correct and the design is reasonable, approve with comments rather than block. Leave nits as "nit:" prefix; explicitly mark blocking concerns.
Comment on the why, not the what. "Could we use X here?" → "Could we use X here? It avoids the N+1 we hit in the orders module last quarter." The reasoning is the gift.
Praise good code. "Nice — this is much cleaner than the old pattern." Code review is also a feedback channel.
Pull bigger discussions out of the PR. When a comment thread is heading toward "should we redesign this," stop, schedule a sync, write an ADR if needed.
Don't gate. As TL you might be one of N reviewers. Don't make every PR wait for you. Identify 2–3 senior-enough reviewers and rotate.

10.3 The "two-rounds" rule

If a PR needs >2 rounds of review, something is wrong. Causes:

The author didn't have enough context before coding (fix: better task hand-off, design first).
The reviewer is over-reaching (fix: separate PR-style nits from blocking issues).
The change is too big (fix: smaller PRs).
The author and reviewer disagree philosophically (fix: pull the conversation out of the PR).

Track this informally — if multiple PRs need 4+ rounds, call out the pattern at retro.

10.4 PR size discipline

Short PRs get reviewed faster, merged faster, ship faster, and have fewer bugs. Targets:

Ideal: <200 LOC of meaningful diff.
Acceptable: <500 LOC.
Refactor: can be large if truly mechanical (renames, code-mod) and explicitly tagged.
Anything else over 500 LOC needs justification in the PR description.

Most large PRs are 3 PRs that got merged into one because the author didn't know how to split. Teach the team to plan PR boundaries before coding.

10.5 Design reviews

Already covered in §6. To add:

Design reviews are async-first (inline comments on the doc) before any meeting.
The meeting is 45 min, focused on remaining open questions, not narration.
Author drives. The TL is a participant, not the chair, unless the author is junior.
End every design review with a written decision summary in the doc itself: "Decided: X. Open: Y. Next steps: Z."

10.6 The "what would I have written?" trap

A senior reviewer's worst instinct: the author wrote working, correct, conventional code, and the reviewer says "I would have done it differently." Discard this voice. Unless your alternative is materially better (correctness, perf, maintainability, conventions), let the author's choice stand. The team's code is the team's code. It does not have to look like your code.

11. 🔥 Incidents, On-Call & Quality

The team's quality bar is set in incidents and post-mortems, not in design docs.

11.1 The on-call covenant

Every team that owns production has an on-call rotation. The TL's job is to make it bearable.

Rules:

One primary, one secondary, weekly rotation.
No one is on-call alone in their first 8 weeks. They shadow.
Anyone awakened twice in a week gets the next week off rotation.
All pages are reviewed every Monday: real or noisy? noisy ones go to a tracked queue and get killed.
The page volume is a team metric you report every month. Down is good.

A team where on-call is a coin flip between "quiet week" and "trauma" will burn out. The TL who fixes the worst alert each month forever will earn lifelong loyalty.

11.2 The incident response rhythm

When things break:

Declare an incident — name a commander (not always you), open a channel, start a timeline.
Stop the bleed first, fix the cause second. Roll back; failover; rate-limit. Resist the urge to debug the root cause while production is on fire.
Communicate. Status updates every 15–30 min, even "no progress yet, still investigating." Silence is worse than bad news.
Mitigate fully before declaring resolved.
Pause before the post-mortem. People need an hour to come down.

The TL is not always the incident commander. Train others to lead — it's a great growth opportunity for senior engineers and reduces single-person dependency.

11.3 Post-mortems: blameless and useful

A post-mortem that reads "X engineer should have noticed Y" is useless. Future engineers will not "notice better" — humans don't work that way.

Format:

## Incident: <one-liner>
Date, severity, duration, customer impact (specific numbers)

## Timeline
- HH:MM — what happened
- HH:MM — what someone did
(Be specific. Use real timestamps. Show the rabbit holes.)

## What went well
## What went poorly
## Where we got lucky (this is the best section)
## Root cause (with the 5-whys done genuinely)
## Action items
- [ ] <action> — owner, due date, type (preventative / detective / resilience)

The "where we got lucky" section is the most under-used. "We got lucky that the engineer who deployed at 3pm was online; if it had happened at 6am there would have been no one." Unearths the latent risks that the dramatic root cause hides.

Action items: 3–5 max, all assigned, all dated. Track them. A post-mortem with no completed action items is theater.

11.4 Quality is a TL responsibility

Bug rate, regressions, support tickets, customer complaints — all roll up to the TL. You don't write all the tests, but you set the bar that says "we don't ship without one for the happy path + 2 edge cases" (or whatever your bar is).

Defaults to enforce:

Tests in PRs for new logic. Always.
A bug found in production = a regression test in the next PR. Cultural rule.
Flaky tests are bugs. Quarantine within 24 hours; fix or delete within a week.
Code coverage is a signal, not a target. Don't chase 100%; do investigate sudden drops.

11.5 The "every team has 1 systemic risk" exercise

Once a quarter, list the top 3 things that could take your team down for >24 hours. Examples: "Our database has no read replica. If it dies, we're down for hours." "Our deploy pipeline depends on a scriptthe original author left." "Our auth is a single library version behind a known CVE."

Pick 1, fix it that quarter. Most teams have an embarrassingly long list of these and most will never blow up — but the day one does, your team will look like heroes for having shipped the fix six weeks earlier.

12. 🤝 Stakeholders: PM, Design, EM, Exec

The political layer. Most new TLs ignore it and learn it the hard way.

12.1 Working with the PM

The PM is your closest collaborator. A great TL/PM pair is the single biggest predictor of team success. Tactics:

Weekly 30-min PM/TL sync (separate from sprint planning). Topics: roadmap drift, customer signal, tech-debt-vs-features trade-off, escalations.
Co-write the roadmap. Not "PM writes, TL approves." Both names on the doc.
Speak in their currency. When pushing for tech debt, frame in terms of feature velocity, customer impact, churn risk. Not "this code is ugly."
Disagree privately, align publicly. If you and PM disagree, fight it out in a 1:1, not in a sprint review in front of engineers. The team's trust is fragile; visible TL/PM conflict shakes it.
Bad PM behaviors to push back on: mid-sprint scope additions without trade-off, customer commitments without team consultation, deadlines decided without engineering input, vague requirements ("make it better").

If your PM is weak (vague, scope-shifting, slow-deciding), document the pattern, share with your manager, propose specifics. Don't suffer silently for a quarter.

12.2 Working with Design

If you have a designer, treat them as a peer of the PM, not an "input."

Loop them into design reviews, not just visual reviews.
Share constraints early ("we cannot animate at 60fps on mobile because of X"). Designers respect constraints; they hate surprises.
Ship design polish as deliberately as features. A "design polish week" once a quarter compounds product quality.

12.3 Working with your EM

Already covered in §3.2 if TL+EM split. To add:

Bring your EM bad news first, in private, with options. Never let your EM hear about a problem from someone else.
Tell them what you need. Air cover, hiring, comp, headcount, escalation. EMs aren't mind readers.
Tell them what's working. Not all your communication is "I have a problem." Make sure they see what's going right.
Expect: candor, defense of you with their leadership, growth coaching, comp/headcount advocacy. If you're not getting these, talk to your EM directly about the gap.

12.4 Working with execs

You'll be in front of your CEO/CTO/VP at some point — quarterly review, incident, hiring panel. Defaults:

Lead with the outcome, not the journey. "We shipped X, customers report Y, here's the data." Not "We started by exploring approach A, then..."
Time-box. Aim for 50% under your slot. Execs talk to many teams; brevity is respect.
Have one "ask" ready. "What I need from you: faster decisions on Z."
When asked a hard question, answer it. Don't dodge. Don't over-promise. "I don't know yet, here's how I'll find out by Friday."
Read the room. Big-picture exec wants narrative; technical exec wants the diff.

Anti-patterns: bringing problems without options, over-explaining technical detail, defending your team aggressively when constructive feedback would help, surprising the exec with bad news in a public forum.

12.5 Cross-team work

When a project spans your team and another:

One DRI (directly responsible individual) per cross-team initiative. Not co-DRIs. Not committees. One.
A shared design doc owned by the DRI, reviewed by both teams.
A shared metric that both teams can see weekly.
Resolve conflicts through the metric, not through politics. "The migration is slipping; here's the data; here's what we'll change."

If you're the DRI, you serve both teams equally. If you're not, you support without taking over.

12.6 Saying no

The single most important political skill of a tech lead. Most TLs say yes too much in year 1 and end year 1 with a team that resents them.

How to say no:

"That's a great idea, but to take it on we'd need to drop X. Want to do that swap?"
"I want to commit to this seriously, which means I can't do it this quarter. Can we pencil it in for next quarter?"
"Engineering capacity for that is roughly 3 weeks. Given our roadmap, here's what would have to slip. Which would you like to drop?"
"I don't think we should do this because . Here's an alternative that hits 80% of the value."

Saying yes to everything is dishonest. The team can tell. The PM can tell. The exec who wanted the thing eventually finds out you didn't actually have capacity. Trust dies in fake yeses.

13. 🤖 Leading in the AI Era (2026)

Every TL playbook written before 2024 is partially obsolete. AI-augmented engineering changes the math.

13.1 What changed

Code is cheaper to write. A senior + Claude/Codex can produce 2–4x the code per hour vs unaided. The bottleneck moved from typing speed to specification quality, review throughput, and integration testing.
Junior productivity gap shrunk and widened. Juniors with AI assistance look more productive than juniors without. But juniors who learn nothing because AI did the work are a long-term liability. Coaching matters more, not less.
Architecture matters more. The constant cost (writing code) dropped; the variable cost (a bad architectural choice) is unchanged. Teams that lean into AI without good design ship faster and end up with worse codebases.
Tribal knowledge → AI-readable knowledge. Codebases with great structure, naming, types, and docs let AI dramatically out-perform. Codebases without get worse AI assistance.
Reviewing AI-generated code is its own skill. Subtle hallucinations, plausible-but-wrong code, over-engineered solutions, missed conventions. The team's review bar must rise, not fall.

13.2 The AI-augmented team operating model

The shape of a great 2026 team:

5 engineers, each AI-augmented.
70%+ of code is AI-assisted in some form (autocomplete, agentic editing, tool-using agents for migrations and tests).
Specs and reviews dominate the human time budget.
The TL is the person responsible for: which AI tools the team uses, what's allowed in code (security, licensing), and the spec/review quality bar.

Specifically the TL must own:

Tool selection. Which IDE assistant, which agentic tool, which model, which guardrails. Update quarterly.
Codebase AI-readiness. CLAUDE.md (or equivalent) at root and per-package. Conventions documented. Tests as executable specifications.
Review bar. AI-generated code does not get a free pass. Author is fully responsible for what they merged. "The model wrote it" is not a defense.
Security & data hygiene. No secrets in AI prompts. Model providers' data handling reviewed. Customer data never sent to consumer-tier endpoints.
Skill calibration. Engineers should be able to do their job without AI for 1 day. If the team would grind to a halt without GPT-5, you've over-rotated.

13.3 What junior engineers need (more than ever)

In 2026 it's easier than ever for a junior to ship code that works and harder than ever for them to learn fundamentals. The TL must defend the learning.

Tactics:

Some tasks are deliberately AI-light. "This is a learning task — please write it without AI assistance and we'll review together."
Pair sessions where the senior shows their AI workflow — including when they reject AI output.
Code review where the question is "explain what this code does and why", not just "does it work."
A quarterly "from scratch" exercise: implement X without AI, then with AI, compare.

This is not about being purist; it's about ensuring the junior in 2026 still has the mental models to be a senior in 2029.

13.4 What senior engineers need

Different problem. Seniors with AI risk:

Becoming over-trusting of AI suggestions in their domain.
Skipping the design step because "the model can figure it out."
Producing more code without producing more value.
Plateauing on harder skills (system design, distributed systems, cross-team work) because line-coding feels productive.

TL response: push seniors toward harder problems faster. Owning a multi-team system. Mentoring 2 juniors. Publishing an internal tech talk. AI gave them time back; spend that time on growth, not output.

13.5 Hiring in the AI era

The bar moved. What you hire for:

Spec/design skill. Can they decompose a fuzzy problem into a crisp spec a model could execute against? This is now a top-3 hiring signal.
Review skill. Can they read AI-generated code and find the subtle bugs? This is the moat.
Domain & customer instinct. AI can write the code; it can't tell you the export format finance actually needs. People who talk to users win.
Judgment & taste. "This works but I wouldn't ship it because…" is the senior signal.
Curiosity about AI tools themselves. Anyone treating AI as a threat or a fad in 2026 is a 1–2 year career risk.

What you de-emphasize:

Boilerplate-grade live coding ("implement linked list reversal"). AI does that; it's now a hiring trap that selects for the wrong skills.
Trivia about specific frameworks. AI knows the API.

13.6 The TL's own AI workflow

You can't lead what you don't use. By end of 2026, a competent TL is comfortable:

Drafting design docs with AI assistance (you write the spine, AI fills sections, you edit).
Generating ADR options for a decision (give it the context, ask for 3 options + trade-offs, then decide).
Reviewing PRs with AI-summarization for unfamiliar code.
Using AI agents for refactor proposals, migration plans, test generation.
Reading AI-generated code skeptically — you are the last line of defense.

If you're not personally fluent, the team will out-skill you in 6 months and you'll lose technical credibility. Block 1 hour/week on tooling.

13.7 Don't be the AI maximalist or minimalist

Two failure modes:

Maximalist. "Everything should be AI-driven." Team ships shallow code, no one has fundamentals, customer issues take longer to debug because no one understands the system.
Minimalist. "I don't trust this stuff, we'll write everything by hand." Team falls behind, talent leaves, you're 2 years behind by 2028.

The right answer is fluent pragmatism: use AI where it accelerates without degrading quality, refuse where it degrades, defend learning, and update your stance every quarter as the tooling improves.

14. 🧑‍🔬 Hiring & Calibration

You don't fully control hiring as a TL but you significantly shape it.

14.1 What makes a good engineer for your team

Generic "good engineers" don't exist; engineers are good for a specific role. Write the spec:

The role's daily work (60% of time): what tasks, what stack, what cadence.
The 20% of growth: what stretches them.
The 20% of unique team needs: domain knowledge, on-call shape, written-async culture.
The 5–8 must-haves and the 3–5 nice-to-haves.

Force the must-have list to be small. Long must-have lists are how teams reject great candidates.

14.2 The interview loop

For a typical SWE hire (mid–senior), 4–5 stages:

Recruiter screen (HR — culture, motivation, salary band).
Technical phone screen (~60 min — code + system thinking, calibrated to the role).
System design or architecture discussion (60 min, senior+ only).
Hands-on / take-home (real-ish problem, 90 min live or 4 hours async with strict cap).
Team / hiring manager / leadership (~45 min — values, motivation, hard questions).

In 2026, AI changes this:

Live coding should allow AI assistance and observe how the candidate uses it. The signal is judgment, not typing.
Take-homes should test design + integration, not implementation.
Add a "review this PR" stage. Show a 200-line PR (some good, some bad) and watch their thinking.

14.3 The TL in the loop

You should:

Own the technical phone screen or system design round (you set the bar).
Attend every hiring debrief.
Veto with reason — you should be able to articulate the no in writing in 3 sentences.
Not block hires for personal taste. Calibrate against the role spec, not against you.

14.4 Common TL hiring mistakes

Hiring people just like you. Diverse teams ship better products. "They felt like a cultural fit" is often "they reminded me of me" with a euphemism.
Hiring for who they are today, not who they'll be in 2 years. Slope > intercept. The candidate growing fast at junior is often a better year-2 senior than the candidate who was already senior but coasting.
Ignoring red flags because you're desperate. Hiring under pressure is the #1 source of regretted hires. No hire is better than a wrong hire.
Over-engineering the loop. 7 rounds of interview lose top candidates to faster-moving competitors. 3–5 well-designed rounds beat 7 weak ones.
Not closing. Once you decide yes, call them within 24 hours. Top candidates are in 2–3 loops. Speed wins.

14.5 Onboarding (where most teams fail)

Hiring is a 60% bet; onboarding is the other 40% of whether they succeed. Most teams treat onboarding as "set up the laptop and find a buddy." That's a setup for 6 months of mediocrity.

A real onboarding plan:

Day 1: environment, accounts, intro, no expectation of code.
Week 1: read the team direction doc, last 3 design docs, last 3 post-mortems. Ship 1 trivial PR (typo, doc fix). Pair with 2 different people.
Weeks 2–4: owned but small task. Daily standups. Weekly 1:1 with TL.
Month 2: owned medium task. Lead 1 design review of their own work.
Month 3: owned project end-to-end. By end of month 3, they're a functional team member. If not, escalate.

Have a written 30-60-90 plan per hire. Review at each milestone. Most hires that fail at month 6 had a bad month 1 that no one caught.

14.6 The "buddy" pattern

Pair every new hire with a non-TL buddy for the first month. Buddy answers stupid questions, walks them through the codebase, joins their first 3 standups. Reduces TL load by 40% and creates a peer relationship for the new hire.

15. 📈 Performance, Promotion & Letting Go

The most consequential conversations of the year.

15.1 The performance signal

Performance is rarely a sudden event; it's a slow signal across months. Track informally per engineer:

Quality of their commits (PRs needing rework, bug rate, test coverage).
Their delivery vs. estimates over a quarter.
Quality of their design contributions.
Quality of their reviews on others' work.
Their engagement signals (1:1 energy, retro contributions, public visibility of their work).
Their growth slope (are they better than last quarter? clearly?).

This isn't surveillance — it's the TL's job. Most TLs run on vibes; the rigorous TL has a private 1-page-per-engineer doc updated monthly.

15.2 The promo case

If you're not in the EM seat, you write the technical case for promotion (the EM owns the people case). Format:

Scope. What they own — clearly bigger than 6/12 months ago.
Impact. What shipped because of them, with concrete metrics.
Influence. Who learned from them, what designs they led, who they reviewed.
Examples (3–5 specific, dated, concrete).
Gaps. What they still need to demonstrate at the next level.
Recommendation.

Bias yourself toward evidence over narrative. "Sara is great" loses; "Sara led the export-service redesign, mentored Jamal through his first design doc, and reduced our P1 bug rate by 40% over Q3" wins. Save evidence over the year so you don't have to scramble in promo cycle.

15.3 The non-promo case (harder)

When someone expects promo and isn't ready:

Communicate it 3+ months before the cycle, not in the cycle. Surprises are unforgivable.
Be specific: "To be promoted to senior, you need to demonstrate X, Y, Z. You've done X. You haven't yet done Y. Z is the gap. Here's what we'll do in the next 6 months."
Tie to evidence, not opinion.
Re-evaluate on schedule. Don't move goalposts.

If they won't level up no matter what — at some point it becomes a different conversation about role fit.

15.4 Performance issues — the gradient

Not every performance issue is a fire. Track:

Severity	Signal	Response
Soft	One off-week, one weak PR, one missed sprint	Note, watch, address in 1:1 if recurs
Pattern	3+ weeks of below-bar output, quality slipping	Direct conversation, written expectations, check-in 4 weeks
Hard	Multi-month underperformance, unwilling to engage	Formal performance plan with EM/HR involvement

Most TLs miss the "Pattern" stage — they avoid the awkward conversation, then 8 months later the engineer is on a PIP and surprised. The TL who names the pattern early and lets the engineer course-correct often turns 60% of these around.

15.5 Letting someone go

The conversation you'll have at most 1–3 times per year (more often, you're hiring badly).

It's never the same day they hear it. Performance conversations should escalate gradually so the final conversation is not a surprise.
It's not yours alone. The EM/HR drives the formal process; you support and provide evidence.
Communicate to the team thoughtfully. A short, dignified note ("X is no longer with us, we wish them well, here's how their work is being handled"). Don't gossip. Don't pretend it didn't happen.
Check the team within 48 hours. Layoffs and firings spike anxiety; people need reassurance.
Reflect honestly. What did you miss? What signals were there 6 months earlier? Most fires reveal a hiring or coaching gap. Update your patterns.

15.6 The reverse case: when a great engineer leaves

When a senior IC quits, treat it as a Sev-1 incident on team continuity.

Have the conversation. Why? (Sometimes there's still time.)
Document everything they own, every decision they're carrying. Pair before they leave.
Plan the void: who steps up, what gets dropped, what gets hired against.
Tell the team without spinning. "X is leaving for Y reasons. Here's what we're doing."
Reflect: what made them leave? Is the cause structural (comp, growth, scope) or local (a project they hated)? Adjust if structural.

A high-performer leaving is often the canary on a structural issue. Don't waste the signal.

16. 🌱 Growing the Team Without Breaking It

Growth is harder than it looks. A team of 4 that adds 3 engineers in a month is a team of 7 with 4 engineers' worth of context.

16.1 The "rule of 5"

Teams under 5 are tight, fast, low-process. Teams of 5–8 are the productivity sweet spot. Teams of 9+ start to need sub-structure (sub-teams, leads-of-leads). Most early-stage tech leads keep ramping past 9 because the company keeps hiring; the team's velocity degrades.

If you're past 9, push for splitting the team. Two teams of 5 typically out-deliver one team of 10.

16.2 The onboarding tax

Every new hire costs 4–6 weeks of a senior engineer's time across the first 8 weeks. If you onboard 3 hires in a quarter, you've spent ~3 senior-months on onboarding, pretty close to the time it would have taken to ship one mid-sized project. Plan for it; don't be surprised.

16.3 Adding seniority vs adding hands

When the team feels overloaded, the instinct is to hire more juniors. Often wrong. Ask:

Are we slow because we don't have enough hands? → mid/junior helps.
Are we slow because we keep making bad decisions? → senior or staff helps.
Are we slow because we keep firefighting in production? → senior + on-call investment.
Are we slow because we don't know what to build? → not a hiring problem (PM/strategy).

Misdiagnosing produces a team with 8 people and the same throughput as 5.

16.4 The TL's transition out

At some point the team is too big to TL alone (typically 8+). Two paths:

Step up to staff or EM. You hand TL duties to a senior; you take on broader scope.
Split the team and hand off one half. You stay TL of one team; new TL takes the other.

Either way, plan the handover. Identify and groom your successor 6 months in advance. Hand off projects, then hand off rituals (standups, design reviews), then hand off final say. A handover done in 2 weeks is a betrayal; in 3 months it's a graduation.

16.5 Don't let the team age into a monoculture

Healthy teams have diversity in:

Seniority (no team should be all senior or all junior; both extremes break).
Background (industry, language ecosystem, prior org type).
Tenure (mix of long-tenure context-keepers and recent fresh-eyes).
Demographic.

Audit yearly. If your team is drifting into homogeneity, the next 3 hires are the lever. Resist the temptation to hire "people like the team" — short-term comfort, long-term staleness.

17. 💬 Communication: Writing, Speaking, Status

Writing is the highest-leverage skill of a tech lead. Speaking is the second.

17.1 The weekly written update

Every Friday (or whatever cadence works), the TL writes a 200–500 word update to the team and stakeholders. Format:

# Team X — Week of YYYY-MM-DD

## Shipped this week
- [item] — [owner], [link]

## In flight
- [item] — [owner], [status], [risk if any]

## Decisions made
- [decision] — [link to ADR/doc]

## What's next week
- [top 3]

## Asks / blockers
- [specific ask, named owner of the request]

Why it matters: forces you to think about the week deliberately; gives stakeholders 0-effort context; builds your team's "story"; trains you to write briefly. Most TLs skip this for a year and wonder why their leadership has no idea what the team does.

17.2 The art of the brief

Compress aggressively. Internal communication has 3 lengths:

One line: Slack message, status update, ask.
One paragraph: decision, escalation, summary of complex thread.
One page: ADR, design summary, weekly update.
Multi-page: RFC, postmortem. Use sparingly.

If a thread is heading toward 50 messages, stop and write a one-page summary. You'll save the team 4 hours of catching up.

17.3 The art of the ask

Most TL asks are too vague. "Can someone help with X?" gets ignored.

Ask format:

@person — by [date], could you [specific thing]?
Why: [1-line reason or impact]
Context: [link]

Three properties: a named person (not @channel), a specific date, a specific thing. "@maria — by Thursday EOD, could you look at the auth design doc and sign off / flag concerns? Need this to start the migration on Monday. [link]"

17.4 Public speaking & demos

You'll present sometimes — quarterly review, demo day, all-hands, customer call. Defaults:

Open with the punchline. Not background, not "first I'd like to thank…" Lead with the conclusion. "We shipped X and customers reduced their workflow time by 40%."
Less is more. A 5-minute demo with 1 thing landed > 15-minute demo with 5 things half-landed.
Tell a story. Problem → approach → result. Engineers default to architecture diagrams; humans connect to story.
Prepare for the question you fear most. Usually you know exactly what it is. Have a clear, short answer.
Practice once. Out loud. Just once. The difference is huge.

17.5 Slack hygiene

A team's Slack culture is set by the TL.

Threads, not channel spam. Reply in thread; only "broadcast back to channel" if relevant.
Async-default. Reasonable response time is 4 hours during work, not 4 minutes.
Status emojis or DND norms. Make it OK to be unreachable for 2 hours of deep work.
No business decisions in DMs. If it matters, it goes in a channel or a doc.
One channel per topic, archive aggressively. A team with 25 stale channels makes everything harder to find.

17.6 Writing for AI

In 2026, write so AI can read your team's stuff well. CLAUDE.md (or equivalent), READMEs, ADRs, design docs — all benefit from being structured, named clearly, and explicit about non-obvious context. The team that writes well for AI also writes well for new humans.

18. ⚠️ The Tech Lead Anti-Pattern Catalog

The 12 most common TL failure modes and their antidotes.

18.1 The Hero TL

Symptom: TL takes the hardest tickets, ships the heroic Friday-night fixes, has the deepest knowledge of every system.
Why it fails: Team plateaus. TL becomes a single point of failure. Burnout in 12 months.
Antidote: rotate ownership of every "hard" thing. Pair before solving. Document instead of hoarding.

18.2 The Ghost TL

Symptom: TL retreated to deep IC work; team rarely sees them; no direction; no 1:1s; no design reviews.
Why it fails: Team drifts. Stakeholders lose confidence. Engineers feel unsupported.
Antidote: force the calendar. Block 1:1s, design reviews, weekly written update. Make them non-negotiable.

18.3 The Bottleneck TL

Symptom: every PR waits on TL approval. Every decision goes through TL. Vacation = team paralysis.
Why it fails: team velocity bounded by TL throughput.
Antidote: delegate review. Identify 2–3 "lieutenants" who can approve. Use ADRs so decisions are documented, not personality-bound.

18.4 The Yes-Person TL

Symptom: TL says yes to every PM request, every customer ask, every exec idea. Team drowns. Quality drops.
Why it fails: trust erodes. Engineers leave. Eventually you fail at delivery despite working harder.
Antidote: §12.6. Practice saying "yes, if we drop X." Build "no" into your weekly habit.

18.5 The Architecture Astronaut

Symptom: TL writes 30-page design docs about future-proof systems for problems no one has yet.
Why it fails: team ships nothing. Customer waits. Engineers lose respect for the role.
Antidote: ship-then-design. Build the simplest thing that works. Refactor when patterns emerge.

18.6 The Cargo-Culter

Symptom: TL imports a process from their last company without examining whether it fits. "At Big Co we did Scrum daily so we will here."
Why it fails: processes designed for 200-person orgs strangle 5-person teams. Team rebels.
Antidote: start from problems, derive process. Steal pieces, not whole methodologies.

18.7 The Conflict Avoider

Symptom: TL doesn't address performance issues, conflict, or hard decisions. Hopes they resolve themselves.
Why it fails: problems compound. Team loses respect for TL. Hardest call still has to be made, just later, with worse outcomes.
Antidote: §8.5. Schedule the hard conversation this week. Use SBI. Practice the script.

18.8 The Drama Magnet

Symptom: every conflict on the team becomes a TL conflict. TL gets drawn into every disagreement.
Why it fails: the team's emotional weather lives in the TL. Burnout and bias.
Antidote: triage. Most conflicts the team can resolve. Step in for structural issues; coach through interpersonal ones.

18.9 The Stack Maximalist

Symptom: every quarter brings a new framework, language, datastore, deploy tool. Team in constant migration mode.
Why it fails: velocity actually drops. Onboarding becomes impossible. Tech debt compounds.
Antidote: boring tech rule. Pick stable, well-documented tools. Migrate only when current tool is failing, not when newer tool is interesting.

18.10 The Vibe-Driven TL

Symptom: TL operates entirely on instinct. Few written docs. Decisions in DMs. Direction in their head.
Why it fails: team can't operate without TL present. New hires take forever to ramp. Decisions get re-litigated.
Antidote: write it down. ADRs, weekly updates, direction doc, definition of done. Pay the writing tax.

18.11 The Performance Blind

Symptom: TL believes "everyone is doing fine" right up until someone's surprise resignation, manager escalation, or PIP.
Why it fails: preventable issues become unfixable.
Antidote: §15. Maintain a per-engineer health doc. Talk early. Lead with evidence.

18.12 The Burnout Heroic

Symptom: TL works 60+ hours/week as a badge. Expects team to follow. Doesn't take vacation.
Why it fails: TL crashes in 12–18 months. Team copies the pattern and crashes alongside.
Antidote: model rest. Visibly take vacation. Visibly leave at 6pm. Visibly say "I don't know, I'll think about it tomorrow." Health is contagious; so is unhealth.

19. 🗺️ The Phased Roadmap (Day 1 → Year 2)

What "doing well" looks like at each stage.

19.1 Week 1–4: Listen & Learn

Goal: build context and credibility, change as little as possible.
Output: 1:1s with everyone, state-of-the-team note, light shadowing of all rituals.
Anti-pattern: announcing changes in week 2.

19.2 Month 2–3: Diagnose & Quick Wins

Goal: 2–3 visible improvements, draft technical direction, establish cadence.
Output: weekly update started, 1:1s rolling, definition-of-done in place, direction doc v1.
Anti-pattern: big bang reorganization.

19.3 Month 4–6: Operate & Make 1 Hard Call

Goal: team is shipping predictably; you've made one visible hard call (kill a project, change on-call, confront a performance issue).
Output: quarterly plan, ADR repo started, healthy review latency, no surprises in 1:1s with EM.
Anti-pattern: still being the bottleneck on every decision.

19.4 Month 7–12: Compound

Goal: the team's habits run without you. You spend more time on direction and less on coordination.
Output: at least 1 engineer leveled up under your coaching, at least 1 architectural improvement landed, on-call quality improved, public weekly updates respected.
Anti-pattern: plateauing — same outcomes as month 3.

19.5 Year 2: Scale or Pass the Baton

Goal: team has grown (in scope, in headcount, in capability). You're either ready for staff/EM scope, or grooming a successor while you take on something new.
Output: at least 2 engineers operating at the level above where they joined; team direction respected by adjacent teams; you're on the company's "radar" as a leader, not just a TL.
Anti-pattern: the team is fine but you're stuck at the same scope.

20. 📋 Cheat Sheet & Resources

20.1 The 1-page TL cheat sheet

Pin to your monitor:

WEEKLY
□ 1:1 with each report (theirs, not yours)
□ Architecture/design review (60 min)
□ Written team update
□ 2–3 hr deep-work blocks protected
□ Manager 1:1 prepped

MONTHLY
□ Direction doc revisit
□ Tech debt registry triage
□ Skip-level / peer-TL coffee
□ Per-engineer health note updated
□ At least 1 hard conversation handled

QUARTERLY
□ Quarterly plan drafted, agreed, communicated
□ Direction doc rewritten
□ Top 3 systemic risks identified, 1 fixed
□ Promo/perf calibration with EM
□ Personal retro (what worked, what didn't)

DEFAULTS
- Two-way doors decided fast
- One-way doors decided in writing
- ADR for irreversible technical calls
- Design doc for >2-week or cross-team work
- DoD signed before commit
- Async-first, written-first
- "No" with options, not without

20.2 Stock phrases (that work)

"What does success look like for you in 6 months?"
"To take that on, we'd need to drop X. Want to make that swap?"
"Considered alt: X. Decided against because Y."
"I want to be wrong in writing so you can correct me."
"Disagree-and-commit: I'll back the team's call publicly even if I'd have decided differently."
"What's the smallest version of this we can ship Friday?"
"What did you learn this sprint that you didn't know last sprint?"
"Where did we get lucky?"
"I don't know yet. I'll find out by Friday."
"That's a good idea. Let's not do it this quarter."

20.3 Reading list

The short list of books worth your time:

The Manager's Path — Camille Fournier. The canonical book on the engineering management ladder, including the TL chapter. Read first.
An Elegant Puzzle — Will Larson. Best operational manual for engineering leadership at scale.
Staff Engineer — Will Larson. Adjacent role; useful frame for what's next after TL.
High Output Management — Andy Grove. The original. Output as the unit. Still the best.
Team Topologies — Skelton & Pais. The org-design book that explains why your team is sized the way it is.
Accelerate — Forsgren, Humble, Kim. The data on what makes engineering teams perform. Reference often.
Crucial Conversations — Patterson et al. The script for hard conversations. Practical.
Thinking in Systems — Donella Meadows. The mental models you'll re-read for the rest of your career.

20.4 Operating templates (steal these)

ADR: §6.1
Design doc: §6.2
Weekly update: §17.1
Definition of done: §7.3
Escalation: §7.4
Postmortem: §11.3
30-60-90 onboarding: §14.5
Direction doc: §5.2

Copy each into a docs/templates/ folder in your repo. New artifacts use them. The team learns the format; the format becomes the culture.

20.5 The single test of whether you're doing this well

At the end of every month, ask yourself two questions:

"Is the team shipping more meaningful work than they were 3 months ago?" Not "more lines of code" — more meaningful. More customer impact, fewer regressions, faster decisions, clearer direction.
"Have at least 2 engineers on the team grown visibly under my watch?" Specific examples. New skills. Bigger scope. Better designs.

If both yes → keep doing what you're doing.
If shipping yes, growth no → you're an operator, not a leader. Invest in the people side.
If growth yes, shipping no → you're a coach, not a TL. Invest in technical execution.
If both no → something's wrong. Stop and diagnose. Talk to your manager, your peers, your team.

The role compounds. Every month doing it well makes the next month easier. Every month doing it poorly makes the next month harder. There is no neutral.

This playbook is a living document. The 2026 reality (AI-augmented engineering, distributed teams, async-default, the rising bar on technical writing) will keep shifting. Update yours. Argue with mine. Ship better than us both.

If you found this helpful, let me know by leaving a 👍 or a comment!, or if you think this post could help someone, feel free to share it! Thank you very much! 😃