The Engineer's Guide to Glue Work: Making Invisible Contributions Visible for Promotions and Resumes
The Engineer's Guide to Glue Work: Making Invisible Contributions Visible for Promotions and Resumes
Glue work is career-making if it's visible. It's career-ending if it stays invisible.
Here's a pattern that plays out silently at most engineering orgs: one senior engineer ships features, closes tickets, and has a clean, easily auditable output. Another senior engineer unblocks three teammates a week, reviews every design doc before it goes sideways, onboards every new hire, notices and fixes the broken CI pipeline nobody else stopped to fix, and coordinates the cross-team dependency that lets everyone else ship on time.
In twelve months, the first engineer gets promoted. The second one gets feedback that their "technical impact wasn't clear enough."
The difference isn't output. It's legibility.
This post is about the second engineer — and how to stop being them.
What Is Glue Work?
The term was coined by Tanya Reilly in her 2018 talk "Being Glue," which has since become one of the most widely shared pieces of writing in engineering career conversations. Reilly, a former 12-year Google SRE and now a Principal Software Engineer at Squarespace, defined it simply: glue work is the essential, often invisible work that holds teams together but doesn't map cleanly to traditional promotion criteria.
The canonical examples:
- Code review — doing thorough, consistent reviews that meaningfully improve quality and unblock teammates
- Mentoring — pairing with junior engineers, answering questions, reviewing implementation plans before they become expensive mistakes
- Onboarding — writing the runbooks, shepherding new hires through their first quarter, being the person people ask when they're lost
- Cross-team coordination — tracking the dependency that two teams haven't noticed they both need, running the sync that gets the shipping order right
- Process improvement — noticing the broken deploy script and fixing it, proposing the postmortem format that actually prevents recurrence, setting up the Slack channel that replaces three recurring meetings
- Documentation — writing the ADR no one was going to write, keeping the README accurate, capturing the architecture decision before the person who made it leaves
Reilly's key observation: most of this work, done well, is indistinguishable from nothing happening. Your mentee doesn't escalate a problem because they learned to solve it. The cross-team handoff goes smoothly because you spent two hours in advance ensuring it would. The production incident doesn't happen because you noticed the edge case in code review.
The engineering performance review system is largely built to measure incidents, not prevented ones.
The scale of the problem is larger than most engineers realize. A 2025 study published in the ACM Proceedings on Human-Computer Interaction, co-authored by researchers at Google, Cornell, and Northeastern, found that roughly 50% of software development work is invisible — observable to at most one other person. Roughly two-thirds of tasks reported by developers in the study were invisible. The study's categories of invisible labor map almost exactly to Reilly's glue work list: code review, writing tests, mentoring newcomers, answering questions, and managing project norms.
The Career Risk Is Real — But Misunderstood
Reilly's warning that "doing glue work too early can be career limiting" gets quoted a lot. It's often misread as "glue work is bad." That's wrong.
The actual claim is more precise: glue work done invisibly and disproportionately will stall your career, regardless of its real impact. Glue work done deliberately, documented carefully, and recognized explicitly is some of the most promotable work in engineering.
Will Larson, author of An Elegant Puzzle and one of the primary architects of staffeng.com, describes the problem as one of legibility. Promotions reward legible impact — shipped features, resolved outages, measurable changes. Glue work often has low legibility by design: when it works, nothing goes wrong. When nothing goes wrong, performance systems register... nothing.
The staff engineer promotion packet template on staffeng.com explicitly asks: "What glue work do you do for the organization, and what's the impact of that glue work?" That question exists because the default is to not answer it — and therefore to not get credit for the answer.
One more wrinkle worth naming: research consistently shows glue work is not distributed evenly. A peer-reviewed study in the American Economic Review by economists at Carnegie Mellon and Pittsburgh found that women in professional workplaces do approximately 200 more hours per year of non-promotable work than men — roughly a full month's extra labor that doesn't show up in promotion conversations. Both male and female managers were found to be 44% more likely to assign non-promotable tasks to women. The engineering industry is not an exception. Engineers who are good at glue work, thorough communicators, and skilled at unblocking others tend to attract more requests for it — often without any corresponding career recognition.
The distinction that matters isn't whether to do glue work. It's whether you're doing glue work that:
- Creates genuine organizational leverage
- Is documented and visible to the people who make promotion decisions
- Is balanced with technically legible output — not replacing it
The Two Types of Glue Work
Not all glue work is equal. A useful mental model: glue work exists on a spectrum from high leverage and promotable to low leverage and career-limiting, and the position on that spectrum is determined not by the type of work but by whether it multiplies others' output and whether it's visible.
High-leverage glue work:
- Code review that meaningfully raises quality or catches architectural issues, not just style nits
- Mentoring that results in a junior engineer reaching independent ownership faster
- Design review that prevents a multi-week rework
- Cross-team coordination that unblocks a critical path dependency
- Writing the RFC that gets adopted by three teams and sets a standard
Low-leverage glue work (the career quicksand):
- Taking notes in every meeting because no one else will
- Scheduling coordination that doesn't require your specific knowledge or judgment
- Answering the same question repeatedly without building a resource that eliminates the question
- Being the default "ask anyone" person because you've trained your team to rely on your availability rather than on documentation or processes you've built
The second category isn't worthless — it has to happen — but it's not promotable, it's not scalable, and it takes time away from work that is. The goal isn't to stop doing glue work. It's to shift your glue work profile toward the high-leverage tier and document it so others can see it.
How to Document Glue Work for Promotion Packets and Resumes
The documentation problem is real: most engineers keep a decent record of features shipped and bugs fixed, because those have tickets and PRs. Glue work often lives in Slack messages, calendar invites, and institutional memory that disappears when you switch jobs.
Here's the system that works.
Track it in real time
The brag document is the standard tool, and it works for glue work exactly as it does for code output — but only if you're disciplined about capturing glue work at the same cadence as technical work. Julia Evans, whose canonical brag document post is one of the most widely shared pieces of engineering career writing, is explicit: "Glue work like helping peers and responding to incidents is all valuable to the business, so it belongs on your brag doc. It's easy to remember the big feature launches, but don't forget the glue work that often flies under the radar."
Every week, for each significant piece of glue work, write three things:
- Before state: What was the situation?
- Action: What did you do, specifically?
- After state: What changed, and how does that connect to a business or team outcome?
Vague entries are useless. "Did a lot of mentoring this quarter" means nothing to a promotion committee. This entry means something:
Mentored two junior engineers (one backend, one full-stack) through their first major feature ownership. Conducted weekly implementation plan reviews before coding began, paired on two debugging sessions, and built a reusable testing pattern they now use independently. Reduced direct escalations from 6/week to 2/week by Q3.
That entry has a before state, a specific action, and a measurable after state. It shows organizational leverage. It can be cited in a promotion packet and defended in a calibration conversation.
Categorize by impact type, not work type
Promotion packets are evaluated against career ladders, and most career ladders measure impact across dimensions: technical quality, organizational impact, mentorship and growth, and cross-team influence. Map your glue work to those dimensions before you write the packet.
A code review that caught an architectural issue that would have required a two-week rework: technical quality, organizational impact.
Onboarding a new engineer who reached independent ticket ownership in 6 weeks vs. the team's usual 10: mentorship and growth, organizational velocity.
Coordinating the cross-team dependency that let three teams ship a project two weeks early: cross-team influence, organizational impact.
This mapping step turns a pile of activities into a narrative that fits the structure reviewers are actually using.
Make it visible to the decision-makers before review
The worst time to reveal your glue work is during the promotion packet submission. By then, the people writing your packet have already formed an impression of your impact, and a list of activities they didn't know about will read as post-hoc rationalization rather than evidence.
The engineer's internal promotion playbook covers this in detail, but the core tactic is simple: share what you're working on and what impact it's having in your regular 1:1s, in team updates, and in your manager's preferred format — before review cycles, not during them.
A weekly 5-line update to your manager that includes "finished the onboarding doc for the payments service; Sam was able to set up the dev environment in 2 hours instead of the usual full day" is more valuable to your career than including the same note in a performance review packet six months later.
Framing Glue Work on a Resume
Resumes have an additional constraint: space. The framing principles are the same as for promotion packets, but the format needs to be even tighter.
Two patterns that work for resume bullets:
The impact-first bullet:
Reduced new engineer ramp time from 10 to 6 weeks by building a team onboarding guide and standardizing the development environment setup — adopted across 3 teams.
The multiplier bullet:
Mentored 4 junior engineers to independent feature ownership; team's ticket throughput increased 40% YoY without additional headcount.
Both follow the resume bullet formula: action verb, what you did, measurable result. Neither says "glue work." Neither needs to. The evidence speaks for itself.
For engineers applying to senior or staff roles, resume bullets about code review, mentoring, and cross-team coordination are not filler — they're often the differentiating signal. A hiring manager reading 20 resumes of engineers who shipped features will notice the one who also made their entire team ship features better.
When to Stop Doing Glue Work
Reilly's original talk includes advice that gets quoted less: at some point, you should deliberately stop doing certain kinds of glue work, especially the career-quicksand variety.
There's a structural reason most engineers accumulate glue work over time: they're good at it, they care about team health, and no one else steps up. The result is an engineer who is genuinely, substantively valuable to the team — and who isn't getting promoted because their output profile looks like a support function, not a technical leadership track.
A few situations where pulling back is the right call:
If you're the default note-taker in every meeting. Once. Ask someone else to take the next set of notes. If no process exists for rotating this, propose one. If you're the only person who will do it, you've found a team culture problem, not a you problem.
If you're answering the same question more than twice. The third time someone asks you how to configure the local dev environment, the answer isn't to answer it again. It's to write the documentation that makes the question unnecessary and point people there.
If your glue work isn't being acknowledged in review cycles. This is the signal that you're in the career-limiting zone. The right conversation to have with your manager: "I've been doing X, Y, and Z to support the team. I want to make sure that work is visible and is being factored into my performance evaluation. Can we talk about how to make it more legible?" If the answer is "we don't count that," you now have critical information about whether you'll ever be promoted at this company for doing the work you're doing.
The Manager's Role (And What to Do When They Don't Play It)
The dirty secret of glue work is that its visibility is almost entirely a management problem. Engineers can document their impact, track their mentoring, and frame their work for promotion packets — but if their manager doesn't understand that coordinating a cross-team dependency is a promotable skill, the packet won't matter.
Will Larson's writing on glue work describes a simple reframe for engineering managers: instead of asking "what did this engineer build?" as the primary performance question, ask "what would have broken or slowed down without this engineer?" That question surfaces glue work naturally, because the answer is almost always about coordination, quality enforcement, and knowledge transfer rather than features.
For engineers whose manager doesn't make this reframe naturally:
Name the work explicitly. Don't assume your manager knows what you're doing or that they'll ask. In your next 1:1, say "I want to walk you through some of the team-support work I've been doing this quarter and make sure you have visibility into it." Then walk through it, with the before/action/after framing.
Get peer testimony. The staffeng.com promotion packet template includes a "who can speak to this work?" section. Engineers whose work is primarily glue work should have 2–3 colleagues who can specifically describe what the mentee learned, what the coordination unblocked, what the code review caught. That testimony, in a calibration conversation, carries weight that self-reported documentation alone does not.
Connect it to business outcomes. "I mentored four engineers" is weak. "I mentored four engineers; the team shipped 40% more tickets this quarter without adding headcount" is strong. Managers can advocate for work they can connect to business outcomes. They struggle to advocate for work that sounds like team hygiene.
TL;DR
- Glue work is real work, and it can be highly promotable — but only if it's visible and documented. Left invisible, it stalls careers regardless of actual impact.
- Shift toward high-leverage glue work. Code review that catches architectural issues, mentoring that produces independent engineers, cross-team coordination that unblocks critical paths — these are promotable. Note-taking and answering repeated questions are not.
- Document in real time, with before/action/after framing. "Did a lot of mentoring" doesn't appear in a promotion packet. "Mentored two engineers to independent ticket ownership in 6 weeks, reducing my escalation load by 70%" does.
- Map your glue work to the career ladder dimensions your company uses — technical quality, organizational impact, mentorship and growth, cross-team influence. That mapping is what turns activity into evidence.
- Make your manager your ally, not your evaluator. Surface glue work in 1:1s, not just in performance packets. Build peer testimony from the engineers whose work you've multiplied.
- Know when to pull back. If your glue work isn't being recognized, have the explicit conversation with your manager. If it's still not being recognized, you're learning something important about whether this company will ever promote you for the work you're actually doing.
The engineers who make staff aren't always the ones who wrote the most code. They're often the ones whose teams consistently shipped more than anyone expected, with fewer incidents, and with junior engineers who grew faster than average. That's a set of outcomes. Glue work is frequently the cause. Your job is to make the causal arrow visible.
Related: The Engineer's Brag Document Guide — the tool for capturing glue work impact across the year, not just at review time.
Related: The Engineer's Internal Promotion Playbook — how to build the case for promotion, including the glue work that doesn't appear in your commit history.
Related: Technical Writing for Engineers: How READMEs, Design Docs, and RFCs Accelerate Your Career — the written artifacts that transform glue work into organizational evidence.
Wrok builds your professional profile from your GitHub history, work experience, and technical contributions — including the cross-team coordination, mentoring, and review work that never makes it into a commit. Start telling the full story of your engineering career. Try it free →