Engineering practices @ Meta: #8 Performance review process

Photo by Glen Carrie on Unsplash

<!-- Output copied to clipboard! --><!-----

Yay, no errors, warnings, or alerts!

Conversion time: 0.569 seconds.

Using this Markdown file:

1. Paste this output into your source file.
2. See the notes and action items below regarding this conversion run.
3. Check the rendered output (headings, lists, code blocks, tables) for proper formatting and use a linkchecker before you publish this page.

Conversion notes:

• Docs to Markdown version 1.0β34
• Thu Aug 24 2023 21:44:44 GMT-0700 (PDT)
• Source doc: [Blog] Software engineering practices at Meta
• This is a partial selection. Check to make sure intra-doc links work. ----->

Meta’s engineering performance review process is designed to help employees grow and develop their skills. It is a two-way conversation between the employee and their manager, and it covers the employee’s performance over the past year, their goals for the coming year, and their development plan. Let’s see more nuances about the process and what can we learn as engineers on how to approach performance.

How does Meta do performance reviews for engineers?

Let’s find out. 🤓

Meta has an annual review cycle with a lighter 6-month check-in process.

What are the different stages? Let’s see them below from the lens of the two main parties involved.

For employees:

• Firstly and most importantly 😉You do the work, make progress towards personal, org, or company goals, and make posts about it! 😉
• Every 6 months you write a self-review about your own performance. The review is quite concise with a 1000-word limit enforced by the internal tool itself.
• You also write feedback about your peer engineers and managers.

For managers:

• Your manager would then navigate your performance packet through a set of mash-ups and calibration sessions with other managers to normalize and de-bias it in view of the larger engineering org or function
• Eventually, your performance is rated on a 6-point scale with some broad categories of your performance being either below expectations 😟, met expectations ✅, or exceeded expectations 🥲
• You get an increase in salary 💰, and bonus and also get a refresher on equity in terms of meta RSUs (restricted stock units)

The process is straightforward and is similar to that of most other companies, with each company having its own variations.

What’s rather more interesting, is to observe the different dimensions upon which an engineer’s performance gets evaluated and how an engineer can mentally reframe their own work throughout the year. 🤔

I found this a pretty useful way of thinking and rationalizing your performance at work.

A cautionary tale 🧙: Meta’s engineering culture is pretty competitive and cutthroat. If you don’t meet the high standards, you’ll get dinged a lot in your annual reviews and in some worse cases could be managed out of the company. Engineers take their PSC seriously, sometimes even to a nonsensical standard but I guess this is the darker side of working in a FAANG company.

All the doom 😣 and gloom aside.

There are 4 broad categories where engineers’ contributions are evaluated

Project impact

This is the most important axis for an engineer and essentially answers the question:

“What work was delivered by this person and what was the impact on team, group, org, or company goals”

As you can imagine this is standard bread-and-butter stuff for engineers.

Any engineer worth their salt would want their work to amount to some degree of positive impact on business or engineering goals. Notice the axis clearly calls out **Impact **as the focus area, so engineers who make an impact with their projects are usually rewarded rather than esoteric engineering pursuits. You also need to know how to actually paint your projects in a favorable light with the right metrics and communication around it.

Meta Leadership recognizes some projects have a long poll so partial progress toward milestones is also rewarded.

In search of potential impact 🔍

If your work directly moves the needle on the top problem for your org then kudos, you’ve found yourself a potential Impact that could look very good on your year-end performance review and that naturally motivates engineers to seek and solve meaningful problems.

A quick tip to ensure you work on relevant things is to get manager and tech leads alignment, get regular feedback, and potentially even self-reflect on how exactly what you are working on contributes to the larger team goals and priorities.

Direction

The next axis is called Direction.

What is direction you may ask? Each engineer needs to ask the below question:

How did you influence the roadmap or set direction for your team/org?

The contribution expectation here largely depends on your current level as well, this is at a lower priority for an IC3 (entry-level) or IC4 (mid-level) but starts to become increasingly important at IC5 (senior) and plus levels.

Some of the common activities that contribute to this are:

• Contributions to setting up a roadmap for your team
• Identifying top problems, doing due diligence and research, creating RFC docs, and influencing and convincing fellow engineers to solve them
• Setting up a longer-term charter or vision for the area you are working on
• Look at strategic goals and figure out tactics to achieve them

Engineering excellence

Previously called Better Engineering, This one is my personal favorite axis and answers the below question

Did you meaningfully improve some engineering aspects like code health, processes, refactoring, or improved engineering efficiency?

At meta, Move fast is a core engineering value and what that also means is that it has ripple effects on code quality where sometimes in order to ship things faster, the code is not written in the most optimized manner possible.

Having a ginormous mono repo also means that there is tons of code and mentally loading it within your brain is a super difficult task and practically speaking slip ups do happen leading to regression in coverage and code quality.

So what could be some activities that positively contribute to this axis:

• Improve code structure by doing planned refactorings
• Write tests and improve coverage,
• Improve documentation
• Write user guides
• Picking up development of some tooling or infra that enables other engineers to move faster and with better quality

Quite often multiple such items are picked during focus weeks. Leadership also encourages an allocation of 20% engineering bandwidth and after project impact, this axis holds a ton of weight during performance reviews as well.

People Impact

The last axis is people impact and this primarily measures:

What activities were done to support other metamates and the larger community?

Examples of some common activities are:

• Support Hiring by taking Interviews
• Conducting tech talks
• Support other engineers in their careers through mentoring
• Participate in DEI (Diversity, equity, and inclusion) initiatives
• Organize Team social gatherings, club activities, and so on.

In short, the stuff that actually makes a workplace compassionate and lively.

Just as you figure, this could be at a lower priority than other axeses but varies at different levels, for example at higher levels mentoring expectations are more than at more entry levels.

Hope this was helpful. Let me know in the comments if you have questions or thoughts about this process.

| Thanks for the time you spent reading this 🙌. If you found this post helpful, please share it with your friends and follow me ( @automationhacks ) for more such insights in Software Testing and Automation. Until next time, Happy Testing 🕵🏻 and Learning! 🌱 | Newsletter | YouTube | Blog | LinkedIn | Twitter. |