Recognizing Invisible Work in Engineering Teams

There was an engineer on my team named Sarah who kept everything running.

She wasn't building flashy features or presenting at all-hands. She was the person who noticed when the CI pipeline was flaky and fixed it on a Friday afternoon. She onboarded every new hire with patience and thoroughness. She reviewed more PRs than anyone else — not because she was assigned to, but because she cared about code quality. She updated the runbooks. She answered the questions in Slack that nobody else wanted to answer.

During our annual review cycle, I almost gave her a "meets expectations" rating. After all, she hadn't shipped any major features. She hadn't led any high-visibility projects. By the metrics we tracked — story points completed, features delivered, projects led — she was unremarkable.

Then I asked myself: what would happen to this team if Sarah left?

The answer made my stomach drop. Everything would fall apart. Not immediately — not in a dramatic, obvious way. But gradually, painfully, as all the things she quietly held together stopped being held.

That was the day I realized our systems for recognizing engineers were fundamentally broken. We were celebrating the people who built the house while ignoring the people who maintained the foundation.

The Invisible Work Taxonomy

After that experience with Sarah, I started paying closer attention to the work that happens without fanfare. It falls into several categories:

Category	Examples	Why it's invisible
Maintenance & reliability	Monitoring, dependency updates, bug triage, performance optimization	No one notices until it's not done
Knowledge sharing	Documentation, onboarding, answering questions, code reviews	Not tracked as "deliverables"
Team health	Mediating disagreements, checking on struggling colleagues, planning social events	Seen as "not real work"
Process improvement	Fixing flaky tests, improving CI/CD, cleaning up tech debt	Doesn't show up as a "feature"
Cross-team coordination	Unblocking dependencies, representing the team in meetings, building relationships	Rarely attributed to individuals
Organizational scaffolding	Running retrospectives, maintaining Jira hygiene, managing on-call rotations	Administrative and undervalued

Every healthy engineering team has people doing this work. And in my experience, it's disproportionately done by women, people of color, and anyone who's been socialized to prioritize collective wellbeing over individual visibility.

That's not a coincidence. It's a systemic inequity that gets reinforced every time we fail to recognize this work.

Why We Fail to See It

Several forces conspire to make invisible work... invisible:

Our metrics are biased toward building. Story points, features shipped, PRs merged — these all measure creation. They don't measure preservation, protection, or enablement.

Visibility is confused with impact. The engineer who presents at the all-hands is more visible than the engineer who kept production stable all quarter. Visibility and impact are different things, but our brains conflate them.

The work prevents problems rather than solving them. When Sarah kept the CI pipeline healthy, there was no outage, no crisis, no dramatic save. The absence of problems doesn't generate stories the way solving problems does.

It's often distributed across many small actions. Nobody tracks the 15 minutes spent helping a colleague debug a test, the 10 minutes updating a runbook, the 5 minutes answering a question in Slack. These add up to hours per week, but each individual act is too small to notice.

The people doing it often don't self-promote. Many of the engineers who do invisible work are the same ones who are uncomfortable drawing attention to themselves. They do it because it needs doing, not because they want recognition. Which makes it even easier to overlook.

Making the Invisible Visible

Here's what I've learned about building systems and habits that actually see and value this work:

1. Redefine what you track

If you only measure features shipped, you only see feature shippers. Expand your definition of contribution:

• Code review quality and volume — Who's helping others ship better code?
• Documentation contributions — Who's making knowledge accessible?
• On-call response and reliability work — Who's keeping things stable?
• Mentoring and onboarding — Who's making new people successful?
• Cross-team collaboration — Who's the connective tissue?

I added a section to my team's weekly update specifically for maintenance and support work. Not as an afterthought — as a first-class category alongside feature work. Suddenly, the work was visible because we'd created space for it to be seen.

2. Name it publicly and specifically

Generic appreciation is better than nothing, but specific, public recognition is transformative.

Not this: "Thanks to Sarah for all her help this quarter."

This: "I want to highlight something Sarah did this week. She noticed that our deployment pipeline was consistently failing on the integration test step, spent her Friday diagnosing the root cause, and fixed a race condition that had been causing intermittent failures for three months. Because of her work, we haven't had a single failed deploy this week. This is the kind of quiet, essential work that keeps our entire team productive."

The specificity matters. It communicates what the work was, why it mattered, and that leadership sees it.

3. Build recognition into your rituals

Don't rely on spontaneous recognition — it's too easy for invisible work to stay invisible when recognition is ad hoc.

Practices that work:

• Weekly team meeting shout-outs — Dedicated time for anyone to recognize someone else's invisible contributions
• "Glue work" category in retrospectives — Explicitly asking "who did the connective work that made this sprint possible?"
• Quarterly invisible-work awards — Seriously. Make it a thing. Give it prestige.
• One-on-one acknowledgment — Privately telling someone "I see what you're doing and it matters" is powerful even without public recognition

4. Value it in performance reviews and promotions

This is where it gets real. Recognition means nothing if invisible work is celebrated in Slack but ignored in promotions.

I've advocated — successfully, though it took time — for promotion criteria that explicitly include:

• Team-level contributions (code review, mentoring, documentation)
• Reliability and maintenance work
• Cross-team collaboration and unblocking
• Process improvement and tooling
• Organizational health contributions

If your promotion criteria are purely about individual output on visible projects, you're structurally disadvantaging the people who hold your team together. Fix the criteria.

5. Distribute it more equitably

Part of recognizing invisible work is noticing that it's often unfairly distributed. The same people — often the most generous, most empathetic team members — end up doing a disproportionate share.

This matters because invisible work, while essential, rarely leads to promotions in most organizations. If the same people always do it, they fall behind on the visible work that advances careers.

Strategies:

• Rotate on-call, support, and code review responsibilities — Don't let volunteers become permanent owners
• Make it explicit in sprint planning — "Who's taking documentation and review duty this sprint?" treats it as real work
• Check the distribution — Look at who's doing the most code reviews, answering the most Slack questions, onboarding the most new hires. Is it balanced?
• Say no on their behalf — If you notice someone drowning in invisible work while others coast, intervene. "Sarah has been carrying a heavy review load. Let's redistribute this sprint."

The Conversation With "Sarah"

After my realization, I had a conversation with the real Sarah (not her actual name) that went something like this:

"I want to tell you something directly: I've been failing to adequately recognize the work you do for this team. You keep our CI healthy, you onboard every new hire, you review more code than anyone, and you answer questions nobody else will. This work is essential and I haven't been treating it that way. I'm sorry, and I'm changing it."

She teared up. Not because the recognition was so overwhelming — but because she'd been feeling invisible for over a year and had started to wonder if her contributions actually mattered.

That conversation taught me something important: the absence of recognition isn't neutral. It actively communicates "this doesn't count." People hear that message even if you never say it explicitly.

A Note About "Glue Work"

Tanya Reilly's concept of "glue work" names something crucial: the work that makes teams function but doesn't appear on anyone's roadmap. If you haven't read her article on this, please do.

What I want to add to her framework is this: leaders have a specific responsibility here. We're the ones who define what counts. We're the ones who write performance criteria and decide promotions. If glue work goes unrewarded, it's because we haven't built systems that reward it.

This isn't just a matter of fairness (though it is). It's a matter of team sustainability. If your team's "glue workers" burn out or leave — and they will, if they feel perpetually unseen — the infrastructure they quietly maintained will crumble.

What Changes When You Get This Right

When you build a culture that truly sees and values invisible work:

• People volunteer for maintenance work because it's rewarded, not punished
• Documentation stays current because writing docs is valued, not dismissed
• On-call is equitable because it's recognized as meaningful contribution
• New hires ramp up faster because onboarding is treated as important work
• The team is more resilient because infrastructure doesn't depend on invisible heroes

And most importantly: the people who naturally do this work — the ones who care about the team's collective success — feel valued. They stay. They thrive. They keep doing the essential work that nobody notices until it stops.

Start This Week

Here's my challenge to you: this week, identify one person on your team doing invisible work. Name their contribution specifically, publicly, and with genuine appreciation. Not a Slack emoji. Not a generic "great job." A specific, detailed acknowledgment of work that would otherwise go unseen.

Then build the systems so you never have to rely on yourself remembering to do this again.

The people holding your team together deserve to be seen. Be the leader who sees them.