Is sprint planning and agile not a thing at Meta?

Meta is famously anti-process and pro-engineer. Almost nobody within Meta uses Jira or runs their team with 2-week sprints. This is because Meta wants to move fast, not slow. However, there is a trade-off: Meta is far more chaotic than almost all other tech companies. It took me a while to understand this culture, and I now describe Meta as "controlled chaos". Everything is incredibly free-flow, but there is just enough organization for people to know what they're doing and get stuff done.

So what exactly does Meta do?

• It actually depends on the team and organization (I define this as director level). Instead of forcing everyone to follow 1 tool and 1 process, Meta lets every organization determine how to best run themselves.
• Some teams use Google Docs, some teams use Quip, and some teams use Tasks (the internal tool within Meta that is the closest to Jira). Some teams use a mix of all of them!
• The mechanism that unites everyone is due dates. I've never seen any team do story pointing, and this is because we all jumped straight to what matters: What actual day do we need this done by?
• I never saw a team do daily standup as it's too much process. Meta prides itself in open communication, so there's usually not a need to sync up on a daily basis. Most teams will have weekly or biweekly sync meetings.
• Workplace usage is pretty much ubiquitous and is a vital project management + alignment mechanism: "Is posting on Workplace required for good performance?"
• Once you start getting to senior levels (higher end of E5, E6), you will usually grow into a tech lead and have a lot of autonomy organizing how projects are managed.
• E3 and E4 engineers are expected to follow whatever project management mechanisms their tech lead has put in place. Their goal is to just deliver as fast as possible. No need to align to a "sprint cycle".
• Meta engineers are constantly looking to delete meetings and skip them. Back when I worked at Portal, I remember a brilliant E7 engineer (Senior Staff) just declared one day that he wasn't going to go to any meetings for a month in order to get stuff done, and everyone was just cool with it (he ended up getting a lot of stuff done by the way 😉).

Meta's culture is incredibly unique, and many engineers are unable to adapt to it (often with disastrous consequences). It is hard to truly understand unless you live through it. My advice is to go with the flow instead of clutching to the working styles you're used to and trying to swim against the current (this will almost certainly end with you getting a PIP). Forget "agile". Forget "sprint". Forget Jira. Just get stuff done.

There are 2 Meta values in particular I strongly recommend living by if you're going to work there:

• Be open
• Be bold

Here's some other great resources to understand Meta culture:

• [Course] Effective Communication For Engineers
• "How can I become more independent and better at unblocking myself with tricky technical issues?"
• "What’s the most effective way to switch domains in tech?"

For folks who are interested in working for Meta: "How does the Meta interview work?"

I can't speak directly about Meta, but I do come from a company that hires heavily from Meta (so I'll give my experiences at Robinhood).

• Deliverables and milestones are set at a project level: it's up to the project's eng lead on how they set these up to make sure things are delivered.
• Project update meetings are also driven by the project's eng lead: it's up to them to decide the frequency.
• Teams will usually have a weekly/biweekly team meeting for teammates to give project updates.
• Sprint planning is not a thing, but quarterly/yearly/half planning usually happens at a team/org level. This is driven by managers mostly with the input of tech leads (if there are senior enough engineers to fill that role).

While not agile in what'd we see in more traditional companies, it does share the same high-level framework around planning and executing projects. It's just that for these "top" tech companies more value is put on engineers to be owners beyond coding: there's a lot more freedom with how engineers choose to deliver, but there's more pressure on engineers to own the broader delivery of the project beyond coding.