Your Manager Can't Remember What You Did in March — and That's a Systems Problem

The problem

Every consequential decision about your career — promotion, calibration rating, who lands on a layoff list — gets made in a room you're not in, usually in a few minutes per name.

Here's the uncomfortable part: the input to that decision is not your work. Your commits, your incident responses, your design docs — none of that is in the room. What's in the room is a lossy, human-memory summary of your work, reconstructed months after the fact by people juggling ten other names.

Most engineers treat this as politics. It's not. It's a data problem, and you can engineer around it.

Why it happens

Think of it as a caching problem.

Your actual output lives on disk: the repo history, the closed incidents, the migration that shipped without drama. Nobody reads disk during calibration. There's no time. They read cache — the handful of impressions that survived in your manager's memory.

And that cache has a brutal eviction policy:

• Recency wins. Q1 work is mostly gone by review season. The last six weeks are over-weighted.
• Loud events survive; quiet competence doesn't. The engineer who heroically fixed a burning outage generates a story. The engineer whose systems never caught fire generates... nothing. Prevention produces no events, so it's evicted first.
• Manager change = cache flush. New manager, and your last two years of context drop to whatever made it into writing. In most orgs, that's a few one-line review summaries.

This is why the most load-bearing engineers so often score as "solid, meets expectations" while the firefighter — sometimes fighting fires of their own making — scores as "high impact." Nobody is being malicious. The work was simply never logged anywhere a decision-maker could read it.

What to do about it

Maintain an evidence log. Five minutes a week, three fields per entry:

1. What changed — the outcome, not the activity. "Migrated checkout to the new payment service" beats "worked on payments."
2. The number — before/after, with a link to the dashboard or PR. "p95 checkout latency 480ms → 210ms; conversion +1.9%." A claim with a number survives a calibration room. "Worked on performance" does not.
3. Who can vouch — the staff engineer who reviewed it, the PM who saw the metric move. Names make claims checkable, and checkable claims get repeated.

Then do three things with it:

• Log prevention explicitly. "Added connection-pool alerting after incident #2141 — zero repeat incidents in 6 months" turns invisible work into a record.
• Send your manager a short monthly summary. Five bullets, no prose. This isn't bragging — you're warming their cache with accurate data before eviction does its work. Most managers are quietly grateful: you're writing their calibration notes for them.
• Write one-page decision docs for anything contested. Six months later, "why is the queue architecture like this?" has an answer with your name on it, instead of an archaeology project.

Before review season, distill the log into five promo-ready claims. What took your peers a panicked weekend of git-log archaeology takes you twenty minutes.

Key takeaways

• Career decisions read from memory, not from history. Memory is a cache with recency and drama bias.
• Prevention work is evicted first. If you don't log it with numbers, it functionally didn't happen.
• Five minutes a week of evidence logging beats five hours of reconstruction the night before your review.
• Legibility isn't politics. It's writing for the room you won't be in.