Research reveals how bias affects tech promotions. Why great engineers get passed over—and what you can do about it.
Performance review season is coming. If you've ever felt like your work wasn't fully recognized, you're not alone—and it might not be your fault.
I looked into the research on promotion bias in tech. Here's what I found.
You've shipped more features than your peers. You've fixed critical bugs that saved the company money. You've mentored junior developers. Yet when promotion season arrives, someone else gets the title.
This promotion gap happens far more often than it should. And it's probably not because you're not good enough.
Research suggests that systematic biases in how we evaluate engineers create patterns where excellent work goes unrecognized. This doesn't explain every missed promotion, but it explains more than most engineers realize.
The Core Problem: Your Rating Depends on Who's Rating You
If there's one number that matters most, it's this: more than 50% of performance rating variance comes from rater bias, not actual performance differences.
More than half the difference between your rating and your peer's rating has nothing to do with how good you actually are. It's about who's doing the rating, their preferences, and what they happen to remember.
How Bias Shows Up in Practice
Two biases matter most:
Proximity bias affects who gets seen. 42% of managers admit they forget about remote workers when assigning high-visibility work. Your manager sees the person sitting next to them every day. They remember that person's wins.
Recency bias affects what gets remembered. Recency bias is one of the most common biases in performance reviews—managers give disproportionate weight to what happened in recent weeks rather than the full review period. The engineer who shipped something visible last week beats the engineer who shipped something critical in March.
These biases compound. If you're remote and your biggest wins happened early in the review cycle, you're fighting an uphill battle that has nothing to do with the quality of your work.
What This Looks Like in Practice
Consider two engineers on the same team. Both are senior. Both are technically strong.
Engineer A works from home. In February, she led a complex database migration that prevented a potential outage affecting thousands of users. In her 1:1s, she mentioned it briefly. She didn't write it down anywhere else.
Engineer B sits two desks from their manager. In October—three weeks before reviews—he shipped a visible dashboard feature. Nothing critical, but the whole team saw the launch. His manager mentioned it in the weekly standup.
Come December, the manager writes performance reviews. The migration? It's been ten months. The specifics are fuzzy. The dashboard? Fresh in mind, easy to describe, clearly impactful.
Engineer B gets the stronger review. Not because he's better—because his work was recent and visible.
This isn't a story about bad managers. It's a story about how memory works, and what happens when documentation doesn't exist.
The Structural Reality
According to Levels.fyi research, staff engineers typically make up less than 10% of engineering organizations. The senior level is a "career level" by design—most engineers who reach it stay there.
This isn't necessarily bad. Not everyone wants to be a staff engineer, and that's valid. But for those who do want to advance, internal promotions to staff are notoriously difficult. At competitive levels, visibility can be the deciding factor between candidates of similar ability.
What the Data Doesn't Explain
Before we talk about solutions: limitations matter.
A missed promotion might be bias—or it might be that you weren't ready, that there wasn't headcount, or that your manager had legitimate concerns. Documentation helps in organizations that are fundamentally fair but imperfect. It doesn't help in toxic environments. It doesn't replace having a manager who advocates for you.
If good documentation and consistent performance still don't move the needle, the problem might not be your visibility. It might be the organization.
What You Can Actually Do
For engineers in reasonably functional organizations, visibility gaps are often fixable:
- Document wins as they happen. Julia Evans' brag document approach captures achievements when they occur, not six months later. (See our guide on how to write a self-evaluation.)
- Be specific about impact. "Fixed a bug" is forgettable. "Fixed a race condition causing 2% transaction failures, protecting $50K/month revenue" is not.
- Share wins regularly. Distribute when your manager learns about your work across the year to counteract recency bias.
These aren't guaranteed solutions. They're habits that tend to help in environments where effort is generally rewarded.
Why We Built BragDoc
We kept noticing the same pattern: engineers scrambling before review season, trying to reconstruct months of work from vague memories and incomplete git logs. The same struggle showed up in job searches, salary negotiations, and even weekly standups.
BragDoc pulls from Git history, GitHub activity, and other sources to capture achievements automatically. Your commits already document what you did and when—we translate that into statements you can actually use.
It won't fix broken organizations or guarantee promotions. But for engineers in environments where documentation matters, it removes the part where you have to remember everything yourself.
Whether you're preparing for performance reviews, negotiating a raise, or maintaining a clear record of your trajectory, documented evidence tends to improve your odds.
Next steps: Start documenting your wins this week. Add three recent accomplishments to a simple document, then capture each new win as it happens. By review season, you'll have clearer evidence of your impact—and a better foundation for whatever conversation comes next.
Top comments (0)