Chapter 5: Leading Big Projects
tsep project-leadership raci rfc anchor-doc execution big-picture-thinking
Status: Notes complete
Overview
Chapter 5 is the practical execution guide for leading large, ambiguous technical projects — the kind that span multiple teams, have unclear requirements, and take months or years. These projects are typically where staff engineers spend a significant portion of their time, and they’re often where staff engineers struggle most.
The chapter acknowledges that leading big projects feels overwhelming at first. The sheer number of unknowns, stakeholders, and moving parts can be paralyzing. The chapter provides a systematic approach to managing this complexity: first get context, then create structure, then drive continuously. It’s not about having all the answers up front; it’s about building understanding incrementally and keeping the project moving.
Core Concepts
Anchor document: A shared document that holds the key context, decisions, and status for a project — the “single source of truth” that orients new stakeholders and keeps existing ones aligned.
RACI matrix: A responsibility assignment tool: Responsible (does the work), Accountable (owns the outcome), Consulted (gives input), Informed (kept updated).
RFC (Request for Comment): A design document format that structures technical proposals for broad review and consensus. Separates “presenting a solution” from “soliciting feedback.”
Sponsor: A senior leader who champions the project, provides air cover, and helps unblock organizational obstacles.
Sounding board: A trusted person (peer, mentor, or outside the project) who gives honest feedback and helps the project lead think through difficult problems.
Phase 1: Handling the Initial Overwhelm
When you first take on a large, ambiguous project, it’s normal to feel lost. The chapter gives specific tactics for the first few days/weeks:
Get an anchor document: Start writing immediately — not because you know what you’re doing, but because writing forces clarity. The anchor doc starts rough and improves over time. It’s a place to capture what you know, what you don’t know, and what you’re trying to find out.
Talk to your sponsor: Make sure you understand why this project matters to the person who gave it to you. What does success look like for them? What does failure look like? What resources do you have?
Find a sounding board: Identify 1–2 people you can talk to honestly — about what you don’t understand, about ideas you’re not sure about, about the problems you’re running into. This is not the same as a mentor; a sounding board can be a peer.
Give yourself a win: Pick something small and concrete you can accomplish in the first week. It resets the mental state from “overwhelmed” to “making progress.”
Use your strengths: In the early ambiguous phase, lean on what you’re best at. If you’re good at talking to people, start with stakeholder conversations. If you’re good at writing, start with a doc. Build momentum from a place of capability.
Phase 2: Building Context
Before you can create a plan, you need to understand the problem. A project context document should answer these questions:
| Category | Questions |
|---|---|
| Goals | What are we trying to achieve? What does success look like? |
| Customer needs | Who uses or depends on the outcome? What do they actually care about? |
| Success metrics | How will we know it worked? What are measurable outcomes? |
| Sponsors | Who has given organizational backing? What do they need? |
| Constraints | What can’t change? What deadlines are non-negotiable? What’s the budget? |
| Risks | What could go wrong? What are the biggest unknowns? |
| History | What has been tried before? Why did it fail or stop? |
| Team | Who is involved? What do they own? What are their priorities? |
This context doesn’t arrive all at once. Build it through conversations, document reading, and system exploration. The goal is not perfect information; it’s enough understanding to make good decisions.
Phase 3: Creating Structure
Structure enables other people to work without waiting for you. A well-structured project can continue making progress even when you’re unavailable.
Roles Table
Before formal RACI, create a simpler roles table that answers for each person: what is their involvement, what do they own, and what decisions can they make independently?
RACI Matrix
| Role | Meaning | Notes |
|---|---|---|
| Responsible | Does the work | Can be multiple people; they execute |
| Accountable | Owns the outcome | Only one person; they’re on the hook |
| Consulted | Gives input before decisions | Two-way communication |
| Informed | Gets updates | One-way communication |
Common errors:
- Multiple people “Accountable” (means nobody is)
- Everything going to “Consulted” (drowns people in requests)
- Key stakeholders missing from the matrix entirely
Scope and Milestones
Define:
- What is in scope (specific) and what is explicitly out of scope
- 2–4 milestones that represent real, observable progress
- What the final “done” state looks like
Time Estimation
- Don’t estimate alone; involve the people who will do the work
- Use ranges, not point estimates (pessimistic / realistic / optimistic)
- Identify the highest-risk items and give them extra buffer
- Name the major assumptions; if any assumption breaks, the estimate changes
Logistics
- How will the team communicate? (channel, cadence, format)
- How will decisions be made and recorded?
- What are the meeting rhythms?
- How will status be shared with stakeholders who aren’t in the day-to-day?
Kickoff
A kickoff meeting (or document) that brings the whole team together to agree on goals, scope, roles, and working norms. This is the moment when “a bunch of people who might work together” becomes “a team with a shared mission.”
Phase 4: Driving
Leading is ongoing work, not a one-time setup. The chapter covers the recurring activities that keep a project moving:
Exploring
Staff engineers must continually deepen their understanding of the problem. Talk to users, read related docs, understand adjacent systems. The model of the problem you build in Phase 2 needs to stay current as you learn more.
Clarifying
Ambiguous things will constantly arise. Your job is to resolve ambiguity before it blocks people. If a team member says “I’m not sure if I should do X or Y,” that’s your signal to investigate, facilitate a decision, and document it.
Designing with RFC
For significant technical decisions, use an RFC process:
- Write a document that describes the problem, explores options, makes a recommendation, and solicits feedback
- Share it widely; set a deadline for comments
- Integrate feedback, make the decision, and document the outcome
- The RFC is evidence that the decision was made thoughtfully
RFC structure:
- Problem statement: What are we solving, and why?
- Context: Background the reader needs
- Requirements: What must the solution achieve?
- Options: What are the viable approaches?
- Recommendation: What do you propose, and why?
- Open questions: What feedback are you seeking?
- Decision: (filled in after review)
Coding
Staff engineers on execution projects should write some code. Not all the code — that’s not the job — but enough to:
- Stay credible with the team doing the work
- Understand the real difficulty of the problem
- Unblock critical paths
- Demonstrate the approach for others to follow
Communicating Status
Stakeholders who don’t get regular updates will either:
- Fill the void with assumptions (often negative)
- Interrupt you constantly for information
A regular status update (weekly or biweekly) that covers: what’s been done, what’s coming up, what’s blocked, and what decisions are needed. Brief is better than thorough.
Navigating
Projects will encounter unexpected obstacles, stakeholder conflicts, and changing requirements. The staff engineer’s job is to navigate these without the project falling apart:
- When stakeholders disagree, facilitate resolution rather than escalating immediately
- When scope creep arrives, evaluate it against the project’s mission before accepting
- When blocked, use the techniques from Chapter 6
Key Takeaways
- Big projects feel overwhelming initially; the antidote is structure (anchor doc, sponsor, sounding board) and quick early wins.
- Spend time building context before building a plan — understand goals, customers, constraints, and history.
- Structure enables the team to work without waiting for you: RACI, milestones, roles, logistics.
- Driving a project is ongoing work: exploring, clarifying, designing, coding, communicating status, navigating.
- The RFC format structures design decisions for broad review and creates a record of reasoning.
- RACI prevents diffuse accountability — there should be exactly one Accountable per deliverable.
- Status updates prevent the vacuum that stakeholders fill with worry.
Related Resources
- ch04-finite-time — How to evaluate whether to take the project at all
- ch06-why-have-we-stopped — What to do when the project stalls
- ch03-creating-big-picture — How technical strategy gives projects a north star