Tech Project Lead A -> Z: What This Series Teaches

You can be a great engineer for a decade and still freeze the first time someone hands you a project to lead. Not because you cannot code - the code is the easy part - but because leading is a different skill. The skill is deciding who does what, defending a timeline, shielding the team from chaos, and talking to people who have never read a stack trace. This series teaches that skill in twenty-six chapters, every one ending in a template you can copy into your repo or wiki on Monday.

Why does an engineer need a separate project-management series?

Three reasons.

Tool-and-template gap. Most engineering articles teach code; most project-management articles teach process. The space in between

• "what does the kickoff doc actually look like, in markdown, that I can paste into Confluence" - has very few good resources. This series fills that gap with artifact-first chapters.

Vocabulary mismatch. A senior engineer who joins a meeting full of PMs hears "RACI", "RAID log", "RAG status", "moscow", "T-shirt sizing", "burndown", and feels like an outsider. The vocabulary is not hard but no one teaches it together. Each chapter defines its terms and shows where they came from.

Trust is built from artifacts. A new tech lead earns the team's trust by being clear on paper - the status report does not lie, the risk log is current, the decision log explains why. Software is trust translated to code; project management is trust translated to documents. This series teaches the documents.

What is the seven-question chapter shape?

Every chapter walks through the same seven questions so you can skim in sixty seconds:

1. When does this artifact / situation actually show up? - the real-world trigger, not the textbook definition.
2. What is the cost of skipping or doing it wrong? - the incident, missed deadline, or angry stakeholder you avoid.
3. What does the minimal version look like for a 5-person team? - the smallest thing that works.
4. What does the scaled version look like at 50+ people? - what changes when you go multi-team.
5. What is the concrete template? - markdown, yaml, or mermaid you can copy into your repo.
6. What are the failure modes and how do I detect them? - the smell when the artifact is being ignored.
7. When should I not use this? - the over-engineering trap.

Code blocks in this series are templates rather than C#. Where the System Design series shows you a Program.cs registration, this series shows you a status-report.md skeleton.

What does the series cover, by group?

Twenty-six chapters in seven groups:

flowchart LR
    Start[00-introduction] --> Found[5 Foundations<br/>roles, estimation, risk, comms, scope]
    Found --> Method[3 Methodology<br/>Scrum, Kanban, when which]
    Method --> Life[6 Lifecycle<br/>kickoff -> launch -> retro]
    Life --> People[3 People<br/>1-on-1, hiring, feedback]
    People --> Artifact[2 Artifacts<br/>status reports, ADRs]
    Artifact --> Case[4 Case Studies<br/>rescue, MVP, legacy, vendor]
    Case --> End[24-checklist + 25-conclusion]

The groups compose. Foundations give you the vocabulary; methodology gives you the cadence; lifecycle gives you the timeline; people give you the team; artifacts give you the paper trail; case studies show all five working together on real projects.

How should I read this series — by chapter or by problem?

Two paths, both valid.

By problem. Open the chapter that names the symptom you have right now. Project running over budget? Read estimation fundamentals and scope and tradeoffs. Stakeholders surprised every week? Read stakeholders and comms and status reports. Each chapter is self-contained.

In order, 00 to 25. The order builds: foundations explain why, methodology explains cadence, lifecycle walks one project end-to-end, case studies replay the lifecycle in different shapes. The full read is about a week of evenings; the reward is recognising the same artifacts across every project you join afterward.

What template style does the series ship?

Every chapter ends in a copy-pastable template. Three formats appear:

# Project Kickoff: {{ Project Name }}

## Why now
{{ One paragraph: what changed in the world to make this project worth doing now. }}

## In scope
- {{ Capability 1 }}
- {{ Capability 2 }}

## Out of scope
- {{ Things explicitly deferred }}

## Decision deadline
{{ Date by which we must commit or kill }}

## Stakeholders
| Role        | Name           | RACI |
|-------------|----------------|------|
| Sponsor     | {{ Name }}     | A    |
| Tech lead   | {{ Name }}     | R    |
| Engineers   | {{ Names }}    | R    |
| Design      | {{ Name }}     | C    |
| Legal       | {{ Name }}     | I    |

## Top 3 risks
1. {{ Risk + mitigation }}
2. {{ Risk + mitigation }}
3. {{ Risk + mitigation }}

Templates are intentionally short. The fastest way to make a project work is to have some artifact instead of no artifact - even a 50-word kickoff doc beats no kickoff. You will iterate from there.

What does the series assume about your stack?

Engineering examples reference .NET (ASP.NET Core, EF Core) because the surrounding series do, but the project-management ideas are stack-neutral. A Java team, a Go team, or a frontend-only team can use every chapter without translation. Where a chapter needs to show concrete tooling - a CI pipeline, an incident runbook - it picks the .NET shape but flags the alternative.

The case studies will reuse domain context from the System Design series so the project becomes a thinking exercise about the shape, not a domain re-explanation.

Where should you start tomorrow?

If you have ten minutes, read PM vs EM vs TPM - it tells you which role fits the work you are actually doing. If you have an hour, read it plus estimation fundamentals and pick one artifact to introduce on your team this week. If you have a week, read 00 through 14 - that gets you through every methodology and lifecycle chapter, and the case studies become much faster after that.

The series is not a textbook to finish; it is a reference to keep open. The artifacts will appear in every project review, every stakeholder meeting, every postmortem. Knowing the names lets you describe your project in one paragraph instead of five hours of status updates.

Welcome aboard.