The Cost of Invisible Work

Invisible work is any effort the team is spending that isn't tracked in a shared system. It's more common than most teams admit, and it takes predictable forms:

• Slack-thread decisions. A 40-message thread between two engineers resolves a design question, but the decision never makes it into the ticket or the PR description. Six months later, someone reverses the decision because they didn't know it was made.
• "I'll just do it" tasks. An engineer notices a flaky test, spends two hours fixing it, and never creates a ticket. The work happened, the time was spent, but the team's capacity plan doesn't reflect it — and nobody learns from the fix.
• Side projects and spikes. Exploratory work that lives on a local branch, never gets reviewed, and either dies quietly or surfaces as a surprise PR three weeks later.
• Undocumented hotfixes. A production issue gets patched at 11 PM with a direct commit to main. No ticket, no post-mortem, no record that the fix exists or why it was necessary. The next engineer who touches that code has no idea what the three mysterious lines are protecting against.

None of these are malicious. Engineers do invisible work because the friction of tracking it feels higher than the cost of just doing it. And for any single instance, they're right — creating a ticket for a 20-minute fix feels like overhead.

The problem isn't any single instance. The problem is the pattern.

Invisible work doesn't stay cheap. It compounds in three ways that get more expensive over time.

Onboarding cost climbs. Every decision that lives in someone's head instead of in a ticket or a document is a decision a new team member can't find. A team with six months of invisible work requires a multi-week verbal download to onboard someone — and that download is incomplete, because the people giving it have forgotten half of what they did. Teams with high invisible-work loads routinely report onboarding times of 4–8 weeks for work that should take 2.

Work gets duplicated. When engineer A doesn't know engineer B already solved the same problem last month, engineer A solves it again. In a 10-person team, this happens more often than anyone realizes — particularly with infrastructure work, utility functions, and configuration changes that live outside the main product codebase.

Context evaporates. Code without a ticket trail is code without a "why." The next engineer who reads it sees what was done but not why it was done, which means they can't safely change it. They either leave it alone (accumulating tech debt) or change it and break the assumption the original author was protecting (creating a bug). Both outcomes are expensive, and both are preventable with a one-paragraph ticket description written at the time of the work.

The compounding is what makes invisible work dangerous. A single undocumented hotfix costs five minutes of context loss. A year of undocumented hotfixes costs weeks of archaeology every time someone touches that part of the system.