The Staff Engineer Track — Scope, Influence, Strategy and Judgment
The craft of senior technical leadership on the individual-contributor path: what a staff engineer actually does, operating at the right altitude, technical strategy, writing that changes decisions, making good technical decisions, driving cross-team projects, influence without authority, glue work and leverage, mentorship and sponsorship, technical health, incidents and judgment, and getting to staff and staying effective. With reusable templates: design doc, ADR, project one-pager, incident review, brag doc.
Most engineering courses teach you to build things. This one is about a different and harder skill: changing what gets built, and how, for many people at once. That’s the staff engineer’s job, and almost none of it is in the code.
If you’ve been a strong senior engineer for a while, you’ve probably noticed that the ladder doesn’t just continue as “write even harder code.” It bends. The people who have the most impact aren’t the fastest coders; they’re the ones who choose the right problems, align teams that were pulling in different directions, write the document that stops a bad quarter before it starts, and make everyone around them better. That’s a real craft, with real techniques, and it’s rarely taught, you’re expected to absorb it by osmosis, which mostly means by luck.
This course teaches it directly. It draws on the well-known staff-engineering literature (Will Larson’s Staff Engineer, Tanya Reilly’s The Staff Engineer’s Path, and ideas from Rumelt, Bezos and others), but the writing is my own, grounded in how engineering actually works in Indian product companies and startups. Plain language, honest about the trade-offs, and practical. The stories are illustrative, made to teach a point, and I say so; the frameworks and templates are things you can use at work tomorrow.
A note on what this is not: it’s not a promise that reading it makes you a staff engineer, and it’s not only about getting the title. It’s about the work. The title, as you’ll see in the last lesson, follows the work, not the other way around.
What This Course Covers
| # | Lesson | What you will learn |
|---|---|---|
| 1 | What a Staff Engineer Actually Does | The archetypes, the IC-vs-manager fork, what changes from senior |
| 2 | Scope, Impact and Altitude | Operating at the right level and choosing what matters |
| 3 | Technical Strategy and Vision | Diagnosis, policy, action, setting direction that sticks |
| 4 | Writing That Changes Decisions | Design docs, writing for the reader, the BLUF |
| 5 | Making Technical Decisions | One-way vs two-way doors, trade-off matrices, ADRs |
| 6 | Driving Cross-Team Projects | The one-pager, dependencies, and why the critical path is people |
| 7 | Influence Without Authority | The trust equation, stakeholder mapping, disagree and commit |
| 8 | Glue Work and Leverage | The invisible work, and where your hour goes furthest |
| 9 | Mentorship and Sponsorship | Growing others, and the difference that makes careers |
| 10 | Architecture and Technical Health | Tech debt, safe migrations, keeping systems alive |
| 11 | Incidents, Risk and Judgment | Being the calm, blameless postmortems, managing risk |
| 12 | Getting to Staff and Staying | Promotion, the brag doc, the traps, and a 90-day capstone |
Who Is This For?
- Senior engineers who want to grow on the individual-contributor path, not into management
- New staff/principal engineers finding that the job is different from what got them here
- Engineering managers who want to understand and grow the staff engineers on their team
- Anyone curious about what “staff” really means beyond a title
How to Use It
Read it in order the first time, the parts build. Then treat it as a reference: when you’re about to write a big design doc (Lesson 4), drive a cross-team project (Lesson 6), run a postmortem (Lesson 11), or make your promotion case (Lesson 12), come back to that lesson and its template. The templates (design doc, ADR, project one-pager, incident review, brag doc) are meant to be copied and adapted.
Let’s start with the question everyone asks and few answer clearly: what does a staff engineer actually do all day?