Glue Work: How to Get Credit for the Work That Holds the Team Together

Glue work is the term Tanya Reilly gave to the connective tissue of a team: writing the doc nobody else would write, running the meeting that finally aligns two groups, onboarding the new hire beyond the official checklist, mentoring the junior through their first incident. It is necessary, often senior-level work. It is also the work most likely to be invisible at review time — not because managers do not value it, but because nobody created a record of it happening. This is not an essay about whether glue work should count. It should. This is a system for making sure it does.

What is glue work

Glue work is any contribution that makes a team function but does not produce a shippable artifact with your name on it. Writing the design doc that aligns three teams, facilitating the meeting that unsticks a stalled decision, onboarding a new teammate beyond the checklist, translating between technical and non-technical stakeholders, maintaining the wiki everyone uses but nobody updates. The work is real, necessary, and often requires senior-level judgment. The problem is not that the work is unimportant. The problem is that it is invisible to every system that decides what you are worth.

Tanya Reilly's talk on glue work identified the core failure: organizations reward artifacts and punish the labor that makes artifacts possible. The engineer who mentors a junior teammate into shipping their first feature gets no credit for the mentoring — the feature ships under the junior's name. The PM who aligns stakeholders before the kickoff gets no credit for the alignment — the project launches under the team's name. Glue work is load-bearing and uncredited by default.

Why glue work disappears from reviews

Three structural reasons, none of which are your manager's fault.

• No artifact trail. Shipped features leave PRs, docs, and launch posts. Facilitation, mentoring, and context-sharing leave nothing in any system your manager checks when writing your review.
• The credit attaches to the output, not the enablement. When the junior engineer ships, the git log says they shipped. When the cross-team project launches, the project tracker says the project launched. The enablement work that made both possible is not recorded anywhere.
• Calibration happens from memory. Your manager walks into a calibration meeting and argues your case from what they can remember. If your work left artifacts, they remember it. If your work left conversations, they remember a vague sense that you were helpful — which translates to 'steady contributor,' not 'exceeds expectations.'

Categories of glue work

Facilitation and alignment

Running the meeting that unsticks a decision. Aligning stakeholders before the kickoff so the kickoff is productive. Mediating between two teams with conflicting priorities. This work requires judgment about timing, framing, and sequencing — senior-level skills that produce no artifact unless you create one.

Documentation and knowledge management

Writing the runbook nobody else would write. Updating the wiki after the process changed. Creating the onboarding guide that makes the next five hires ramp faster. The documentation itself is an artifact, but authorship credit fades fast — within a quarter, the doc is just 'the doc,' not 'the doc Sarah wrote.'

Mentoring and teaching

Pairing with a teammate on a problem they cannot solve alone. Reviewing a colleague's promotion packet. Teaching a new tool or process to someone who would otherwise spend a day figuring it out. The learner's output improves; the teacher's contribution has no artifact.

Translation and context-sharing

Explaining a technical decision to a non-technical stakeholder. Translating customer feedback into an engineering problem statement. Sharing institutional knowledge that prevents a team from repeating a known mistake. Context decays the fastest of any work product — it exists in the moment and evaporates within hours.

The documentation system for glue work

The system has three parts: capture, surface, and include. Each part takes less than five minutes and together they close the gap between doing glue work and getting credit for it.

Capture: one line per incident

When the glue work happens — immediately after the meeting, the pairing session, the context share — write one sentence in your career journal: what you did, who was affected, and what changed. Not polished. Not framed for an audience. Just the record, written while the names and outcomes are still fresh. Two examples:

• 'Facilitated the payments/platform sync. Outcome: shared schema locked, unblocked both teams for Q3.'
• 'Paired with James on the event-sourcing migration for 2 hours. He shipped the first consumer independently and can do the remaining four solo.'

Surface: name it in your 1:1

Once a week, pick the strongest glue work entry from your journal and mention it in your 1:1 with your manager. Not as self-promotion — as a status update. 'I spent Tuesday aligning the payments and platform teams on the shared schema. Both are now unblocked for the quarter.' You are giving your manager a data point they would not otherwise have. Most managers actively want this.

Include: write it into your self-review

At review time, pull your glue work entries and write them with the same structure as any other contribution: situation, action, outcome. The key addition for glue work is the counterfactual — what would have happened without your intervention. 'Without the stakeholder alignment before kickoff, the project would have opened with conflicting requirements from three teams' is the sentence that makes the glue work legible to a calibration committee.

When glue work becomes a career risk

There is a version of this problem that documentation alone does not fix. If you are doing so much glue work that you do not have time for the shippable work your role is measured on, the documentation will show a pattern your manager should see — a pattern of high-value team contribution coupled with declining individual output. That is a conversation worth having explicitly: either the glue work should be recognized as part of your role, or it should be redistributed so you can do the work your level requires.

The journal makes this conversation possible because it provides the evidence. Without the record, the conversation is 'I feel like I am doing a lot of invisible work.' With the record, the conversation is 'Here are fourteen specific instances of glue work in the last quarter. They total roughly two days a week. I want to discuss whether this is part of my role or whether we should redistribute it.'

Who should and should not do glue work

Everyone does some glue work. The question is whether it is recognized, distributed, and priced correctly. Senior ICs doing glue work are demonstrating scope and leadership. Junior ICs doing glue work are sometimes demonstrating initiative and sometimes being exploited by a team that does not value their time. The journal helps you see which one it is — because the pattern over three months tells a story that any individual week cannot.

If your journal shows that you are spending more than 20% of your time on glue work that is not in your role description, that is a signal. Document it, name it, and bring it to your manager with a specific proposal: formalize it, redistribute it, or compensate it. The record gives you standing to have that conversation.

The system is small: capture the glue work in the moment, name it in your 1:1, and include it in your self-review with evidence. Glue work does not become visible by being done harder. It becomes visible by being documented — and the documentation takes sixty seconds per incident. That is the gap between 'steady contributor' and 'the person who holds this team together.'