An acquaintance who works at Facebook, which we should now call Meta, visited Korea on vacation. We met up for drinks after a long time. Since it had been a while, we talked about many things. As the evening went on, we naturally drifted back to our usual topic: development. We often discussed work and development, so it felt natural. The bold and flexible architecture for native apps, which I can't detail here, gave me a lot of inspiration. The main topic that day became how developers at Facebook work. We talked, losing track of time. Although it was during the "With Corona" period, we unfortunately had to part ways early. What I heard that day was incredibly insightful, so I thought it would be good to organize and share it.

This post primarily covers how work is initiated, executed, managed, and leads to results at Facebook, and how those results are evaluated. I spent a bit more time on the performance aspect. The story flows based on what I heard, but I'll be incorporating many of my subjective feelings and opinions :) I've omitted some sensitive parts. For ambiguous points, I double-checked via phone calls, but there might be parts I misunderstood or exaggerated.

Here's a quick summary:

Clear goals based on data
Proactive work where individuals decide their tasks
Development focused on A/B testing
Data-driven performance measurement
Managers like celebrity managers
Systematic and rational performance management and evaluation

Now, let's dive into the stories I heard.

The Start of Work

For Korean developers, work typically begins with a planning document written by a planner. However, I heard Facebook doesn't have dedicated planners. PMs, managers, developers, designers – anyone can initiate planning. This structure is common overseas, so it might not seem like a huge feature. Allowing anyone to plan work encourages individuals to be more engaged and proactive with the service, but it also means they can't solely focus on their main expertise. Whether this is an advantage or disadvantage depends on where you place the emphasis on efficiency.

First, clear goals are set for a specific period. These are often called KPIs. Once these goals are established, individuals have to figure out how to achieve them on their own. No one tells you exactly what to do step-by-step. Managers don't assign tasks saying, "Do this, do that."

What I found important here is that KPIs are clear, simple goals based on data. Of course, the clarity might differ depending on the organizational depth, but the goals given to developers are distinct. For example, "Increase the click-through rate from screen A to screen B by 20%." While it's a simple click-through rate, its importance and contribution to the service have already been analyzed based on various data points, which form the basis of this goal. The reasoning might be complex, but the goal is simple. To achieve goals or solve problems, you must first simplify the goals and problems.

Once these goals are shared, projects are voluntarily formed based on ideas not just from PMs, but also from developers, designers, and other individuals aiming to achieve the goals. They define the "What," but the developers and workers decide the "How." Projects can be large or very small, perhaps just moving a button slightly. Regardless, they are ideas aimed at achieving the goal. When a project is formed around someone's idea, they recruit the necessary people. Usually, the person who initiated the idea becomes the leader, but not always. Whoever is best suited to lead the project takes charge. Just like the project's initiation, participation is also voluntary. It's like recruiting your "kkambu" (allies/teammates). For recruitment, they use an internal collaboration tool, similar to Facebook itself, developed in-house. They post something like, "To achieve goal X, I have idea Y. Need 1 developer, 1 designer. Estimated effort and schedule: Z," publicly seeking team members. Interesting, right? It might seem similar to the "Need 2 Java devs, hop on" scene from Kim Kuk-hyun's famous cartoon, but the context is entirely different. :)

There will also be projects initiated by PMs that are essential from a business perspective. Since anyone can propose and implement ideas to achieve goals, PMs, who bear that responsibility, likely have many projects to run. However, projects initiated by PMs are treated no differently. People who want to participate voluntarily raise their hands. If there aren't enough participants, the project might struggle to proceed. What motivates people is impact (they actually use this term). People want to work on things that generate the most results and impact. We'll revisit performance later.

If a crucial project lacks participants for various reasons, managers intervene. They might persuade individuals who need to boost their performance or those essential for the project to join, matching them appropriately. Managers act like headhunters, connecting projects needing people with people needing tasks. While this is a natural role and not fundamentally different from Korea, it feels different somehow. It feels like each individual is an independent entity, doesn't it? The basic organic unit seems to be the individual, not the team.

Work Progress

The very first step before starting work is documentation, I was told. Not a planning document, but documentation on how to verify the results of implementing the idea aimed at achieving the goal. What matters most is the outcome, not the hours worked, effort, hardship, or sacrifice. Therefore, the very first stage of work involves contemplating how to measure the performance. They first think about how to verify the impact of their work on the goal. If verification is impossible, the work is considered futile as performance cannot be proven. If this part isn't clear, it's hard to even recruit people for the project. This process also determines what logs to collect, and A/B testing is considered from the outset.

All work at Facebook reportedly goes through A/B testing to decide whether it gets fully deployed. Typically, A is the original scenario, and B is the scenario applying the new idea. They compare A and B, partially deploying the new feature while assessing its effectiveness. Initially, it might be opened to 5% of users. If logs prove the work achieves its intended purpose, they might increase it to 10%. They gradually increase exposure while performing various checks, eventually aiming for 100% deployment. Imagine a bug or error is discovered when the feature is live only to 5% of users. In such cases, there's no need for complex rollbacks; they simply switch the exposure to 0% (effectively disabling it), fix the problem, deploy again, and gradually reopen it.

My friend's team apparently doesn't have a separate QA. This doesn't mean the company lacks a QA team, but not all projects go through QA. This team's projects typically don't have a QA process. I was shocked that changes could be reflected in such a large-scale service without QA, but the thought that A/B testing provides support made it seem slightly more feasible. A/B testing serves both as a tool to analyze user reactions and as a final defense against the anxiety arising from the absence of QA. If something goes wrong, they can quickly revert to the original code. If initially unsure, they might release to just 0.01% and monitor the logs. Given the massive user base, even 0.01% represents a huge number of users. If logs show abnormal signs, they immediately switch back to 0% exposure, fix the issue, and redeploy. While verifying the utility of B (the new component) against A, they simultaneously verify its stability.

Instead of QA, they rigorously apply E2E testing during development. Using a company-wide, well-established development environment, testing environments for various devices are readily available. If test code is written well, results for supported devices can be easily obtained. Debugging and viewing execution screens for problematic devices are also straightforward.

Speaking of the development environment, they use a customized VS Code-based sandbox for individual development, easily accessible like a cloud environment. With a single click in VS Code, the project repository (Mercurial) is checked out, and simultaneously, a sandbox server spins up to check the work results. This sets up a cloud-based solo development environment instantly, without needing separate tool installations or configurations. Code changes can be immediately verified on the server, and E2E tests run seamlessly. A single click can also deploy changes globally. Essentially, it's an environment where anyone, anywhere, can modify code and deploy it worldwide instantly. My friend praised this development environment immensely, calling it the most surprising aspect. And for those thinking, "Well, maybe for web development," the environment described is for developing native apps like iOS and Android. Honestly, this is possible due to a shockingly progressive client architecture, which I personally found revolutionary. Unfortunately, all I can mention here is that they use Hack.

Work Crisis

Once a project team is formed, the leader assigns tasks according to roles, and the team operates as a small task force until the project concludes. The issue being addressed might be a simple task requiring only a day or two, or it could be a long-term effort. An individual might participate in multiple projects simultaneously. Ideally, projects proceed smoothly, but problems inevitably arise. Sometimes, an expert in a specific field might become newly necessary, or personnel changes might occur for various reasons.

When people are needed, leaders or members might recruit directly, or they might ask their team managers to find someone capable of handling a specific task. Managers can connect suitable talent or individuals currently looking for work. In cases of real shortages, they might encourage individuals who need to improve their performance records to join the project. The managers here felt like celebrity managers. The word "manager" is the same, but the nuance feels different from a typical management role versus managing a celebrity, right? They manage each person like an athlete, connecting them with the company (the client?) and tasks.

As an aside, like other international companies, Facebook has clearly distinct tracks for managers and developers. A development team manager isn't required to have development skills, nor is a developer expected to have management skills. The manager-developer relationship isn't hierarchical; it felt more like the manager is just another member of the managing team. Therefore, managers are responsible for developers' performance but not necessarily their growth. This is why newly hired developers often struggle initially, I heard. They have to find work themselves, and nobody explicitly teaches them things.

On-call duty is typically rotational, with team members taking week-long shifts (update 220311). If an outage or urgent issue occurs, it's registered as an incident in the system. Anyone can register an incident, but usually, the on-call person does. Once registered, the system automatically contacts the assigned personnel via ARS (Automated Response System) calls. The calls continue until the contacted person enters a pre-agreed code. This usually happens for very severe incidents. Incidents are managed in 4 severity levels, each with a defined resolution deadline. For the highest severity level (e.g., service unusable), the priority is to apply a temporary fix within the deadline, followed by addressing the root cause. Having a deadline to resolve incidents sounds intense.

There are also "saviors" who constantly monitor service incidents and provide help. They have a specific title, but I won't disclose it. Like Superman, they seem to scan from above and swoop in to rescue services in crisis. The difference from Superman is that this is their performance metric. They aren't helping out of sheer goodwill. These are senior developers, typically with 10+ years of experience at Facebook, familiar with the workings of various organizations. They might directly help resolve incidents or connect the team with people or teams who can assist. Once an incident is resolved, these individuals lead a review with relevant parties to create an incident report. This report details how long it took to detect the issue, why it took long if it did, how it was resolved, and what needs to be done to prevent recurrence.

There's also a warm on-call culture. If someone is unable to handle an on-call alert in the middle of the night due to illness or other reasons, they might ask a colleague on the opposite side of the globe (whose regular work hours it is) to cover for them. They then return the favor later under similar circumstances. This seems less like a formal company system and more like a unique culture of consideration found in global companies.

Beyond these points, it felt like all other aspects were meticulously organized to allow people to just focus on doing their jobs well. These details likely stem from the know-how accumulated over many years of operating a global service for a vast user base.

Performance Standards

As mentioned several times, evaluations here are strictly performance-based. Thus, the criteria for performance are very clear. Performance is assessed based on four categories:

Project Impact
Engineering, Service Overall
People
Direction

I've slightly rephrased the terms at my friend's request. Each category has an expected amount of achievement based on the individual's experience level and position. So, like university credits, you need to accumulate them. For example, if someone has sufficient Project Impact but lacks People achievements, they need to focus on People-related tasks before the evaluation period to fill that gap.

The four performance categories and their contents seem generally applicable for performance management, not just at Facebook. In fact, these are desirable qualities anywhere.

Project Impact

Project Impact, as the name suggests, refers to contributions made to projects. Statements like "Maintained AA" or "Handled BB part for N sprints" are not considered verifiable performance.

How much click-through or visit rates increased due to my work (in percentages).
How and how much my work contributed to achieving KPIs.
What significant ideas I proposed and how they were implemented.
How and how much I improved performance (this is crucial).
Other contributions to the project itself.

For ideas discussed in chats or verbally, proving them as performance is difficult. Therefore, even if discussions happen informally, the idea originator writes a document summarizing the idea, shares it with relevant people, and uses that document as evidence of performance. It strongly felt like writing well is essential at this company. My friend actually mentioned that writing is as important as coding.

Engineering, Service Overall

This category covers overall competence as a developer.

Code quality, testing, documentation.
Quality of code reviews.
Contributions to development guidelines.
Incident response, monitoring enhancements.
Significant improvements in stability, performance.
Other achievements demonstrating developer competence.

This focuses on pure development performance, although it's not entirely separate from the service. Performance improvements might overlap with Project Impact. For instance, if service performance was improved, it could count here. In such cases, individuals manage their performance records strategically: if Project Impact is already sufficient, they categorize the achievement under Engineering, Service Overall, and vice versa.

Detailed items like code quality and code review standards are evaluated in other companies too. What seems slightly better at Facebook is that they reportedly have metrics, standards, and systems to judge stability, code reviews, code complexity, and coverage both qualitatively and quantitatively. This makes it easy to track things like the total number of code reviews performed. These metrics are used to substantiate performance claims.

People

People performance relates to sharing, colleagues, attitude, and communication.

Helping colleagues.
Collaborating effectively (specific examples).
Sharing knowledge through presentations.
Documenting important or complex issues on the wiki for sharing.
Participating in interviews.
Mentoring.
Organizing parties.
Thanks Votes.

Most items are self-explanatory. "Parties" and "Thanks Votes" might be somewhat unique.

Organizing a party to improve team morale counts as "People" performance. Such parties follow certain rules, often involving pre-defined games, much like a playshop. There's a sort of guide, apparently. Planning, scheduling, inviting people, and ensuring participation in such events are considered achievements equivalent to development work.

"Thanks Vote" is a feature in their internal work management system, which resembles Facebook. Similar to Facebook's "Like," you can give "Thanks" not just to posts but also to people. Thanks Votes are well integrated into the system, even applicable to code reviews. People give Thanks Votes for helpful code reviews or to someone who helped solve a problem. The number of Thanks Votes received can also be used as People performance evidence, although it's typically included only when someone really needs to scrape together achievements.

Direction

Direction is a performance area highly relevant for seniors or juniors on track to become seniors.

Leading projects.
Contributing significantly with ideas during bi-annual roadmap meetings.
Providing technical guidance and leadership.

Direction, true to its nuance, relates to leadership and technical leading. Project leading includes breaking down large tasks into smaller ones and assigning them appropriately – tasks commonly done by technical leads in Korea too. Project leading can be categorized under Direction or Project Impact, depending on what's needed.

Bi-annual roadmap meetings determine the service's direction. Contributing significantly with important ideas during these meetings is also a performance achievement. Since mere opinions don't leave evidence, proposing an idea is followed by documenting it, essentially creating a plan. Just talking a lot in meetings doesn't count. Only when a clear idea is documented and shared does it become a recognized achievement.

Guiding others to better utilize existing technologies is also a Direction achievement. For example, writing a document explaining "Let's do testing this way," complete with appropriate examples, and sharing it. This could also involve guides on code reviews, or suggesting improvements for poor development practices or performance-hindering code.

Performance Evaluation

Performance evaluations happen annually. Previously, they were done twice a year (semi-annually), but this was changed because it tended to make people focus excessively on short-term results. Although evaluation is annual, individuals can request feedback from colleagues and managers anytime to check their progress. The term they use, which seems fine to share, is literally "mid-term check." Performance achievements are tracked using a tool, and this information can be shared with anyone. One can casually ask, "Hey, can you check if I'm doing okay?" Receiving helpful feedback allows individuals to identify and improve on weaknesses before the formal evaluation, which ultimately reflects positively on their assessment.

As discussed, performance is evaluated systematically and specifically. Thinking of everything as measurable performance, it seems like the most transparent, honest, and clear personnel evaluation possible. It's rational. That's why nobody cares whether someone works during specific hours or not. The amount of time spent working is irrelevant; only results matter. Therefore, claiming you couldn't achieve results because you worked overtime, or because meetings and collaborations prevented you from coding, holds no weight. Individuals are expected to reduce unnecessary meetings or collaborations themselves, or raise the issue to solve it collectively. Improving processes this way also becomes an achievement. Small or large improvements, it doesn't matter. Conversely, keeping quiet about such problems and letting them fester leads to a bigger negative impact if they blow up later.

People tend to avoid work that doesn't have clear performance outcomes. However, if currently unclear work is necessary, efforts will be made to make its performance measurable. Ultimately, all necessary work is linked to quantifiable results. This seems to be the core idea behind "everything is performance."

Annual evaluations don't necessarily mean annual salary negotiations. If someone accumulates enough performance to warrant a raise, they get one regardless of the timing. Similarly, if they demonstrate the capabilities for promotion, they get promoted whenever deemed ready. However, annual salary increases roughly aligned with inflation are provided. Conversely, if someone consistently underperforms for several years, they are included in a company-level performance improvement program and managed separately. This includes training on work management, introductions to suitable projects, and pairing with a high-performing employee as a 1:1 mentor. For the mentor, this mentoring counts as "People" performance. However, if after all this support, performance still doesn't improve, they are let go.

Evaluations are primarily based on the performance report submitted by the individual. This report, focusing on objective achievements, carries more weight than the manager's subjective impressions or colleagues' opinions gathered over time. Consequently, preparing this performance report is reportedly a very intense process. It's not just a single A4 page; every detail, from minor to major, is recorded. Imagine how much there is to write. Therefore, skills in writing the performance report are considered very important, ensuring that key achievements are properly highlighted amidst the volume of information. Given the amount of content, compiling it all at once during the evaluation period is nearly impossible; people usually document their achievements progressively as work happens.

Conclusion

While listening to my friend, I was constantly amazed and full of praise, but it also gave me much food for thought. Superficially, it doesn't seem drastically different from Korean corporate culture, apart from the level of detail. Many Korean IT companies also advocate for performance-based systems. However, I don't believe they are operating effectively with clear standards. There needs to be a clear basis for performance and a system robust enough for objective scoring. It's a sensitive thing to say, but Korean corporate systems always seem to have areas that are vaguely glossed over. Well, that's just my humble opinion. This doesn't mean I think, "Wow, foreign companies are the best!" either. Throughout the conversation, I often thought about how demanding it must be. My friend also mentioned many difficulties. "It's good, I get it, but it's tough, it's intense." That kind of thing. Apparently, many newcomers, especially foreigners including Koreans, struggle to adapt initially. In a way, perhaps those vaguely glossed-over aspects of our culture also provide a certain comfort.

culture

How Facebook Developers Drive Performance