Engineering practices @ Meta: #7 Focus on impact and data
Meta-engineering culture is driven by obsessing over the impact and the use of data to support and inform decisions. This is a core engineering value and leads to some unique outcomes.
Focus on long-term impact
Meta has a core value of “Focus on long-term impact”, previously this was just “Focus on impact” and this is engrained deeply in the soul of Meta’s engineering culture.
What does it mean in practice?
Every project, decision, or task is heavily biased toward potential impact.
Engineers obsess over impact while they pick their projects. Any tangible piece of work on a project is usually followed up with a workplace post calling out what impact it had.
And of course, this is also a big part of performance reviews. A major question asked is, “What was your impact on this project?”. This becomes tricky to justify if a group of people worked collaboratively to deliver a project but nevertheless is still equitable as you probably would not want to get credit for something where you did not measurably contribute anyways.
Impact-driven culture is probably not new to most, as most companies follow an SBI (Situation, Behavior, Impact) or STAR (Situation, Task, Actions, Result) methodology when it comes to writing self-reviews or feedback, but quite often this is pushed to the end of the performance cycle when engineers slog through months worth of work and try to understand what impact it even had. At Meta by contrast, What I observed was, that is very much a part of the core engineering culture.
Fun fact: 🤪 There is an internal workplace group called “Shitposting @ Meta” (an epic group by all means) where engineers also make some sarcastic jokes about this strong tilt towards impact and affectionately call it “Impacc” 😏
Overall, I think it’s a pretty good practice because it keeps engineers laser focussed on “why” they are doing or spending their time on some task or project and also helps to weed out the stuff that probably is not that impactful.
A sad caveat of this practice is that in some contexts, people don’t focus as much on tasks that are very sometimes essential but not necessarily very measurable.
Focus on metrics
Another core aspect of Meta’s engineering culture is a focus on data and metrics.
Data is heavily used to drive actions or decisions. It’s also possible since data is heavily instrumented into a data store and access to it is democratized with convenient tools and visualization libraries.
How this materializes is that if you say want to do anything, you probably find a way to get some data on “why” this is a problem to solve in the first place. And during implementation phases use data to confirm whether things are on track. This is not to say that intuition is disregarded completely and engineers also use anecdotal evidence but I’ve observed numerous occasions where an argument for why to do X falls flat in the room when data supporting it is missing.
From an engineering performance review perspective, each engineer’s productivity is also measured with data with metrics like No of Diffs, Diffs commented on, no of workplace posts authored, and no of wikis authored or edited and these metrics are stack ranked in comparison to other engineers on the team. If you on the team are below a certain range, you may also be questioned by your manager on the reasons for so.
What this means is engineers tend to use data heavily, in their projects or initiatives, while being on call and keeping track of metrics like reliability, etc and even to track their own performance compared to their team members. I guess having visibility into so much granular data helps to inform meaningful actions as well.
| 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 | Twitter. |
Comments