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

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

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

---

1. ⚡ Read This First

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

1. 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.
2. 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.
3. 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:

1. Direction (what we should do, why, and what we won't). 1 hour here = 100 hours saved later.
2. Hiring & growth (who is on the team, what they're working on, what they're learning). 10x compounding.
3. System health (architecture, tech debt, on-call quality). The team's velocity ceiling.
4. Unblocking (the 5-minute Slack message, the design review, the data point). Cheap, high-impact.
5. Reviewing (PRs, designs, plans). Important but second-tier — not everything needs your eyes.
6. 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:

1. 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.
2. 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.
3. 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:

1. Who runs sprint planning / roadmap planning?
2. Who decides architecture and tech direction?
3. Who owns hiring loop ownership for engineering candidates?
4. Who delivers performance feedback (technical vs growth)?
5. Who escalates engineering-impacting decisions to leadership?
6. Who is the visible face of the team to external stakeholders?
7. 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:

1. 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."
2. 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.
3. 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."
4. 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:

1. Write the v0.1 yourself, alone, in 2 hours. Be opinionated. Mark every decision as "draft."
2. Share with 2–3 trusted team members for raw feedback. Listen, take notes, do not defend yet.
3. Rewrite as v0.2.
4. 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."
5. Take the strong objections, rewrite v1.0. Publish.
6. 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:

1. 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.
2. Painful occasionally — the migration that has 5 known traps, the legacy module touched once a quarter. Schedule deliberately, 1 per quarter.
3. 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.
4. 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:

1. Anyone with a design or major decision presents (10 min max each).
2. Team asks questions, raises concerns.
3. TL summarizes outcome ("approved", "needs revision", "rejected", "let's spike").
4. 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:

1. Goal — outcome statement, business-meaningful, not engineering jargon. ("Customers can export their reports to CSV.")
2. Workstreams — 2–5 parallel tracks. ("Backend export service. Frontend trigger UI. Async job infra. Observability. Docs.")
3. Tasks — 1–5 day chunks. Each has owner, acceptance criteria, dependencies.
4. 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:

1. State the issue specifically and observably. SBI format.
2. State the impact on the team / project / them.
3. State your expectation, with a measurable change.
4. Ask their perspective. Listen.
5. Agree on a 2–4 week experiment with a checkpoint.
6. Document it (in your notes, not theirs).
7. 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:

1. 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.)
2. Find the shared interest. (Both engineers want a maintainable system.)
3. 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."
4. If trade-offs don't resolve it, the TL calls the decision and explains in writing. Both engineers commit.
5. 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.

(...to be continued...) Read Part 2 here https://viblo.asia/p/the-tech-lead-playbook-from-best-ic-to-multiplier-part-2-Nj4vg8B8J6r

---

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! 😃