The Invisible Work Problem: Why Your Best Engineers Look Unproductive
Sarah was driving me crazy.
She'd been on my team for six months, and by every metric we tracked, she was underperforming. Fewer commits than anyone else. Tickets took her twice as long to close. In standups, she'd often say she was "still working on it" while others moved through their lists.
Then our senior engineer quit.
Within a week, everything started breaking. The build failed constantly. Nobody could figure out why the API was randomly returning 500s. The junior developers, who'd been shipping features left and right, suddenly couldn't get anything done.
That's when I realized what Sarah had been doing all along. She wasn't slow. She was doing invisible work.
The Hidden Enemies
Dominica Degrandis figured out something that most managers miss: knowledge work has five invisible enemies. Too much work in progress. Unknown dependencies. Unplanned work. Conflicting priorities. Neglected work.
Sarah was fighting all five. While others optimized for ticket velocity, she was preventing disasters that would have sunk the entire team.
She spent time mapping dependencies between systems. She investigated flaky tests before they became blockers. She helped junior developers understand the codebase. She fixed technical debt that would have exploded later.
None of this showed up in our metrics. All of it was essential.
Why Knowledge Work Stays Hidden
Factory work is visible. You can see cars rolling off the assembly line. Software work is different. The most valuable activities happen inside people's heads.
Understanding a complex system. Seeing connections between different parts of the codebase. Preventing bugs by designing better abstractions. These things take time and look like "not working" to anyone keeping score.
I learned this watching two developers debug the same issue. One dove straight into fixing the symptom. The other spent two hours reading code, understanding the root cause, then fixed it properly in twenty minutes.
The first approach looked more productive. The second looked wasteful. Six months later, the quick fix had created three new bugs. The thoughtful fix prevented weeks of problems.
The Context Switching Tax
Here's what really kills productivity: switching between tasks. Every time you interrupt someone, they lose 23 minutes getting back to deep work.
But we optimize for the opposite. Slack notifications. Urgent requests. "Quick questions" that derail entire afternoons.
Sarah had learned to batch her context switches. She'd check messages twice a day, not every ten minutes. She'd block time for deep work and protect it fiercely. She looked less responsive but got more done.
Making the Invisible Visible
The solution isn't better metrics. It's making work visible before measuring it.
Start with a simple board: To Do, Doing, Done. But add columns for invisible work: Blocked, Waiting for Review, Investigating.
Suddenly you can see where time actually goes. That developer who looks slow? They're blocked waiting for infrastructure. The one who seems unproductive? They're investigating a complex bug that will save weeks later.
We started tracking different types of work: features, bugs, technical debt, learning, helping others. The patterns became obvious.
Our "most productive" developers were working on easy, visible tasks. Our "slowest" developers were tackling hard, invisible problems that made everyone else more effective.
The Real Cost
Invisible work compounds. Every day you don't refactor that messy module, it slows down everyone who touches it. Every bug you don't investigate properly creates more bugs. Every junior developer you don't help stays stuck longer.
But invisible work is also optional. You can always choose the quick fix over the right fix. The visible task over the important one.
The best engineers choose differently. They do invisible work because they understand its leverage. They optimize for long-term team velocity instead of personal metrics.
What Good Looks Like
The most effective engineering organizations value invisible work. They measure outcomes, not activity. They reward prevention, not just fixing. They recognize that the best engineers often look the least busy.
They create systems that surface invisible work. Work-in-progress limits that force prioritization. Regular technical debt sprints. Time allocated for learning and helping others.
Most importantly, they trust their engineers to do important work even when it's not immediately visible.
The Paradox
Here's the thing about invisible work: the more you make it visible, the more you realize most "productive" work isn't productive at all.
Moving tickets through a sprint doesn't matter if you're building the wrong thing. Closing bugs quickly doesn't help if you're not preventing them. Looking busy doesn't count if you're not solving real problems.
The engineers who look unproductive are often the ones preventing crises, reducing complexity, and enabling others to work effectively. Their impact is invisible but essential.
Start measuring what matters. Make invisible work visible. Stop optimizing for metrics that miss the point.
Your best engineers might be the ones who look like they're doing nothing at all.
ABOUT THE AUTHOR
Shane Davis is a software engineering team lead who writes on philosophy, society, living an excellent life (Arete - Greek for excellence), and leadership.
RELATED POSTS
Why Your Most Productive Teams Look Like They're Doing Nothing
The best software teams have something in common that looks like waste but is actually their secret weapon: slack time for thinking, fixing, and preventing problems before they happen.
The Myth of the 10x Engineer: Why Teams Matter More Than Heroes
Examining how the obsession with individual productivity obscures the true drivers of software excellence: jelled teams, collaborative intelligence, and the collective mastery that emerges when humans work in harmony.
The Human Architecture of Software Teams: Why Structure Shapes Everything
We obsess over software architecture while treating human architecture like an afterthought. But the structure of your team determines everything.