What do L6 Meta engineers and Zidane have in common?

Meta is a company that is famous for its engineering culture and especially it's old motto: "Move fast; break things". In the last few months, I've been thinking more about what kind of culture I would like to see in the company that I plan on building out. During the process, I ended up reminiscing about my experience at Meta and what aspects of its engineering culture I would like to borrow.

I ended up on the three features below -

1. Engineering IC levels and their corresponding expectations.

2. The different archetypes of Staff+ engineers.

3. The impact-driven recognition culture.

IC Levels & Expectations

Based on my experience, the hierarchical levels within Meta's engineering culture are structured as follows:

L3: A fresh out of college engineer joins Meta as an L3. At this level, you are told what projects to work on as well as given a roadmap to completing the project. You are completely judged on the quality of code you output as well as volume. It's analogous to being given a recipe (maybe a little less precise) and then judged on how well you followed the recipe.

L4: At this level, you are given a component of a system to own and are told at a high level what to do to achieve it. This level focuses on testing your ability to navigate uncharted territory. How well can you unblock yourself on your way to the end objective?

L5 (Senior): This is the terminal level @ Meta (i.e. promotions are no longer up or out). You are now entrusted with a particular metric (e.g. CTR on a particular type of search result) and are expected to move it by a target percentage. At this level, you operate as fully independent engineers, possessing the expertise and acumen to navigate projects without the need for guidance on engineering intricacies or implementation particulars.

L6 (Staff): Here is where the transformative impact occurs, as you transition from only individual contributors to enablers, elevating team performance exponentially. This is the level at which your impact becomes less about your individual contributions and more about what you can enable. To quote what Zlatan Ibrahimovich said about Zizou: "When Zidane stepped onto the pitch, the ten other guys just got suddenly better. It is that simple." To me, this is exactly what the role of a staff engineer was. As soon as they stepped onto a team, they multiplied everyone else's impact greatly. What was interesting was the different ways in which they could multiply their team's impact which I discuss in the next section.

Levels continue all the way up to L10 which is a VP equivalent. Just to provide scale, engineers are at these levels are expected to have industry-wide impact (e.g. leading Pytorch or React).

What does this mean for you as a reader?

Well, it depends. I don't believe that there is any one correct way of defining engineering levels. A lot depends on the circumstances of the company. That said, if you're an engineer, try to examine what level you would consider yourself falling into (regardless of whatever your current title is) and what you can do to get to the next level. What's especially difficult is the move from IC to Enabler (5 -> 6). In most companies, this is the most difficult transition and usually takes a 3+ years if at all. My advice: be like Zidane (i.e. a playmaker).

Senior Engineering Archetypes

At Meta, as engineers move up the ranks, they usually fell into 1 of 6 archetypes. L5 engineers were also asked to think about what type of archetype they wanted to continue in and would find appropriate mentors who could help them grow in that path. The types were -

1. Generalist: This is an engineer had broad knowledge of the different systems @ Meta and how to leverage them to quickly build 0->1 products and features. They are the quintessential "Jack of all trades" engineers. These engineers mostly worked in vertical teams.

2. Specialist: This is an engineer who is focused on a particular domain such as caching, ML, or Computer vision. They have a deep knowledge of the intricacies and idiosyncrasies of the field. They usually have PhDs or years of cutting-edge research under their belt (or both). These engineers mostly worked in horizontal teams.

3. Technical Lead: This is the lead engineer on a team, vertical, department, app at L6, L7, L8, L9 respectively. As a TL, they provide technical guidance to junior engineers, project direction, leadership and mentoring. These engineers are just as focused on growing others as they are on individual contributions.

4. Product Manager / Engineer Hybrid: This engineer has an incredible grasp of the knowledge needed to build products. In addition to their technical individual contributions as Staff+ engineer, they help co-ordinate user research into potential product directions, devise new metrics to track success and set up evaluation processes for features.

5. The Coding Machine: This is an engineer who outputs a ridiculously large amount of high-quality code, often completely building large features, libraries or products by themselves.

6. The Fixer: This engineer spends a lot of time and effort developing a fix to a common issue @ Meta. The fix doesn't need to be more than even a few lines of code but often results in 2x to 3x whatever metric is being used to track success.

In a big company, each of these roles plays in an important part. For example, specialists might be able to develop a key piece of technology but then they need generalists to build a platform or product around it. At the same time, the distribution of these archetypes is not equal in number. You are more likely to find generalists and specialists than fixers and coding machines at most big companies. Perhaps, the role of a Fixer only exists in Big Tech.

What does this mean for you as a reader?

This information is probably most useful for engineers who are 0-7 years into their career. If you're later on in your career, you've probably already decided your path. However, junior engineers still have flexibility and room to grow. Your skills and interests will help you decide which one of these archetypes you want to be.

What's important to remember is how these roles can affect your long-term career. For example, being a generalist brings a lot of flexibility. It's easier for you to find jobs since most companies will always need someone to build apps & platforms. However, your subject matter expertise and hence value to the company is less than that of a specialist who is developing the key technology of the company. To make best use of this information, I'd recommend the following steps -

1. Research the archetypes and pick the one you'd like to follow.
2. Evaluate the list of skills and strengths a successful member of the archetype needs.
3. Introspect and list out your existing skills and strength.
4. Figure out what skills are missing and work with your engineering mentor (perhaps at your job or external) to chart a path to get there.

Results-driven Recognition

Even at the lowest level, such as the launch of a feature or fix, Meta's culture strongly follows the scientific method -

1. Define the problem statement.
2. Gather initial information and observations.
3. Form an explanatory hypothesis.
4. Test the hypothesis by performing an experiment and collecting data in a reproducible manner. This is usually done via A|B testing.
5. Analyze the data and interpret the results. The experiment was successful if and only if the hypothesis was correct.
6. Publish results for team members and leadership to critique.
7. Retest. This is often done via long term holdouts.

The advantage of the hypothesis-driven approach is that it leads to teams analyzing initial data and forming targeted solutions rather than just randomly throwing darts at a board and seeing which hits the bullseye.

At the highest level, Meta's culture is heavily driven by metrics. Almost all success is defined by the movement of metrics. What this means (for better or for worse) that only results are rewarded. Unsuccessful effort is not recognized. You can spend an entire 6 months working on a project, but if the base hypothesis was wrong and the project didn't move its goaling metric then you will not be recognized for your work. A caveat to this - it depends on your level. An L3 IC engineer who has limited to no control over direction of the team/product, would not be penalized for base hypothesis being wrong.

One of the advantages of this results-oriented culture, is that engineers (especially senior engineers) are incentivized to do whatever it takes to get a project completed. As an example, one half when I was working on the Hashtags team, I was responsible for leading the efforts to build out the hashtag typeahead for the Facebook App. As an engineer with mostly backend experience till then, I worked on the server APIs, pagination, privacy, retrieval and ranking aspects. The front-end (Android, iOS and Web) was meant to be built out by other expert client engineers. However, we had a lot of difficulty finding an Android & Web engineer for the project. Knowing that it would only hold me back during review season, I learnt Android & React to build out the feature on those two surfaces. This ended up boosting my review that half and helped develop my reputation as "An engineer who would do anything to get the feature out the door" which helped me tremendously in the long run.

What does this mean for you as a reader?

A results-based culture reduces any subjectivity in the rewards process. You can easily point to the impact you've achieved by pointing to the movements in metrics you were able to produce. It also makes individuals think more deeply about a potential feature or product since a feature based on a misguided hypothesis will likely fail. In the long run, this reduces wasted effort tremendously.

If you're a position to influence your company's recognition system, you might think about establishing a similar culture. Of course, each recognition system has its pros and cons so you might opt against it.

Those were the top three takeaways I got from my work experience. Like I've mentioned above, there are many cultures and systems with their own pros and cons. If there are any aspects of work culture that you've found experienced and found useful, I'd love to know about them. You can comment below so that the information might also help others as well :)

#engineering #workculture #meta