Glue Work: The Invisible Effort That Actually Ships Products
Most software gets built through work that never hits a Jira ticket. This “shadow work” – mentoring others, cleaning up messy code, and aligning teams – is the real engine behind every release. While leaders often focus only on new features, ignoring this invisible labor leads straight to burnout and technical debt. If you don’t track the work that holds everything together, the whole system eventually falls apart.
The Bottom Line Up Front
Shadow work is the “invisible iceberg” of software engineering. Research suggests that roughly 50% of all work in technical ecosystems is invisible to at least one other person. For the individual developer, performing too much shadow work without a strategy for visibility results in career stagnation. For the organization, ignoring this work leads to “hidden capacity loss,” where teams appear to have full bandwidth but are actually spending up to 40% of their time on unrecorded tasks. Transitioning from “accidental glue” to “intentional glue” requires a shift in both individual documentation and organizational recognition systems.
Defining the Shadow: Two Faces of Invisible Work
The term “shadow work” functions on two distinct planes within the engineering context. One is rooted in analytical psychology, focusing on the individual’s unconscious patterns. The other is a practical technical concept centered on the “glue” that holds teams together.
Your “Shadow”: The Hidden Habits Stalling Your Career
In psychology, your “shadow” consists of the parts of yourself you ignore or hide. In a high-pressure tech job, this usually shows up in three ways:
- The Impossible “No”: You want to be the helpful team player, so you never turn down a request. You end up buried in “busy work” that doesn’t get you promoted.
- Playing Small: You have the talent to lead or make big architectural decisions, but you hide behind your code because it’s safer than being the person in charge.
- The Blame Game: When you get angry at coworkers who log off on time or set strict boundaries, it’s usually because you’re jealous of their ability to do what you can’t.
The Technical Shadow (Glue Work)
In software engineering, the shadow is the work that keeps the project running but isn’t a “feature.” Tanya Reilly popularized the term “glue work” to describe these essential but often non-promotable tasks. This includes:
- Technical Risk Detection: Noticing architectural flaws early and facilitating the discussions to fix them before they become production incidents.
- Documentation and Onboarding: Writing the guides that allow the next hire to be productive.
- Mentorship: Answering ad-hoc questions and unblocking junior developers.
| Feature | Psychological Shadow Work | Technical Shadow Work (Glue Work) |
|---|---|---|
| Primary Origin | Personal unconscious and repressed traits. | Tasks absent from roadmaps and ticket systems. |
| Visibility | Hidden from the individual’s own awareness. | Invisible to managers and stakeholders. |
| Goal | Wholeness and emotional regulation. | Team cohesion and system stability. |
| Consequence of Neglect | Emotional fatigue. | Burnout, attrition, and technical debt. |
The Taxonomy of Invisible Labor in IT
To manage shadow work, one must first categorize it. It is not a monolithic block of “extra tasks” but a varied set of work that consume cognitive energy.
Technical Glue Work and System Maintenance
The most common form of shadow work is the work required to keep a codebase healthy. This is often the result of “Bit Rot,” where software degrades over time due to neglect.
- Incident Support: Investigating alerts, managing error logs, and fixing issues that are too small to create a formal ticket but too critical to ignore.
- Refactoring: Cleaning up “dirty hacks” written at 2 AM to solve a production crisis.
- Infrastructure Reconciliation: Manually adjusting configurations in a cloud console because the Infrastructure-as-Code (IaC) pipeline was broken or incomplete.
People Work: The Unseen Effort That Keeps Teams Running
Relational labor is the mental energy you spend managing people and team dynamics. It’s essential, but it rarely shows up on a performance review:
- Mentoring & Pairing: You spend hours on deep code reviews or teaching others. This helps the team grow, but it makes your own “output” look lower on paper.
- Managing Stakeholders: You act as a translator, turning complex technical risks into business terms that managers and executives can actually understand.
- Building Consensus: You run the meetings and side-chats needed to get everyone aligned on a single architectural path so the project doesn’t stall.
The Three Types of Shadow Work
| Category | Description | Impact of Invisibility |
|---|---|---|
| Production Support | Investigating alerts, ad-hoc fixes, error monitoring. | Recurring problems; skipped quality steps. |
| Technical Glue | Code reviews, mentorship, documentation. | Undervalued; creates bottlenecks for seniors. |
| Shadow Backlog | Off-the-record fixes and improvements. | Creeping misalignment; trust erosion. |
Is Shadow Work Good or Bad?
The consensus among engineering leaders is that shadow work is essential for the team but dangerous for the individual.
The “Good”: Team Health and Stability
Shadow work acts as the connective tissue of a team. Without it, software projects often collapse under the weight of their own complexity.
- Risk Mitigation: Glue work detects systemic risks before they materialize as outages.
- Team Velocity: By unblocking others and improving documentation, a “glue” person can increase the total output of the team even if their personal commit count is low.
- Culture Building: Mentorship and collaboration build a culture of shared ownership.
The “Bad”: Career Detours and Burnout
The primary risk of shadow work is that it is often non-promotable. If a developer spends 80% of their time on glue work, they may be viewed as “not technical enough” or “underperforming” compared to peers who focus solely on features.
- Promotion Barriers: Performance reviews often rely on documented impact. Invisible work rarely counts toward career progression.
- The “Irony of Glue”: If an engineer is good at glue work, they are naturally asked to do more of it, which further sidelines their technical growth.
- Burnout: Sustained cognitive and emotional load without recovery leads to exhaustion. Because the work is invisible, others may not understand why the developer is tired.
The Scars of Shadow Work: Technical Debt and Failure
Engineers trust failure stories more than success stories. The “scars” of shadow work are the technical debts and production failures that occur when invisible labor is ignored or performed poorly.
Configuration Debt: The Ticking Time Bomb
One of the most dangerous forms of shadow work is manual infrastructure adjustment. When a developer changes a security group in the AWS Console without updating the Terraform state, they are creating a “ticking time bomb”. The next person to run the deployment pipeline will encounter a failure, and the hours spent debugging this “spaghetti infrastructure” will become another layer of shadow work.
The Doctrine Query and the Dirty Hack
Consider the “Doctrine query” that brought down production because it was written as a “dirty hack” to meet a deadline. The shadow work here involves the hours spent tracing the performance issue back to a misunderstanding of memoization or database indexing. If the team’s culture discourages refactoring, these hacks accumulate until simple changes that should take 20 minutes turn into day-long investigations.
The Kitchen Analogy of Bit Rot
Software degradation can be compared to a kitchen. If one cooks a five-course meal (a new feature) but never washes a pan (shadow work/refactoring), eventually the kitchen becomes unusable. Bit rot is the symptom of this neglect. It happens when teams fail to “tidy up” as they go, leading to a monolith where every patch breaks something in an unrelated module.
Strategies for Visibility: How to Make Everyone Aware
To survive shadow work, a developer must shift from “accidental” to “intentional” glue. This involves strategic narrative management and documentation.
The “Brag Document” (Work Log)
The most effective tool for making invisible work visible is a continuous work log. This document should record every achievement and its impact.
- Log Specifics: Include key code changes, pull requests, code reviews, design documents, and instances of helping others.
- Quantify Impact: Instead of saying “I helped with the rollout,” say “Coordinated a complex rollout that unblocked the deprecation of the monolith, reducing risk for future migrations”.
- Share with Management: Regularly present the progress to the manager to ensure they are aware of contributions that don’t show up in automated reports.
Reframing Language
Quiet engineers often downplay their expertise. To be noticed, one must reframe their communication.
- Stop saying: “This may not be right, but…” or “I haven’t looked into this much…”.
- Start saying: “Another approach could be…” or “My initial thoughts are…”.
- Speak Early: Aim to be the second or third person to contribute in a meeting. Speaking within the first 10 minutes decreases anxiety and establishes presence.
Mastering Asynchronous Communication
In a remote-first world, written records are lasting evidence of intellectual contribution.
- Follow-ups: Send detailed follow-up notes after meetings with insights.
- Technical Blogs and Docs: Volunteer for writing technical specs and design documents. These are often viewed as “architect work” and are highly promotable.
- Public Channels: Contribute thoughtfully in Slack channels where the entire organization can see the expertise.
Organizational Shifts: Dealing with the Shadow Collectively
Engineering leaders must build systems that recognize shadow work at the organizational level. If infrastructure work is optional, it stays invisible. If it is built into the identity of the team, it becomes celebrated.
The “Prevented Disasters” Channel
Creating a dedicated Slack channel for “prevented disasters” allows engineers to share catastrophes that never happened because of their careful planning or intervention. This sends a powerful signal that the company values risk mitigation as much as feature delivery.
The Refactoring Budget
A formal refactoring budget reserves a fixed sprint capacity (e.g., 20%) for upgrades and debt remediation.
- Non-Negotiable Guardrails: Burn rates of error budgets can dictate when to pause feature work and focus on debt.
- Debt Register: Maintaining a “living debt register” with impact scores ensures that engineering and product are aligned on trade-offs.
Implementing an Automated Recognition System
Recognition should not be relegated to managers. Peer recognition systems (e.g., #wins channels) keep the culture human and ensure that small victories are celebrated.
| Practice | Organizational Impact | Individual Benefit |
|---|---|---|
| Refactoring Budget | Steady repayment of technical debt. | Reduces “burnout from maintenance”. |
| Wins Channel | Strengthens team connection and trust. | Immediate, public recognition for effort. |
| Rotational Roles | Prevents single point of failure (knowledge silos). | Ensures glue work is shared equitably. |
Tools and Approaches for Tracking Progress Without Manual Logs
Manual timesheets are widely hated by developers. They feel like surveillance and are often inaccurate. Modern “Engineering Intelligence” tools provide visibility without the “admin work.”
Engineering Analytics Platforms
Tools like Swarmia, LinearB, and DX integrate with Git, Jira, and CI/CD pipelines to automatically generate metrics.
- PR Cycle Time: Tracking how long it takes to complete code reviews allows teams to identify bottlenecks without manual tracking.
- Investment Distribution: These tools can show what percentage of time is spent on “New Features” vs. “Maintenance” vs. “Bug Fixes”.
- DORA Metrics: Measuring deployment frequency and lead time for changes provides an objective view of team velocity.
Automated PR Summaries and AI Agents
AI tools will generate much of the “how-to” code. The developer’s role will shift toward reviewing and arbitrating these outputs.
- CodeRabbit and Panto AI: These tools provide automated PR summaries, risk scoring, and line-by-line suggestions.
- Qodo (CodiumAI): Specializes in automated unit test generation and multi-repository understanding, reducing the “shadow work” of testing.
- GitHub Copilot PR Reviews: Summarizes changes to help reviewers understand “what” and “why” before they even look at the code.
The Chrono and Super Productivity Approach
For those who still need time tracking (e.g., for billing or tax credits), local and automated tools are preferred.
- Chrono Platform: Automatically categorizes work from Jira, Asana, and Slack to provide executive-level visibility into ROI and costs.
- Super Productivity: An open-source tool where the timer lives next to Jira/GitLab tasks. It treats time tracking as a “natural byproduct of doing work” rather than a separate activity.
Actionable Blueprint for Engineering Teams
When an Engineering Manager finishes this analysis, they should take immediate steps to address the shadow work in their team.
Retro Questions to Ask the Team
- “What was the most important thing you did last week that isn’t reflected in a Jira ticket?”.
- “Is there a specific piece of the codebase that you are afraid to touch? Why?”.
- “Who unblocked you this week, and how long did it take them?”.
- “What percentage of your time are you spending on ‘glue work’ vs. ‘feature work’?”.
The Shadow Work Audit Checklist
- [ ] Identify the “Glue”: List the people who are naturally doing the mentorship and coordination work. Are they being rewarded for it?.
- [ ] Standardize Documentation: Use tools like Range or Geekbot to run asynchronous standups that capture “how people are feeling” alongside what they are doing.
- [ ] Establish a Refactoring Budget: Dedicate 20% of the sprint to tech debt. If the error budget is exhausted, stop new features.
- [ ] Create a #Wins Channel: Start celebrating both customer outcomes and “invisible” technical wins.
- [ ] Deploy an Engineering Intelligence Tool: Move away from manual timesheets to an automated platform like Swarmia or LinearB.
