You Are "The Glue"

Early in a career, glue work looks like distraction. You're still building technical depth, and time spent updating the roadmap or mediating a design disagreement is time not spent getting better at the craft. At that stage, the instinct to stay close to the code is correct — depth has to come before breadth.

As you grow, the dynamic shifts. The team's output becomes the thing you're responsible for, not just your own. And the skills that drive team output — noticing misalignments before they cost two weeks, keeping a new hire from going down the wrong path, making sure the right people are in the room for the right decisions — aren't the same skills as writing good code. They develop separately, and deliberately.

The trap is that this work is largely invisible. It doesn't show up in commit history or ticket counts. Metrics measure what ships, not what didn't go wrong because someone caught it early. That invisibility has a real cost: glue work gets undervalued by managers who aren't looking for it, and by engineers themselves who feel guilty about a light week of commits.

Tanya Reilly, who named and defined this work, makes the point that making it legible is part of the job. A manager who understands what you're doing can advocate for it — but that understanding doesn't happen automatically. It requires active narration: calling out the unblocks in a retrospective, framing your contributions in terms of team outcomes, making the decisions you pushed for visible rather than letting them disappear into the background noise of a sprint.

Glue work doesn't speak for itself. Neither should you let it.