Module 2: The Operating Model
Five lessons on how the job actually runs: the maps you draw, the projects you refuse, the documents that carry your influence, and the code you keep your hands in.
| Source | Used for |
|---|---|
| Tanya Reilly, The Staff Engineer’s Path (ch. 2 to 6) | Three maps, finite time, vision and strategy, big projects, why projects stop |
| Hands-on Architects, The Staff Engineer Toolkit | Stakeholder mapping, the deep-work ratio, the doc template, execution habits, “stay hands-on” |
| Will Larson, staffeng.com | Getting in the room, work on what matters, engineering strategy |
| GitLab Handbook | Epics and MVCs, “hands-on to hands-off” |
| Alex Ewerlöf | The ivory tower anti-pattern, as the tiebreaker in lesson 2.5 |
Three Maps: Locator, Topographical, Treasure
Chapter 2 of The Staff Engineer’s Path is the most borrowed chapter in the staff engineering canon. Tanya Reilly says a new staff engineer needs three maps. She is right, and she also does not spend much time on how to draw them. This lesson takes the maps from Reilly and the drawing tools from the Hands-on Architects toolkit.
The Three Maps
The locator map answers “you are here.” It is perspective. Reilly’s phrase is “seeing bigger”: understanding how your team’s work looks from the rest of the company, and how the company looks from the industry.
The topographical map is the terrain. Who decides what, where the shortcuts and the swamps are, which teams talk to each other and which do not. Reilly’s advice when the terrain stays hard to read: be a bridge.
The treasure map is the destination. Where is the organization going, and why. Her warning is against “chasing shiny things.” If the treasure map is unclear, she says it may be time to draw a new one, which is what chapter 3 and lesson 2.3 are about.
Source: The Staff Engineer’s Path, ch. 2, Tanya Reilly.
How to Draw the Topographical Map
Hands-on Architects give the tools Reilly leaves out. Map key stakeholders, teams, and relationships with an org chart, a stakeholder mapping matrix, and a network diagram. Identify the influencers and decision-makers, which are often not the people with the formal authority. Then build the relationships: read their documents, comment on them, ask questions, book 1:1s. Their one strong opinion: “If possible, meet people in person.”
For the treasure map, follow the goal chain. Company OKRs, then department goals, then your manager’s goals, then your team’s goals. If you cannot draw a straight line from your current project to a company OKR, that is a finding.
Source: The Staff Engineer Toolkit, Hands-on Architects.
What to Do When the Map Shows a Room You Are Not In
The topographical map usually reveals the same thing: decisions get made in a meeting you are not invited to. Will Larson’s guide on getting into the room says you are not there for one of two reasons: you have not shown the room a kind of expertise it lacks, or nobody with social capital has advocated for you. So getting in takes both. Bring something distinctive, and make sure a sponsor knows you want in.
Staying in is a shorter list of things to avoid: misreading what the room is for, taking dogmatic positions, blocking decisions, dominating the discussion, embarrassing your sponsor, and missing meetings.
Source: Getting in the room, and staying there, Will Larson.
The Short Version
If you want the three maps in six minutes, Todd Larsen’s summary at technical-leaders.com covers them. It adds nothing to Reilly, but it is fast.
Finite Time: The Project Filter and the Calendar
Your problem: a staff engineer’s calendar is the only resource they fully control, and most of them give it away.
Chapter 4 of Reilly’s book is titled Finite Time, and that is its argument.
The Filter
Reilly treats project selection as a bin-packing problem. You have a fixed amount of time and energy. Every project has a size. The question is which set of projects fits. Her chapter includes a set of questions to ask yourself about any project before you sign on: what it will do to your energy, your credibility, your quality of life, your social capital, and your skills growth.
A project that burns three of those to buy one is a bad trade even when it is important to the company.
She also has a section titled “What If It’s the Wrong Project?” Staff engineers get handed work that looks like staff work and is not. Saying no is part of the job.
Source: The Staff Engineer’s Path, ch. 4, Tanya Reilly.
The Calendar
Hands-on Architects borrow Reilly’s five questions and add a number to aim for. Track your deep-work ratio every week and target 40 to 50 percent of your time. Their blocking pattern: mornings for deep work, afternoons for meetings and collaboration, a Friday slot for learning and coding practice, everything on the calendar so it is defended by default.
“Your ‘no’ is a gift to your future self.”
They add one more reason to guard the calendar. Every technical skill set goes obsolete over time, so the projects you pick are also how you learn. Pick ones where you work closely with someone highly skilled, or you end up learning in your spare time, which does not last.
What “Matters” Means
Reilly tells you how to filter. Larson tells you what to filter for. His guide “Work on what matters” names three things to stop doing:
- Snacking. Easy, low-impact work that feels productive.
- Preening. High-visibility, low-impact work that gets mistaken for achievement.
- Chasing ghosts. Importing solutions from your last job that do not fit this one.
Then he names where the impact is: existential issues for the company first, then work where there is room and attention, meaning problems the company values that nobody is already on. His last three are foster growth, edit (small changes and conversations that unlock a lot), finish things, and “what only you can.”
Read his three “stop” items against Reilly’s five questions. Snacking scores well on energy and badly on everything else. Preening scores well on credibility for about a quarter.
Source: Work on what matters, Will Larson.
Measure your deep-work hours for one week without changing anything. Then run every current project through Reilly’s five questions and cut or hand off the one that scores worst.
Writing as the Main Tool
A staff engineer without authority has one lever that scales: a document. This lesson takes the template from Hands-on Architects, the process from Reilly, and the argument from Larson.
The Template
Hands-on Architects put it in three words: writing is thinking. Their reasons are that it clarifies ideas, preserves decisions, and enables asynchronous collaboration. They use one document shape for ADRs, RFCs, and design docs.
# [Decision title]
## 1. TL;DR
One paragraph, for the stakeholder who reads one paragraph.
## 2. Audience
Who reads this. Who approves it. Who is informed.
## 3. Context
Background and history. What led here.
## 4. Problem statement
The problem, stated so someone could disagree with it.
## 5. Options considered
Option A / Option B / Option C, with tradeoffs.
## 6. Decision rationale
Which one, and why this one over the others.
## 7. Consequences
Risks, and next steps with names attached.Two habits go with it. Timebox the writing so perfectionism does not eat the week. Revisit the doc after feedback and again later. They use AI tools to summarize and tighten, and they review the output afterward.
Source: The Staff Engineer Toolkit, Hands-on Architects.
The Process for the Big One
The template covers a decision. Reilly’s chapter 3 covers the document that decides a direction: a technical vision or a technical strategy. She separates the two. A vision describes the destination. A strategy describes the path.
Then she gives the approach that gets one written and adopted, and every step is about people rather than prose. Embrace the boring ideas. Join an expedition already in progress instead of starting a rival one. Get a sponsor. Choose a core group. Set scope. Make sure it is achievable. Make it official.
Only then does the writing loop start, and even that alternates between making decisions and getting aligned. The launch step is “make it official,” and the last step is “keep it fresh.”
Source: The Staff Engineer’s Path, ch. 3, Tanya Reilly.
Why This Is the Leverage
Will Larson’s guide on writing engineering strategy is the companion read. Larson’s framing is that a strategy is built from the design decisions an organization keeps making, written down so the next decision does not have to relitigate the last five, and a vision is the longer view those strategies add up to.
Reilly gives the process for one document. Larson gives the reason the staff engineer is the person who should own it: it is the written form of setting technical direction, the first item in the job description from lesson 1.4.
Source: Writing engineering strategy, Will Larson.
Take a decision your team made verbally in the last month and write it up in the seven sections. Send it to the people who were in the room. The corrections you get back are the point.
The Code: Your daily unfair advantage in software engineering.
Join 350,000+ software engineers, tech leads, and CTOs who start their morning with The Code.
Leading Big Projects, and the Six Ways They Stop
Reilly gives two chapters to projects. Chapter 5 is how to run one. Chapter 6, titled “Why Have We Stopped?”, is a diagnosis list. This lesson pairs each diagnosis with a habit from GitLab or Hands-on Architects that prevents it.
Running the Project
Reilly’s chapter 5 walks the life of a project from the start. Her first section is for the moment you feel overwhelmed, which she treats as normal. Then: build context, give the project structure, and drive it through six kinds of work she names as exploring, clarifying, designing, coding, communicating, and navigating.
Coding is one of six.
Source: The Staff Engineer’s Path, ch. 5, Tanya Reilly.
The Ways It Stops, and What Prevents Each One
Chapter 6 lists why projects stall. Here is that list against the habit that prevents it.
| Reilly’s diagnosis | The habit that prevents it |
|---|---|
| Blocked by unassigned work | GitLab: “break down large tasks for the team into epics with smaller issues or MVCs.” Unassigned work is usually work that was never broken down small enough to assign. |
| Blocked by another team | Hands-on Architects: milestones with explicit risks and dependencies. A dependency written down with a name next to it gets unblocked. One that lives in your head does not. |
| Blocked by a decision | Asynchronous updates: dashboards, weekly summaries, short reports. Iterate the plan on feedback. |
| Blocked by a single button click | A topographical map problem. Go back to lesson 2.1 and find who actually decides. |
| Blocked by a single person | Same map, same fix. |
| Blocked by a huge crowd of people | Reilly’s own answer in ch. 6, plus the core-group step from lesson 2.3. |
| You are lost | A writing problem. The seven-section doc from lesson 2.3 answers where you are going, how you get there, and where you stand. |
| “Done” but nobody is using it, or built on a shaky foundation | Reilly’s third set. The launch step from ch. 3: make it official, then keep it fresh. |
Sources: The Staff Engineer’s Path, ch. 6, GitLab Handbook, and Hands-on Architects.
Take your current project and pick one line from Reilly’s list. Not “it’s complicated.” One line. The fix follows from the diagnosis.
The Hands-On Question
Two of our sources contradict each other, and neither one acknowledges the other. This is the lesson where the guide takes a position.
The Case for Hands-Off
GitLab’s handbook tells a newly promoted staff engineer what changes. The first item: “Shift your technical prowess from hands-on to hands-off by guiding, coaching, aligning, and organizing others.” You still take the most critical or complex topics in your group, and you get pulled in when the group is struggling, but the default is to empower others to take your place on the work you used to own.
The handbook’s list of 18 staff initiatives in lesson 1.4 contains no coding item.
Source: Staff Engineers, GitLab Handbook.
The Case for Hands-On
Hands-on Architects list “losing touch with coding” as one of four traps for staff engineers, and their language is not gentle.
“Stay hands-on! No excuses!”
Their reasoning is that credibility, social capital, and empathy for the team all come from the code. Their fixes are pair programming, small coding tasks, code reviews, hackathons, and internal coding dojos.
The Tiebreaker
Alex Ewerlöf’s anti-pattern list names the ivory tower staff engineer: someone who spends their time in leadership meetings and understands the tech secondhand through reports from managers and tech leads. His test is a question.
“Who is closer to tech than engineers? And who can have an informed opinion about tech without touching it?”
That question resolves the contradiction. GitLab and Hands-on Architects are talking about different things. GitLab is describing what you own. Hands-on Architects are describing what you touch. You can stop owning features and still write code every week. What you cannot do is set technical direction for systems you no longer understand from the inside.
Hand off ownership. Keep your hands in the code. The floor is enough code to hold an informed opinion about every system you set direction for. For most staff engineers that means reviews every week, a small change most weeks, and one real piece of work a quarter that ships under your name.
Lesson 4.4 revisits this with AI coding agents in the picture, because the economics of “enough code” changed in 2026.
By this point you should have:
- Three maps drafted for your organization, even rough ones
- A weekly deep-work number, measured, not guessed
- One document written in the seven-section template
- The name of the blocker your current project is stuck on
- A position on how much code you write, and why
Module 3: Getting the Title
Larson’s staffeng.com is the spine, because it is the only source built from interviews with people who actually got the title. The packet, the sponsor, the myth, and the blockers you cannot fix.