Staff and leadership cheat sheet (Staff engineer)

1. 1Owning architecture across teamsThe hard design problems now sit between teams: ownership boundaries, build versus buy, reliability and debt. Decide them in writing.8 concepts

   1. 1Service and data ownership boundariesClear lines saying which team owns each service, database and API, who may change it, and who gets paged when it breaks.
   2. 2Conway's lawThe observation that systems tend to mirror the communication structure of the organisation that builds them.
   3. 3Build versus buyDeciding whether to build a capability in house, use open source you operate, or pay for a managed product, based on total cost, differentiation, risk and…
   4. 4Choose boring technologyThe idea that an organisation can afford only a few new, unproven technologies at once, so most choices should use well-understood tools it already runs.
   5. 5Decision records other teams can findArchitecture decisions written as ADRs or design docs and stored in one searchable, well-known place, with status, context, options and consequences.
   6. 6Failure modes and blast radiusThe ways a system can fail, such as dependency outages, overload, retry storms or bad deploys, and how much of the product each failure takes down.
   7. 7SLOs and error budgetsAn SLO is a reliability target for a measured indicator, such as 99.9 percent of requests succeeding over 30 days.
   8. 8Technical debt as a portfolioManaging debt like investments: listing the main items, estimating the ongoing cost of each and the cost to fix, and paying down the ones with the best return.

   8 in this chapterOpen this chapter
2. 2Leading projectsLead work that runs through other people and teams: shape it so it ships, track risks and dependencies, and report honestly.7 concepts

   1. 1Project briefA one-page document stating the problem, why now, the time budget, goals, non-goals, owners and how success will be measured.
   2. 2Appetite and fixed time, variable scopeDeciding first how much time a problem is worth, then shaping a solution that fits that time, instead of estimating a fixed scope.
   3. 3Cutting scopeRemoving or deferring parts of a project, openly and in writing, so the most important part ships on time.
   4. 4MilestonesCheckpoints that each deliver something working you can demo, such as one end-to-end flow for internal users, rather than finished layers like "backend done".
   5. 5Risks and cross-team dependenciesA living list of what could go wrong and what you need from other teams, each with an owner, a date and a mitigation, reviewed weekly.
   6. 6Weekly status updateA short written update saying whether the project is on track, at risk or off track, why, what changed and what help is needed.
   7. 7Brooks's lawThe observation that adding people to a late software project makes it later, because new people need onboarding and communication paths multiply.

   7 in this chapterOpen this chapter
3. Leading incidents and postmortemsRun incidents calmly with clear roles, then learn from them without blame.6 conceptsOpens with credits
4. Communication and influenceBoth paths lead mostly through writing and relationships: write for senior readers, map stakeholders and align people who do not report to you.8 conceptsOpens with credits
5. The staff engineer pathThe individual contributor route past senior: finding problems that span teams, choosing work that matters and making glue work count.9 conceptsOpens with credits
6. Technical strategy and sponsoring othersSet direction for a group of teams with written strategy and vision, and grow the next senior engineers through sponsorship.8 conceptsOpens with credits
7. 7Glossary, A to ZEvery concept in the sheet and the smaller terms it uses, in one list.131 terms

Staff engineer or manager.