When are Microsoft performance reviews? (2026)
Microsoft evaluates impact on a three-part model that counts what you built, what you contributed to others, and what you built on others' work. Cycle dates vary by org, so keep a record organized around those three buckets.
Once a year
No specific review month is published for this company, because none could be sourced from the company's own material. What follows is the cycle shape, which is what is actually knowable. Your own manager is the authority on this year's dates.
How the cycle works
The organizing idea at Microsoft is impact rather than output, and the definition of impact is unusually explicit: your own individual contribution, your contribution to the success of others, and your results built on the work and ideas of others. Those three buckets are the frame the conversation happens inside, and a self-review that only fills the first one is describing a third of what is being assessed.
The second and third buckets are the ones people forget. Helping another team ship counts. Reusing an existing platform instead of rebuilding it counts, and counts positively, which is the opposite of the instinct that says building something from scratch shows more skill. Someone who deliberately adopted an internal component and shipped in half the time is telling a strong story if they say it that way.
Cycle dates differ across the company's very large organizational surface and shift year to year. Do not plan against a month you heard from someone in another division; ask your own manager for this cycle's dates.
What actually gets weighed
Because the company spans cloud infrastructure, developer tools, enterprise productivity, gaming and hardware, what counts as evidence varies enormously by division. What travels everywhere is the three-bucket framing: whatever your work was, express it as your contribution, your amplification of others, and your leverage of what already existed.
Cloud reliability and customer impact carry heavy weight in the infrastructure organizations, where a regression is measured in enterprise customers rather than in users. In the developer-facing groups, adoption of what you shipped counts more than the shipping. In the enterprise groups, the ability to work across a very large organization without escalating is itself the skill being measured.
Growth mindset language shows up throughout, and it is worth taking literally rather than as decoration. A project that failed, was diagnosed accurately, and produced a change in approach is a legitimate entry, not a gap to hide.
What to have ready
- Your year sorted into the three impact buckets before you write anything else, so the shape of the review is set correctly from the start.
- Named colleagues or teams whose success you contributed to, with what specifically changed for them.
- Cases where you built on existing internal work rather than starting fresh, and the time or risk that saved.
- Customer or partner outcomes for anything you shipped, stated in their terms rather than in yours.
- Anything that did not work, with the diagnosis and what you changed afterward.