20 Examples of Invisible Work That Disappear From Reviews

Invisible work is not a metaphor. It is a category of contribution that produces no artifact a manager can point to when someone asks what you did. The pull request is visible. The three conversations that made the pull request possible are not. The launch is visible. The stakeholder alignment, the support FAQ, the rollback plan you wrote at 10pm — invisible. This is a catalogue of twenty specific examples, organized by why they disappear, each paired with the one-line journal entry that prevents them from disappearing.

Why invisible work disappears

Work becomes invisible through three mechanisms. The most common: no artifact was created. The Slack thread expires, the meeting ends without minutes, the hallway conversation produces a decision but not a record. The second mechanism: the artifact exists but lives in someone else's namespace. You wrote the support FAQ but the support team published it. You fixed the flaky test but the CI dashboard just shows green. The third mechanism: the work is defined by absence. You prevented the outage, resolved the conflict before it escalated, caught the bug before it shipped. Prevention leaves no trace because its success is that nothing happened.

All three mechanisms share a single fix: someone creates a record. That someone is you, because no one else has the incentive or the context to do it.

Glue work examples

Glue work holds teams together. It is the connective tissue between the work that gets tracked. The term comes from Tanya Reilly, and it names a category that most organizations reward in speeches and punish in calibrations.

• Writing the design doc nobody else was going to write. — The doc gets cited; your authorship does not. Journal entry: 'Wrote the auth-migration design doc. Three teams are using it as the reference for their implementations.'
• Running the cross-team sync that finally aligned two engineering groups. — The alignment is visible; the facilitation is not. Journal entry: 'Facilitated the payments/platform sync. Outcome: shared schema locked, unblocked both teams for the quarter.'
• Onboarding a new hire beyond the official checklist. — They ramp faster; no one traces it back to you. Journal entry: 'Spent 3 hours with Maya on her first PR. She shipped it same-day without a follow-up review cycle.'
• Translating between technical and non-technical stakeholders in a meeting. — The meeting goes well; your translation work is invisible in the notes. Journal entry: 'Translated the latency trade-off for the sales team in the product review. They dropped the feature request that would have added 400ms to checkout.'
• Cleaning up the shared codebase, documentation, or wiki without being asked. — Entropy decreases; nobody notices. Journal entry: 'Reorganized the API docs wiki. Three people messaged me this week saying they found what they needed without asking in Slack.'

Prevention work examples

Prevention is the purest form of invisible work. Its success is that the bad thing did not happen. No one thanks the person who prevented the outage — they thank the person who fixed the one that slipped through.

• Catching a bug in code review before it shipped to production. — The bug never existed in production, so no incident report credits the catch. Journal entry: 'Caught a race condition in the payment retry logic during Amir's PR review. Would have double-charged ~2% of retries.'
• Flagging a scope risk early enough that the project plan adjusted. — The project shipped on time; nobody remembers why the scope changed. Journal entry: 'Flagged the third-party API migration as a 3-week risk in sprint planning. PM rescoped launch to exclude it. We shipped on schedule.'
• Updating a runbook before someone needed it during an incident. — The incident response goes smoothly; no one attributes it to the updated runbook. Journal entry: 'Updated the database failover runbook with the new replica topology. Next oncall will have the correct procedure.'
• Monitoring a deploy and catching a regression before customers noticed. — The revert happens quietly. The deploy log shows green. Journal entry: 'Noticed error rate spike 8 minutes post-deploy, reverted before any customer reports. Root cause: missing index on the new query.'

Mentoring and teaching examples

Mentoring produces visible outcomes in someone else's name. The junior engineer ships the feature; the senior engineer who taught them how does not appear in the commit history.

• Pair-programming a junior teammate through a complex problem. — They learn, they ship, and the credit attaches to the shipper. Journal entry: 'Paired with James on the event-sourcing migration for 2 hours. He shipped the first working consumer and can now do the remaining four independently.'
• Giving feedback on someone's promotion packet or self-review. — Their review improves; your contribution is invisible. Journal entry: 'Reviewed Priya's promotion packet. Rewrote the technical-leadership section to foreground the system-design work she undersold. She submitted it today.'
• Teaching a non-obvious tool, process, or internal system to someone new. — They become productive faster; the teaching moment has no artifact. Journal entry: 'Walked the new PM through our metrics pipeline. She can now pull her own data instead of filing a ticket with the data team.'
• Giving hard feedback privately that changed someone's approach. — The behavior changes; nobody knows why. Journal entry: 'Gave direct feedback to Alex about the deployment cadence. His next release went through staging first — first time in three sprints.'

Context-sharing and coordination examples

Context is the most perishable form of work product. You shared it once in Slack, the thread scrolled off the screen, and now the context lives only in the memory of the people who were online at the right time.

• Answering a question in Slack that saved someone a day of investigation. — The questioner moves on; the answer sinks. Journal entry: 'Answered the deploy-pipeline question in #platform-eng. Saved three engineers from debugging a known issue with the new CI runner.'
• Connecting two people who needed to talk but did not know each other existed. — The connection produces value; your role in creating it vanishes. Journal entry: 'Connected Sarah (data team) with the mobile oncall after realizing they were debugging the same anomaly independently. Fixed in 2 hours instead of 2 days.'
• Sharing institutional knowledge during a meeting that changed the decision. — The decision was correct; nobody records whose input made it so. Journal entry: 'Mentioned the 2024 incident with the rate limiter during the architecture review. Team chose the safer migration path.'
• Writing the follow-up summary after a meeting where no one took notes. — Everyone benefits; the note-taker is not credited. Journal entry: 'Wrote the action items from the quarterly planning meeting. 14 people got clear next steps instead of leaving with different memories of what was decided.'

Customer and stakeholder work examples

• De-escalating a customer issue before it became an executive escalation. — The crisis did not happen. Nobody thanks the person who prevented it. Journal entry: 'Called the enterprise account directly after their ticket sat for 6 hours. Resolved the config issue on the call. Account renewed the next week.'
• Running a demo or workshop that was not part of your formal job responsibilities. — The sales team closed the deal; your name is not on the opportunity. Journal entry: 'Ran a live product demo for the healthcare prospect. Sales closed $180K ARR the following week and cited the demo as the tipping point.'
• Handling weekend or off-hours support that nobody else saw. — The customer was happy Monday morning; the weekend work is invisible. Journal entry: 'Resolved the API timeout for FinCo at 9pm Saturday. Their batch job completed on time. No Monday escalation.'

How to recover invisible work in your journal

Every example above includes a one-line journal entry. The format is intentional: what you did, who was affected, and what changed because of it. Three components, one or two sentences, written in the moment. That is the entire system.

The journal entry does not need to be polished. It needs to exist. Six months from now, when your self-review is due, the difference between 'I think I helped with onboarding' and 'I paired with Maya for three hours and she shipped independently after that' is the difference between a vague claim and a specific example a manager can take into a calibration room.

None of these examples are exotic. All of them happened in your last quarter. The difference between the people who get credit and the people who do not is a documentation habit — not the work itself. One line per incident, captured in the moment, is enough to turn invisible work into evidence that survives a review cycle.