Good Work Doesn't Speak for Itself

Review season rolls around, and you sit down to write your self-assessment. You stare at the blank document. You know you had a good six months. The team shipped faster. The new hire got up to speed in half the time it usually takes. That one architectural decision that would have caused a nightmare three months later got caught before it ever touched production. The CI pipeline that everyone complained about for a year finally stopped randomly failing at 2am.

And yet somehow, looking at the document, you feel like you did nothing.

That is not imposter syndrome. That is a documentation problem.

The Work Nobody Sees Is Still Work

There is a category of engineering work that keeps teams functional. Mentoring a new hire through their first production commit. Catching the design flaw in a review before it becomes a six-week incident. Writing the runbook means the next person does not have to figure it out from scratch. Fixing the flaky test suite that everyone complained about in Slack, but nobody ever actually fixed because it was never on a roadmap.

This is called glue work, and it is real engineering work. Not support. Not overhead. Not soft skills. It is leverage. When you do it well, multiple people move faster, make fewer mistakes, and spend less time blocked. The team's output improves in ways that are genuinely hard to attribute to any single commit.

The problem is not that glue work lacks value. The problem is that it lacks legibility.

When someone ships a feature, there is a ticket, a PR, a deploy, and a demo. The artifact is visible. The contribution is traceable. When you spend three hours in a design review steering a service away from an approach that would have caused cascading failures, there is no artifact. There is just a decision that looks obvious in hindsight, made by a team that never had to deal with a failure that never happened.

Promotion committees are not evaluating your actual impact. They are evaluating the evidence of your impact that exists in the room. If you did not create that evidence, nobody else is going to do it for you.

One Kind Builds. The Other Traps.

Here is where it gets important to be honest with yourself. There is a meaningful difference between glue work that compounds and glue work that just absorbs dysfunction.

Glue work that compounds makes many people faster, safer, or less blocked over time. You write the onboarding guide once, and the next four hires benefit from it. You fix the flaky CI, and the entire team stops losing thirty minutes a week to false failures. You establish a review pattern that catches a class of bugs before they ever reach staging. The work you did once keeps paying out.

Glue work that traps you is different. It is the recurring manual task that nobody else has learned because you always handle it. It is the same question you answer in DMs every week because there is no documentation. It is the operational burden you absorb because you are good at it, and it is easier than fixing the underlying system. You are not building leverage. You are becoming load-bearing infrastructure for a broken process.

Both look the same from the outside. Both look like "being helpful." But one is building a case for your promotion, and the other is quietly consuming the time you could use to do the work that would actually get you there.

The question to ask yourself is whether the problem is getting smaller over time or whether you are just getting better at managing it. If it is the latter, you are not solving the problem. You are hiding it.

Activity Is Not Impact

This is the part most engineers get wrong when they finally sit down to write their self-assessment.

"Reviewed a lot of PRs" is not evidence. It is a description of activity. It tells the promotion committee that you were present and busy. It tells them nothing about what changed because of your presence.

Compare that to: "Identified a recurring pattern of missing error handling in a high-change service area, wrote a review guide with examples, and reduced the back-and-forth cycles on PRs in that area while improving the consistency of error handling in production."

Same underlying work. Completely different story. The second version describes what the friction was, what you changed in the system, and what got better afterward. It gives someone who was not in the room a way to understand why it mattered.

The formula is not complicated. Describe the friction that existed before. Describe what you changed. Describe what improved. Name who benefited. Provide whatever proof you have.

That last part trips people up because glue work rarely comes with clean metrics. But soft proof counts. Fewer repeated questions in a channel counts. A new hire who shipped their first feature in three weeks instead of eight counts. A postmortem that did not happen because someone caught the problem in review counts. You do not need a dashboard. You need to be specific enough that someone reading it can picture what actually changed.

The Objection Worth Taking Seriously

The obvious response to all of this is that engineers should not have to sell themselves. Good work should speak for itself. A company that cannot see your value does not deserve you.

There is something real in that. But it is also a little naive about how promotion cycles actually work, even at good companies.

Your manager is not watching your every contribution in real time. They are reconstructing your impact based on memory, peer feedback, and any available artifacts. That reconstruction happens under time pressure, across multiple people being evaluated at once, with significant recency bias toward whoever shipped the most visible thing last quarter. This is not malice. It is just how human memory and committee dynamics work.

If you do not help your manager accurately reconstruct your impact, the default is not that they figure it out anyway. The default is that the gaps get filled in by whoever made the most noise, and your six months of work that actually mattered gets summarized as "solid contributor, good teammate."

This is not about self-promotion. It is about not letting your actual work get misrepresented by a process that was never designed to surface it automatically.

Start Now, Not in October

The single most practical thing you can do is start capturing your work before review season, not during it.

When you do a piece of glue work, write it down. Not in a formal document. A running note somewhere. What was the friction? What did you change? What got easier? Who benefited? What evidence exists, even soft evidence?

This takes five minutes when the work is fresh. It takes five hours in October when you are trying to reconstruct six months from memory and Slack search. And the version you write in October will be worse. You will forget the details that made it meaningful. You will default to vague descriptions because you cannot remember the specifics. You will undersell yourself, not because you lack confidence, but because you genuinely cannot remember what you did.

The engineers who get promoted are not always the best coders on the team. They are the ones who figured out how to translate what they did into something a promotion committee can actually evaluate. That translation is a skill. It is learnable. And it starts with treating your own work as worth documenting in real time, not just worth doing.

You do not need to do more visible work. You need to stop letting your actual impact disappear before anyone can see it.

Your work kept the team from falling apart. The least you can do is make sure someone can prove it.

Dev Survival Guide: Promotion Prep Edition — for engineers trying to figure out what's actually blocking the next step.