Roadmapping process at Meta

Why Planning Matters (Even When It Fails)

I don’t think it will come as a surprise to any of you, but every company, big or small, has to do planning. They often say that any plan [of battle] falls apart at first contact with the enemy - but after going through countless planning sessions, both at Meta and elsewhere, I came to a perhaps counterintuitive realisation: the outcome of the planning process doesn’t matter as much as the process itself.

That, of course, doesn’t mean the outcome doesn’t matter - you have to know where you’re going, or else you’ll end up somewhere else. But the process of roadmapping often acts as a way of aligning leadership expectations and channeling the energy of engineers in the right direction. Let me explain what I mean.

How Planning Works at Meta

At Meta, the process starts with top leadership - often Mark, or some of his top lieutenants - posting an update on Workplace (think of it as Facebook for Facebook), sharing their view on the key directions and challenges for the next half. (Unlike many companies, Meta plans in halves, not quarters.) This then trickles down until it reaches VP level, at which point the company usually publishes roadmap guidelines - including key dates and planning milestones.

The Bidirectional Model

So far, so good - but at this point, the direction reverses. Instead of continuing a steady top-down flow, tables are turned, and planning starts at the lowest level: individual engineers and their teams. Line managers (i.e. those to whom individual engineers report) become responsible for the first draft of the roadmap.

Planning is done around key themes in subteams (often led by rotating IC TLs), then rolled up at the team level. It’s reviewed by senior engineering managers (typically M2s or Senior EMs), who are ultimately responsible for their team’s roadmap. From there, it moves up to engineering and product Directors (D1, then D2), merging with other teams’ roadmaps at each level - becoming broader in scope and, inevitably, losing some detail.

Eventually, the roadmap reaches the VP level, where the two directions of the bidirectional planning process meet.

What Works Well

Personally, I think it’s a very sound model, but it comes with a number of caveats. It’s good for several reasons:

• People on the ground (i.e. engineers) usually know best how to achieve what leadership wants.
• It creates a strong sense of ownership and accountability at the team level - after all, if it was your idea to begin with, you’re more likely to be engaged and effective than if someone above simply assigned it to you.
• It’s one of the best processes I’ve seen for addressing tech debt. It creates space for an engineering manager to say, “We can deliver what you want - but first, we need to fix this.” And we all know that proposing pure refactors without new features can be politically difficult or career-limiting at best.

Where It Struggles

But like I said, the caveats are numerous. To name a few:

• It’s very time-consuming and emotionally draining, especially on tight timelines (as is often the case). For nearly six weeks (OK - two weeks at best), roadmapping becomes the only thing managers and team-level TLs focus on.
• Teams often struggle to balance “business as usual,” mandatory initiatives (e.g. for regulatory reasons), and long-term bets - leading to bloated roadmaps.
• Finally, it surfaces flaws in the org structure.

When the Org Chart Gets in the Way

To focus on that last point: if the org structure isn’t a good fit, problems emerge as early as the M2 layer and escalate at the D1/D2 level. Subteams may pull in completely different directions or work on unrelated efforts that can’t be measured in the same way. (Remember, Meta is data-driven.) Ideally, this should trigger critical feedback to leadership about org design - which, to be fair, is already an ongoing process.

How We Might Improve It

Can this be improved? Quite likely - and in practice, the process is already being iterated on. If I were leading roadmapping at company level, I’d experiment with lightweight pre-planning among M2/D1/senior engineers to align on the theme of the half. I’d also define clear buckets - mandates, bets, hygiene - to give air cover for tech debt, which otherwise gets sidelined indefinitely. At the director level, I’d introduce a dedicated section for org misalignments - normalising them instead of treating them as exceptions is the only realistic way to adapt to a constantly evolving business landscape. And finally, I’d start each roadmapping cycle with a short retrospective: what we planned, what we shipped, what worked, and what didn’t. We already run retros for individual projects - so why not treat planning the same way?

Final Thoughts

At the end of the day, no planning process will ever be perfect - and maybe it shouldn’t be. The real value lies not in producing a flawless document, but in forcing us to ask the right questions, talk to the right people, and think hard about what we’re doing and why. The Meta model, with all its quirks, does a good job of that. And as long as we treat the process as a living system - one that evolves with the company - it will keep serving us well.

It’s hard work. But it’s also one of the few things that, done right, can make the difference between drifting and driving.