Stage 2 of 5 · 8 lessons · ~6 weeks
Leading projects and incidents
Lead work that runs through other people and teams: scope it so it ships, track risks and dependencies, and run incidents and postmortems calmly.
Start: A one-page project briefLessons· one lesson for each topic, in this order
Do this
- Write a one-page project brief: problem, time budget, non-goals and owners
- Break the work into milestones that each ship something you can demo
- Keep a risk and dependency list and review it weekly with the other teams
- Send a short weekly status: on track, at risk or off track, and why
- Cut scope early when a milestone slips, and say so in writing
- Act as incident commander once, with someone else doing the debugging
- Write a blameless postmortem whose action items have owners and dates
Start with· follow one of these
- BookFreeShape Up
Ryan Singer, Basecamp · Intermediate
Free book on shaping and scoping work so projects actually finish
- BookFreeGoogle Site Reliability Engineering Book
Google · Advanced
The chapters on managing incidents and blameless postmortem culture
Keep handy
Also worth your time
Before moving on: Lead a project of several weeks involving at least two teams from scope to launch with written milestones, and run or write a blameless postmortem for one incident.
Cut scope early and say so out loud, because a late surprise costs more trust than a smaller plan. In an incident one person coordinates, and nobody tries to debug and communicate at the same time.