Glue work is leadership. Make it countable or stop doing it.

October 17, 2026

Senior TPMs spend their careers doing the work promotion committees call "not technical enough," and the fix is not working harder at it.

Here is the oldest trap in the TPM career, and it is still open. You unblock a launch, rewrite the onboarding doc nobody owned, untangle two teams that were quietly blocking each other, and keep a messy program honest. Your manager is delighted. Then promotion season arrives, and the credit for the outcome goes to the person who wrote the code and the person who drew the architecture.

Tanya Reilly gave this pattern a name in her 2019 talk "Being Glue": glue work, the collective work that makes a project succeed beyond the code itself. She was clear that it is real technical leadership, and equally clear that it is routinely left out of how people get promoted. Seven years on, the trap has a new accelerant. As agents absorb more of the mechanical coordination, the glue that remains is the judgment-heavy part, and it is still the part that is hardest to see on a promotion packet.

The argument of this issue is blunt. Glue work is not a character flaw to be cured and not a calling to be endured. It is an investment with a visibility problem, and you manage it like any other investment: decide how much you hold, make the returns countable, and rebalance when the returns stop showing up.

Deep Dive — Career & Growth: Glue Work Is an Investment, So Manage the Portfolio

Start with what Reilly actually claimed, because the popular version flattens it. Her story is of an engineer who fills gaps: she helps a customer, clarifies a confused project direction, writes onboarding documentation, introduces coding standards. Her manager treats her as an unofficial lead and her reviews glow. At promotion time she is told her work is not technical enough, and the project's success is credited to the coder and the system designer. Reilly puts part of the responsibility on the manager, calling it a communication breakdown rather than a personal failing. She also cites an HBR finding that non-promotable work is distributed unevenly, with women volunteering for it more often and being asked for it more often.

Two sentences from her advice matter most for senior people. First, if glue work is not being rewarded, temporarily stop doing it and focus on visible technical output, even where that is not your strongest area. Second, if you only ever do glue, you will only get better at glue. Most skills are learned on the job, so choose roles for the skills you want to build, not the ones you already have.

For a TPM this lands differently than for an engineer. Coordination is not a side activity in your job description; it is the job. So the useful question is not "should I do glue work?" It is "which glue work produces leverage that someone can see, and which produces only gratitude?"

Here is a way to sort it. Take your last quarter and list every piece of coordination you did. Then place each item in one of four boxes along two axes: does it change an outcome that has a number attached, and does it build a capability that survives you leaving the room?

• Counted and durable. You redesigned the launch-readiness process, the release cadence shrank, and three other programs now use it. This is leverage. Put it at the top of your packet.
• Counted and personal. You personally chased approvals and the launch shipped on time. Real value, but it vanishes when you do. Fine in moderation; dangerous as a steady diet because you become the single point of failure.
• Durable and uncounted. You wrote the doc that answers the question people ask every month, but nobody measured the questions avoided. Worth a small effort to count: ask the support channel or the on-call rotation for before-and-after numbers.
• Neither. Meeting notes nobody reads, reminders anyone could send, status pages updated by hand. This is the work to delegate, automate, or decline.

That last box is where agents belong. If a task is repeatable coordination with no judgment, it is the first candidate for an agent or a rotation, and your time moves to the other three boxes. The point of the exercise is not to shrink your glue; it is to spend it where it compounds.

Fatima Taj, a senior engineer at Yelp interviewed by Visual Studio Magazine, offers warning signs worth stealing. You are the only person who knows how a recurring process works. Your calendar is dominated by coordination. Your brag document or promo packet emphasizes alignment over systems you designed or built. Any one of these is a flag; all three means you have drifted into the trap by accumulation, not by choice.

The conversation with your manager matters more than the document. Taj's framing is the right one: raise it as a risk and growth topic, not a complaint. The risk is that you are a single point of failure. The growth need is technical or strategic ownership tied to the level you want. Ask for help spreading the knowledge and rebalancing your projects. A manager can say yes to that in a way they cannot say yes to "I feel undervalued."

And write the evidence down continuously, not at promotion time. Will Larson's guide to promotion packets at StaffEng suggests treating the packet as a running record you begin long before you expect to need it, with sections for staff-level projects, organizational improvements, quantified impact, mentorship, and, notably, glue work with its impact stated, plus advocates and honest gaps. Notice that glue work has its own heading there. It is not hidden; it is counted, and it is one section among several, not the whole document.

One caution for leaders reading this. If you run a team, you are part of the problem when glue falls to whoever volunteers. Reilly's advice to managers is to make glue work visible, track it, share it deliberately, credit it publicly as leadership rather than "helping," and check whether your job ladder actually requires the skills your senior people use. If your ladder says "technical depth" and your best people win by coordinating, the ladder is lying to them.

Try this week. Sort your last quarter of coordination work into the four boxes above, one line per item, on a single page. Then pick one item from "counted and personal" and make it durable (write the runbook, train a second person, or turn it into a template), and one item from "durable and uncounted" and go find its number. Bring the page to your next 1:1 and ask your manager which box they think your promotion case lives in.

Method — The Brag Document (Julia Evans, 2019)

What it is. A running, private-by-default record of what you accomplished and why it mattered, kept so you do not depend on your memory or your manager's. Julia Evans described it in a June 2019 post.

When to use it. From now on, and especially before a review cycle, after a manager change, or whenever you are weighing a promotion or a move. It is the raw material for a promotion packet.

How to run it:

1. Create one document and give it the headings Evans suggests: goals, projects, collaboration and mentorship, design and documentation, company building (hiring, interview and onboarding improvements), what you learned, and outside-of-work contributions such as talks and writing.
2. Put a recurring reminder in your calendar. Evans does a yearly marathon, and some people update every two weeks. Biweekly is easier to sustain.
3. For each entry, write the impact and not just the activity. Add numbers where you can, and return months later to update the result.
4. Include the fuzzy work (code quality, process improvements, glue) and tag each item with its box from the glue portfolio: counted and durable, counted and personal, and so on.
5. Share it with your manager before reviews and give it to peer reviewers to jog their memory. Once a quarter, read it back to see which themes you want more of.

When NOT to use it. Do not treat it as a trophy case or inflate it; Evans' own advice is that you do not need to make your work sound better than it is, just exactly as good as it is. And do not use it as a substitute for a direct conversation with your manager about what the next level requires.

One-line example: a TPM who logs "ran weekly sync" for a year has a diary; a TPM who logs "replaced the weekly sync with a decision log, cutting the program's open-decision backlog from 31 to 9, now used by two other programs" has a promotion case.

Field Notes

Avoiding the Glue Trap: Recognizing and Rebalancing Non-Promotable Work — Fatima Taj's warning signs and manager-conversation framing in Visual Studio Magazine (David Ramel, Dec 2025); qualitative, with no survey data, but the checklist is practical for TPMs.

Promotion packets (StaffEng) — Will Larson's guide to a running packet, with an explicit section for glue work and another for honest gaps; read it before your next calibration cycle.

How to get promoted beyond staff engineer (LeadDev) — A 2024 LeadDev panel with Blanca Garcia Gil moderating on advancing within staff+; the page is a registration gate, so treat it as a pointer to the topics, not a source of claims.

Events

• Oct 21 · Prove your AI gains, then improve them (LeadDev webinar) — a vendor-hosted session on measuring AI agent adoption and outcomes; useful for making your own impact countable.
• Nov 9–10 · LeadDev Berlin — two days in Berlin for engineering leaders, at the Estrel Congress Center.
• Nov 16–18 · QCon San Francisco — practitioner-led software conference with tracks on AI systems and architecting for agents.

Reading

• Being Glue · Tanya Reilly — the original talk write-up on why coordination work goes unrewarded and what individuals and managers can do.
• Brag documents · Julia Evans — the source for this issue's Method, with a template and the case for keeping one.
• Where Is Technical Program Management Heading in 2026? · Aadil Maan — predictions for the TPM role; read it as informed speculation, not forecast.

"Just make it sound exactly as good as it is."

— Julia Evans, "Brag documents" (2019)