DEEP READING · READ 919
Tanya Reilly · O'Reilly · 2022
Once you make Staff, the job stops being "write harder code" and becomes changing how a large group of people work, with no reports and no authority to compel anyone — and this is the most concrete book yet written about what that actually looks like day to day: how to see the whole board, how to decide what not to do, how to get a project spanning five teams genuinely finished, and how to raise the people around you without becoming their manager.
Tanya Reilly spent over a decade in site reliability engineering at Google and went on to be a principal engineer at Squarespace. Her 2019 talk "Being Glue" travelled unusually far in the industry — the phrase "glue work" is in the engineering vocabulary largely because of her. This book pairs with Will Larson's Staff Engineer: Larson answers what a staff engineer is and how you get there; Reilly answers what you actually do once you have.
The book's most portable tool is a metaphor of three maps. Engineers make locally sensible, globally absurd decisions, she argues, not because they're foolish but because the only map they hold is zoomed all the way in on their own team.
Why keep all three on you: it turns the useless criticism "you need more big-picture thinking" into three separate, fixable gaps. Next time a technical argument refuses to converge, before making your case again, ask: which map are we missing? Do we not know where we sit in the whole (locator), not know what's in the way (topographic), or not share a destination at all (treasure)? In my experience most "technical disagreements" are a missing third map that people spend three weeks litigating as if it were the first.
The companion skill to the maps is altitude. Reilly likens your attention to a plane's cruising height: you can fly at ground level, down inside the implementation of one function, or climb to 30,000 feet and consider where the company's architecture should be in three years.
The point is that there is no correct altitude, only the altitude this moment calls for — and the Staff+ skill is moving between them freely. Stay on the deck forever and you're just a highly productive senior engineer with the fuselage blocking your view. Stay at 30,000 feet and you become the person who writes beautiful vision documents and knows nothing about the actual system — no one in an engineering organization loses credibility faster, because engineers can smell someone who doesn't touch the code within about three sentences. Her advice is practical: land regularly. Do some real work — fix a bug, take an on-call shift, walk through the new-hire setup yourself — not for the output but so that your view from altitude has ground truth under it.
What this changes: when someone strikes you as wrong, usually they aren't — you're speaking from different altitudes. They're discussing how this interface changes this quarter; you're discussing whether the architecture should exist in three years. Both statements can be true and still fail to meet. Align altitude first, then argue.
This is Reilly's most famous idea and the one with real social weight. Glue work is everything that makes a team actually function while producing no artifact attributable to you: noticing two teams building the same thing and getting them in a room; spotting the hole in a design doc that nobody asked about; onboarding the new hire; writing down the decision that has been re-argued for three weeks; catching a project as it starts to come apart.
Her observation has two layers and both need saying. First: this work is necessary. Without it projects rot in a way nobody can quite diagnose — everyone is busy, nothing moves. Second, and this is the part that stings: it usually doesn't count at promotion time. Promotion committees look for what you led, what you shipped, what impact is attributable to you — and the nature of glue work is that its results show up as somebody else's project succeeding.
Then the judgment she's most quoted for: this work is not distributed randomly. It lands disproportionately on women, on people from underrepresented groups, and on anyone conscientious enough to do a thing simply because they saw it needed doing. The loop is cruel: the more you hold the team together, the more likely you are to be told your contributions weren't distinctive enough.
Her advice runs two ways, and she concedes it isn't a complete answer. One: know what you're doing rather than drifting into it. Before taking it on, ask whether the work is important — and if it is, whether it should really depend on one person's goodwill in the margins, or become a named, owned, credited piece of work. Two: if you're going to do it, do it in a shape that can be seen — turn "I helped coordinate a bit" into "I led the alignment for the X migration and produced the decision record." Same work, different account, different fate. That isn't spin; it's correcting a genuine bookkeeping error.
How it changes what you see: you start looking for who the glue is. Every smoothly running organization has one or two people carrying an enormous invisible load. They are rarely the brightest names on the performance list — and when they leave, it takes about two quarters before everyone finally understands what they had been doing.
She insists on separating them, because conflating them is why so many "technical planning documents" end as wallpaper.
| Technical vision | Technical strategy | |
| Answers | what "good" looks like when we get there | how we get there from where we actually are |
| Map | the X on the treasure map | the route drawn on the topographic map |
| Failure mode | lovely adjectives everyone agrees with and nobody is affected by | a list of everything, which is a list of nothing |
Vision says where, strategy says how — without the first you sprint blind, without the second you only hold meetings.
On strategy she draws explicitly on the "kernel" from Richard Rumelt's Good Strategy Bad Strategy: a real strategy needs a diagnosis (what is actually wrong, not a list of symptoms), a guiding policy (given that diagnosis, which road we take and which we abandon), and a coherent set of actions (what the policy means tomorrow morning). The signature of bad strategy is a missing diagnosis: skip straight to a list of goals. "We will improve reliability, ship faster, and make the developer experience better" — nobody will oppose any of it and nobody will behave differently, because it names nothing to give up.
She adds one counterintuitive warning: the hard part of writing a strategy isn't writing, it's talking to everyone first. A strategy authored without participation, however correct, gets politely admired in review and then forgotten — because the value of a strategy lives in the agreement, not the document. The document is just where the agreement is stored.
The characteristic Staff+ pain isn't incompetence, it's that everything is worth doing and all of it is waiting on you. Her remedy is to lay out what you actually have — and two of the accounts are the ones engineers forget to track.
Credibility: how much people trust your technical judgment. You earn it by delivering — the thing you said would work worked, the risk you flagged materialized. You spend it when you need people to back something whose payoff won't be visible for six months. A new arrival has no balance, which is why the smart opening move is one or two short, winnable, visible pieces of work to fund the account.
Social capital: whether people want to work with you and will do you a favour. It is not the same thing — you can be deeply respected technically and still be someone nobody wants on their project. You earn it by helping, collaborating well, and doing what you said; you spend it every time you ask someone to jump a queue, compromise, or accept a decision they dislike.
Why the two-accounts metaphor matters: it translates "politics" — a thing many engineers instinctively resent — into a language they're fluent in, resource management. You needn't enjoy it, but you can do the arithmetic: how much credibility is this worth? Have I spent all quarter and deposited nothing? Someone who objects constantly and ships nothing is running a deficit; someone who ships relentlessly and never collaborates has one account overflowing and the other long overdrawn.
And a line she leans on hard: you can do anything, but not everything. The typical Staff failure isn't picking the wrong project — it's carrying five and moving each to 60%. Hence the almost rude question she recommends asking on a schedule: what is the most important thing I could be working on right now, and am I working on it? If not, change what you're doing or admit honestly that you chose otherwise — but don't let being busy pass for being aimed.
Leading something that crosses several teams and runs half a year is the archetypal staff assignment. Reilly's core claim: these projects almost never fail on technical difficulty. They fail where shared understanding quietly breaks. She takes that understanding apart into layers, each worth confirming separately:
Paired with this is an excellent diagnostic question: "why have we stopped?" When a project stalls the instinct is to add hours, add people, chase status. Her advice is to classify the stall first: does nobody know the next step (no plan)? are we waiting on another team (blocked dependency)? are we waiting on a decision nobody will make (a decision vacuum)? or is everyone simply working on something else (it was never really prioritized)? The four have completely different remedies, and working weekends fixes none of the last three. Her recurring point: most obstacles on a big project are social, not technical — and an engineer's default is to go optimize the technical part, because that's the part they know.
The third pillar is raising the people around you, and here she draws a distinction many people blur.
Mentorship is advice: I tell you what I know and you go use it. Sponsorship is opportunity: I put my own reputation behind you and hand you something risky and visible — the presentation to the executive, the tech lead role on the big project. The difference is who carries the risk: mentorship is free goodwill, sponsorship stakes your own chips on someone else. Her verdict is blunt: what changes careers is overwhelmingly sponsorship, not mentorship. Anyone can offer advice; only someone with chips can hand over an opportunity — and reaching Staff is the first time you have any.
Two more that land. First, your behaviour gets copied whether you intend it or not. How you talk in code review, whether you'll say "I don't understand this" in a meeting, whether you look for causes or for culprits after an incident — more junior people are learning from exactly these details what being an engineer here means. This is the most real and least noticed piece of Staff+ power: you don't need to author the norms, your ordinary conduct is the norms. Her small, sharp example: when someone senior enough says "hang on, I didn't follow that," the psychological safety of the whole room moves up a notch — every person who was afraid to ask has just been given permission.
Second, get the knowledge out of your head. A system only you can operate looks like job security and is actually a ceiling: you get chained to it, and the organization's capacity is capped at your calendar. Documenting, teaching, making hard things explicable is not extra credit — it's the only way out.
The book runs from seeing to moving to multiplying, each part answering one side of a single question: how does someone with no authority change an organization?
Misreading 1: this is a guide to getting promoted to Staff. It's mostly about doing the job once you're in it. For positioning, visibility and navigating the promotion process, Larson's Staff Engineer is the better fit; the two are complements, not alternatives.
Misreading 2: "make glue work visible" solves the problem. It does the opposite — it relocates a structural problem onto the individual. If a company's promotion machinery systematically fails to score collaborative contribution, the thing to fix is the criteria, not the sufferer's self-marketing. Reilly doesn't dodge this, but the book's genre limits it to individual advice where the remedy is institutional. Honestly: this is the book's most powerful insight and also the place it is most powerless.
Objection 1: applicability depends heavily on the kind of company. The whole book assumes a mid-to-large tech firm with an established Staff+ ladder, many teams and a promotion-review culture. At a twenty-person startup two of the three maps can be covered over one lunch; in an IT department outside tech, much of the description simply doesn't hold. Convert as you read rather than transplanting.
Objection 2: the evidence is experience, not research. The material comes from a decade-plus on the ground plus the shared vocabulary of the engineering-leadership community (Larson, Camille Fournier and others) — not from empirical study. Nothing here shows that people who work this way succeed more often, and survivorship bias can't be ruled out: we hear the retrospectives of people for whom it worked. As a high-quality distillation of professional experience it's excellent; read as experience it's right, read as law it will disappoint.
Objection 3: some readers find it long and soft. Compressed, a good deal of it comes to "communicate, write things down, choose deliberately" — hardly novel; the value is in how finely she operationalizes it. If you've already run cross-team projects in a large company for a few years, stretches of it will confirm what you know; if you've just arrived at this level, the "obvious" parts are precisely the valuable ones.
Objection 4: one question the book never really answers. The whole influence-without-authority approach presupposes an organization that is basically healthy and responsive to good arguments. And if it isn't? If decisions are made by a couple of people on instinct and no volume of documentation gets read? The answer offered is closer to "that's information too — this place may not be right for you," which is true and of limited use to someone currently stuck in it.
1. Staff+ isn't a more senior senior; it's a different job — the measure moves from what you produce to how much more the organization produces because you're there.
2. Three pillars — see the big picture, land the work, raise the people; drop one and you become the corresponding kind of useless.
3. Carry three maps: the locator (your red dot is small), the topographic (swamps and quicksand appear in no process doc), and the treasure map (where we're going); most "technical disagreements" are a missing third map.
4. There's no correct altitude, only the one this moment needs: fly on the deck forever and you lose the direction; live at 30,000 feet and you lose your credibility fast.
5. Glue work keeps the organization running and never reaches the promotion ledger — and it is not handed out at random; so either make it a named piece of owned work, or do it in a shape that can be seen.
6. Vision says where, strategy says how; the mark of bad strategy is skipping the diagnosis for a list of goals nobody opposes — because it tells no one what to give up.
7. A strategy's value is in the agreement, not the document: one written without participation gets politely admired, then forgotten.
8. You hold four finite accounts: time, energy, credibility (earned by delivering, spent on things others can't yet see) and social capital (earned by collaborating, spent asking people to yield); you can do anything, but not everything.
9. Big projects run on four layers of agreement — problem, approach, ownership, definition of done; when one stalls, classify the stall, because most obstacles are social and overtime only cures the technical kind.
10. Mentorship is advice; sponsorship is staking your own reputation to hand someone a risky opportunity — advice is cheap, opportunities come only from people holding chips. And your ordinary conduct is the norm: when someone senior enough says "hang on, I didn't follow that," the whole room's psychological safety moves up a notch.