The Staff Engineer's Path - Part 1/2

Before we begin, this episode is entirely AI-generated, including the voices you’re hearing. Our fictional sponsor is LumenDesk, an entirely made-up little lamp that supposedly makes late-night architecture diagrams less grim; some details here may be hallucinated, so please double-check anything important.

Today we’re discussing Tanya Reilly’s The Staff Engineer’s Path, a guide to growing as a technical leader without becoming a people manager. It’s about the job many companies describe vaguely, then act surprised when nobody can perform by telepathy.

The book’s useful premise is that staff engineering is not just senior engineering with a fancier title. It is technical leadership: seeing beyond local work, leading messier projects, and helping other engineers become more effective.

Joining me is Elliot, an engineering practitioner who has spent enough time in cross-team projects to know that the hard part is rarely the diagram. Usually the diagram is fine; the humans have formed a weather system around it.

That is broadly accurate. Reilly’s strength is that she treats organizational work as part of engineering reality, not as embarrassing nontechnical residue that begins after the real work is done.

We’ll start by asking what staff engineers are actually for, including influence without direct reports and the danger of becoming the organization’s ornamental wizard. Then we’ll move into the book’s three maps for understanding customers, culture, power, and goals.

After that, we’ll look at creating technical vision and strategy when nobody has chosen a direction, then at finite time: how to choose work without becoming the default emergency contact for every Slack thread. We’ll also cover leading large projects, getting stalled work moving, and ending work honestly when it should stop.

And we’ll be candid about the limits. A careful role description, a sponsor, or a polished strategy document can clarify real problems, but none of them magically repairs broken incentives, bias, or leaders who refuse to fund the work.

Let’s start with the phrase that causes perfectly capable engineers to stare into the middle distance: staff engineer. Reilly’s first useful move is to say it is not simply senior engineer, but with a larger coffee and a more alarming calendar.

Yes. Her central claim is that the levels above senior are technical leadership roles. The difference is less about personally producing more code, and more about increasing impact across a wider system of people, projects, and technical decisions.

And this matters because the traditional fork is misleadingly theatrical. One road says, become a manager with direct reports; the other says, apparently become a wizard in a cave.

The book rejects the wizard framing. Management and staff engineering are parallel paths in many companies, and they increasingly require overlapping leadership skills, but they use different mechanisms.

A manager has formal people authority: performance, hiring, compensation, time off, the whole little kingdom of forms. A staff engineer usually does not.

Right. A staff engineer leads through technical judgment, communication, relationships, standards, and influence. They may advise on growth and performance, but they generally cannot promote, fire, or directly assign people’s work.

Which sounds like leadership with fewer levers. Perhaps more like steering a shopping cart downhill while explaining distributed systems to it.

Sometimes. But the book’s argument is that formal authority is not the only way organizations need leadership. Technical work crosses boundaries that a manager may not have time, context, or specialized depth to handle.

Reilly organizes that job around three pillars. Let’s name them before we turn them into decorative wallpaper.

The pillars are big-picture thinking, execution, and leveling up others. They rest on a foundation of technical knowledge and experience, and they are supported by what Reilly jokingly calls humaning skills: communication, leadership, framing problems, and navigating complexity.

Big-picture thinking is not just drawing an architecture diagram with more boxes, is it?

No. It means seeing the broader context and longer horizon: understanding who is affected, what the business needs, what will be costly later, and which local decisions create organization-wide consequences.

The book gives a very clean example. A team can choose software A because it installs easily, and from inside that team it looks obviously better.

But software A creates ongoing work for legal, security, IT, and platform teams because of its authentication and operational needs. Software B takes two extra sprints to set up, yet reduces the company-wide burden enough to repay that delay within a quarter.

So A is the local maximum: best for the immediate team, not best for the company. A tiny hill with a very confident flag on it.

Exactly. Reilly’s staff engineer is someone who can gather enough cross-team context to expose that trade-off. They do not have to dictate the answer alone, but they help the group choose with the real costs visible.

And that is one reason managers cannot simply absorb the whole role. Not because managers are bad at technology, but because people management is itself substantial work.

That is the book’s more realistic distinction. In a small company, a manager or CTO may stay deep in the technical details, and the organization may not need staff engineers yet. As scale grows, separating technical and people leadership can preserve both technical judgment and attention to humans.

The second pillar, execution, is where the fantasy of a glorious cross-team initiative meets the legacy database from 2014. What changes at staff level?

Projects become messier and more ambiguous. They cross teams with different priorities, contain gaps and overlaps in ownership, require alignment on risky decisions, and often need someone to care about the whole outcome rather than only one component.

So the staff engineer might coauthor the high-level design, spot a missing dependency, help a team unblock, and explain the project to people outside it. Not merely hover near a roadmap saying, “Have we considered vibes?”

Yes. They also protect engineering quality while delivery moves forward. Reilly distinguishes this from technical program management: a program manager may be accountable for delivery coordination, while the staff engineer is accountable for the technical coherence, robustness, and maintainability of what gets delivered.

Important distinction, but not a turf war. A strong staff engineer and a strong program manager can make each other look suspiciously competent.

That is very much the book’s view. The roles overlap in communication and unblocking, but they bring different depth and responsibilities, and the pairing can be unusually effective.

Then there is leveling up others, which sounds wholesome until we remember that standards are contagious in both directions.

That is Reilly’s point. Respected engineers set norms through code reviews, design reviews, tooling, technical decisions, and everyday behavior. If senior engineers skip tests or rubber-stamp reviews, formal standards will not save the culture.

And if they ask clarifying questions, credit other people’s work, and stay calm during incidents, that becomes permission for everyone else to behave that way too.

Yes. Leveling up is intentional teaching and mentoring, but also accidental influence. A staff engineer is a role model whether they asked for the role or not.

The book is firm that technical depth remains the foundation. This is not a conversion story where you transcend code and become a misty organizational cloud.

No. Technical judgment makes the other pillars credible. You need to understand trade-offs, dive into details when necessary, and make reviews and designs better; the leadership skills do not replace technical competence, they let it have wider effect.

But Reilly also says coding may no longer be the best use of every hour. That can feel mildly insulting to engineers who enjoy the comforting little applause of a passing test suite.

It can. Her argument is not that staff engineers must stop coding, but that they should solve problems efficiently. Sometimes the highest-leverage contribution is clarifying an ambiguous problem so another engineer can implement it as a growth opportunity.

Which brings us to autonomy. At staff level, there is supposedly no magic backlog labeled “high impact, please enjoy.” You create it.

That is one of the book’s sharper claims. Your manager should share context, but you should also identify important problems, weigh requests against opportunity cost, and propose where your time can have the most value.

Autonomy is not freedom from responsibility, though. If an executive asks for something harmful or misguided, the job is not to quietly build the disaster with excellent formatting.

Correct. Reilly says autonomy demands responsibility: bring your judgment to the request, speak up about risks, and build a reputation for being trustworthy and correct enough that people will listen. That is influence, not permission to freelance indefinitely.

Now, scope. Too broad and every issue becomes your issue, like an inbox that has achieved consciousness. Too narrow and you can become the world’s most expensive owner of a minor internal library.

The book identifies real failure modes at both extremes. An undefined broad scope produces side quests, decision fatigue, weak relationships, and sometimes a bottleneck where everyone waits for the senior person to attend every decision.

And narrow scope can mean low leverage, stealing difficult work from engineers who need room to grow, or, yes, overengineering because you have time and a very polished hammer.

Exactly. A narrow role can be right if the domain is genuinely business-critical and deep enough to justify it. But Reilly recommends being explicit about whether your scope is temporary, what it includes, and why staff-level attention is warranted.

She offers a few lenses for shaping the role, not as a personality test with suspiciously accurate animals, but as useful distinctions. One is breadth-first versus depth-first.

A breadth-first engineer ranges across teams and systems, often connecting work and influencing direction. A depth-first engineer concentrates on a difficult technical area; neither is inherently superior, but the role’s scope should fit the person’s way of working.

Then there are the four disciplines Reilly borrows from Yonatan Zunger: core technical work, product management, project management, and people management. The seniority trick is that you touch all four, even if your job title pretends otherwise.

Yes, and you do not need to be excellent at all of them. The practical advice is to notice which kinds of work give or drain energy, and partner with people who are stronger or more willing in the areas you avoid.

She also asks whether you need to code regularly, how you tolerate delayed feedback, and whether you are keeping one foot on the management track. None of that is moral character; it is job design.

And she uses Will Larson’s archetypes as vocabulary rather than a taxonomy to obey: tech lead, architect, solver, and right hand. A tech lead guides execution for teams, an architect holds direction and quality in a critical area, a solver tackles one hard problem at a time, and a right hand adds leadership bandwidth.

Titles appear here too. Reilly argues that titles matter partly because they vest authority and can reduce the repeated effort some people, especially those facing biased assumptions, must spend proving competence.

That is an important nuance. A title can communicate expected scope and give someone access or credibility they might otherwise be denied, but it is not evidence of actual judgment, and it does not eliminate bias or broken evaluation systems.

So if you are in this ambiguous role, what is the book’s very unglamorous, very useful move? Write down what you think your job is.

Write a role description and share it with your manager. Include your primary focus, goals, approximate time allocation, sample activities, and what success looks like; then find disagreements early, rather than at review time when everyone discovers they were grading different jobs.

That is the anti-mysticism at the center of this chapter. Not “be more staff-like,” whatever that means, but make your scope, contribution, and outcomes discussable.

Yes, with one final caveat: the shape of the role varies by company, team, reporting structure, and moment. The book gives a framework for clarity, not a universal staff-engineer costume.

We have the job description now: technical competence plus wider judgment, execution, and influence. Next, we need to zoom out, because choosing the important work is difficult when your entire field of vision is one team’s slightly haunted backlog.

We’ve defined the staff role as wider than a team’s ticket queue. Now Reilly says: before you announce a grand direction, perhaps first confirm you know what planet you’re standing on.

Yes. Her Chapter 2 framework is three maps: a locator map for perspective, a topographical map for organizational terrain, and a treasure map for the destination. It sounds whimsical, but it is really a discipline for reducing bad assumptions.

And not one enormous corporate mural with seventeen arrows and a sad little swim lane for legal.

Exactly. One map cannot show every relevant fact without becoming unreadable. Each map answers a different question: where are we, how does this place work, and where are we trying to go?

Start with the locator map. What does Reilly mean by perspective here?

She means locating your team and your work in the larger company. A staff engineer has to notice that the problem filling their week may be small, outdated, or merely one local expression of a larger business concern.

So the first hostile question is not, “How do we fix this service?” It is, “Does anybody outside this service care?”

That is deliberately blunt, but yes. The book suggests asking who your customers are, what the business needs now, and how your work affects people outside your immediate group.

Customers can be internal too, right? The platform team’s customer might be application engineers, not somebody tapping a phone at midnight.

Absolutely. The point is to understand success from the user’s side. If a platform takes three weeks to provision access, its internal customers experience that as a product failure, however elegant its backend may be.

Reilly also talks about objectives that are always true, which I like because they are so unglamorous. The company needs to continue existing, pay people, retain some reputation, and have a product that basically works.

Right. These implicit objectives may not appear in quarterly goals until they are endangered. A staff engineer should keep them in view alongside the explicit roadmap, because they explain why reliability, deploy speed, customer trust, and operating costs can matter.

That guards against the sacred local priority. Every team has one, usually wrapped in a spreadsheet and defended by candlelight.

Reilly’s warning is that prolonged focus distorts perspective. You can prioritize badly, lose empathy for other teams, normalize worsening problems, or forget what the work was originally for.

Give me the customer version of that. The book has a good availability example.

It cites a former Bing principal engineer describing unreliable internet providers where Bing was unreachable. Bing itself may not have been broken, but users do not distinguish DNS, an ISP, a CDN, and an endpoint; they just see that the site does not work.

Which makes “our availability metric is fine” a slightly haunted sentence.

It can be. Reilly uses Charity Majors’s phrase, “Nines don’t matter when users aren’t happy,” to make that point: an availability target is useful, but it is not a complete account of the customer experience.

So if an engineering team spends a quarter raising an internal service-level number while customers still cannot complete checkout, they have optimized a number, not necessarily the outcome.

That is an additional illustration, but it fits the book’s reasoning. The question is not whether the metric is false; it is whether it captures the thing users actually need.

The locator map also asks whether a problem has been solved before. This is the part where we gently put down the whiteboard marker.

Yes. Reilly recommends looking for prior art inside and outside the organization. The goal is to solve the problem, not necessarily to earn the privilege of writing a fresh implementation.

There is a social snag, though. New people see an old system and say, “Why on earth is this like this?” Then everyone who built it experiences a small internal weather event.

The book is good on that. A newcomer can provide a useful outsider view because they have not adapted to gradual deterioration, but being new is not a license to be contemptuous. Respect what came before, investigate the constraints, then decide what still needs to change.

So respectful skepticism: neither “legacy is wisdom” nor “legacy is criminal evidence.”

Precisely. You want to recover the original reasons, see which remain valid, and distinguish them from habits that survived after their purpose disappeared.

And avoid the echo chamber. Reilly says infrastructure people and product people can have very different instincts, which is hardly shocking once you have watched them argue about risk for ten minutes.

Different groups see different costs. Infrastructure engineers may prioritize reliability and operational simplicity, while product teams may rightly prioritize delivering features customers need. Building relationships across those groups makes each side’s judgment more realistic.

That means staff engineers should talk beyond engineering: support, sales, product, legal, operations, whoever lives with the consequences.

Yes. Customer support in particular often knows the product’s failures in a way dashboards do not. Reilly also recommends paying attention to all-hands information, skip-level conversations, industry context, and the facts that might become useful later.

She calls that clearing the fog of war. You train yourself to notice the company announcement that hints at a traffic spike, or the leadership shift that makes an old platform suddenly relevant.

Right. Context gathering is a learned skill, not mystical senior-engineer radar. If your memory is not naturally sticky, the book suggests writing down facts that could matter later, just to build the habit of noticing.

All right, we know where we are. Unfortunately, there is a ravine between the identity team and the payments team, and somebody has installed a drawbridge process with twelve forms. Topographical map time.

The topographical map describes how work actually moves through the organization. Reilly uses team tectonics: boundaries rub together, reorganizations shift the landscape, and gaps or overlaps in ownership create friction.

Her landforms are excellent: chasms, fortresses, disputed territory, uncrossable deserts, paved roads, and secret goat tracks through the swamp.

They are memorable because they capture recurring patterns. A chasm might separate product engineering from platform or security; a fortress might be a gatekeeping team that is difficult to engage; disputed territory is work several teams believe they own, or none fully owns.

And an uncrossable desert is the initiative everyone tried before, failed at, and now discusses with the warmth usually reserved for an old curse.

Yes. The book does not say never attempt it again. It says learn why earlier attempts failed, solve the hardest uncertainty early if you can, and be honest about whether this time is actually different.

The fortress metaphor could make people sound villainous. Reilly is more careful: gatekeepers may be protecting quality, safety, or an overwhelmed team.

That distinction matters. If a security review team demands evidence, the productive response is usually to understand the risks they are accountable for and bring the information they need, not to treat process as irrational obstruction.

Then there are paved roads that lead nowhere useful, while the unofficial shortcut works because one person in IT answers direct messages.

That is a real organizational hazard. Learn the actual paths, but do not confuse knowing an informal route with a mandate to bypass fair processes. The long-term fix may be making the official path work for the common case.

Culture is part of that terrain, but Reilly does not mean the values slide with a watercolor mountain.

No. She says culture is observable in what happens: who gets information, how decisions are documented, how quickly change occurs, whether people cooperate, and what behavior is rewarded or punished.

She offers sliders rather than a personality test. Secret or open, oral or written, top-down or bottom-up, fast change or deliberate change.

Also formal front doors versus informal back channels, teams with available capacity versus teams already fully allocated, and more fixed or more fluid paths to influence. The point is not to score a company; it is to predict what kind of approach is likely to work.

For example, in a highly written, deliberate organization, turning up with an urgent verbal pitch can look unserious. In a fast-moving oral culture, a twenty-page design may become a lovely place for dust to settle.

Exactly. The same idea may need different packaging. Reilly’s broader argument is that organizational navigation is part of engineering because humans are part of the system you are trying to change.

She also brings in Ron Westrum’s categories: power-oriented, rule-oriented, and mission-oriented cultures. I can already hear someone assigning their coworkers a diagnosis over lunch.

They should resist that temptation. Reilly presents the model as a lens on information flow, not a casual label for individuals. In Westrum’s framing, pathological cultures hoard information and scapegoat, bureaucratic ones rely on rules and narrow responsibilities, and generative cultures emphasize cooperation, inquiry, and mission.

Useful because it changes your travel plans. In a bureaucracy, plan ahead and respect the process; in a low-trust environment, take fewer risks and document carefully. Not romantic, but neither is getting blamed for a decision nobody recorded.

Yes, though the book notes these categories are not permanent identities. They help explain why information may move easily or painfully, and why a staff engineer may need to build bridges.

Let’s talk about decisions. Reilly asks, where is the room where it happens? Not metaphorically, though also metaphorically, because power loves a room.

Some decisions are made in formal leadership meetings, architecture groups, planning forums, or a director’s staff meeting. Others emerge through informal conversations, and occasionally there is no clear room at all.

The practical move is to trace one decision backward. Ask someone you trust, “I’m not contesting it. How did this decision get made?”

That is a sensible way to learn without sounding accusatory. Once you know the forum, you can assess whether you need access, whether your information can travel through another channel, or whether you are overestimating that forum’s authority.

And if you ask to join, do not pitch it as, “My career requires a chair at this table.” Pitch the organizational value of having your perspective present.

Correct. Reilly is explicit that adding people to a decision-making group has costs. If you are invited, reduce the cost: show up prepared, speak concisely, and collaborate without making the room slower or less candid.

This is not “attend every important meeting until no decisions can occur without you.” That would be less leadership, more invasive species.

Quite. The aim is enough access to understand and influence decisions within your scope, not universal attendance. There are also management conversations about performance and compensation where individual contributors generally should not be participants.

Then comes the shadow org chart, which sounds dastardly but is mostly just admitting that titles are not the whole story.

Exactly. Reilly draws on the idea that connectors, long-tenured people, and trusted advisers may shape decisions despite not occupying the most senior boxes on the formal chart. Understanding whom leaders consult helps you understand how a proposal will land.

But if you use that knowledge only to manipulate people, congratulations, you have learned the map and immediately fallen into the bog.

The ethical use is relationship building and better communication. Speak with the people who hold context, learn their concerns, and make sure relevant information reaches them; do not use informal influence to evade accountability or silence others.

Let’s run an additional example. Say an API migration is stalled: product wants a new mobile launch, security wants stronger authentication, and platform wants to retire the old gateway before it consumes another fiscal year.

Using the locator map, first identify the actual users and desired outcome. Is the purpose faster partner onboarding, reduced security risk, lower operating cost, or all three, and which matters most now?

Then the topographical map says: product owns launch timing, security owns approval criteria, platform runs the gateway, and nobody owns the partner documentation. There is our disputed territory, wearing a fake moustache.

Yes. You would also find the decision forums, learn each team’s planning cycle, and identify trusted connectors across those groups. A credible bridge could be a shared migration plan that makes security requirements explicit, names the documentation owner, and gives product a staged path instead of an all-or-nothing launch.

And the treasure map asks what this migration buys. “Move endpoint version two” is not the treasure. “Let partners integrate safely without bespoke platform support” may be closer.

That is the key move. Reilly uses Civilization’s technology tree to explain it: researching one technology is usually a prerequisite for a later capability. You are not building a service mesh for its own majesty; you may be trying to reduce time to market.

So write the chain. We standardize authentication so partner teams can self-serve, so integrations take days rather than months, so the business can enter a market before everyone gets distracted by a different market.

Exactly. Once the real goal is visible, you can evaluate whether each technical task actually advances it. You may discover a cheaper path, or discover that the existing project has continued long after the original goal vanished.

A treasure map also needs milestones, not merely an X at the far end of the sea. Otherwise every detour becomes an argument about whether it is progress.

Yes. A shared destination lets teams make local decisions with more autonomy, because they understand the direction. It also helps them recognize when a short-term workaround needs a later correction to get back on course.

What routines keep these maps current? Because organizational terrain changes while you are blinking at a dashboard.

Read relevant design documents and announcements, check in with leaders, talk to customers and teams outside engineering, and participate enough in operational work to stay connected to reality. Reilly also recommends making time for informal conversations, because they are often where context travels.

The book even endorses a little careful lurking: scan new channels, meeting notes, and other available signals. Not espionage; just noticing the project that exists before it lands on your desk on fire.

Right. The standard is appropriate access and good judgment. You are building situational awareness, not collecting secrets.

There is a limit here, though. Maps help, but they do not grant magical access, repair low trust, or cause a director to fund an unpopular project because your diagram has excellent arrows.

That is an important limitation. The framework is strong because it makes hidden organizational constraints visible, but visibility is not control. In a constrained or unsafe organization, the practical response may be to reduce scope, build a small alliance, document risks, or recognize that the blockage exceeds a staff engineer’s authority.

Still, it beats mistaking a power problem for a Kubernetes problem. That mistake has funded many very expensive feelings.

It has. And this chapter gives a sensible stopping point: first discover the existing maps. If the destination is unclear or competing, then you are ready for Reilly’s next question—how do you create a technical vision or strategy that people can actually follow?

So we have our maps. We know where the org’s weird little swamps are, who owns the drawbridge, and that somebody has called the shared database “temporary” since the Bronze Age.

Right, and the next problem is more serious: sometimes the map has no destination. Or it has three destinations, each backed by a different senior person, which is a fun way to spend a quarter.

Reilly opens this part with exactly that sort of mess: one troubled system, SystemX, and three simultaneous messages about it. Scale it up, deprecate it, or form a working group to evolve it.

Each response is individually plausible. Together, they reveal that nobody has made a shared decision about what the organization is trying to accomplish.

And that is the opening problem for strategy. Decentralized teams make sensible local decisions, then the company wakes up inside a quilt made of incompatible sensible decisions.

Yes. Shared concerns get neglected because no team has both the incentive and authority to solve them. Conflict gets delayed rather than removed, until it shows up embedded in an API or an architectural dependency.

The book separates two words that companies usually throw into a blender: vision and strategy. What is the useful distinction?

A technical vision describes a desirable future state. A technical strategy describes a realistic path through obstacles toward a goal; one says where we want to be, the other says how we intend to get there.

So a vision might say, “Product teams can independently add new offerings without destabilizing shared systems.” A strategy says what changes, in what order, with what people and constraints.

Exactly. The vision can remain fairly high level. It should reduce ambiguity without trying to dictate every implementation detail.

And Reilly is careful here: not every awkward technical question deserves a 30-page North Star document with a heroic mountain on slide two.

Quite. If a short goals section in a design document will align everyone, do that. Vision and strategy documents are expensive coordination work, not ceremonial paperwork for making a problem feel important.

That is refreshingly anti-incense. The book’s other slightly rude point is that strategy is usually not a genius engineer arriving with laser eyes and a new paradigm.

Usually it is synthesis. There are already good ideas, partial attempts, constraints, and people with domain knowledge; the hard work is deciding what to prioritize and getting enough people to act together.

Which may look boring from the outside, because the final recommendation can sound obvious. “Stabilize the thing that breaks everyone’s work” is not exactly engraved on a wizard’s staff.

But obvious after careful analysis is not the same as obvious before it. A good strategy makes trade-offs explicit, and that is often the part everyone had been avoiding.

Reilly borrows Richard Rumelt’s strategy kernel: diagnosis, guiding policy, and coherent actions. Let’s take those one at a time.

The diagnosis answers, “What is actually going on?” It deliberately simplifies messy reality into the pattern that matters most, without pretending the simplification captures everything.

Then the guiding policy is the signpost. Not a task list, but the approach that tells people how to get around the obstacle.

And coherent actions are the concrete commitments that follow. They need to reinforce each other, including staffing, process, and organizational actions, not merely a wishful list of technologies.

That last part matters. A strategy saying, “Adopt event-driven architecture and become happier,” is not a plan; it is a hostage note written by a conference booth.

Also, architecture is not automatically the hard part. The strategy has to acknowledge who will do the work, what they will stop doing, and whether the organization can support the change.

Before writing anything, Reilly says to check whether there is already an expedition underway. Why is competing with it so dangerous?

Two nearly identical initiatives divide attention, allies, and legitimacy. You can share the lead, contribute as a supporting expert, or step away if the work will succeed without you; creating a rival effort is often just ego with a project plan.

The book calls those dominance contests “ape games,” which is rude to apes but clear enough. The issue is not that you have an opinion, but that you need your opinion to be the winning flag.

Yes. A staff engineer should ask whether a different path is genuinely dangerous or merely different from the one they would have chosen. A marginally better plan that cannot gather support may be worse than a good plan that can.

Suppose the existing effort is weak, though. You think the lead is missing key risks, and the group is wandering toward a bad outcome. Do you just smile and hand them a decorative shovel?

No. Reilly’s advice is not passive agreement. Join the work if you can, bring the missing context, and shift the direction from inside the effort; competing from scratch should be the last option, not the first reflex.

Then comes sponsorship, the word that makes engineers suddenly inspect their shoes. What does a sponsor actually do in this book?

A sponsor is typically a director or executive who can give the work legitimacy, help resolve deadlock, and allocate organizational attention or resources. The sponsor does not guarantee success, and the staff engineer usually does not control staffing alone.

So “my VP liked my document” is nice, but it is not a strategy unless the organization can actually make room for the work.

Correct. The useful sponsor is connected to the problem and has incentives to solve it. Reilly recommends pitching the work in terms of what blocks that leader’s goals, not in terms of why the author deserves a larger stage.

There is a hard practical test in that. If you cannot explain the need in roughly fifty words, you might not understand it well enough to ask someone important to back it.

That is the purpose of the elevator pitch. It forces you to describe the business or organizational consequence, not only the technical irritation that has been haunting your dreams.

Once sponsorship looks possible, you build a core group. Reilly’s recommendation is surprisingly small: two to four people, including the lead.

A small committed group can think and write together. A broader circle can still provide expertise, dissent, reviews, and goodwill, but a room of twenty overallocated people tends to produce a working group shaped like fog.

And the core group should include people who understand the territory you are trying to change. Writing a network strategy without network expertise is a bold choice, in the same way juggling chainsaws is a bold choice.

You need relevant technical knowledge and influence in the affected area. Otherwise, you are asking people to accept a plan from someone who has not understood their constraints, and they may be right to resist.

This is where scope becomes a sanity check. How broad should a strategy be?

Broad enough to solve the problem, but not so broad that it relies on authority or knowledge you do not have. Fixed constraints matter: a plan that depends on a new CEO, unlimited hiring, or customers changing their behavior is not strategy.

And if the plan is too large for you, that is not a moral failure. It may mean recruit someone more experienced, reduce scope, take a subsection, or admit the company will not solve it.

Exactly. Reilly is unusually direct that some problems are not currently solvable by you, or perhaps by the organization. Continuing anyway without changing the premise can turn into performative busyness.

The book has a blunt preflight checklist: we need this, there is no competing effort or we joined it, there is support, we agree what we are making, it is achievable, and we are not lying to ourselves.

That last item is the important one. Staff-level work has high opportunity cost, so you should not spend months writing an elegant document for a plan nobody will ever fund.

All right, the work is real, there is a sponsor, and the tiny council has assembled. What does the actual writing process look like?

It is a loop, not a straight line. You inspect existing plans, interview people, think, draft, revise, make decisions, align again, and repeat until additional iteration stops producing much value.

The interviewing part is a corrective to the staff-engineer temptation to emerge from a cave carrying The Answer. Who should you talk to?

Not only your friends or the people who already agree. Talk to leaders, close practitioners, skeptical stakeholders, and people whose work will absorb the consequences; ask open questions early, then test more specific ideas later.

Questions like, “What is difficult about this today?” or, “If you could change one thing, what would it be?” Not, “Please confirm my beautiful Kubernetes migration has already won your heart.”

Right. And end by asking what you should have asked but did not. That often reveals the missing constraint or stakeholder that can make a seemingly good strategy fail.

There are two writing patterns here. One is leader-first: somebody writes a draft, then the group reacts. What is the advantage and risk?

It gives coherence and momentum. But the first author frames the problem, and less senior reviewers may feel they are only allowed to edit around that frame rather than challenge it.

The alternative is multiple people independently drafting, then someone synthesizes. More unfiltered input, more editorial danger, more chances for everyone to become emotionally attached to their own little constitutional convention.

That is why roles must be explicit. If several drafts are inputs, name who combines them and how disagreements will be resolved; otherwise, the group can mistake draft ownership for a competition.

And all of this needs a timebox. Because there is always one more person to interview and one more glorious edge case that insists it is the main character.

A strategy should be revisited as conditions change, so it does not need to be perfect on the first launch. Endless research can become a quiet way of avoiding the decision.

Let’s talk about the decision itself. Reilly recommends “even over” statements, which I like because they force adults to admit they cannot have every nice thing.

For example, “We prioritize ease of use even over performance,” or “We choose long-term support even over time to market.” The wording makes the sacrificed benefit visible instead of smuggling it past the group.

And then, rough consensus. Not total consensus, because that is how you end up in a room in 2029 still debating the font on the incident dashboard.

The book draws on the Internet Engineering Task Force’s approach: seek broad support and address serious dissent, but ask whether someone cannot live with a choice rather than whether everyone loves it.

If rough consensus does not get you there, name a decider. A sponsor can break a tie, but ideally the decision authority was clear from the beginning.

Yes. Escalating every technical choice to a distant executive is slow and usually poorly informed. A designated lead with enough context is generally better, provided the group knows that person has the final call.

There is also Option C: do not decide. The book is emphatic that this is still a decision, usually in favor of the status quo and all its hidden costs.

Sometimes postponing is sensible, such as when more information is genuinely arriving soon or the choice is expensive to reverse. But make that deliberate: say what you are waiting for and when you will decide.

Then show your work. Write down the decision, the alternatives, the disadvantages, and why this is still the right trade-off. That prevents a new engineer from reopening the same argument six months later with great confidence and a fresh diagram.

It also treats dissenting colleagues fairly. They may still disagree, but they can see that their concerns were understood rather than erased.

Now, nemawashi. It sounds faintly like an artisanal noodle, but it is the book’s term for laying groundwork before the formal decision.

It means sharing information and building understanding so that a public decision is not the first time important people see the proposal. By the time the meeting happens, the serious objections have been explored and the key decision makers know why the plan exists.

Important distinction: that is not supposed to mean backroom pressure until everyone agrees with your original idea.

No. Alignment is two-way. Interviews and early reviews should change the plan when others have better knowledge, when a concern is legitimate, or when an element is causing needless conflict.

The story you tell has to be comprehensible, relatable, and plausible inside the organization’s Overton window. Not too alien for the people who must do the work.

A strategy can be technically elegant and still fail if it assumes people can make a leap they are not ready or resourced to make. You need to start from their actual situation, not from the situation you wish existed.

And the story cannot just promise gold at the end. It needs to explain the muddy bit in the middle, where the heroes are stuck in a pit and someone has accidentally renamed production.

Precisely. If difficulties are expected and named, teams are less likely to interpret them as evidence that the whole plan was fraudulent. A credible plan includes its hard parts.

Let’s use Reilly’s SockMatcher case study. To be completely clear, SockMatcher is fictional: it is the book’s deliberately ridiculous company for matching lost socks, gloves, buttons, and eventually food-storage containers.

The company’s architecture grew around a monolith and shared data model. Product-specific rules are scattered through billing, personalization, matching, and other components, so every new product creates more coupling and unexpected breakage.

The immediate fight is over food containers and lids. That team wants its own service, but still needs authentication, billing, personalization, and safe handling of personal data that are trapped in the monolith.

Meanwhile, outages are hurting users, builds and deploys are slow, APIs are difficult to evolve, and everyone has a favored solution. Some want sharded data, some microservices, some a better matching algorithm, some improved reliability.

That is the kind of situation where every engineer arrives with a wrench and discovers the building is a disagreement about what counts as a door.

The fictional staff engineer in the case does something sensible first: investigates why prior attempts to change the architecture failed. One engineer wrote a detailed plan that other teams rejected; another convened a large working group that got stuck in endless debate.

The diagnosis is not merely, “Monolith bad.” It is that teams need changes in shared billing and personalization components, those changes are risky and slow, and each new product worsens the coupling.

More specifically, the organization needs more teams to add matchable item types without development grinding to a halt. That diagnosis is narrower and more useful than trying to repair every architectural flaw at once.

Then comes the tempting grand solution: split everything into microservices. But the case does not say microservices are evil, merely that a multi-year rewrite does not fit the immediate constraint of launching food storage soon.

It would also create new operational demands for teams that had not run services before, while leaving risky shared changes unresolved. The strategy has to fit the current organization, not a different and imaginary company.

So the guiding policy is wonderfully unglamorous: make billing and personalization easy and safe to integrate with.

That focus creates leverage. The concrete actions include feature flags for staged rollout and quick rollback, additional staffing for the billing and personalization teams, modular self-service additions, and using food storage as a pilot customer.

The food-storage launch stays viable because those shared-component teams provide an initial integration, then migrate the product toward the new model. It is a strategy that acknowledges sequencing rather than shouting “future state” at everyone.

And it requires sponsorship. The case’s sponsor donates headcount, helps make the work an organizational objective, and creates the conditions for the plan to be more than a document.

It also makes a hard choice: some real issues, like login debt, unversioned APIs, and matching improvements, are not the first focus. Strategy means letting important things remain unfixed for now.

That is probably the most difficult discipline in the chapter. If every problem is in scope, no priorities exist; the diagnosis and guiding policy are what make exclusion defensible.

Let’s add a broader engineering illustration, clearly not from the book. Say a company has a shared authentication service and every product team keeps patching around its unstable interfaces.

A diagnosis might be: product teams cannot safely evolve login flows because the shared service has unclear interface guarantees and deployments create cross-product regressions. That is better than beginning with, “We need OAuth version seventeen.”

The guiding policy could be, “Stabilize supported authentication interfaces and give teams a staged migration path.” Then coherent actions might be interface versioning, compatibility tests, a pilot migration, published deprecation dates, and actual people assigned to support it.

Or the analysis may show that a rewrite is unnecessary. Perhaps a small compatibility layer and clear ownership solve the real problem; the framework is useful because it evaluates the need, not because it points toward a fashionable architecture.

After writing comes launch. What converts a strategy from an attractive internal link into something that actually changes decisions?

Official endorsement, visible sponsorship, and resources. The document should be accessible, complete enough to look final rather than perpetually tentative, and connected to planning, staffing, budgets, or organizational goals.

In other words, no more “Here is our three-year vision,” followed by nobody being allowed to spend a day on it. That is not vision; that is decorative fiction.

The author should also stay with the work where possible. Strategy does not end at publication; it needs translation into projects, checks on momentum, and revision when business direction or technical facts change.

There is a limitation here worth naming. This framework is excellent when you can get access to decision makers, find a sponsor, and speak honestly with peers. What if your organization is low-trust or very political?

Then the method becomes harder, sometimes much harder. A document cannot solve a power problem if leaders will not fund the work, people cannot safely surface disagreement, or information is systematically withheld.

So the answer is not to write a more majestic document with sixteen concentric circles and the word synergy hidden in the footer.

No. You may need to reduce the scope to an area where you have influence, build allies gradually, seek a sponsor for a smaller concrete problem, or honestly conclude that the organization will not support the change.

Generally speaking, titles, sponsorship, and a written strategy can soften ambiguity. They cannot by themselves fix biased evaluation, bad incentives, chronic understaffing, or an executive layer determined to ignore reality.

That is an important boundary. Reilly provides tools for navigating organizations, but readers should not mistake skillful navigation for total control over the system.

Another boundary: this is not a universal document template. The book gives useful components and a process, but it does not command every company to create a sixty-page strategy, nor does it worship consensus.

Right. The test is whether the artifact produces clarity and coordinated action. Sometimes that is a short decision record; sometimes it is a strategy, and sometimes the best decision is to stop trying to create one.

So the staff-engineer move is less “I personally have the technical direction” and more “I can help this group see the real problem, choose a workable direction, and make the trade-offs explicit.”

Yes, with enough technical judgment to know whether the direction is plausible, and enough humility to let the people closest to the work change the plan. Agreement is not an obstacle before the work; in this kind of work, agreement is a large part of the work.

That gets us to the next problem. Once you can see all these important opportunities, every one of them starts waving from the roadside and yelling, “Pick me, I am strategic.”

And you cannot pick all of them. The next question is how a staff engineer chooses work, protects finite attention, and avoids becoming the organization’s extremely tired universal adapter.

We’ve talked about seeing the bigger system and choosing a direction. Now comes the rude little detail: even a very good direction competes with the fact that there is only one of you.

That is the premise of Reilly’s chapter on finite time. Staff engineers can see an effectively infinite supply of worthwhile problems, but they still have finite hours, attention, and energy, so every yes is also a decision not to do something else.

Which sounds obvious until your Slack lights up, somebody says “quick question,” and suddenly you are the municipal emergency contact for a company you do not own.

Exactly. The issue is not whether helping is good; often it is. The issue is whether you are choosing the help deliberately, or allowing the most interruptive request to allocate your week for you.

Reilly has a remarkably concrete fix for the calendar problem. Put focus work on the calendar too, not just meetings.

Yes. Schedule the design reading, the project writing, the difficult conversation, even the administrative task. Then, when someone asks for two hours, you can see what it would displace rather than pretending those hours were empty.

And if you keep moving the same block from Tuesday to Friday to next geological era, that is data, not a moral failing.

Right. It may mean the work is less important than you claimed, you are avoiding it because it is difficult, or your plan is simply overloaded. In any case, repeatedly rescheduling it tells you something useful about reality.

The book also uses a time graph, which is less glamorous than a strategy diagram but probably more honest. You draw the available capacity over a month or quarter, then watch projects consume it.

And Reilly’s important addition is buffer. If you allocate every hour, an incident, launch, or unexpected dependency means either dropping important work or working beyond capacity; neither is a very clever operating model.

So the target is not maximum utilization. That phrase has harmed enough people already.

It is more about sustainable slack. A staff engineer is often pulled into volatile work, so leaving some capacity is not laziness; it is how you remain able to respond without sacrificing everything else.

Then Reilly gets more personal. She says project choice is not only about what helps the company, but what it does to your own dashboard.

Her dashboard has five resources: energy, quality of life, credibility, social capital, and skills. It is not a scoring formula, and she does not pretend you can calculate the perfect project; it is a way to notice costs you might otherwise ignore.

Let’s separate the two that people blur together: credibility and social capital. They sound like identical suits at a corporate funeral.

Credibility is whether people believe your judgment and competence. Social capital is whether they want to help you, give you the benefit of the doubt, or spend effort on your request; one is trust in your capability, the other is goodwill in the relationship.

So solving a difficult production failure calmly may increase both. But asking three teams to do a dubious migration because you got excited about a diagram spends both.

That is a fair reading of the book. Reilly’s warning is to spend these resources deliberately, especially after a success when people may be willing to support an initiative mainly because they trust you; that is not a blank check for a pet project.

And energy is not just time with a different hat. You can have an hour free after six meetings and still possess the cognitive texture of mashed potato.

Yes. Different work drains different people. Reilly notes that some find one-on-ones exhausting and coding energizing, while others are the reverse, and life outside work affects the same energy supply: illness, caregiving, moves, poor sleep, all of it.

Quality of life gets a place too, which I appreciate. A project can be prestigious, technically rich, and still make you miserable because the work itself or the people around it are awful.

The book is practical about that. Work need not provide all meaning in life, but it occupies a large portion of it, so enjoyment, safety, values, compensation, and the kind of collaboration a project requires are legitimate parts of choosing work.

Then skills are the slightly alarming meter because they decay even while you are sitting perfectly still.

More precisely, their relevance decays. Reilly identifies deliberate study, learning alongside highly skilled people, and learning by doing as ways to refresh skills; a role that teaches you nothing for too long can leave you less prepared for the work you want next.

This is where the book gets usefully anti-heroic. You do not pick only the company’s top priority, in a sterile queue, because people are not interchangeable processors.

Correct. A project can be important but wrong for you right now, or modest in organizational importance but valuable because it develops a missing skill, rebuilds credibility, or lets you work with people who will raise your game.

Reilly names different shapes that work can take. You might be invited onto a project, ask to join one, notice a problem yourself, get pulled into a fire, or acquire a side quest because a clunky API has offended you personally.

She also includes grassroots working groups, unowned work that somebody needs to do, and what she calls meddling: inserting yourself into a project that did not request your help. Each can be worthwhile, but each has hidden time and relationship costs.

The fire alarm is particularly seductive. There is an outage, everyone suddenly agrees what matters, and you get the clean adrenaline of being useful instead of the swamp of an ambiguous long-term project.

Reilly does not say never help in a crisis. She says notice if crisis response becomes your whole narrative, because constant rescue can prevent you from building sustained results or developing in other directions.

Her all-hands example is good. You have just delivered an eighteen-month project, you are exhausted, and a VP asks you to present it at the engineering all-hands while you were planning vacation.

That request may build visibility, credibility, and social capital. But it also costs time, energy, and perhaps your recovery, so the book asks whether you need this particular opportunity, whether a teammate would benefit more, or whether you can reshape it by co-presenting or postponing.

Not “visibility bad,” then. More like, do not sacrifice your holiday to make slides merely because a calendar invitation has arrived wearing a tiny crown.

Exactly. Visibility is useful when it supports a real outcome or a person’s growth. It is not automatically more important than rest, nor proof of impact by itself.

Another source example is incident-command on-call. It can interrupt your sleep and demand preparation, but it also develops a visible, transferable leadership skill and gives immediate feedback.

Reilly’s question is situational: do you have the resilience for out-of-hours pages right now, and do you want the skill? If your life is already constrained by health, family, or exhaustion, the same opportunity may be a bad fit despite being impressive on paper.

Then there is the project you desperately want but cannot fit. You have become the person everyone asks about testing, onboarding, incidents, and production readiness, while a new, interesting technical project appears over there, glowing faintly.

The book’s blunt answer is that you may need to torch the back burner. If you keep every existing responsibility warm, you will not have capacity for the new work; talk with your manager, hand off work where appropriate, and protect the time before others consume it.

Let’s add an engineering scenario, clearly ours rather than Reilly’s. A staff engineer keeps getting tagged in deployment-platform Slack escalations: failed releases, permissions confusion, odd rollback behavior, every day.

First distinguish a true emergency from a recurring operating pattern. If customer deployments are blocked, help now; but if the same questions recur, the durable response may be an owning team, clearer self-service documentation, office hours, delegation, or protected focus time to fix the root cause.

In other words, becoming permanently available is not the same as being accountable. It can actually conceal the missing ownership because everyone learns to page the helpful human instead.

Yes, and that creates a bottleneck. The staff engineer might say, “I can handle the current incident, but after this we need a named owner and a two-week plan for the recurring failure,” which is support without accepting indefinite invisible work.

Suppose a project is important but a bad fit. Reilly gives several options besides the traditional technique of silently suffering until your laptop develops opinions.

You can do it temporarily, with explicit exit criteria. You can free capacity by stopping something else, delegate it as a growth opportunity, reshape your involvement into an early feasibility review or occasional advising role, or say no.

Delegation here is not dumping the miserable bits on a junior engineer, obviously. It is finding work where someone else can get a credible stretch opportunity, with enough support to learn.

Right. Reilly quotes the idea of aggressively delegating work you could reliably ace, allowing someone else to perhaps get a B at first and improve with coaching. The staff engineer should not take every visible chance to demonstrate competence.

And saying no is part of doing good work, because if you accept everything, you cannot do it well. That is almost offensively reasonable.

It is also difficult, particularly for people trained by hierarchy, bias, or prior experience to believe that every request is mandatory. A clear no can be kinder than a vague yes followed by missed deadlines.

This is where I want an honest limitation. Calendaring your focus work is useful, but it does not repair chronic understaffing, discrimination, low formal power, or caregiving demands. No color-coded calendar has ever defeated a broken incentive system.

Agreed. The book’s individual-agency frame is valuable because it gives readers levers, but those levers have limits. Generally speaking, someone with little authority may need manager support, collective prioritization, allies, or a different role; personal optimization cannot solve a structural overload problem.

So defend your time, but do not become a hermit guarding a calendar cave. The point is not withdrawal from shared responsibility; it is choosing where your help has real leverage and making the cost visible.

That is the chapter’s practical conclusion. Once you have chosen a worthwhile project, made room for it, and kept enough capacity to be a responsible colleague, the next challenge is leading that complicated work across teams without direct authority.

So we’ve chosen work deliberately, protected some time, and now a large project arrives looking like a drawer full of cables from 2009. What does Reilly think the staff engineer actually does next?

She reframes project leadership away from the myth of the lone technical savior. The difficult part is usually ambiguity, cross-team coordination, and legacy behavior nobody can fully predict, not one brilliant insight at a whiteboard.

Which is slightly rude to anyone who bought twelve colors of whiteboard markers for their genius moment. But useful, because it says persistence and clarity are technical leadership too.

Exactly. The lead is responsible for the whole outcome, including gaps between teams and work nobody initially believes belongs to them.

And that responsibility can feel enormous at the start. You inherit a vague mandate, several old documents, three urgent messages, and a person saying, "We need a plan by Thursday," which is always soothing.

Reilly is unusually direct that feeling overwhelmed is normal. If the project were obvious and tidy, it probably would not need a senior technical lead.

So the panic is not necessarily evidence that you are unqualified. It may simply be evidence that the project is, regrettably, real.

Right. Her first move is practical: create a private anchor document. Put uncertain facts, links, rumors to verify, questions, names, decisions, and next steps in one place so your brain is no longer pretending to be a reliable database.

Not the polished project charter for public consumption. More the external hard drive for your anxious little processor.

That’s fair. Then talk to the sponsor and test your understanding of the goal, the expected outcome, and your own authority before you build momentum around the wrong mission.

And find one person who can hear your uncertainty without turning it into a referendum on your competence.

Yes. A manager, mentor, or peer can be a sounding board, but Reilly cautions against pouring all that uncertainty onto less experienced teammates who need stability from you.

That distinction matters. You can be honest without making the whole team feel they’re trapped on a sinking ship with a captain live-blogging the water level.

You also get a small win and start with your strongest learning mode. If you learn through code, inspect the code; if through relationships, talk to people; if through documents, read the relevant history.

That sounds almost too basic, but it stops the frozen staring contest with the project. One useful action gives you information and reduces the drama.

And it begins building context. Reilly brings back the three maps here: locate the project in the business, understand the organizational terrain, and make the destination explicit.

Let’s unpack the locator part first. What are you trying to learn beyond, "We are building service whatever"?

Why this project exists, who needs it, what problem it solves, and how success will be observed. You need customer needs, business goals, sponsorship, fixed constraints, risks, history, and the relevant relationships between teams.

The customer can be another engineering team too, of course. Internal users still get to be confused, delayed, and annoyed, just with better access to Slack emojis.

They absolutely count. If you are building an internal platform, talk to the engineers who will use it rather than assuming their needs from an architecture diagram.

And the book is firm that code completion is not a success metric. A repository full of lovingly tested code can still solve nothing.

Right. Metrics should represent the user or business outcome. Reilly cites Sarah Wells measuring a migration through time spent keeping the cluster healthy and the number of snarky Slack messages about functionality failing, which is not a formal metric perhaps, but it is highly legible.

Few dashboards capture the truth like increasingly creative workplace sarcasm. So if a deployment system is supposedly improved, perhaps measure deployment time, rollback time, or outage duration, not merely how many services moved.

That is directly in the spirit of the book. Ask what will be different for users: fewer outages, faster delivery, safer operation, less manual effort, or a capability they could not access before.

Then comes the topographical map: who can help, who owns a dependency, which decisions happen in which room, and where the old project scars are buried.

Yes, including risks. A key engineer might leave, a partner team might lack capacity, a deadline might be immovable, or a supposedly simple integration may touch systems nobody understands.

And history is not trivia. If three previous attempts at a migration failed, walking in and saying, "At last, I have discovered YAML," is probably not going to build trust.

Precisely. Respect what came before, learn why earlier work struggled, and avoid treating past engineers as foolish simply because you have hindsight.

Now, roles. This is where many projects become interpretive dance, because five senior people think they are leading complementary things and nobody has checked.

Reilly recommends clarifying responsibilities early. Product management may own customer requirements and product success measures; the technical lead may own high-level technical direction; engineering management may own staffing and team health; program management may own timelines and status flow.

But that table is illustrative, not holy scripture. Some projects have no product manager, some have no TPM, and sometimes one person is covering several functions because reality enjoys a compact budget.

Exactly. The point is not to enforce job-title borders. It is to expose gaps and duplicate authority before they become conflict or dropped work.

And RACI is one optional device for that. Responsible does the work, accountable owns the outcome, consulted gives input, informed gets updates.

Yes, and it can be overkill for a small project. It is useful when people keep relitigating who decides, who must be consulted, or why everyone assumed someone else would do the task.

Once roles are clear, the project needs a shape. Reilly talks about milestones, workstreams, and small usable increments rather than one enormous ceremonial reveal.

A milestone should describe what a user can do or see, not just an internal engineering event. Treating milestones like beta tests creates feedback opportunities and may change the next milestone based on what users learn.

That is less glamorous than unveiling a grand system, but much safer. A grand system has a suspicious habit of revealing its user requirements after the budget is gone.

And plans need realistic estimates. Reilly notes that software estimation is hard, so use smaller slices, learn from actual delivery, and update forecasts rather than defending an early guess as if it were a treaty.

Dependencies deserve early attention too. If the platform team needs a quarter to add a capability, asking two weeks before launch is not agile; it is just a surprise with branding.

Exactly. A dependency team has its own roadmap and priorities. Surface what you need, from whom, and by when early enough that they can plan rather than scramble.

What logistical structures does the book recommend once the work is real?

Agree on meeting cadence, informal communication routes, status reporting, a documentation home, development practices, and a kickoff. These structures are not bureaucracy for its own sake; they reduce the cost of sharing context.

A documentation home sounds gloriously unsexy, but without it every project becomes archaeology. Somebody asks for the current decision, and six people produce six links with the confidence of rival popes.

A single, visible project home gives the team a place for goals, decisions, milestones, meeting notes, and links to related work. It makes it easier to recover after interruptions or new people joining.

And the kickoff is not just a calendar ritual. It tells scattered contributors that they are now a project, with a purpose, next steps, and a way to ask questions.

Yes. It is especially valuable when participants come from different teams and do not yet have enough familiarity to challenge or help one another comfortably.

Then comes the word Reilly takes seriously: driving. Not sitting in the passenger seat updating a spreadsheet while the project drifts toward a lake.

Driving means actively choosing routes, making decisions, watching for hazards, and course-correcting. It starts with exploring the problem before prematurely locking in an implementation.

So if the opening document says, "We will build a GraphQL server with Node," that may already be suspicious. It states a solution before it states the problem.

That is Reilly’s point. A goal should explain the need, not smuggle in an architecture choice; otherwise reviewers cannot judge whether the chosen implementation is actually appropriate.

The lead has to make the destination legible too. Different teams may use the same words for different things, or different words for the same thing, which is a lovely way to spend six weeks.

Shared mental models reduce that risk. Use clear names, glossaries where necessary, diagrams, before-and-after pictures, and graphs that show movement toward a measurable goal.

A diagram is not decoration, then. If a component owns data before the migration and another owns it afterward, draw that plainly rather than burying it in prose.

Exactly. Reilly also urges careful naming, borrowing from domain-driven design’s idea of a ubiquitous language. If product, finance, and engineering each mean something different by "account," the project needs to say which meaning applies.

Now we reach the RFC, that beloved document genre where a person may write "TBD" under every difficult heading and call it collaboration.

Reilly’s standard is stronger: written designs make misunderstanding cheap to discover. Her useful maxim is that wrong is better than vague, because a specific proposal can be corrected while vagueness hides disagreement.

What must a credible RFC contain?

At minimum, context, goals, the design, security or privacy or compliance concerns, and alternatives considered. The goals must stay separate from the implementation, and the alternatives section proves you are trying to solve the problem rather than merely justify your favorite tool.

Then, depending on the change, include trade-offs, risks, dependencies, operations, data models, APIs, diagrams, and who will actually carry the pager. Tiny detail. Apparently production systems do not operate themselves out of gratitude.

They do not. Operability and ownership belong in the design, including monitoring, deployment, backups where relevant, and the team responsible after launch.

Reilly also gives a catalogue of design traps. Let’s do a few, because these are painfully recognizable.

One is treating a domain as easy because you do not yet understand it. An engineer may think an accounting, payroll, or on-call scheduling system is simple, when the apparent simplicity is really missing domain knowledge.

Another is building only for today. A system that works with five products may become a bottleneck when every new product requires one central team to add custom logic.

But the opposite mistake is building for a distant hypothetical future with complex machinery that current needs do not justify. The book favors explicit trade-offs over either reflex.

And "every user just needs to remember this complicated sequence" is not a design. It is a small behavioral experiment conducted on unwilling coworkers.

Right. If hundreds of users must change their behavior, the design needs to account for how they will make mistakes, learn the new path, and get support.

I also liked the warning against deferring the hard migration case. Teams can make a shiny system work for two easy users, then discover the difficult users were the actual project.

And they should be honest about rewrites. If rearchitecting means replacing most of a tangled system, calling it a refactor does not reduce the cost or risk.

Where does hands-on coding fit for the staff lead? Some people hear project leadership and immediately fear they have been exiled from the terminal.

Reilly does not prescribe one amount. Coding can keep you grounded, reveal the cost of architectural choices, and establish a pattern others can reuse, but the lead should avoid taking critical-path work that makes everyone wait on their unpredictable schedule.

So write the exemplar pagination test, perhaps, then let the team extend the pattern. Pair on a difficult component rather than quietly becoming the sole keeper of the sacred implementation.

Exactly. Code and review should make other engineers more capable. Constructive reviews, pairing, and sharing context prevent the staff engineer from becoming a bottleneck disguised as quality control.

Let’s apply this to an additional scenario, not one from the book. A company is migrating checkout across payments, identity, mobile, and observability teams, all with different release cycles. Where do we begin?

First, define the outcome in user terms: perhaps customers can complete checkout through the new flow without increased failures, and support can diagnose failures quickly. Do not define success as "four services migrated," because that could happen while customers cannot pay.

Then map roles. Payments may own payment authorization behavior, identity owns session and authentication changes, mobile owns client releases, observability owns required signals, and one technical lead owns the cross-system design and unresolved seams.

Yes, while a program manager, if the organization has one, might coordinate timelines and status. The group would set milestones such as internal test transactions, a limited client rollout, and a measured customer rollout, each with explicit rollback criteria.

The RFC would state the goal, the end-to-end flow, data and security boundaries, alternatives, dependencies, operational ownership, and the painful cases, like an identity token expiring halfway through payment.

And status updates should lead with impact: "The limited rollout remains on track, but mobile approval now threatens the customer date," rather than a vague green indicator hiding that the essential release dependency is late.

That is the watermelon project: green on the outside, red on the inside, and everyone gets a disappointing slice at launch.

Reilly’s advice is to communicate honestly and with the audience in mind. Stakeholders usually need to know what users can do now, what changes next, and whether a risk affects the promised outcome.

So this chapter is less about heroic execution than making reality visible: clear roles, visible dependencies, explicit decisions, usable documentation, and enough contact that people can say, "I don’t understand," before the outage does it for them.

That is a good summary. Clear planning does not eliminate uncertainty, but it gives a project somewhere to put uncertainty, test it, and respond to it together.

And next comes the unpleasant but necessary sequel: what to do when the project stops moving, the decision never arrives, or the destination turns out to be a decorative wall.

Yes. Leading includes knowing how to diagnose a stall, unblock work, reroute it, or end it responsibly rather than pretending the status is still green.

We’ve built the plan, named the milestones, written the RFC, and created a dashboard with enough colors to frighten a parrot. Then the project stops moving. What does Reilly say the technical lead owns at that point?

First, they own understanding why it stopped. The lead does not merely report that a dependency is blocked; they help restart it, reroute around it, escalate for help, or conclude honestly that the work should end.

And not every stalled project is an invitation to become the company’s emergency emotional-support engineer. That job description becomes a swamp quite quickly.

Exactly. Reilly warns against filling all your time with side assists and rescues. A staff engineer can often unblock work with a small intervention, but has to protect time for the outcomes they are already accountable for.

The book keeps returning to four moves, which are reassuringly less glamorous than heroics. Understand and explain, make the work easier, get organizational support, and make alternative plans.

That is the practical loop. It works because most blockages are not one thing called resistance; they are different failures that need different responses.

Start with the classic: another team is blocking you. Your launch needs one configuration change from platform, and they have not done it. Surely they can just press the little button.

Maybe the change takes ten minutes, but your request is one item among many for that team. Reilly distinguishes misunderstanding, misadventure, and misaligned priorities: they may not know the deadline, may be understaffed or blocked themselves, or may be doing work their leadership considers more important.

So the phrase “it only takes ten minutes” is usually spoken by someone who has not seen the other team’s queue. A tiny act can still require ownership, review, and somebody accepting blame if it goes wrong.

Right. Begin with a direct conversation and explain the user or business impact, the specific deliverable, and the date. Then ask whether the request is realistic rather than treating silence as a moral failing.

If they cannot do the whole thing, make the request smaller. Perhaps you need one endpoint enabled for launch, not the entire platform upgrade with ceremonial ribbons.

And look for reciprocal unblocking. If their delay comes from a dependency you can help resolve, a small side quest may unlock both teams; but do not assume offering to write their code is helpful, because supervising an unfamiliar contributor can create more work.

When do you escalate without becoming the person who treats every calendar conflict as a constitutional crisis?

When the priorities genuinely conflict and the teams cannot resolve them. Bring unemotional facts to a shared leader: what is needed, why it matters, what is delayed, and what choices remain; escalation is asking someone with authority to help decide, not staging a public trial.

The next blockage is a decision. Engineering asks product, legal, or a customer group whether to choose A or B, and receives a reply that somehow means both yes and no.

That often happens because the decision is difficult from where they sit, or because engineering language has hidden the actual trade-off. A stakeholder may not understand the distinction between two architectures, but they can understand an example of what users can do, what will cost more, or what becomes hard to reverse.

So instead of asking, “Do you want synchronous replication or eventual consistency?” you might ask, “Is it acceptable if a newly changed address appears on a receipt a few minutes later?” Less alphabet soup, more reality.

Yes. Reilly’s method is to help people obtain the information they need, clarify which parts are consequential, and use pictures, examples, or mental models to make the decision legible.

And if nobody can decide?

Choose deliberately among waiting, making a reversible best guess, or stopping. The key is not to drift into an accidental nondecision while building an elaborate hedge around every possible future.

Then there is the approval blocker, the one-button tragedy. Security, communications, or production review has not approved the launch, and the project lead begins staring at the ticket like it owes them money.

Reilly is good on the perspective shift here. Approval means accountability, and the approving team has its own workload and risk; a respectful request that includes the relevant facts and one clear action is far more likely to move than an irritated demand.

Make it easy to say yes: concise context, the actual deadline, the risk assessment, and a specific question. Not a fourteen-page document dropped into their lap at 4:57 on Friday, wearing a fake mustache.

Precisely. If someone helps at short notice, acknowledge it afterward. Gratitude and follow-through build the relationships that make the next cross-team request less costly.

The book also covers a more awkward case: one person is assigned the work and it simply is not happening. It is tempting to label that procrastination and seize the keyboard.

But the visible behavior may conceal intimidation, overload, an unclear request, conflicting instructions from their manager, or stress outside work. Reilly’s example involves someone avoiding a small scripting task because the task represented a scary first step into coding.

Which does not make the deadline disappear, unfortunately. Compassion cannot compile the missing script.

No, but it can help you find a workable response. Clarify why the work matters, break it into smaller steps, set an earlier check-in, and pair or whiteboard if the person needs help starting; do not assume you are their manager or therapist.

And if their manager has told them to do something else, that is not a personal productivity flaw. It is another priorities problem wearing a trench coat.

Exactly. At that point, discuss the conflict with the appropriate manager or sponsor. The aim is to get the work correctly prioritized, not to shame an individual for responding to incentives you cannot see.

My favorite blockage is unowned work. Everyone agrees a shared data model is dangerous, six teams attend the meeting, thirty comments appear on the doc, and not one roadmap contains the fix.

That is Reilly’s organizational plate-tectonics problem. The work falls between team boundaries, so more technical polishing will not solve the actual issue: it needs an owner, staffing, and usually sponsorship.

She recommends a rollup here, yes? Not another ambient Slack debate, but one document that collects facts and states the conclusion.

Yes. For example: Team A owns ingestion, Team B owns retention, Team C owns access controls, and no team owns end-to-end deletion; therefore, the compliance requirement cannot be met under the current ownership model. Stating the conclusion is important because scattered facts let everyone pretend the gap belongs to someone else.

Then the staff engineer’s job is to make the staffing decision possible, not to heroically refactor one adjacent service until morale becomes a faint historical memory.

Well put. They can make an elevator pitch, find a sponsor, propose a realistic scope, and perhaps offer technical guidance, but if leadership will not fund the work, the honest response may be to defer it rather than simulate progress.

Migrations are a special species of collective avoidance. The old system is supported, the new system is better, and half the company has decided to wait for everyone else to move first.

Reilly asks the lead to tell both stories. The migration team may have a real business, security, or maintenance need, while product teams may be exhausted by constant changes that bring them no obvious benefit.

So do more of the work yourself: automate steps, name exact files to change, provide tooling, and make the new route the default. Do not send a cheerful announcement saying “please modernize by Tuesday” and call that enablement.

Also make adoption visible. A progress graph can create momentum when it shows that most teams have moved, but it should not become public humiliation for the remaining teams; find their specific constraints and help where possible.

And mandates?

Use them carefully and only with real organizational backing. Adding friction to the old path or eventually withdrawing support may be necessary, but not as a substitute for a usable replacement or for understanding customer impact.

Sometimes nobody is blocked exactly. The group is simply lost, because forty people have forty architectural opinions and all of them have brought diagrams.

That is analysis paralysis. Reilly’s answer is to clarify authority and destination: appoint a decider where appropriate, form a small strategy group, or select one limited vertical slice that serves a real stakeholder rather than debating the entire future architecture forever.

A vertical slice is useful because it makes the argument touch a user. “Help this team move its data safely” is more actionable than “achieve modernity,” which is not even a destination, it is an expensive perfume.

And once you solve a bounded problem, you gain evidence about what should happen next. You may then have enough shared context to write the broader strategy that was impossible at the start.

What if the project lead is the one who is lost? The problem is technically hard, their brain is full of meetings, and every attempt to think produces another tab.

Reilly’s advice is refreshingly basic: articulate the precise problem, revisit assumptions, schedule uninterrupted thinking time, look for prior art, start with a smaller piece, and ask for help. Difficult work often stays difficult because people try to solve it in fragmented minutes between interruptions.

There is also a useful suspicion in that list: perhaps you have already selected a solution and are calling it the problem. Maybe the constraint is movable, or a less elegant trade-off is acceptable.

That is an important staff-level judgment. You do not need the globally perfect answer; you need an answer that meets the real goal under the actual constraints, with risks you understand.

Now, endings. The book is very skeptical of “code complete,” which is fair because software can be technically finished and operationally imaginary.

The first false ending is code that exists but is not usable. It may not be deployed, documented, monitored, approved, or accessible to the person who needs it; as Reilly puts it through a memorable analogy, users do not want software, they want to catch a Pokémon.

The second is the internal tool nobody uses. It has a charming name, a lonely wiki page, and perhaps a sign in a locked basement cabinet warning of a leopard.

That is Reilly’s point: building is not adoption. Teams need to tell users repeatedly, make the tool discoverable where users already search, demonstrate value, and often provide hands-on help to early adopters.

The third false ending is the quick feature on a shaky foundation. The user can catch the Pokémon, but each catch causes an unmonitored cron job to whisper ominously into a database.

Sometimes a minimum version is the right business decision, but temporary solutions tend to become permanent. The book argues for making quality work visible in the plan, tying it to user reliability or future capability, and setting norms where testing, observability, documentation, and cleanup are part of delivery.

So when can a lead say, “Done enough, let’s stop”? Not when every engineer has achieved inner peace, presumably.

No, when the agreed user or organizational outcome is met, the system is usable, and further investment is lower value than other work. The lead should check that they are not simply abandoning a half-migration, unhappy users, or deferred foundational risks.

The harder ending is killing a project. Reilly treats that as potentially good judgment, which is unusually sane in a field that enjoys turning sunk costs into monuments.

A project can reveal that its proposed technology will not work at the required scale or that its benefit no longer justifies its cost. Ending it after learning that is not the same as failing to notice reality and spending another year pushing forward.

And externally canceled work can sting even if the decision is rational. A new executive arrives, the market changes, funding disappears, and suddenly the roadmap is compost.

The project lead should communicate the why directly, allow people to react, shut down systems and code cleanly where possible, document useful learning, and consider a retrospective. They should also advocate for team members whose promotion evidence or reputation might otherwise vanish with the canceled project.

Then celebrate real arrivals: the users are using it, the measure improved, the old system can be turned off, and the team has evidence rather than confetti alone.

Yes. Reilly recommends celebrating and retrospecting successful work too, including the behaviors that made it succeed, because that is how a group learns what good engineering looks like.

Which brings us to the slightly alarming Chapter 7 turn: whether you asked for it or not, senior engineers are role models. Your half-baked hallway thought may return a month later as somebody’s unofficial roadmap.

That is Reilly’s warning. A staff title gives ideas extra weight, so values are expressed not by posters but by behavior: how senior engineers review code, respond in incidents, treat colleagues, make trade-offs, and speak when they are uncertain.

If the senior engineer skips tests, others learn that tests are ceremonial. If they write clear RFCs, credit coworkers, and stay calm during an outage, that spreads too.

And role modeling is not about being loud or charismatic. Quiet, thoughtful engineers can lead through sound judgment and constructive collaboration, but they need to recognize that their actions set a local standard.

The foundation remains competence. This book is not claiming that an impressive meeting cadence can replace knowing how systems work, thank heavens.

No. Reilly is explicit that technical leadership rests on technical knowledge and experience, plus the capacity to learn a new domain, recognize the shape of unfamiliar problems, and stay current enough that your judgment is not based on obsolete habits.

I liked her objection to saying someone is “not technical enough.” It sounds decisive, but it explains almost nothing and gives the person nowhere to go.

A better statement is specific: they need more hands-on experience, lack knowledge in this domain, or need practice with a particular skill. That is both more accurate and more useful than treating technical ability as a fixed personality trait.

Let’s be fair to the framework. What does this first part of the book do exceptionally well?

It makes ambiguity concrete. Rather than saying “influence without authority” and walking away in a cloud of executive vapor, Reilly gives practical ways to map organizations, define scope, write strategy, choose work, run projects, and diagnose why they stop.

And its limitation?

It is a staff-plus book, written for people who have some technical credibility and at least potential access to sponsors, decision rooms, and cross-team work. A written strategy cannot repair broken incentives, severe understaffing, biased evaluation, or leaders who will not support the necessary work.

Generally speaking, titles, sponsorship, and documents can reduce ambiguity, but they cannot magically neutralize power. If an executive has already decided the answer, your beautiful RFC may become decorative upholstery.

That broader caution matters. The book itself acknowledges context repeatedly, but readers should avoid performing strategic leadership—making maps, convening groups, producing vocabulary—when the real need is to solve a user problem or name an organizational constraint nobody will address.

So the test is not, “Did I look staff-shaped today?” Mercifully. It is whether people now understand the important work better, can do it more safely, and are less dependent on one heroic engineer.

That is the heart of it. Technical leadership is less about being the smartest person in every room, more about making the next right piece of work clearer and more achievable for the people around you.

So, if we pull the whole thing together, Reilly is not offering a fancy title as a personality transplant. She’s describing technical leadership as wider responsibility: seeing the system, helping work move, and making the people around you more capable.

Right. Her three pillars are big-picture thinking, execution, and leveling up others, all resting on actual technical judgment. The role is not less technical; it is less about personally producing every line and more about ensuring the important problem gets solved well.

We began with the awkward fact that staff engineer is not a standardized creature. One company’s architect is another company’s solver, and a title can grant useful authority without proving that you’ve acquired wizard bones.

That is why the written role description matters. State your scope, primary focus, expected activities, and what success would look like, then compare it with your manager’s view before performance review season turns into interpretive dance.

Then came the maps: locator, topographical, and treasure. Before charging into a technical fix, ask where your team sits, who the customer is, how decisions really happen, and what destination the work is meant to serve.

Those maps are a defense against local optimization. The easy tool for one team may impose permanent security, legal, or platform costs elsewhere, and a healthy availability metric can still conceal an unhappy user who cannot reach the product.

And if the destination is missing, don’t announce a grand strategy because you enjoy documents with tiny diagrams. Reilly separates a vision, the future state you want, from a strategy, the realistic route through the obstacles.

The useful core is diagnosis, guiding policy, and coherent actions. Get sponsorship, involve the people with relevant context, make trade-offs explicit, and remember that alignment is not an annoying prelude to the work; in this kind of work, it is much of the work.

Next, the unpleasant arithmetic: there is infinite work and one you. Protect focus time, keep some buffer for reality arriving with a small axe, and evaluate commitments not just by importance but by energy, skills, credibility, social capital, and whether the work makes your life worse.

That framework is practical, but not magical. Better calendaring cannot fix chronic understaffing, biased evaluation, caregiving constraints, or leaders who create permanent emergencies; those are organizational problems that need organizational changes.

When you do take on the big project, lead it actively. Clarify roles, users, milestones, dependencies, and success measures; write down the design and alternatives; communicate status in terms of impact, not merely how many technical widgets now exist in a drawer.

And when the work stops, diagnose the actual blockage. It may be a confused dependency, an unmade decision, unowned work between teams, or a migration that asks everyone else to absorb the cost; don’t keep polishing adjacent code when the obstacle is organizational.

The final test is whether people can actually use the thing, whether the foundation is safe enough, and whether stopping is wiser than throwing more effort into a doomed project. Senior engineers model standards through what they ship, review, say, and calmly refuse to pretend is green.

If you do one thing after this episode, write four short lines: the important problem, the user or organizational outcome, the current blockage, and the next conversation needed to move it. That is not a promotion guarantee, but it is a learnable way to make the work clearer and less dependent on one heroic person; and, as always, double-check anything important against the book and your own context.