Forem: Natália Spencer

Meta Built an AI to Write Reviews. You Still Need to Remember.

Natália Spencer — Fri, 27 Feb 2026 00:16:36 +0000

Meta built an AI to help write performance reviews. But you still need to remember what you accomplished. Learn how to track work achievements automatically.

Late last year, Meta launched an AI-powered performance review assistant for their employees. The tool, which integrates their internal AI assistant Metamate with Google's Gemini, helps staff write better self-reviews and peer feedback.

There's just one problem: you still have to tell it what you accomplished.

The AI can make your writing more polished. It can format your achievements into compelling narratives. It can ensure your review aligns with company values. But it can't remember the critical bug fix you shipped in March. Or the architectural decision you made in July. Or the teammate you mentored in September.

Meta's AI solves the output problem. It doesn't solve the input problem.

What Meta Actually Built

In December 2025, Meta launched their AI Performance Assistant for year-end reviews. According to Business Insider, the tool does exactly what you'd expect from a modern AI writing assistant.

Employees feed their accomplishments into the system. The AI—using both Meta's internal Metamate (trained on company docs) and Google's Gemini—generates polished review text. Employees edit the output. Submit the review.

Based on available reports, the workflow appears to work like this:

Employee manually compiles what they worked on
Employee inputs accomplishments into AI tool
AI drafts review text
Employee refines the AI-generated content
Employee submits review

Notice what's missing? Steps 0 through 1. The part where you actually remember what you did.

How to Remember Accomplishments for Performance Reviews

If you've ever prepared a performance review, you know the hard part isn't writing eloquent prose. The hard part is answering a much simpler question: what did I actually accomplish in the last six months? This is the universal challenge: how to remember accomplishments for performance reviews when months have passed.

You shipped code every day. You closed tickets. You reviewed PRs. You fixed bugs. You participated in design discussions. You mentored teammates. You made architectural decisions. All of this happened, but can you list it six months later?

Most engineers can't. Not because they didn't do the work, but because human memory doesn't work that way.

You remember the big projects. The feature launch that took three months. The incident that kept you up until 2am. But what about everything else? The steady stream of smaller contributions that actually make up most of your work?

That refactor in April? Gone. The performance optimization in May? Fuzzy. The bug fix that saved a customer from churning? You know you did something like that, but when was it exactly?

This is the documentation problem that Meta's AI doesn't solve. You can have the most sophisticated AI writing assistant in the world, but if you can't remember what you accomplished, it never makes it into your review. The challenge isn't writing—it's capturing and tracking work achievements before memory fades.

Meta's Approach Still Requires Manual Input

Here's what Meta's AI Performance Assistant actually does:

Metamate searches internal docs. If you wrote design docs, sent emails, or posted in internal forums, Metamate can find and summarize those. That's useful for context.

It generates draft text. Feed it bullet points about your work, and it'll turn them into polished review language. It knows company terminology. It can map your work to Meta's values.

It combines multiple AI models. Using both Metamate and Gemini gives employees different strengths—internal context from one, broader reasoning from the other.

But based on available information, it doesn't appear to automatically capture code commits, merged PRs, or closed bugs. Employees still need to tell the system what they accomplished.

Even with access to internal documentation, the system still relies on you remembering what's worth documenting. If you didn't write a design doc for that critical bug fix, Metamate won't find it. If you didn't post about that architectural decision in the internal forum, it's not in the system.

Your actual work—the code you shipped, the PRs you reviewed, the commits you made—isn't automatically captured.

The Missing Layer: Automatic Achievement Capture

This is where the automation gap becomes obvious. Meta employees still need to do the same thing everyone else does: manually track their accomplishments and compile them from memory before they can use the AI writing tool.

Compare this to a system that starts with your actual work:

Your Git commits are automatically captured as they happen
PRs you created and merged are tracked
Issues you closed are documented
Technical context is preserved (branch names, commit messages, dates)
When review time comes, you have a complete record

This is what automatic achievement tracking provides. You're not relying on memory. You're not scrolling through six months of Git history at 11pm. The documentation already exists because it was captured while you were working.

Then—and only then—does an AI writing assistant become useful. It can help you synthesize that complete record into compelling review language. But it needs the complete record first.

Why This Matters Now

Meta isn't just helping employees write reviews. They're changing how they evaluate them. Starting in 2026, "AI-driven impact" becomes a formal part of performance reviews. Employees are assessed on how effectively they use AI tools to deliver results.

This raises the stakes for documentation. It's not enough to say "I shipped features." You need to show how AI tools amplified your work. What did AI accelerate? Where did your strategic decisions matter most? What impact resulted from combining your judgment with AI capabilities?

Answering these questions requires complete documentation of what you actually did. Not a partial list assembled from memory. Not the big projects you remember plus a few smaller ones you happened to write down.

The complete record. Every contribution. Every decision. Every outcome.

What Meta Got Right (And What They Missed)

Meta deserves credit for recognizing that AI can improve the performance review process. Writing clear, compelling self-reviews is hard, and an AI assistant helps. The multi-model approach—combining their internal Metamate with external models like Gemini—is smart architecture.

But they solved the wrong bottleneck. The hard part isn't writing polished prose. It's remembering what you accomplished in the first place.

Put differently: Meta built a better typewriter when what employees needed was a better notebook.

How to Track Work Achievements Automatically

The solution to tracking work achievements isn't better AI writing. It's automatic capture.

Your Git history already contains a complete record of your technical work. Every commit. Every PR. Every code review. Timestamped. With context. With diffs showing exactly what changed.

This is objective documentation that requires zero additional effort. You create it automatically every time you push code.

The problem isn't the data—it's extracting meaningful achievements from it. That's where automated achievement tracking changes the equation.

Instead of manually compiling your work six months later, the system processes your Git history continuously. As you work. Commit by commit. PR by PR. When review time comes, you have a comprehensive record documenting every work achievement.

That's when an AI writing assistant becomes truly valuable. It can help you synthesize that complete record into compelling review language. But it needs the input first.

The Shift to AI-Driven Performance Reviews

Meta's move signals where the industry is heading. Other companies will follow. [AI-driven impact (https://www.bragdoc.ai/blog/documenting-impact-ai-coding-era) will become a standard evaluation criterion.

This makes comprehensive documentation even more critical. You'll need to show:

What problems you solved
How you used AI to amplify your work
Where your strategic decisions mattered
What impact resulted
How you enabled others to do better work

You can't demonstrate any of this if you forgot half your accomplishments. The engineers who thrive in this environment will be the ones with complete achievement records. Not because they're better self-promoters. Because they have better systems.

Start With Better Input

Meta built an AI to help write performance reviews. But the real leverage comes earlier: automatic capture while you work.

Then use AI to polish the writing. Start with complete data. Everything else is trying to write a good story about work you forgot you did.

Where to Go From Here

If you're using Meta's AI Performance Assistant—or any similar tool—make sure you're feeding it complete information. The AI can only work with what you give it.

That means documenting work achievements continuously. Git commits, PRs you created, issues you closed—all captured as it happens so you never have to remember accomplishments from memory.

That's what we built BragDoc to do. It extracts achievements from your GitHub activity automatically. When review time comes, you have a comprehensive record ready. Use AI writing tools to polish it, but start with complete input.

Meta built AI to help employees write reviews. You can solve the harder problem—remembering what to write—by capturing your Git history. Your actual work is already documented. It's time to use it.

The Long Game: How to Document Impact That Takes Years

Natália Spencer — Thu, 05 Feb 2026 17:01:23 +0000

Output-based reviews reward quick wins. But refactoring, mentoring, and paying down tech debt take years. Learn how to document long-term engineering impact effectively.

Engineer A shipped 47 features this year. Got promoted.

Engineer B refactored the payment system, reducing technical debt that had been slowing the team down for 18 months. No promotion.

Engineer C mentored three junior developers who went on to become productive contributors. Performance review said "needs more visible impact."

These aren't hypothetical scenarios. They're patterns we've seen repeatedly in performance review cycles at tech companies. The names are changed, but the problem is real.

This is the problem with output-based performance reviews. The system rewards what's easy to measure—features shipped, tickets closed, lines of code committed. It struggles with what actually matters most: the foundational work that takes months or years to show results.

As one thoughtful engineer recently pointed out in response to our LinkedIn post on output-based reviews: "This incentivizes short-term wins over long-term investments. Attribution is hard for foundational work that only comes to fruition after a long baketime."

He's right. And he's not alone in noticing this. A recent analysis of big tech performance systems concluded they are "neither fair, nor meritocratic, nor humane"—and one major reason is that they fail to properly attribute work that takes time to show impact.

The question isn't whether output-based reviews are perfect. They're not. But Meta, Amazon, and others have adopted them anyway. So the real question becomes: how do you document long-term impact in a way that's legible to this system—without it feeling like politics?

The Attribution Problem

Long-term engineering work creates a specific kind of documentation challenge: the impact is real, but it's disconnected from the work by months or years.

When you ship a feature, the timeline is compressed. You write code, it goes to production, metrics improve, you document the win. The cause-effect relationship is immediate and obvious.

When you refactor a core system, the timeline expands. You spend six months modernizing the codebase. Three months later, the team's velocity improves because new features are easier to build. Six months after that, a major incident is avoided because the system is more maintainable. A year out, engineers still benefit from better architecture.

The impact is real and substantial. But at review time, when your manager asks "what did you ship?", the answer is complicated. You didn't ship features that users saw. You created conditions that made future work better. That's harder to quantify and even harder to remember.

Here's what makes it worse: the people who benefit most from your long-term work often don't know you did it. The junior engineer you mentored six months ago is now independently shipping features—but when they get praised for their work, the connection to your mentorship has faded. The technical debt you paid down prevented three incidents—but those incidents never happened, so no one noticed.

Good work becomes invisible precisely because it succeeded.

Three Types of Long-Term Impact

Not all long-term work looks the same. Each type requires a different documentation strategy. (For a broader view of all developer contributions, see our guide on the 6 types of developer impact.)

1. Infrastructure and Technical Foundations

This is work that improves the system itself: refactoring legacy code, modernizing architecture, paying down technical debt, implementing better testing infrastructure, improving deployment pipelines.

The impact shows up as second-order effects: faster development velocity, fewer production incidents, easier onboarding, reduced maintenance burden. Our co-founder Ed is a huge fan of this kind of work, but we fear that in output-based review systems it's harder than it used to be for a manager to perceive and attribute the value of this kind of work.

The documentation challenge: You can't point to a feature and say "I built this." The value is distributed across everything that came after.

How to document it:

Capture before/after metrics. The key is measuring the second-order effects rather than the work itself. Research on measuring technical debt shows that while you can't directly measure "units of debt," you can track its impact on business metrics.

Example:

"Refactored authentication system to eliminate 3-year-old legacy codebase that was blocking feature development. Before: new auth features took 2-3 weeks and required working around limitations in multiple places. After: new auth features take 2-3 days. This unblocked 5 engineers who were spending 30% of their time on workarounds. Tracked via team velocity metrics—auth-related stories now close 70% faster."

Notice what this does:

Quantifies the problem (3 years old, blocking work)
Measures the improvement (weeks to days, 70% faster)
Shows the multiplier effect (5 engineers, 30% of time)
Ties to trackable metrics (team velocity)

Another example:

"Migrated CI/CD pipeline from Jenkins to GitHub Actions after repeated failures were slowing deployments. Before: builds took 25 minutes, failed 15% of the time, required manual intervention 2-3 times per week. After: builds take 8 minutes, fail rate under 2%, zero manual intervention in 3 months. Team deploys 40% more frequently and engineering time saved: ~12 hours per week across the team."

The pattern: document the old state, the new state, and the measurable difference. The work you've done there is hugely valuable, but you need to help your manager to see it and understand its impact.

Important caveat: Not every refactoring produces spectacular results. Sometimes you invest six months in modernizing a system and velocity improves by 15% instead of 70%. Sometimes the metrics are harder to quantify. Document what you can measure, be honest about what you can't, and explain why the work still mattered. "We reduced technical complexity and made the codebase more maintainable, though velocity improvements were modest (15%). However, this work prevented the system from becoming a complete blocker as we scale to new markets next year."

Realistic documentation is more credible than inflated claims.

2. Mentoring and Knowledge Transfer

This is work that multiplies the effectiveness of other engineers: mentoring junior developers, onboarding new team members, conducting thoughtful code reviews, creating documentation, running internal workshops.

The impact shows up when the people you helped start contributing independently. But by then, the connection to your mentoring has faded from memory.

The documentation challenge: Your contribution is indirect. The person you mentored ships features—but they get credit for the output, and your role in enabling that output is invisible.

How to document it:

Track the progression of the people you help. Research on effective mentoring emphasizes documenting progress through specific milestones and skill development over time.

Example:

"Mentored two junior engineers (Sarah and James) through their first 6 months. Time investment: 5-6 hours per week on code reviews, pair programming, and technical guidance. Progress tracked: both completed their first production features independently by month 4, now handling increasingly complex work. Sarah led the dashboard redesign project. James resolved a critical production incident that previously would have required senior engineer intervention. Team velocity improved as they became independent contributors."

Notice what this captures:

Specific names (makes it concrete, not vague)
Time invested (shows commitment)
Progression milestones (from mentored to independent)
Concrete outputs (specific projects they led)
Team impact (velocity improvement)

Note that in impact-based review systems, you get no credit for saying "invested 5-6 hours per week on X", but it's still worth documenting to make sure you have alignment with your manager (who may want you spending more/less time doing this).

Another example:

"Created comprehensive onboarding documentation for our GraphQL API after observing new engineers spent 2-3 days ramping up. Documentation includes architecture overview, common patterns, troubleshooting guide, and example implementations. Result: new team members now productive in under a day. Documentation referenced 50+ times per month by broader engineering team. Three engineers have contributed updates, making it a living resource."

The pattern: identify the problem, document what you created, measure the improvement, track ongoing impact.

3. Architecture and Strategic Decisions

This is work that shapes how the system evolves: making technology choices, defining technical strategy, writing RFCs, establishing coding standards, preventing bad decisions.

The impact shows up when future work becomes easier because of the foundation you established. But at the time you made the decision, nothing shipped to production.

The documentation challenge: Good architecture prevents problems that never happen. You can't show an incident that didn't occur or a wrong path that wasn't taken.

How to document it:

Explain the decision context, the options considered, and the long-term consequences. Make the counterfactual visible.

Example:

"Proposed and led migration from monolithic API to microservices architecture after identifying scalability bottlenecks. Context: monolith was limiting deployment frequency (could only deploy twice per week) and preventing team autonomy (changes required coordination across 4 teams). Led technical design discussions over 6 weeks, evaluated trade-offs, built consensus. Migration launched in Q3. Results after 6 months: deployment frequency increased from 2x per week to 15x per week. Teams now deploy independently. System handled 3x traffic growth during Black Friday with no architecture changes needed."

Notice the structure:

Problem context (why this mattered)
Decision process (how you led it)
Options considered (shows judgment)
Long-term results (the payoff)

Another example:

"Advocated for adopting TypeScript across frontend codebase despite initial team resistance. Built proof-of-concept showing 40% reduction in runtime errors in converted modules. Presented cost-benefit analysis to engineering leadership. Led gradual migration over 4 months. Results after 1 year: runtime errors down 60%, onboarding time for new engineers reduced (type system makes codebase self-documenting), refactoring confidence increased (type checking catches breaking changes)."

The pattern: context, advocacy, adoption, long-term results. But this is also work, and it's hard to farm that kind of work out to AI. You just have to do it yourself, or gamble that your manager will figure it out for themselves. Nobody's coming to do it for you.

When to Document Long-Term Work

The worst time to document long-term impact is at review time. By then, you've forgotten the details, the metrics are stale, and the connection between your work and the outcomes has faded.

Here's when to actually capture it:

At the start: Document the problem state. What's broken? What's the cost? What metrics matter?

Before you refactor the authentication system, note how long auth features currently take and how many workarounds exist. Before you mentor a junior engineer, note their current skill level and what they can't do independently yet. This gives you a clear baseline.

During the work: Track your time investment and major milestones.

For long-term projects, note how much time you're spending weekly. When significant progress happens, write it down. This isn't busy work—it's building the narrative of what you're doing and why it matters.

When early results appear: Document the first signs of impact.

The first time a junior engineer ships something independently, note it. The first week where the refactored system enables faster development, capture the metrics. These early wins build the case for long-term value.

Quarterly: Review and update the story.

Set a calendar reminder to revisit your long-term projects every quarter. How has the impact evolved? What new benefits have emerged? This turns a one-time event (the work) into an ongoing narrative (the compounding impact).

Making Long-Term Impact Visible

The engineers who get credit for foundational work aren't necessarily doing better work. They're documenting it better.

Here's the framework:

1. Create a tracking document for long-term projects

Don't rely on memory. When you start a major refactoring, mentoring relationship, or architectural initiative, create a simple document:

What's the problem you're solving?
What metrics define success?
What's your time investment?
What milestones matter?

Update it monthly. By the time the work pays off, you'll have a complete narrative. Make a private github repo for it so you don't lose it, and hook up Claude Code or similar if you think you can benefit from an agentic partner.

2. Quantify the multiplier effect

Long-term work is valuable because it helps multiple people or prevents multiple problems. Make that visible.

Instead of: "Mentored junior engineers"

Write: "Mentored 2 engineers, investing 5 hours per week over 6 months. Both now contribute independently, recovering ~200 hours of senior engineer time previously spent on guidance. Team velocity increased 15%."

3. Connect your work to later outcomes

When something good happens because of your earlier work, draw the line explicitly.

"New authentication feature shipped in 3 days—this was only possible because of the auth system refactoring completed in Q2. Previous similar features took 2-3 weeks."

Your manager won't make these connections automatically. You have to show them.

4. Use your 1:1s strategically

Don't wait for formal reviews. In monthly 1:1s with your manager, share updates on long-term work:

"Quick update on the API refactoring: we're now seeing velocity improvements. Auth features that used to take weeks are now taking days. This is already paying off."

This keeps the narrative alive in your manager's mind and provides regular evidence of progress.

The Reality Check

Let's be honest: even with perfect documentation, output-based review systems will still undervalue some long-term work. A junior engineer who ships 50 small features will often get rated higher than a senior engineer who refactored a critical system—even if the refactoring created more value.

The system isn't perfect. But documentation improves your odds.

Without documentation, your long-term work is invisible. With documentation, it's at least in the conversation. Your manager might not be able to give you full credit for work that took a year to pay off—but they can't advocate for you at all if they don't know what you did or why it mattered.

The goal isn't to game the system. It's to make sure your actual contributions are visible within an imperfect system.

When Documentation Isn't Enough

Documentation helps—but it's not magic. There are situations where even perfect documentation won't change the outcome:

Forced ranking systems: If your company uses stack ranking that requires a certain percentage of engineers to receive low ratings, someone has to get cut regardless of performance. Documentation can help you avoid being that person, but it can't eliminate the system's built-in quota.

Biased managers: If your manager doesn't value the type of work you're doing, or has already decided on ratings before reading documentation, no amount of evidence will change their mind. In these cases, the problem isn't your documentation—it's your manager or your company culture.

Toxic environments: Some workplaces systematically devalue certain types of work or certain types of people. If refactoring and mentoring are consistently dismissed as "not real engineering," that's a cultural problem that individual documentation can't solve.

The wrong level of work: If you're a senior engineer spending all your time on junior-level tasks (even well-documented ones), that's a scope problem. Documentation shows what you did, but promotion committees want to see you operating at the next level.

If you're documenting thoroughly and still being consistently undervalued, that's a signal. Sometimes the right answer isn't better documentation—it's a different team or a different company. Documentation should make good work visible. If your workplace can't or won't see good work even when it's documented clearly, that tells you something important about the workplace.

Start This Week

Pick one long-term project you're working on right now—a refactoring, a mentoring relationship, an architectural initiative.

Create a simple document with four sections:

Problem: What's broken or inefficient right now?
Your work: What are you doing to fix it?
Time investment: How much effort is this taking?
Success metrics: What will improve when this is done?

This takes 10 minutes to set up and 5 minutes per month to maintain. That's 70 minutes over a year—far less time than you'll spend scrambling before your next review. Throw it into a private github repo so you don't lose it.

Yes, this requires time you might not feel you have. If you're underwater with deadlines, taking 5 minutes per month to document might feel impossible. But consider the alternative: spending hours before review time trying to reconstruct what you did months ago, with half the details forgotten and none of the metrics available.

Update it monthly. By the time the impact shows up, you'll have the full story ready for your next review.

The engineers who advance fastest aren't necessarily the ones doing the most impactful work. They're the ones who document their impact most effectively—including the kind that takes years to show results.

Start documenting this week. The simplest approach: create a running document and capture the problem state before you start long-term work. Note your time investment monthly. When results appear, connect them back to the earlier work.

If you want something that automates the short-term documentation (features, commits, PRs), that's what we built BragDoc to do. It extracts your achievements from GitHub automatically. For the long-term work—the refactoring, the mentoring, the architecture—you'll still need to tell that story yourself. But at least you won't be scrambling to remember what you shipped in March.

Output-Based Performance Reviews: What Engineers Need to Know

Natália Spencer — Thu, 29 Jan 2026 16:27:25 +0000

Meta, Amazon, and X switched to output-based performance reviews. Learn what this means for engineers and how to document your impact for better reviews.

Update: Amazon just laid off 16,000 employees this week—the second wave of a 30,000-person cut that started in October. Their reason? Too many 'layers of bureaucracy' and not enough 'ownership.' Meanwhile, the employees who remain are being evaluated on their Forte system, which requires 3-5 specific accomplishments with measurable impact. The message is clear: output matters, effort doesn't.

Your performance review is changing. Meta, Amazon, and X just made it official: they're rating engineers on output, not effort.

Earlier this month, [Meta announced (https://finance.yahoo.com/news/meta-changing-performance-review-reward-171427657.html) a complete overhaul of its performance review system. The new platform, called Checkpoint, does away with the old model and introduces something more direct: employees will be rated on what they delivered, not how hard they worked.

Amazon made a similar move earlier this month. Their internal review system, Forte, now requires employees to submit 3-5 specific accomplishments—not reflections on their work style, but concrete examples of what they delivered.

X has been doing this since 2022, when Elon Musk required employees to explain their weekly accomplishments.

This isn't a coincidence. It's a shift in how tech companies evaluate engineers. And if you're not adapting, you're falling behind.

What "Output Over Effort" Actually Means

Let's be specific about what changed.

The old model rewarded presence and activity. You showed up, you worked hard, you participated in meetings, you were a good teammate. At review time, you wrote about your "contributions" and "involvement" in projects.

The new model rewards results. What did you ship? What impact did it have? Can you quantify it?

Here's how Amazon's internal guidance puts it:

"Accomplishments are specific projects, goals, initiatives, or process improvements that show the impact of your work."

They give an example of what not to write: "I contributed to team projects."

And what to write instead: "Led a cross-functional team to reduce server downtime by 15%, resulting in $2 million in savings."

The difference isn't subtle. One describes activity. The other describes output.

Why This Is Happening Now

Three forces are converging:

1. The "Year of Efficiency" became permanent. Meta called 2023 its "year of efficiency." Three years later, that mindset hasn't relaxed—it's intensified. Companies are running leaner and expecting more from fewer people. That means every person needs to justify their seat.

2. AI is changing how productivity is measured. According to internal communications reported by Fortune, Meta's head of people, Janelle Gale, told staff that "AI-driven impact" will become a core expectation starting in 2026. Employees will be assessed on how effectively they use AI to achieve results. The bar for what counts as productive output is rising.

3. Competition for roles is fierce. With 500,000 tech workers laid off since ChatGPT launched, there's no shortage of qualified engineers. Companies can afford to be selective—and they're selecting for people who can demonstrate impact, not just effort.

What This Means for You

If you're an engineer at a company that hasn't announced these changes yet, don't assume you're exempt. The pattern is clear: what starts at Meta and Amazon spreads across the industry.

Here's the practical reality:

Your manager can't advocate for you with vague descriptions. When your manager goes into a calibration meeting to argue for your promotion or raise, they need specific examples. "She works really hard" doesn't compete with "She shipped the new authentication system, reducing login failures by 60% and saving 200 support tickets per month."

Recency bias will hurt you even more. If the only outputs your manager remembers are from the last few weeks, you're competing against yourself from 11 months ago. Everything you shipped in Q1 needs to be documented, or it effectively didn't happen.

"I was busy" is no longer an excuse. Busy with what? What was the result? If you can't answer that clearly, you're in trouble.

How the New Review Systems Work

Let's look at what you're up against:

Meta's Checkpoint System

Four ratings: Outstanding (top 20%), Excellent (70%), Needs Improvement (7%), Not Meeting Expectations (3%)
Bonus multipliers: Outstanding = up to 300% bonus. Excellent = 115%. Needs Improvement = up to 50%. Not Meeting = no bonus.
Frequency: Two review cycles per year, bonuses paid twice annually

The gap between "Excellent" (115% bonus) and "Outstanding" (up to 300% bonus) is massive. The difference? Documented, quantifiable output.

Amazon's Forte System

Required: 3-5 specific accomplishments with measurable impact
Linked to compensation: Your "Overall Value" rating determines pay
Explicit criteria: Must connect accomplishments to Amazon's Leadership Principles

Amazon's guidance is explicit: "Consider situations where you took risks or innovated, even if it didn't lead to the results you hoped for." They want specifics, even about failures.

The Engineers Who Will Thrive

The engineers who succeed in this environment share one trait: they document their output as it happens.

Not at the end of the quarter. Not the week before reviews. As it happens.

Here's why that matters:

Details fade. You shipped something important in March. By November, you remember that you did it, but not the specifics. Not the metrics. Not the context that made it matter.

Context gets lost. The feature you built was important because it unblocked another team, saved the company from a compliance issue, or prevented a customer from churning. Six months later, that context is gone unless you wrote it down.

Impact compounds. A single achievement might not seem impressive. But when you can show a pattern—five performance improvements, three mentorship wins, two architectural decisions that paid off—the story becomes compelling.

What to Do Starting This Week

You don't need to wait for your company to announce a new review system. Start documenting your output now.

1. Shift your language from effort to output.

Effort-based (old)	Output-based (new)
Worked on the payment system	Shipped payment retry logic, reducing failed transactions by 12%
Helped with the migration	Led database migration affecting 2M records with zero downtime
Participated in code reviews	Reviewed 47 PRs, catching 3 critical security issues before production

2. Capture metrics when they're fresh.

The week you ship something, you know the numbers. You know how much faster it is, how many errors it prevents, how much time it saves. Write that down immediately. In three months, you won't remember.

3. Document the "why," not just the "what."

"Fixed a bug" tells your manager nothing. "Fixed a race condition in the payment queue that was causing 2% of transactions to fail silently, protecting approximately $50K/month in revenue" tells a story.

4. Review monthly, not quarterly.

Set a calendar reminder. Once a month, look at what you shipped and make sure it's documented with impact. This takes 15 minutes and saves hours of scrambling before reviews.

The Bottom Line

The shift to output-based reviews isn't a trend—it's the new normal. Meta, Amazon, and X aren't experimenting. They're standardizing an approach that rewards engineers who can demonstrate what they delivered, not just that they showed up.

This is actually good news for engineers who do great work but struggle to talk about it. The new systems don't reward self-promotion or politics. They reward documentation. Specifics. Impact.

If you've been doing good work quietly, now's the time to start writing it down. Your next review depends on it.

Start documenting this week. The simplest approach: create a running document and add one win every Friday. Note what you shipped, what impact it had, and any metrics you can attach.

If you want something that captures your output automatically, that's what we built BragDoc to do. It connects to your GitHub, extracts achievements from your commits and PRs, and helps you translate them into the kind of impact statements that perform well in the new review systems.

Your effort matters. But only your documented output will be rewarded.

Your Manager Can't Fight for You Without Documentation

Natália Spencer — Tue, 20 Jan 2026 20:31:20 +0000

Documentation isn't bragging. It's giving your manager the evidence they need to advocate for you in salary, promotion, and bonus conversations.

I used to think documenting my work was bragging. Then I realized my manager had no idea what I'd actually done.

Developers hate talking about their work.

You've shipped features that changed how your company operates. You've fixed bugs that saved thousands. You've mentored juniors. You've made technical decisions that will echo through the codebase for years.

And when you think about telling anyone about it, you cringe.

That cringe is real, and it's built into the culture. We celebrate humility. We're skeptical of chest-thumping. We believe work should speak for itself. These are mostly good values—but they come with a cost.

The cost is that your manager doesn't know what you've done.

That's not because your manager is bad. It's because your manager isn't a mind reader. They manage multiple people. They attend meetings. They spend their day reacting to problems. They're not in your head. They don't see every pull request, every architecture decision, every problem you solved at 2am when the production system went down.

Without documentation, your manager has to rely on two things: what they happen to witness, and what they happen to remember. And neither of those things is reliable.

The Real Problem Isn't Bragging

The discomfort developers feel about documenting their work isn't really about bragging. It's about framing.

When you frame documentation as self-promotion, it feels icky. "I'm telling people how great I am." That violates our values, so we avoid it.

But documentation isn't self-promotion. It's something else entirely.

Documentation is giving your manager the tools to do their job.

Your manager's job includes advocating for you. In salary conversations, bonus discussions, and promotion decisions, they need to make a case for why you deserve X rather than Y. That case is stronger with evidence.

When your manager walks into a budget meeting and says "I have an engineer who's been crushing it," that's persuasive. When they walk in and say "I have an engineer who led the migration to the new payment system, reducing transaction latency by 40%, and also shipped the new admin dashboard while mentoring two juniors, and fixed the race condition in the order processing system," that's a completely different conversation.

The second version isn't bragging. It's documentation. And it makes your manager's job easier.

Your Manager's Memory Is Not Reliable

Here's what actually happens:

Your manager has eight, ten, sometimes fifteen people on their team. They spend time in meetings about roadmap, hiring, company strategy, other teams' problems. They get pulled in six directions. They're genuinely trying to keep everyone's wins in mind.

But they're human. Human memory is terrible at retaining specific details over long periods.

If you shipped something critical in March, your manager was excited about it in March. They might have mentioned it in a 1:1. But by November, when review season arrives, that work has been abstract in their mind for eight months. The details are fuzzy. The impact is vague. It blends together with everything else you've done.

Meanwhile, something you shipped last week is crystal clear. It's recent. It's concrete. Your manager can articulate exactly what happened.

This is how memory works. Research shows that memories become weaker and more susceptible to distortion over time—details fade, specifics blur into generalizations, and confidence stays high even as accuracy drops. The result in the workplace? Recent work gets overweighted in performance reviews—a well-documented pattern called recency bias—while earlier contributions fade into the background.

Documentation solves that problem. Not because it eliminates bias—nothing does—but because it gives your manager a way to fight it.

When your manager has a clear list of what you shipped, when you shipped it, and what the impact was, they can argue for you even when their memory is fuzzy. The documentation is the backup.

Documenting Work Is Collaboration

Here's the reframe: documenting your work isn't self-promotion. It's collaboration.

You and your manager have the same goal: accurately representing your contributions so that compensation, promotion, and opportunities reflect the value you create.

Your manager wants to advocate for you. They want to make the case for a raise or a promotion. But they can't do that without information. When you don't document your work, you're not being humble—you're making their job harder.

You're forcing them to either:

Guess based on fuzzy memory
Ask you directly (awkward in many cultures)
Underestimate what you've done

None of those outcomes are good for anyone.

Documentation is how you help your manager do right by you. It's collaboration in the direction of fairness.

When you keep track of your wins and share them with your manager, you're saying: "Here's the information you need to make a strong case for me." That's not bragging. That's teamwork.

How to Document Without Feeling Slimy

So how do you actually document your work in a way that doesn't feel gross?

Make it factual, not emotional. "Shipped payment processing feature" is documentation. "I'm awesome and single-handedly saved the company by shipping the payment feature" is self-promotion. Write the first one.

Focus on impact, not effort. "Reduced database query time from 500ms to 50ms" is useful. "Spent three weeks optimizing database queries" doesn't tell anyone why it mattered. Focus on what changed, not how hard you worked.

Share it with your manager, not everyone. Documentation isn't about making a public show of what you did. It's about giving your manager the evidence they need. Share it in 1:1s, in your self-evaluation, in emails that happen to capture what you've shipped. Keep it between you and the person who advocates for you.

Update it throughout the year. The worst time to document is right before reviews. By then, you've forgotten half the details. Document as you go. Note achievements when they happen. Review monthly. By the time formal feedback arrives, everything is clear and accurate.

This isn't bragging. This is professionalism. This is taking responsibility for making sure the people who advocate for you have the ammunition to do it well.

Your Manager Wants to Advocate for You

Here's what's worth remembering: your manager probably wants to fight for you. They want to push for a raise. They want to promote you. They want to make sure you get credit for the good work you're doing.

But they're fighting uphill without information.

When you document your work, you're not being arrogant. You're giving them a fighting chance.

Next review cycle, when your manager is in a meeting arguing for your compensation or your promotion, they'll have specific evidence. Concrete examples. Clear impact statements. That's the difference between "this person is great" and "this person shipped X, which resulted in Y, and also did Z."

The second version wins the argument.

So start documenting. Not because you need to brag. But because your manager needs ammunition, and you're the only one who can provide it. It's not self-promotion. It's fairness.

Start documenting this week. The simplest approach is a running document where you note wins as they happen. Even a bullet point is enough—just capture the what and the impact while it's fresh.

If you want something that does the heavy lifting for you, that's why we built BragDoc. It connects to your GitHub, extracts achievements from your commits and PRs, and helps you turn them into documentation you can actually share. No more scrambling before reviews trying to remember what you shipped in March.

Introducing Workstreams: See the Patterns in Your Career

Natália Spencer — Thu, 15 Jan 2026 21:38:00 +0000

BragDoc now automatically groups your achievements into meaningful themes. Discover what you've really been working on and tell a better story in your next performance review.

Automatic grouping of your Achievements

You've been tracking your Achievements in Bragdoc, maybe dozens of them by now. But when it's time to write your self-review or update your resume, you're still staring at a long list trying to figure out what story it tells.

Today we're launching Workstreams — a feature that automatically discovers the themes and patterns in your work.

What Are Workstreams?

Workstreams are AI-generated clusters of related achievements. Instead of a chronological list, you see your work organized by what it actually represents:

Backend Performance Optimization — 8 achievements
Team Leadership & Mentoring — 12 achievements
API Design & Integration — 6 achievements

Each workstream tells a story about a theme in your career. The groupings happen automatically based on what your achievements are actually about, not just when you did them or which project they belonged to.

Why This Matters

Performance reviews become easier. 6 months worth of Achievements can be overwhelming, but Workstreams put them each into context. Each workstream becomes a talking point. You can immediately see where you've been spending your time and what impact you've had in each area.

Career patterns become visible. Are you becoming more specialized or more generalist? Are you developing the skills you want to grow? Workstreams show you the actual shape of your work over time.

Your story writes itself. When someone asks "what have you been working on?", you have a real answer. Not a list of tasks, but a narrative about the themes that define your contributions.

Better Performance Reviews

The creation of Workstreams helps you better prepare for Performance Reviews by providing clear context about how all of your hundreds of Achievements this year fit into the themes that define your contributions. Seeing the wood through the trees is the first step in writing a great self-review.

Next week, we'll be launching the first version of the bragdoc.ai Performance Reviews tool, which builds on Workstreams and automatically creates excellent self-reviews to support your next Performance Review.

The documents it creates can be completely personalized to how your company does performance reviews, and you can create as many Performance Reviews as you want, with each one aware of and able to refer back to the last. More to come next week!

Try It Now

Workstreams are available to all BragDoc users with 20 or more achievements. Just click "Generate Workstreams" in your dashboard and watch as your achievements organize themselves into meaningful groups.

Want to see it in action first? Try our instant demo — it's pre-loaded with sample data so you can explore Workstreams right away:

Learn More

Head to the Workstreams feature page for the full details on how it works, use cases, technical specs, and FAQs.

Workstreams is our biggest feature launch since BragDoc v2. We can't wait to hear what patterns you discover in your own career. Give it a try and let us know what you think.

The Promotion Gap: Why Engineers Get Overlooked

Natália Spencer — Tue, 13 Jan 2026 18:33:21 +0000

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.

Stop Setting Goals, Start Tracking Wins

Natália Spencer — Mon, 05 Jan 2026 20:21:18 +0000

Forget New Year's goals—they fail by February. Learn why tracking wins instead is more effective for your career advancement.

It's January 5th. Your inbox is full of emails about "crush your 2026 goals" and LinkedIn is overflowing with goal-setting frameworks. Everyone's talking about OKRs, SMART goals, and accountability partnerships.

And here's the thing: almost none of it will work. Your goals will be forgotten by February. Life will happen. Motivation will fade. You'll be right back where you started.

So let's stop pretending that goal-setting is the answer. It's not. There's something far more effective—and way simpler.

Why Goals Fail (And It's Not Your Fault)

Goal-setting sounds perfect in theory. You identify what you want. You make it specific and measurable. You track progress. You crush it.

Except you don't.

The research is brutal. Studies show that 92% of New Year's resolutions fail by mid-February. And it's not because people lack discipline. It's because goals are fundamentally misaligned with how humans actually work.

Goals are abstract. You set "improve my technical leadership" and then what? How do you know if you're making progress? The target is too vague, too far away, too dependent on circumstances outside your control.

Motivation evaporates. That motivational rush on January 1st gets crushed by the reality of January 5th. When your goal is "get better at system design" and you're stuck debugging a production issue at 3 AM, the goal feels irrelevant. Life always wins.

Goals ignore compounding. You set a goal, fail to hit it, and feel like a failure. But you're missing something crucial: the small wins you did achieve still count. They compound. You just didn't notice them because they weren't on your goal list.

Most goals don't matter for your career anyway. Your manager doesn't care about your personal goals during performance review season. They care about what you actually accomplished. What you shipped. What problems you solved. What impact you created.

If your goal was "improve code quality" but you shipped a feature that doubled user engagement, your goal becomes irrelevant. But that accomplishment? That's permanent ammunition for your career.

The Alternative: Track Your Wins Instead

Here's what actually works: stop setting goals. Start tracking wins.

A "win" is any achievement, no matter how small. Shipped a feature. Fixed a critical bug. Mentored a junior engineer. Improved build times. Documented a complex system. Unblocked a team. Solved a thorny problem.

The magic of tracking wins is that it's reactive, not predictive. You're not guessing about what you'll accomplish. You're documenting what you actually did. No motivation required. No willpower required. You just show up, do your job, and write down what happened.

Think about what happens across your year:

You ship 5-10 significant features
You fix 20+ bugs, some important
You review 100+ PRs
You help teammates solve problems
You attend meetings that matter
You make architectural decisions
You respond to incidents
You mentor junior engineers
You improve tooling and infrastructure

That's probably 50-100 meaningful contributions across 12 months. That's more than enough.

But here's the problem: you won't remember them. Your brain is designed to move on to the next problem. In six months, you won't remember what you shipped in January. In nine months, you'll forget which features you built versus which your teammates built.

That's why tracking wins matters. You're creating a permanent record of what you actually accomplished.

Why Tracking Wins Works (And Why Goals Don't)

Goals are about the future. Wins are about the present. And the present is all you can actually control.

When you track wins, you're not fighting motivation. You're just documenting reality. Did I ship something today? Write it down. Did I fix something important? Write it down. Did I help someone? Write it down.

No willpower required. No motivation required. Just honesty.

Wins compound in ways goals don't. You don't set a goal to "have 50 achievements this year." You just document them. By March, you've accumulated 15. By July, 40. By December, you've got a comprehensive record of what you actually contributed.

Wins are currency for the moments that matter. Performance reviews? You've got 50 concrete examples. Salary negotiation? You can point to specific wins and their impact. Job interview? You've got detailed stories ready. Promotion conversation? You've got proof.

Wins don't require perfection. A goal asks: did I hit my target? Win tracking asks: did I do something that mattered? Those are different questions. The second one is actually answerable.

How This Connects to Your Brag Doc

A brag doc is simply a running list of your wins. Nothing fancy. No perfect grammar. No elaborate structure.

You might organize them by quarter, by project, by impact type. Or you might just make it a chronological dump. The organization doesn't matter. The wins themselves do.

When you prepare for your Q1 performance review, you don't scramble to remember what you did. You open your brag doc and you've got it all right there.

When you're interviewing for a new role, you don't stumble through vague descriptions. You've got detailed examples of your impact, including metrics and context.

When you discuss career growth with your manager, you come with evidence, not hopes. That shifts the entire conversation.

This is why brag documents matter. They're not about bragging. They're about remembering. They're the difference between underselling your work and being paid what you're actually worth.

The Easiest Way to Start

The hardest part of tracking wins is remembering to do it. You ship something, move on to the next problem, and forget to write it down.

That's why BragDoc exists. It automatically extracts achievements from your Git history, so you don't have to remember what you shipped. Your commits and code reviews become documented wins without you lifting a finger.

You focus on the work. We handle the documentation.

By the end of March, you'll have 30-50 concrete wins documented automatically. By the end of the year, you'll have 100+. And every single one of them will be ammunition for your career.

Or Do It Manually

Prefer to do it yourself? That works too. You just need five minutes and one document.

Create a Google Doc, Notion page, or Markdown file. Call it "2026 Wins" or literally anything. Add 3-5 recent wins from the last month. Then every Friday, jot down what happened. One line per win. Two sentences max.

"Shipped new logging infrastructure that reduces debugging time by 30%"
"Fixed race condition in payment processing that was causing 2% of transactions to fail"
"Mentored Alex through their first production feature deployment"
"Led architecture discussion that unblocked the mobile team"

That's a brag doc. Not fancy. Not complicated. Just honest.

Skip the Goals. Track the Wins.

Here's what I'd do if I were you: don't set any New Year's goals. Instead, create a brag doc today. Add three wins from the last month. Then every Friday, add one or two more.

By March, when everyone else is abandoning their goals, you'll have a comprehensive record of what you actually accomplished. And that's infinitely more valuable than a list of intentions that never happened.

Your career depends on the wins you document, not the goals you set.

So skip the goals. Track the wins.

New Year's Resolution: Start a Brag Doc

Natália Spencer — Mon, 29 Dec 2025 21:36:49 +0000

Forget the gym membership. A brag doc is the one resolution that actually pays off. Here's why it matters and how to start in 5 minutes.

New Year's resolutions are mostly theater. You'll hit the gym six times in January. You'll read that book and never finish it. You'll swear off caffeine and break by February 2nd.

But there's one resolution that actually works. One that doesn't require motivation or discipline. One that literally pays off.

Start a brag doc.

Why This Resolution Actually Works

Unlike gym memberships, a brag doc has immediate, concrete payoff. You're not doing this for future-you in six months. You're doing this for future-you in three months, during performance review season. And three months is close enough that you'll actually care.

Here's the deal:

During reviews, you'll remember what you did instead of scrambling at the last minute. No more scrolling through GitHub at 11 PM trying to piece together what you actually accomplished.

During interviews, you'll have a running list of your wins. No more vague hand-waving. You can point to specific accomplishments, metrics, and impact.

During conversations with your manager, you'll sound confident because you've documented your work. You won't accidentally undersell something or forget to mention something important.

During salary negotiations, you'll have ammunition. You can point to concrete wins and their business value. That's infinitely more powerful than "I think I've done good work."

This isn't meditation. It's not one weird trick. It's giving yourself the best chance to advance in your career.

The Easiest Resolution Ever

Here's the best part: you don't need to become a different person. You don't need discipline or motivation.

You just need to keep one running document. That's it.

Every time you ship something meaningful, fix something important, help someone, or solve a problem—jot it down. One line. Two sentences max. No perfect grammar required. No elaborate formatting.

Just a list of stuff you did.

"Fixed the N+1 query bug in the dashboard API"
"Mentored Alex through their first major feature"
"Reduced build time from 22 minutes to 8 minutes"
"Led the on-call rotation for Q4"

That's your brag doc. It's that simple.

How to Actually Start

Today: Open a document (Notion, Google Docs, a Markdown file, whatever). Call it "2025 Wins" or "Brag Doc" or literally anything.

This week: Add 3-5 things you've already accomplished. You don't have to go back through your entire history. Just the wins you remember from the last few weeks.

Moving forward: When you finish something, take 5 minutes and write it down. That's it. One line per week on average. You can do that.

If you want structure, we have a template that organizes wins by impact type. But honestly? A plain list works fine.

The Resolution That Compounds

New Year's resolutions die because they feel pointless. You'll never actually look like the people in those fitness ads. But your brag doc? You'll use it in Q1 reviews. You'll use it in interviews. You'll reference it with your manager.

The resolution compounds. Every achievement you document this year becomes easier next year. By 2026, you'll have a two-year running record. By 2027, three years.

You'll never scramble during review season again.

Make It Effortless

The hardest part of any habit is remembering to do it. BragDoc solves that by automatically extracting achievements from your Git history. Your commits and code reviews become documented wins without you lifting a finger.

You focus on shipping. BragDoc handles the documentation.

Your New Year Setup

Make 2025 the year you stop scrambling during performance reviews. Stop underselling your work. Stop forgetting what you did.

Open that document today. Add three wins. Do it again next week. By March, you'll have a comprehensive record of what you accomplished.

Your future self will thank you. Your manager will notice. Your next raise will reflect it.

That's a resolution that actually works.

Ready to make this a habit? Check out our template for more structure, or learn why automated brag docs save time. Either way, start documenting today.

Your career depends on it.

How to Prepare for Q1 Performance Reviews Right Now

Natália Spencer — Wed, 17 Dec 2025 20:22:57 +0000

The year is almost over. You've shipped code, solved problems, and made an impact. Now comes the hard part: remembering what you actually accomplished.

This is the critical window. Right now, while 2025 is still fresh, your memories are clear and your context is available. In three weeks when everyone returns from the holidays, motivation vanishes and memory fades fast. The achievements you took for granted in December will feel like ancient history by March.

If you wait until Q1 performance review season to document your work, you'll be scrambling. You'll forget projects. You'll miss context. You'll undersell your impact because the details have evaporated.

The smartest move is to document now, while everything is still vivid.

Why This Month Matters Most

Your brain isn't built to retain a year of work. It's optimized for the next problem, not the last one. This is fine for day-to-day engineering, but it's terrible for career documentation.

Here's the timeline:

This week: Memories are sharp, context is fresh, you remember why decisions mattered
January: Holiday reset means you're mentally refreshed but details are already fading
March: Review season arrives and you're scrambling, remembering maybe 40% of what you did

The difference between a great performance review and a mediocre one often comes down to this: did you document your work when memory was strong, or did you wait until memory was weak? Understanding what managers actually look for makes this even clearer.

What to Capture Right Now

Don't try to write perfect achievement statements yet. Just capture the raw material while it's fresh. You can refine later.

Major projects shipped:
List every significant feature, system, or change you shipped in 2025. For each one, note: what problem you were solving, your specific role, who else was involved, and when it shipped.

Metrics and quantifiable impact:
Query latency improvements, test coverage increases, deployment time reductions, infrastructure cost savings, support tickets reduced, incident frequency decreased. Numbers are powerful. Capture them now before they're lost. This is why automated brag docs save so much time—they capture metrics automatically.

Challenges overcome:
What was genuinely difficult? What did you learn? "Debugged a race condition that took three days to track down" and "Led a contentious technical decision where teams disagreed" both demonstrate growth and judgment.

Code reviews and mentoring:
If you spent significant time reviewing code or helping teammates, capture that. This is one of the six types of developer impact that often gets overlooked. Don't just say "did code reviews." Get specific: "Reviewed 150+ PRs this year" or "Mentored two junior developers through their first major features."

Reliability and incident response:
If you participated in on-call rotations, debugged production issues, or improved systems reliability, document it with specifics.

Cross-team collaboration:
Did you work with product, design, sales, or other engineering teams? Document the context and your role.

Where to Find This Information

You're not starting from scratch. Your work already exists in multiple places.

Git history and pull requests: This is your primary source of truth. Find the main PRs for each major project, note merge dates, capture commit message summaries, and check PR discussions for context about decisions and challenges.

Issue tracking system: Issues capture the problem statement, acceptance criteria, and decision-making. Search for issues you reported or worked on.

Slack and email: Look for praise or feedback from teammates, questions where you provided key answers, discussions about decisions you influenced, and project announcements you were part of.

1-on-1 notes: These often contain feedback about your growth, challenges you're working on, and goals you hit.

Your calendar: Look at tech talks or training you gave, architecture decision meetings, project kickoffs, and presentations.

How to Structure Your Self-Review

Once you've gathered your raw material, organize it by impact category rather than chronologically:

Code & Features: Products and features you shipped
Reliability & Debugging: Critical issues resolved, production incidents handled
Technical Leadership: Architecture decisions, system design, technical direction
Mentoring & Knowledge Sharing: Code reviews, onboarding, documentation, people you helped grow
Process & Infrastructure: Build improvements, testing frameworks, dev tools
Cross-Functional Collaboration: Work with product, design, sales, or leadership

This structure helps your manager understand the full scope of your contributions. Most developers focus only on features, accidentally underselling other valuable work.

Writing Achievement Statements

For each achievement, follow this pattern:

Problem/Context: What was the situation?
Your Action: What specifically did you do?
Measurable Impact: What changed as a result?
Broader Significance: Why did it matter?

Example:

Instead of: "Fixed performance issues in the API."

Write: "Identified and resolved N+1 query problems in the user dashboard API. Reduced response times from 2.3 seconds to 340ms through query optimization and connection pooling. This improved user experience metrics by 15% and reduced infrastructure costs by $8K annually."

See? It's not flowery. It's concrete, specific, and credible.

Common Mistakes to Avoid

Being too vague. "Improved system reliability" sounds good but tells nobody what you actually did.

Underselling non-code contributions. Mentoring, process improvements, and reliability work are invisible unless you document them. Senior developers are senior because they create leverage, not just because they write more code.

Forgetting to quantify. "Mentored three junior engineers through complete features, averaging 4-5 hours per week of code reviews and pair programming" is much stronger than "mentored team members."

Only preparing positives. Managers know you're not perfect. Balanced reviews are more credible than flawless ones. Understanding what managers look for helps you strike the right balance.

Your Action Plan

This week:
Spend 30 minutes listing major projects and accomplishments. Pull your GitHub history, Jira, and Slack. Capture the raw material while it's fresh.

Before the holidays:
Write 5-10 achievement statements using the pattern above. Organize by impact category.

When you return:
You'll have this foundation ready. The hard work—capturing memories while they're strong—will be done. You can refine during Q1 before reviews actually happen.

Automate the Boring Part

If you're documenting achievements from Git history, you can automate this. BragDoc's CLI automatically extracts achievements from your commits and pull requests. Run it once before the holidays, review what it captured, and you've saved hours of manual digging.

The automation handles the busywork. You handle the context, the metrics, and the significance.

The Compounding Effect

Documentation compounds. If you document 2025 now, you have a complete record. When 2026 ends, you add to your already-solid documentation. By 2027, you have three years of clear achievement records.

Conversely, if you skip documenting 2025, when 2026 ends you're still scrambling to remember both years. Every year without documentation makes the problem worse.

Start the habit now. It pays dividends for your entire career. Learn more about why developers need automated brag docs to make this sustainable.

Start Today

Pick three major projects you shipped in 2025. For each one, jot down what you built, when it shipped, measurable impact, and who benefited. That's your starting point.

By the time Q1 reviews arrive, you'll be prepared instead of scrambling. Your work speaks for itself—but only if you document it. Ready to get started?

What Engineering Managers Look For in Performance Reviews

Natália Spencer — Tue, 16 Dec 2025 17:00:33 +0000

Performance reviews aren't some mysterious process happening in a conference room. From a manager's perspective, they're actually pretty straightforward. But there's a gap between what managers are evaluating and what developers think we're evaluating. This gap creates friction—developers undersell their work, managers feel like they're missing context, and the whole process feels less useful than it should be.

I've managed teams for years and conducted more performance reviews than I care to remember. Here's what I actually look for, and why the way you document your work matters far more than you might think.

The First Problem: I Can't Remember Everything You Did

Let me be honest: I don't have perfect memory of your last six months. I'm managing multiple people, handling incidents, attending strategy meetings, and shipping my own deliverables. Your day-to-day work—even the important work—isn't always top of mind for me when review season arrives.

This isn't an excuse for poor memory. It's just reality. What this means is that developers who document their work well have a massive advantage. They're not being evaluated on my memory. They're being evaluated on documented evidence.

When you come into your review with clear achievement statements, links to pull requests, and context around your impact, you're making my job easier and ensuring you're evaluated on your actual work, not on what I happened to remember or what I noticed casually.

The developers who struggle most in reviews are usually excellent engineers. But they assume their work speaks for itself. It doesn't. Documentation speaks for itself. Work just disappears into the codebase.

What I'm Actually Looking For

Let me break down what goes into a performance rating from my side of the table.

Evidence of Impact

I'm looking for demonstrated impact. Not effort, not hours worked, not "I was really busy." Impact.

The difference is huge. Effort is internal—how hard you worked. Impact is external—what changed as a result of your work.

Here's what I'm listening for:

Business impact: Did your work improve revenue, retention, user satisfaction, or reduce costs? Example: "Optimized our database queries, reducing infrastructure costs by $15K annually" is impact. "Refactored database queries" is not.

Team impact: Did your work unblock other engineers, improve their productivity, or accelerate their development? Example: "Set up automated testing framework, reducing QA cycle time from 2 weeks to 3 days for the mobile team" is impact. "Wrote testing code" is not.

User impact: Did your work improve the user experience, fix critical bugs, or ship features users actually want? Example: "Reduced API latency by 40%, improving dashboard load times and user satisfaction scores by 8%" is impact. "Performance optimization" is not.

The pattern is: context → action → measurable result. Managers want to see all three.

Evidence of Growth

I'm also looking for signals that you're growing as an engineer. What new skills did you pick up? What stretch projects did you take on? What feedback did you act on from previous reviews?

Growth shows ambition. It shows self-awareness. It shows you're thinking about your trajectory. Engineers who grow become better engineers. That matters for your career and for the team.

Without documentation, growth is invisible. If you learned a new programming language, architected a new system, or led a project for the first time, I might not know it unless you tell me.

If you document it as you go—"Led the API redesign project, making architectural decisions for a system that will scale to 10x current usage"—then it becomes a clear narrative of growth.

Quality of Judgment

I'm evaluating your technical judgment. Did you make good decisions? Do you think about tradeoffs? Can you defend your technical choices?

The easiest way to demonstrate judgment is through architecture decisions and technical leadership. But it also shows up in how you've documented your work. Are you being honest about challenges? Do you acknowledge tradeoffs instead of pretending your solution was perfect?

Developers who document thoughtfully—"We chose Option A despite Option B being technically superior, because the engineering cost wasn't justified by the timeline" — demonstrate better judgment than those who just say "I shipped X."

Collaboration and Communication

I'm watching to see if you work well with others. Are you helping teammates? Are you sharing knowledge? Are you receptive to feedback?

Documentation matters here too. "Mentored three junior developers through their first features" is collaboration. "Did my job and sometimes helped people" is not. The specificity proves you were actually thinking about collaboration, not just coasting.

What I'm NOT Looking For

Let me also be clear about what doesn't matter.

Busyness. "I was really busy" doesn't influence my rating. You could have been busy writing code that nobody needed. I care about direction and impact, not activity level.

Code quantity. Lines of code, number of commits, number of PRs. These are vanity metrics. Someone could ship 100 trivial PRs and create less value than someone shipping one complicated PR that solved a critical problem.

Being the smartest person in the room. Intelligence is assumed. What I'm evaluating is what you did with that intelligence. Can you apply it? Can you explain it? Can you help others use it?

Going above and beyond on everything. I don't expect you to be extraordinary at every single task. I expect you to be solid at your job and growing in key areas. "Went above and beyond" across everything raises a red flag—it usually means you're unsustainable or you're not prioritizing effectively.

How Documentation Influences Promotion and Compensation

I'll be direct: promotion and compensation decisions are heavily influenced by how well you've documented your impact.

This might sound unfair. Shouldn't the quality of your work speak for itself? In a perfect world, yes. In reality, there's selection bias. The developers I see the most clearly are the ones who communicate best. They're the ones whose work is easiest to defend in promotion discussions.

Here's how it actually works:

When promotion season arrives, I'm building a case for you with my leadership. I need to explain why you deserve a higher level. The case is stronger when I can say:

"Sarah owned the API redesign project. She made strategic decisions about tradeoffs, documented the technical RFC, and led three other engineers through implementation. The new API reduced latency by 50% and enabled us to ship features three times faster. She also mentored two junior developers in parallel."

versus:

"Sarah did good work on the API team."

Both might be true. But one is promotable. One is not. The difference is documentation.

The same is true for compensation. When negotiating budget for raises and refreshes, I need to justify why specific engineers deserve larger increases. Documentation lets me make those arguments. Without it, even excellent engineers can get underpaid simply because their impact isn't visible.

The Presentation Matters Too

How you present your work in the review itself matters. I'm not just looking at what you've documented. I'm also listening to how you talk about it.

Tell stories, not lists. Don't just say "I shipped feature X, fixed bug Y, and refactored system Z." Walk me through the context. Why did the feature matter? What was broken about the bug? Why did the refactor enable the team to work faster?

Back your claims with evidence. If you say you reduced latency by 40%, have the metrics. If you say you unblocked three engineers, be able to talk about what you unblocked them on. This isn't about being overly formal. It's about being credible.

Be honest about challenges. If something went sideways, say so. The developers who impress me most are those who acknowledge when things didn't go as planned and can articulate what they learned. That's maturity.

Discuss impact on business and team. Not just technical impact. Connect your work to what matters: shipping faster, better user experience, reduced costs, happier team members, whatever the business cares about.

What Happens When You Don't Document Well

I see this all the time. A genuinely strong engineer walks into their review with minimal documentation. They're vague about their accomplishments. They struggle to explain the business impact of their work.

The review becomes uncomfortable. I'm trying to advocate for them, but I don't have ammunition. Their rating ends up being lower than it should be. They feel undervalued. I feel frustrated because I know they're better than their review reflects.

Meanwhile, the developer who documented their work comes in prepared. Even if their actual output was slightly lower, the documentation makes them look more senior. They walk out with a better rating and better compensation.

This isn't a complaint about life being unfair. It's an observation about how to navigate the reality of performance management. Documentation is a leverage point. Using it well is professional, not self-serving.

How to Prepare for Your Review

Based on all of this, here's what I'd recommend:

Start early. Three months before your review, list your major accomplishments. One month out, gather evidence from Git, pull requests, and communications. Two weeks out, write impact statements that tell the story.

You don't need fancy formatting. You need clarity. For each accomplishment: What was the problem? What did you do? What changed as a result? Why did it matter?

Document growth explicitly. If you learned something new, took on a stretch project, or acted on feedback, write it down. Make the narrative of growth visible.

Quantify when possible. Numbers are credible. "Improved test coverage from 45% to 78%" is stronger than "improved test coverage." "Mentored three junior developers" is stronger than "helped with mentoring."

Prepare examples. Be ready to discuss two or three specific accomplishments in depth. Not a list of twenty vague things. A few clear stories with context and impact.

Practice your narrative. In the actual review, you should be able to talk naturally about your work. If you sound like you're reading from a script, it's less credible. If you sound like you're genuinely reflecting on what you've accomplished, it's more credible.

The Manager's Job Is to Advocate For You

Here's one more thing: your manager's job is to advocate for you. I want you to succeed. I want you to get promoted, fairly compensated, and recognized for your contributions.

But I can only advocate effectively when I have clear evidence of your impact. Documentation gives me that evidence. It makes my job easier. It makes promotion and compensation discussions easier. It makes your career trajectory clearer.

The developers who understand this—who document their work systematically and present it clearly—advance faster. Not because they're more talented. But because they're more effective at communicating their value.

Think of it this way: you've already done the work. You've already shipped the features, fixed the bugs, solved the problems. Documentation isn't adding more work. It's just capturing work you've already done.

Next Steps

Start with your last three months. What were your major accomplishments? List three or four things you're proud of. Then, for each one, gather supporting evidence from Git, pull requests, or team conversations. You now have the foundation for a strong performance review.

If you want to make this systematic—having documentation ready throughout the year rather than scrambling before review season, check out the six types of developer impact you should be documenting.

The clearer you are about your work, the better your manager can advocate for you.

The 6 Types of Developer Impact

Natália Spencer — Wed, 03 Dec 2025 17:51:56 +0000

Not all developer impact shows up in Git commits. Learn how to document six types of contributions that drive your career forward—from shipping features to mentoring.

Not all developer impact looks the same. You might spend a month shipping a major feature, then spend the next month mentoring a junior developer, then spend a week debugging a critical production issue. Each contribution is valuable. Each requires different documentation strategies.

Most developers document only one type of impact well: the code they ship. Everything else—the mentoring, the architecture decisions, the process improvements—gets lost because they don't know how to capture it.

Your performance review should reflect the full scope of your contributions. Here's how to document each type of impact effectively.

1. Code & Features: Shipping Functionality

What it is: The features you build, the bugs you fix, the technical work that ships to production.

Why it matters: This is the most visible work. It's what users see, what product teams request, and what leadership tracks.

How to document it:

Focus on business impact, not just technical implementation. Answer: What problem did this solve? Who did it help? What metrics improved?

Example:

❌ Vague: "Built user dashboard"

✅ Clear: "Built a user analytics dashboard that surfaced usage patterns and feature adoption metrics. Product team now uses it daily to inform roadmap decisions, reducing the time to identify underperforming features from weeks to minutes."

Another example:

❌ Vague: "Fixed payment processing bug"

✅ Clear: "Identified and resolved a race condition in payment processing that was causing 2-3% of transactions to fail. This recovered ~$45K in monthly revenue and eliminated 30+ weekly support tickets."

Pro tip: Keep a running log of PRs you ship. Note the business context, not just the technical changes. Tools like BragDoc's achievement extraction features can capture this from your Git history automatically. If you want to learn more about why this matters, read our guide on why developers need automated brag docs.

2. Mentoring & Knowledge Sharing: Teaching Others

What it is: Code reviews, pair programming, onboarding new team members, writing documentation, answering questions, giving tech talks.

*Why it matters: * Senior developers are force multipliers. Your ability to accelerate others is often more valuable than your individual output.

How to document it:

Quantify the time and scope. Name the people you helped and what they accomplished as a result.

Example:

❌ Vague: "Mentored junior developers"

✅ Clear: "Mentored two junior engineers through their first production features, spending 4-5 hours per week on code reviews, pair programming, and 1-on-1 technical guidance. Both engineers now contribute independently and have taken on increasingly complex work."

Another example:

❌ Vague: "Improved documentation"

✅ Clear: "Wrote comprehensive onboarding docs for our GraphQL API after noticing new engineers spent 2-3 days ramping up. New team members now get productive in under a day, and the docs are referenced 50+ times per month by the broader engineering team."

Pro tip: Track code reviews separately. "Reviewed 120+ PRs this quarter, averaging 1-2 hours daily. Provided detailed feedback that improved code quality and caught 3 security issues before they reached production."

3. Architecture & Technical Decisions: Shaping the System

What it is: System design, technology choices, technical strategy, refactoring, reducing technical debt, setting technical direction.

Why it matters: These decisions compound over time. Good architecture enables faster development. Bad architecture creates years of pain.

How to document it:

Explain the problem, the options you considered, why you chose what you did, and the long-term impact.

Example:

❌ Vague: "Led architecture discussions"

*✅ Clear: * "Proposed and championed migrating our monolithic API to a microservices architecture after identifying scalability bottlenecks. Led technical design discussions, evaluated trade-offs, and built consensus across 4 engineering teams. The migration is now underway and will enable us to scale to 10x current traffic."

*Another example: *

❌ Vague: "Refactored legacy code"

✅ Clear: "Refactored our authentication system to eliminate a 3-year-old legacy codebase that was blocking feature development. This unblocked 5 engineers who were previously spending 30% of their time working around limitations in the old system. New auth features that previously took weeks now take days."

Pro tip: Architecture decisions often happen in RFCs, design docs, or Slack threads. Save these. They're evidence of your technical judgment and leadership.

4. Process Improvements: Reducing Friction

What it is: Improving CI/CD pipelines, dev tooling, testing infrastructure, deployment processes, reducing build times, automating manual work.

Why it matters: Process improvements multiply everyone's productivity. A 10% efficiency gain across a 20-person team is massive.

How to document it:

Quantify time saved or problems eliminated. Show the multiplier effect across the team.

Example:

❌ Vague: "Improved CI/CD pipeline"

✅ Clear: "Reduced CI build times from 25 minutes to 8 minutes by parallelizing test suites and optimizing Docker layer caching. This saves every engineer ~1 hour per day in context switching and enables faster iteration. Across a 15-person team, this recovers ~300 engineering hours per month."

Another example:

*❌ Vague: * "Automated deployment process"

✅ Clear: "Built automated deployment tooling that replaced a 30-minute manual process with a one-click deploy. This eliminated deployment errors that were causing 1-2 production incidents per month and freed up ~10 hours of engineering time per week."

Pro tip: Before/after metrics are gold here. Measure time saved, error rates reduced, or manual steps eliminated. BragDoc helps you track these automatically.

5. Incident Response & Reliability: Keeping Things Running

What it is: Debugging production issues, on-call rotations, monitoring and alerting, postmortems, proactive reliability improvements.

Why it matters: Keeping systems running is often invisible until something breaks. Reliability work prevents future fires.

How to document it:

Focus on severity, speed of resolution, and preventative measures you implemented.

Example:

❌ Vague: "Fixed production issues"

✅ Clear: "Diagnosed and resolved a critical database deadlock that was causing 15-minute outages every few days. Root cause was complex (race condition under high load), but I identified it within 2 hours using query logs and APM traces. Implemented connection pooling changes that eliminated the issue entirely. No recurrence in 3 months."

Another example:

❌ Vague: "Participated in on-call rotation"

✅ Clear: "Covered on-call rotation for 6 weeks, responding to 12 incidents with an average resolution time of 45 minutes (team average is 90 minutes). After noticing repeated alerts for the same issue, I proactively fixed the underlying problem, reducing alerts by 40% for the entire team."

Pro tip: Keep a log of significant incidents you resolved. Note the business impact (users affected, downtime, revenue impact) and how you prevented future occurrences.

6. Cross-Functional Collaboration: Working Beyond Engineering

What it is: Working with product, design, sales, customer success, or leadership to solve problems, unblock projects, or improve processes.

Why it matters: Senior developers bridge technical and business contexts. Your ability to collaborate across functions becomes increasingly important as you grow.

How to document it:

Explain the business problem, how you contributed, and the outcome. Make your role clear without taking sole credit.

Example:

❌ Vague: "Worked with product team"

✅ Clear: "Partnered with product and design to redesign our notification system after customer feedback showed users were missing critical updates. Led technical feasibility discussions, prototyped 3 different approaches, and implemented the solution. User engagement with notifications increased 45%, and support tickets about missed notifications dropped 60%."

Another example:

❌ Vague: "Helped sales team with technical questions"

*✅ Clear: * "Supported 8 enterprise sales deals by joining technical discovery calls, answering security and compliance questions, and scoping custom integrations. My involvement helped close 3 deals worth $180K in ARR. Sales team now includes me proactively in complex technical evaluations."

Pro tip: When collaborating, acknowledge teammates but make your specific contribution clear. "Partnered with X to do Y, where I specifically handled Z."

Why This Matters for Your Career

Senior developers aren't just senior because they write more code. They're senior because they create leverage—they multiply the productivity of everyone around them through mentoring, architecture, process improvements, and cross-functional collaboration.

If your performance review only documents features you shipped, you're underselling 80% of your actual value.

Document all six types of impact. Your next promotion depends on it.

Start Documenting Today

Pick one type of impact you contributed recently that isn't code. Write one clear statement using the patterns above. That's your starting point.

If you want to automate the "code & features" documentation, BragDoc extracts achievements from your Git history automatically. For everything else, keep a simple monthly log. Ready to start tracking your impact systematically? Get started with BragDoc today.

The developers who advance fastest aren't necessarily the ones who contribute the most. They're the ones who document their contributions most effectively.