Glue Work and Leverage

Every project has work that isn’t in anyone’s job description and isn’t in the code: noticing the thing nobody owns and picking it up, writing the document nobody wrote, getting two teams who are talking past each other onto the same page, following up until a loose end is actually tied. Tanya Reilly named this glue work in a widely-shared talk, and it’s one of the most important and most misunderstood categories of engineering work. Essential: projects fail in the gaps between people far more than inside the code. But also credit-poor and often invisible, which makes it both a staff engineer’s core contribution and, for the wrong person at the wrong time, a career trap. Understanding the difference is this lesson.

What Glue Work Is, and Why It Matters

Glue work is everything that holds a project together that isn’t a discrete deliverable:

It matters because projects fail in the gaps. The code inside each team is usually fine; what breaks is the seam between teams, the assumption nobody checked, the decision nobody made, the piece nobody owned. Glue work is the work of closing those gaps: noticing the unowned problem, writing the doc that aligns everyone, chasing the follow-up until it’s done. A project with great engineers and no glue drifts and fails; a project with decent engineers and someone doing the glue well ships. On a cross-team project (Lesson 6), the glue is the leadership.

Why It’s a Trap (for the Wrong Person)

Here’s the uncomfortable part Reilly highlighted: glue work is often invisible and under-credited, and that creates a trap. If you’re not yet senior, doing only glue work can actively stall your career. Promotion to senior usually requires demonstrated technical depth, visible wins you built, and if you’ve spent all your time being helpful in the gaps, you may have no such wins on the record, even though you were essential. Worse, the research shows glue work gets pushed disproportionately onto women and junior engineers (“you’re so good at organising things”), who then do the vital, invisible work while others do the visible, promotable work and get promoted.

So the honest advice splits by level:

• If you’re not yet senior: do some glue work (it’s how you learn the system and build relationships), but make sure you’re also getting technical wins on the record. If you notice you’re always the one taking notes, herding the project, and writing the docs while others write the code that gets them promoted, that’s a signal to rebalance, and possibly to raise it with your manager.
• If you’re staff+: glue work is the job, and it’s expected to be recognised as leadership. The difference is that at staff level, the org should (and in a healthy place does) see “aligned three teams and unblocked the migration” as exactly the high-value work it is. Your task is to make sure it’s seen that way.

How Staff Engineers Do Glue Work Well

The shift from “glue work as a trap” to “glue work as leadership” comes down to a few practices:

Make it visible. The cardinal rule. Invisible glue work gets no credit and sets a bad example (it looks like the project just magically went well). So write it down and present it: the alignment doc you wrote, the decision you brokered, the dependency you caught. Not to brag, but because making this work visible is how it gets recognised as leadership, and how juniors learn that it’s valued rather than invisible. Your brag doc (Lesson 12) is partly a record of glue work that would otherwise vanish.

Do only the glue that needs you. Not all glue work requires a staff engineer. Some of it needs your specific context, your relationships across teams, your judgment about the trade-off. That’s yours to do. The rote parts, scheduling, note-taking, status-chasing, mechanical follow-up, should be delegated (giving a junior a growth opportunity, Lesson 9), automated, or handled by a program/project manager if you have one. Spending a staff engineer’s time on work anyone could do is low-leverage (Lesson 2).

Turn invisible glue into durable artifacts. This is the highest-leverage version. Instead of repeatedly doing the same alignment or unblocking by hand, turn it into something that lasts and works without you:

• The recurring “how do I set up X?” questions → a runbook or a doc.
• The same design decision made again and again → a template or an ADR (Lesson 5) that encodes the answer.
• The constant friction of everyone building Y slightly differently → a paved road (Lesson 10): a standard, easy way to do Y that’s simply the path of least resistance.

Now the glue work outlasts the moment, scales beyond you, and is visible (it’s a named artifact with your fingerprints on it). You’ve converted invisible, repeated effort into durable, credited leverage. This is the move that turns glue work from a treadmill into a multiplier.

Distribute it fairly, and sponsor people into technical work. As a staff engineer you also have a responsibility here: actively make sure the glue work doesn’t pile only onto the juniors and the women on your team, and actively sponsor those folks into the visible technical work (Lesson 9). You set the norm for whether glue work is valued and fairly shared.

Be a Multiplier, Not a Bottleneck

Underneath glue work is the broader question of leverage (Lesson 2): are you making the people around you faster, or are you becoming the thing they wait on? A staff engineer should be a multiplier, every interaction leaves someone more capable or a system better, so the team’s total output rises. The failure mode is becoming a bottleneck: every decision routes through you, every design needs your blessing, nothing moves without you. That feels important (you’re clearly needed!) but it’s actually a cap on the team and a setup for your own burnout (Lesson 12).

The multiplier moves:

• Delegate real ownership, not just tasks. Give someone a whole problem and let them make the decisions (and the mistakes). You get leverage; they grow.
• Teach the reasoning, not just the answer. When you unblock someone, explain how you’d think about it, so next time they don’t need you (Lesson 9).
• Build paved roads so the common cases don’t need your involvement at all.
• Write things down so your context is available without a meeting with you.
• Make yourself dispensable on the things that are running well, so you can move to the next important problem. The goal isn’t to be needed everywhere; it’s to make things not need you, then go where you are needed.

A good gut-check: if you went on leave for three weeks, would your team slow to a crawl (bottleneck) or keep running well because you’ve built the systems, docs and people to not need you (multiplier)? Aim for the second. Being indispensable is not the goal; making your team unstoppable is.

Pitfalls to Avoid

1. Doing only glue work before you’re senior. You need technical wins on the record too, or your growth stalls.
2. Letting glue work pile on juniors and women. Distribute it fairly and sponsor them into visible technical work.
3. Doing glue work invisibly. Write it down and present it, or it gets no credit and looks like magic.
4. Doing the rote glue yourself. Delegate or automate what doesn’t need your context; spend your time on what only you can do.
5. Repeating the same glue by hand. Turn it into a durable artifact, doc, template, paved road, so it scales and shows.
6. Becoming a bottleneck. If every decision routes through you, you cap the team and set up your own burnout.
7. Optimising to be indispensable. The goal is a team that doesn’t need you, so you can go where you’re needed.

Quick Recap

• Glue work (unblocking, aligning, documenting, herding) is essential, projects fail in the gaps between people, not in the code.
• It’s a trap for juniors (invisible, under-credited, unfairly distributed); at staff level it IS the job and should be seen as leadership.
• Do it well: make it visible, do only the glue that needs your context, and turn repeated glue into durable artifacts (docs, templates, paved roads).
• Distribute glue fairly and sponsor juniors into visible technical work.
• Be a multiplier (make others faster, build systems that don’t need you), not a bottleneck (everything routes through you).

Next lesson: the highest-leverage people work of all, growing others through mentorship and, especially, sponsorship.