A lot of the work that keeps a team moving never fits neatly into a ticket.

Sure, you have your assigned tasks, estimates, PRs, and shipped features. But you also spend a huge part of the week helping the team work better: answering questions, spotting risks early, reviewing design docs, onboarding new hires, and smoothing out friction before it becomes visible.

The team moves faster because you were there.

Then review season comes around and it looks like you did... less.

I know the feeling.

You worked all quarter. You were useful all quarter. You might even have been one of the reasons the team did not collapse into chaos.

But when it is time to explain your impact, your work looks fuzzy.

Not because it was small.

Because it was glue.

The problem with glue work

Tanya Reilly popularized the term glue work to describe the less glamorous work required to make a team successful.

And once you see it, you cannot unsee it.

Glue work is everywhere:

• onboarding the new engineer who would otherwise spend three weeks stuck
• reviewing the design doc that catches the bad idea before it becomes six months of technical debt
• fixing the flaky CI path everybody complains about but nobody owns
• documenting the deployment path that only one senior engineer understands
• translating between product, infra, and engineering so a project does not drift into nonsense

That is real engineering work.

The problem is not that glue work lacks value.

The problem is that glue work often has low legibility.

It helps the team, reduces friction, prevents mistakes, and raises the floor for everyone. But it does not always leave behind an obvious artifact.

And promotions do not reward hidden importance.

They reward legible impact.

Why strong engineers get trapped here

This is where a lot of good people get stuck.

They become the person who:

• answers the hard questions
• catches the risky design
• helps everyone get unstuck
• sees the dependency problem early
• quietly keeps quality from slipping

The team starts depending on them.

Which sounds good.

But dependence is not the same thing as recognition. If your impact mostly shows up in other people's output, you are always at risk of being underestimated.

Some work is easy to remember because it leaves a visible mark. Other work fades, even when it made the visible work possible.

The feature launch gets remembered. The person who made the launch less chaotic usually does not.

The incident fix gets celebrated. The person who spent two months reducing alert noise, cleaning up observability, and lowering the chance of that incident happening again usually gets less credit.

The new hire who ramps quickly looks great. The person who built the onboarding path that made that ramp possible often looks like they were "just being helpful."

That is the trap.

Glue work is often high value, but high value is not enough.

It needs to be visible in the right way.

Not all glue work is equal

This is the part I think gets missed in most discussions.

People talk about glue work as if it is all one thing.

It is not.

Some glue work is deeply promotable.

Some glue work is career quicksand.

You need to know the difference.

That is what I mean by the Glue Work Matrix.

Well, maybe matrix is a bit pretentious. In reality there are just two questions:

1. Does this work create leverage?
2. Can I turn it into evidence?

If the answer to both is yes, that is usually good glue work.

If the answer to both is no, you are probably doing cleanup work that helps the team in the moment but does very little for your long-term growth.

The glue work that actually matters

The best kind of glue work does one of four things:

• It reduces risk.
• It increases the output of other engineers.
• It improves decision quality.
• It removes recurring friction from the system.

That is the work that compounds.

For example:

• mentoring that gets a new hire productive faster
• code review guidance that reduces architectural drift across a codebase
• cross-team coordination that avoids duplicate work or conflicting implementations
• better observability that cuts investigation time every week
• documentation that reduces key-person risk
• process fixes that stop the same planning confusion from repeating every sprint

That is not "just support."

That is leverage.

And mature engineering organizations know it.

Dropbox explicitly wrote that its old framework was too biased toward big, high-profile achievements and undervalued things like glue work, documentation, and keeping-the-lights-on work.

Monzo's public progression framework ties growth to impact, and at Senior and Staff levels it explicitly includes mentoring, cross-functional collaboration, quality, and preventing future fires.

Etsy's public ladder says Staff engineers improve the overall quality of engineering on the team, set technical direction, and support the growth and success of teammates.

GitLab's Staff framework explicitly includes unblocking people, improving team processes, helping others understand the domain, and blending technical, product, and design strategy to make the team more productive.

That matters because it tells us the issue is not whether this work counts.

The issue is whether your company knows how to see it, and whether you know how to explain it.

The glue work that becomes a trap

There is another category of glue work that feels useful but does not really compound.

Things like:

• taking notes because nobody else will
• repeatedly solving the same setup issue by hand
• being the default rescue person for work that should have clearer ownership
• doing emotional or administrative cleanup that never improves the system

Sometimes that work is still necessary.

But if it keeps recurring in the same form, that is a warning sign.

You are not building leverage.

You are absorbing dysfunction.

That is a very different thing.

And if you are not careful, it becomes your identity on the team. You become indispensable, but in the worst possible way.

Too useful to lose.

Too hard to describe as impact.

Too busy cleaning up to build the evidence for the next level.

The seniority shift

This gets more subtle as you grow.

For junior and mid-level engineers, too much glue work can absolutely slow down growth.

If you are still trying to build depth, ownership, and technical confidence, spending all your time unblocking other people is not automatically noble. Sometimes it just means your energy is going into work the next level does not reward yet.

At Senior, things start to change.

Now the question is not just "Can you ship?"

It is also:

• Can you raise the quality bar?
• Can you reduce chaos?
• Can you help the team make better decisions?
• Can you multiply the output of people around you?

At Staff and beyond, some forms of glue work stop being accidental and start becoming the actual job.

Not the clerical kind, the leverage kind.

The cross-team, ambiguous, judgment-heavy, systems-oriented kind.

That is why this conversation gets confusing.

The same person can hear:

"You are doing too much glue work"

and

"You need more organizational impact"

And both statements can be true.

The difference is whether the work is building leverage at the scope your level expects.

Why this disappears during promotion

Glue work gets undervalued for predictable reasons.

First, visible work is easier to point at. A feature launch has a date, a diff, a demo, a metric, a proud Slack post. Glue work often has none of those.

Second, performance reviews are reconstruction exercises. People remember the thing that happened loudly and recently. They forget the five small interventions that made the thing go well in the first place.

Third, glue work often gets absorbed into somebody else's success.

You improved the review quality, but they shipped the feature.

You clarified the decision, but they presented the final plan.

You built the onboarding path, but they got productive faster.

That makes attribution harder.

And if attribution is fuzzy, promotions get fuzzy too.

The fix is not to stop doing glue work

The fix is to stop documenting it like support.

This is where most engineers lose.

They write things like:

• helped onboard new engineers
• reviewed a lot of PRs
• supported cross-team execution
• improved team process

None of those statements are false.

They are just weak.

They describe activity, not changed conditions.

Try to think about the difference.

Instead of:

• helped onboard new engineers

write:

• created a lightweight onboarding path and paired with 3 new hires through their first production changes, reducing repeated setup questions and helping each ship a meaningful change in their first two weeks

Instead of:

• reviewed a lot of PRs

write:

• identified recurring architectural mistakes in a high-change service area, wrote a short review guide, and reduced back-and-forth review cycles while improving merge quality

Instead of:

• kept the project moving across teams

write:

• surfaced an ownership mismatch between infra and product teams before implementation, aligned sequencing, and prevented a dependency conflict that would likely have delayed the launch by a sprint

Instead of:

• improved team process

write:

• turned a recurring retrospective complaint about unclear handoffs into a lightweight ownership template that reduced confusion at sprint boundaries

That is the whole game.

Promotion is a translation exercise: you are turning fuzzy activity into defensible evidence.

A better way to document glue work

You do not need perfect metrics for everything.

That is another trap.

Engineers often think: if I cannot prove a precise percentage improvement, I should not mention it.

Too strict.

What you need is a cleaner record of what changed.

When you do glue work, capture five things:

1. What was the friction, risk, or recurring problem?
2. What did I do that changed the system, not just the moment?
3. What got easier, faster, safer, or clearer afterward?
4. Who benefited?
5. What proof do I have?

Sometimes the proof is a hard metric:

• time-to-first-commit
• PR cycle time
• flaky-test rate
• alert volume
• incidents avoided in a previously noisy system

Sometimes it is softer but still useful:

• fewer repeated questions
• fewer coordination failures
• clearer ownership
• smoother handoffs
• visible changes in team behavior

That still counts.

The mistake is waiting until review season and hoping memory will reconstruct it for you.

It will not.

A useful rule of thumb

If your glue work makes many people faster, safer, or less blocked, it probably matters.

If it keeps recurring in the same manual form, it probably needs to be automated, rotated, or declined.

That distinction matters a lot.

Some glue work should go into your promotion packet.

Some glue work should become a team policy.

Some glue work should become a script.

Some glue work should stop being your problem.

The real point

Glue work is not secondary to engineering. Very often, it is the work that makes engineering actually work.

The problem is that teams admire the building and forget the scaffold. So if you are the person holding the scaffold together, do not just say you were helpful.

Show what changed because you were there.

Show what got faster, safer, clearer, or less fragile.

That is not fluff.

That is impact.

And if your company still cannot see it, at least you will know exactly what kind of work you are doing:

the kind that should be promoted,

the kind that should be redistributed,

and the kind that should never stay invisible again.

That is also why I keep coming back to evidence in my work on careercraft.ing. The goal is not to make engineers write prettier self-reviews. It is to help them keep track of the work that would otherwise disappear before it ever becomes part of the promotion conversation.

If you recognized yourself in this article, you are not the only one.

Join the waitlist if you want early access.