11 min read
On this page

Navigating Performance Reviews

Doing excellent work & being recognized for excellent work are two different skills. Many senior engineers assume that if they deliver strong results, promotion & positive reviews will follow naturally. They are wrong. Performance reviews are a structured process with specific inputs, & if you do not provide those inputs, even outstanding work can be overlooked.

This is not cynicism — it is how organizations work at scale. Your manager reviews dozens of people. The promotion committee evaluates candidates from teams they have never worked with. The people making decisions about your career are working with incomplete information, & it is your responsibility to make that information as complete as possible.


Understanding Leveling Frameworks

Every company with a structured engineering ladder has a leveling framework — a document that describes what is expected at each level. These frameworks are your single most important tool for career advancement, & most engineers never read them carefully.

How to Read a Leveling Framework

Leveling frameworks describe behaviors, not tasks. They do not say "write 500 lines of code per week." They say things like "drives technical decisions for their team" or "identifies & resolves ambiguous problems with minimal guidance." Your job is to translate these abstract statements into concrete evidence from your own work.

Framework statement:     "Influences technical direction beyond their team"

Weak evidence:           "I attend cross-team architecture meetings"
Strong evidence:         "I authored RFC-47 proposing a unified logging
                         standard, which was adopted by three teams &
                         reduced incident diagnosis time by 40%"

The difference is specificity & measurable impact. Attendance is not influence. Authoring a proposal that changed how other teams work is influence.

The Gap Between Levels

The gap between your current level & the next level is not about doing more of the same work. It is about doing qualitatively different work. A senior engineer who wants to reach Staff does not need to write more code or fix more bugs. They need to demonstrate Staff-level behaviors: identifying high-leverage problems across teams, driving technical alignment, & influencing outcomes they do not directly control.

Common misunderstanding:
  "I am a great Senior, so I deserve Staff"

What the committee actually evaluates:
  "Is this person already doing Staff-level work consistently?"

The promotion goes to engineers who are already operating at
the next level, not to engineers who have maxed out their
current level.

This is a crucial distinction. Promotion committees look for evidence that you have already been performing at the next level for a sustained period — typically six months to a year. They are not betting on potential. They are recognizing demonstrated capability.

Building Your Promotion Case

Your promotion case is not something you assemble the week before review season. It is something you build deliberately throughout the year, project by project.

The Brag Document

A brag document is a running log of your accomplishments, updated regularly. The name is slightly misleading — it is not about bragging. It is about maintaining an accurate record of your work so that you & your manager have concrete evidence when review time comes.

Brag document entry format:

Date: 2026-02-15
Project: Payment retry overhaul
What I did: Identified that our retry logic was causing 12% of
            failed payments to be charged twice. Designed & shipped
            idempotency key system. Wrote RFC, got buy-in from
            payments & billing teams, led implementation.
Impact: Duplicate charges dropped from 12% to 0.1%. Saved
        estimated $340K/year in refund processing costs.
Level signal: Cross-team influence, end-to-end ownership of
              ambiguous problem, measurable business impact.

Update your brag document every two weeks. If you wait until the end of the quarter, you will forget half of what you did. If you wait until review season, you will forget most of it.

A senior engineer at an e-commerce company kept a meticulous brag document for eighteen months. When her promotion packet went to the committee, her manager was able to cite fourteen specific examples of Staff-level work, each with measurable impact. The committee approved the promotion unanimously. Her peer, who had done equally strong work but kept no records, was asked to "try again next cycle" because his packet lacked specifics.

Choosing the Right Work

Not all work is equally visible or equally valued in performance reviews. This does not mean you should only do glamorous projects — but it does mean you should be strategic about how you spend your time.

High-signal work for promotion:
- Projects that span multiple teams or systems
- Work that directly addresses a business-critical problem
- Initiatives you identified & drove yourself (not assigned)
- Efforts that created lasting artifacts (RFCs, tools, libraries)
- Mentoring that resulted in measurable growth for others

Low-signal work (valuable but hard to get credit for):
- Keeping the lights on (operational toil)
- Fixing bugs in systems you did not build
- Attending meetings without driving outcomes
- Code reviews without broader teaching impact
- Work that was important but not visible to leadership

This does not mean you should stop doing operational work. It means you should ensure that operational work is not the only thing you do. If you spend 80% of your time on toil & 20% on high-leverage projects, flip that ratio — or at least move it to 50/50.

Working with Your Manager

Your manager is your primary advocate in the promotion process. If they do not understand your work, cannot articulate your impact, or do not know you want to be promoted, your case will be weak regardless of how strong your actual contributions are.

Career Conversations

Have an explicit career conversation with your manager at least once per quarter. Not a vague "how am I doing?" but a specific discussion about your goals & what you need to demonstrate.

Effective career conversation topics:
- "I am targeting Staff Engineer. What gaps do you see?"
- "Here are the three strongest signals from my work this quarter.
   Do these align with what the committee looks for?"
- "What opportunities are coming up that would let me demonstrate
   cross-team impact?"
- "Who else should I build a relationship with to strengthen
   my case?"
- "Is there anything in my current work that is actively
   hurting my promotion case?"

Your manager cannot help you if they do not know what you want. Many engineers assume their manager knows they want to be promoted. Your manager is managing multiple people with different goals. Be explicit.

Helping Your Manager Advocate for You

When promotion time comes, your manager writes your case & presents it to a committee. Make this as easy as possible:

  • Share your brag document with your manager regularly
  • Send a quarterly self-assessment summarizing your key contributions
  • Provide specific examples that map to the leveling framework
  • Identify peers who can serve as references for your cross-team impact
  • Flag any work that might be invisible to your manager (on-call heroics, mentoring that happened in DMs, contributions to other teams)

A senior engineer at a SaaS company did exceptional cross-team work on a database migration, but his manager was new & had only been on the team for three months. The manager did not witness most of the work. Because the engineer had not documented his contributions or shared them proactively, the promotion packet was thin. The committee deferred the decision. The following cycle, the engineer shared a detailed brag document & connected his manager with engineers on other teams who could vouch for his impact. The promotion went through.

Self-Assessment

Most companies require a self-assessment as part of the review process. Engineers consistently do these poorly — either underselling themselves out of modesty or overselling themselves without evidence.

How to Write a Strong Self-Assessment

Self-assessment principles:
- Use the leveling framework as your outline — address each dimension
- Lead with impact, not activity ("reduced deploy failures by 60%"
  not "worked on the deployment pipeline")
- Include specific examples with measurable outcomes
- Acknowledge areas for growth honestly — reviewers respect self-awareness
- Connect your work to team & org-level goals
- Keep it concise — one to two pages maximum

A common mistake is listing everything you did. The self-assessment is not a changelog. It is a curated argument for your impact. Choose your five to seven strongest examples & present them with enough context that someone outside your team can understand why they matter.

Calibrating Honestly

Overestimating your performance is less common than you might think. Research consistently shows that high performers tend to underrate themselves while low performers overrate themselves. If you are reading a guide on how to navigate performance reviews, you are probably in the group that undersells.

That said, calibration matters. Ask a trusted peer to review your self-assessment before you submit it. They will catch both underselling & blind spots.

Handling Feedback

Performance reviews generate feedback — sometimes positive, sometimes critical, sometimes both. How you handle feedback, especially critical feedback, directly affects your career trajectory.

Receiving Critical Feedback

The moment you receive feedback that stings, your instinct will be to defend yourself. Resist this. The correct first response is always: "Thank you for telling me. Can you give me a specific example so I can understand better?"

Feedback processing framework:
1. Listen without interrupting or defending
2. Ask for specific examples if the feedback is vague
3. Paraphrase what you heard to confirm understanding
4. Take 24-48 hours before deciding whether you agree
5. Identify one concrete action you will take in response
6. Follow up with the feedback giver in two weeks with progress

A senior engineer received feedback that she "needed to be more collaborative." Her initial reaction was frustration — she felt she was collaborative. After asking for specifics, she learned that two teammates felt she made design decisions without consulting them. She did not agree with their characterization, but she recognized the perception gap. She started posting design proposals in Slack for feedback before finalizing them. Two months later, both teammates independently told her manager that collaboration had improved significantly.

The feedback was about perception, not reality. But perception matters. A senior engineer who is seen as collaborative has more influence than one who is technically right but difficult to work with.

When You Disagree with Feedback

Not all feedback is valid. Sometimes feedback reflects the giver's misunderstanding, bias, or limited perspective. But even invalid feedback contains a signal — it tells you how you are perceived, & perception shapes your career.

When you genuinely disagree with feedback, the productive approach is to acknowledge the perception & address it, even if you believe the underlying assessment is wrong. "I hear that the team perceives my design reviews as too critical. I believe rigorous review catches real problems, but I can see how the tone might feel adversarial. I will work on framing my feedback more constructively."

The Difference Between Doing & Being Recognized

This is the hardest lesson for technically strong engineers: doing senior-level work & being recognized as doing senior-level work are separate challenges.

Why Great Work Goes Unrecognized

Reasons strong work gets overlooked:
- Your manager changed mid-cycle & the new one missed your best work
- The project was cancelled before it shipped, erasing your contribution
- The impact was real but hard to measure (prevented an outage, not fixed one)
- You did the work but someone else presented it to leadership
- The contribution was collaborative & your specific role was unclear
- The work was operational (keeping systems running) rather than visible

None of these are fair. All of them are real. The solution is not to stop doing important work that might be invisible. The solution is to make it visible.

Making Your Work Visible

Visibility is not self-promotion. It is ensuring that the people who evaluate your performance have accurate information about your contributions.

Visibility practices:
- Send a brief summary to your manager after completing significant work
- Present your team's wins at org-wide demos or all-hands meetings
- Write internal blog posts about technical problems you solved
- Share your RFCs & design docs broadly, not just with your immediate team
- Thank collaborators publicly — this also makes your involvement visible
- Volunteer to present post-mortems — the audience includes leadership

A senior engineer at a logistics company spent three months building a monitoring system that prevented two major outages. Nobody outside his team knew about it because outages that do not happen are invisible. He wrote a short internal post titled "How We Prevented Two P1 Outages This Quarter" that described the monitoring system & the specific alerts that caught problems early. His skip-level manager read the post & cited it in the next leadership review. The work was always valuable — the post made it visible.

Finding Advocates

Your manager is your primary advocate, but not your only one. Promotion committees often ask for input from engineers outside your team. Having two or three people who can speak to your cross-team impact significantly strengthens your case.

Build these relationships deliberately. When you collaborate with engineers on other teams, follow up afterward. When you help someone solve a problem, make sure they know your name. When you attend architecture reviews, contribute meaningfully — do not just observe.

Common Pitfalls

  • Assuming your work speaks for itself. It does not. The promotion committee is evaluating dozens of candidates based on written packets. If your packet is thin, your work is invisible.
  • Neglecting your brag document. Trying to reconstruct six months of accomplishments from memory produces a vague, unconvincing narrative. Update it every two weeks.
  • Avoiding career conversations with your manager. If your manager does not know you want to be promoted, they will not create opportunities for you or advocate on your behalf.
  • Doing only the work that is assigned to you. Promotion to the next level requires self-directed work — identifying problems & driving solutions without being asked. Assigned work, no matter how well executed, signals current-level performance.
  • Ignoring the leveling framework. The framework tells you exactly what the committee is looking for. Map your work to it explicitly. Do not make the committee guess.
  • Optimizing for quantity over quality. Shipping ten small features is less compelling than owning one complex, ambiguous problem end to end. Committees look for depth of impact, not volume of output.
  • Taking critical feedback personally. Feedback is data about how you are perceived. Even feedback you disagree with tells you something useful. Process it before reacting.
  • Comparing yourself to peers. "I am better than X & they got promoted" is never a productive framing. Focus on your own evidence against the leveling framework.
  • Waiting for the perfect moment. There is no perfect cycle. Start building your case now, even if you think promotion is a year away. The best candidates have a long trail of documented impact.
  • Confusing a skip with a setback. Not getting promoted in a given cycle is not a career failure. It is information about what the committee needs to see. Ask for specific feedback & address it.

Key Takeaways

  • Doing great work & being recognized for great work are separate skills. You need both.
  • Read your company's leveling framework carefully & map your work to it explicitly. The framework tells you exactly what the promotion committee evaluates.
  • Keep a brag document updated every two weeks. When review time comes, you will have concrete, specific evidence instead of vague recollections.
  • Have quarterly career conversations with your manager. Be explicit about your goals & ask for specific feedback on gaps.
  • Make your manager's job easier by sharing your brag document, writing strong self-assessments, & identifying peers who can vouch for your cross-team impact.
  • Choose work strategically: self-directed, cross-team, & business-critical work sends stronger promotion signals than assigned tasks executed well.
  • Handle feedback — especially critical feedback — with curiosity, not defensiveness. Ask for specifics, take time to process, & follow up with concrete actions.
  • Make your work visible through writing, presenting, & building relationships beyond your immediate team. Invisible work is unrecognized work.
  • Promotion committees look for evidence that you are already operating at the next level consistently, not evidence that you have mastered your current level.
  • Build advocates outside your team. When the committee asks "who can speak to this person's impact?", you want multiple credible answers.