How Calibration Committees Actually Evaluate Staff Promotions

Calibration committees don't re-grade an engineer's work. They manage risk on behalf of senior leaders who have never met the candidate, never seen the codebase, and have maybe five minutes to decide whether a name on a list deserves a new title. That's the frame engineers need before anything else in this piece makes sense: the room isn't asking "was this person good this year." It's asking "can we defend this decision to everyone who wasn't in the room."

Three distinct formats get lumped together under the word "calibration," and they're not the same thing. Team-level calibration involves line managers and HR comparing notes across a department. Ad hoc calibration happens around bonus cycles, where budgets are finite and ratings get adjusted to fit. The third format, the promotion committee, is where senior leaders review nominee dossiers for people being considered for the next level. This is the format this piece is about, and it behaves differently from the other two because the stakes are structural. A bad bonus calibration costs money. A bad promotion calibration puts someone into a role they can't yet handle, or worse, keeps someone out of a role they've already earned.

The committee's real job is comparison and consistency. One manager's "great" has to mean the same thing as another manager's "great," which means proposed ratings get placed side by side and checked against a shared rubric. Before calibration, one person judges alone. After it, multiple observations meet a common yardstick, and that single shift, from solo judgment to group alignment, is what the rest of this piece is built around.

Why the manager's support is necessary but not sufficient

A manager who wants an engineer promoted will fight for that outcome, write the nomination, and sit in the room making the case. None of that guarantees the promotion happens, because the manager's enthusiasm has to survive contact with people who've never worked with the candidate and have no reason to take anyone's word for it.

Calibration exists to create fairness across teams, but the mechanism that enforces fairness also opens the door to politics. The strength of a manager's advocacy ends up mattering as much as the engineer's actual performance. It's a predictable outcome of asking humans to argue for other humans in front of other humans: the engineer whose manager is persuasive, well-connected, and experienced in the room gets promoted. The engineer whose manager is quiet, new to the process, or unpracticed at advocacy stays at their current level, regardless of what either engineer actually produced that year.

The engineer can't fix who their manager is. What the engineer can do is change what the manager has to work with. The job isn't to convince the manager, who's already convinced, it's to hand the manager a packet that makes the argument easy to defend against skeptics. Adjectives don't hold up in that room. "Strong technical leader" gets challenged. Named artifacts and verifiable outcomes don't, because there's nothing to argue with when the evidence is a document someone can open and read.

This work starts long before the formal cycle opens. An engineer who begins assembling evidence in the weeks before calibration ends up leaning on whatever happened most recently, which skews the case toward the last project and away from the full year. A running log, kept over months, of shipped work, peer feedback, and moments where the engineer operated above their current level gives the manager raw material to build from. The energy spent managing the relationship with the manager is better spent building the dossier the manager will carry into the room.

The structural flaw calibration was built to fix, and the bias it introduced instead

Calibration was built to solve a specific, well-documented problem: one manager's "meets expectations" means something completely different from another manager's "meets expectations," and without a shared process, those gaps compound into unfair outcomes across an entire organization. Putting ratings side by side was supposed to fix that. The fix works, partially, and introduces its own distortions in the process.

Three conditions have to be present for calibration to function as designed: written evidence submitted before the discussion starts, an absolute rubric that measures each candidate against a fixed standard rather than against each other, and active management of bias during the discussion itself. Most committees show up with exactly one of these three. They have the written ratings. They skip the rubric discipline and the bias controls, and that gap produces the distortions visible in the final ratings.

Committees lean toward adjusting ratings downward far more often than upward. Supervisors, left to their own judgment, tend to rate more generously than an organization's targets call for, which puts structural pressure on the group to pull cases back toward the center. The committee ends up correcting too generous ratings by pulling everyone toward the middle, regardless of where they actually land. Standout performers get flattened. Weak performers get propped up. The distribution looks orderly and the individual judgments underneath it get less accurate.

There's a second distortion layered on top of the first. Supervisors in calibration rooms don't share everything they know. They share strategically, protecting information that might hurt their own candidates or reflect poorly on their own judgment, and that selective sharing reduces the quality of the group's deliberation. A committee can only be as good as the information put in front of it, and the incentives in the room push toward less information, not more.

None of this means calibration should be scrapped. Without it, rating standards drift apart by team, engineers learn which managers grade easy, and talent quietly migrates toward whoever hands out the best reviews. That's a real organizational cost, and it's the reason calibration persists despite its flaws. The answer is to understand the incentives working against a fair outcome and build a case sturdy enough to survive them.

What the committee is measuring: scope, impact, and influence at the next level

A calibration committee doesn't promote the most skilled senior engineer in the pool. It promotes the person who's already operating at the next level, consistently, over time, with evidence to show for it. That distinction changes what an engineer should spend the year building toward.

Three categories appear repeatedly across documented promotion criteria: scope, measured by how much of the organization a piece of work touches; impact, measured by outcomes at the systems level rather than individual output; and influence, measured by how much the people around the candidate have grown because of them. Coding ability doesn't appear on that list because at the staff bar it's assumed. An engineer who can't write excellent code is excluded from the room for discussion. The committee is testing for what the engineer does once the code works.

Tenure doesn't substitute for any of the three categories. Five years of outstanding senior-level work is still senior-level work, no matter how many years it spans. A promotion decision has to reflect what the engineer is already doing, not what the engineer might eventually be capable of.

A staff-level case built on one enormous project followed by a year of ordinary senior output won't clear the bar, because the committee is looking for sustained staff-level contribution, not a spike. Four shifts tend to separate the candidates who clear that bar from the ones who don't. The first is a move from individual velocity to organizational velocity: the team around the candidate ships faster because of something the candidate built, and the artifact proving it is usually a document, a review process, or a mentee who got promoted on the strength of that mentorship. The second shift is from individual influence to written, durable influence. Verbal authority works inside one team and stops working the moment the candidate isn't in the room. Staff-level work leaves behind artifacts, documents someone reads three quarters later to make a decision the original author never has to be present for.

Microsoft's impact model captures this distinction directly by scoring three things separately: an engineer's own accomplishments, how that engineer contributed to other people's success, and how that engineer built on the work of others. Under that model, an engineer who ships a great feature entirely alone can score below an engineer who ships something smaller but unblocks two other teams in the process. The committee weighs who else got better because the candidate was there.

Peer recognition carries real weight in this evaluation, specifically recognition from staff and senior engineers outside the candidate's immediate team. That recognition matters because it comes from people with no stake in the outcome. The candidate's level of operation is legible to strangers, not just to a manager who already wants the promotion to happen.

The three types of evidence that move a calibration committee

A packet built on project lists and adjectives gives a calibration committee nothing to point to. The evidence that survives the room shares three qualities: it's verifiable, it's self-contained, and it doesn't require anyone in the room to already know the backstory.

Written artifacts carry the most weight of any evidence type. RFCs, architecture decision records, post-mortems, and design docs all qualify, because they exist independently of the engineer who wrote them. "Wrote the RFC for our deprecation strategy" beats "led a deprecation" in every calibration room, because the RFC can be read by a committee member who's never heard of the project, and it outlasts the engineer's tenure on the team. A packet where every single project happened inside the engineer's own team raises an immediate question for the committee: can this person operate outside familiar territory, or does every success depend on a manager directing the work?

Cross-functional impact answers that question directly. Evidence that the candidate's work changed something outside their direct scope, another team's roadmap, a shared system, a cross-org decision, tells the committee the candidate can operate without someone else steering.

The third evidence type is the multiplier: quantified proof that the candidate made other people more effective. Reduced MTTR. A faster onboarding timeline. Mentees who went on to get promoted. A review process that measurably improved a team's throughput. These numbers matter more now than they used to, because AI tools compress how much individual code output says about an engineer's value. When volume stops being a reliable signal, committees look for judgment instead, measured by the decisions an engineer made, not the lines they shipped.

Every piece of evidence in a packet should be quantified wherever the number exists: incident response time cut by a specific margin, a migration that saved a specific amount, three junior engineers mentored and subsequently promoted. Adjectives describing the engineer's qualities get challenged and discounted. Numbers describing outcomes don't. The test for every project in the packet is simple: would it make sense to a smart, senior engineer with zero context on the team, the quarter, or the codebase? If the story depends on the reader already knowing what happened, it won't survive the room.

How Google, Meta, and Microsoft run the process

Scope, impact, and influence form the evaluative core everywhere, but each company operationalizes those categories through a different mechanism, and the mechanism shapes what evidence actually counts.

Meta handles this inside its Performance Summary Cycle, which runs twice a year.

Microsoft runs its process through Connect, a periodic written record where engineers document priorities and impact over time. Microsoft's three-part impact model underlies Connect, scoring an engineer's own accomplishments, how that engineer contributed to others' success, and how that engineer built on others' work. The model is structured to reward the engineer who unblocks two teams over the engineer who ships a bigger feature solo. A Connect entry heavy on individual output without any mention of other people's success tells an incomplete story by the model's own standards.

Startups and scale-ups don't usually have either of these formal mechanisms. The ladder is often informal or recently written, and titles like "Founding Engineer" carry no fixed scope, so they don't map cleanly onto a standard level at a larger company. The same categories of evidence still apply at a startup, scope, impact, influence, but the committee reviewing the case is smaller and the written criteria, where they exist at all, are often incomplete. The practical move for an engineer at a company like this is to look at the last few people who got promoted to the target level and treat their actual track record as the real bar, since the written rubric, if one exists, tends to describe the floor.

Where calibration reliably introduces bias

The group dynamics inside a calibration committee create predictable patterns in who gets adjusted downward, and an engineer who isn't in the room has no way to correct for a pattern they can't see happening.

Remote and distributed engineers face a specific version of this risk. Fully remote workers get promoted less often than in-office peers, and the gap traces back to visibility, not performance. The fix for a remote engineer is the same fix that applies everywhere else in this piece: written, durable artifacts that make the work visible to a committee without requiring anyone to have physically watched it happen.

Research on calibration data from a law firm found something more troubling than a visibility gap. The committee process introduced bias against women of color that hadn't existed in the original supervisor evaluations. A small gap in initial individual ratings grew substantially larger once those ratings went through group consensus. That outcome runs directly against what calibration is supposed to accomplish, and it comes from the same group dynamic described earlier in this piece: the committee ends up weighting whoever argues most forcefully, and that weighting doesn't distribute evenly across every candidate in the room.

One engineering leader who sat through hundreds of calibration sessions put the structural flaw in plain terms: promotions often come down to the manager's advocacy skills, not the engineer's engineering skills. That's the risk a strong packet is built to manage. An engineer can't sit in the calibration room and can't control who argues on their behalf or how persuasively. What an engineer can control is whether the evidence in front of the committee is strong enough that the argument barely needs to be made.