Onboarding at Meta: ramp-up plan and why it matters

There were tons of comments on my recent Threads post related to consuming large amount of documentation during onboarding process, and some comments really resonated with me to the point that I decided to put up a summary here.

Onboarding - especially in a senior role - often feels like drinking from a fire hose. There’s an enormous amount of information, often hundreds of people to speak to, and only so much time and mental capacity to go through this. Doing so without any structure in mind is almost certainly a recipe for disaster (in the very best case - long and inefficient onboarding). There must be a better way.

Many years ago, when I was starting my first management role at Google, my then-manager, an awesome guy named Miles Barr gave me a book - it’s called The First 90 Days by Michael Watkins. I read it back then, but frankly I couldn’t comprehend all of it - it suddenly started making a lot more sense as I progressed up the career food chain, and at certain level of seniority is suddenly all clicked: this was not a book for beginner managers, this was a book for senior leaders stepping into even more senior role.

So when I joined Meta, I read it again. I read it, I listened to it, I made notes on my Onyx Boox Note, and obsessively argued with myself about whether this or that approach was efficient and why. The outcome of that was a structured learning plan - a few pages long document, which explained in details, how exactly I am planning to ramp-up, what will be my key milestones and how I will be evaluating my own performance against this plan. For what it’s worth, I’ve heavily adapted what the book was suggesting to make it more suitable for a technical person – but the basic ideas and key outcomes were essentially the same.

Three Key Pillars of Learning

To make my own life easier, I separated my learning plan into 3 large sections:

1. Technical Mastery – Gain a comprehensive understanding of the systems, their architecture, and underlying technologies critical to my area of work. I should be able to effectively contribute and lead in technical discussions and decisions.
2. Strategic Influence – Grok the business context and strategic goals tied to my technical work. Dive into the product regulatory landscape to make sure my technical choices align with Meta’s bigger picture. Sync technical decisions with business objectives and product strategies to make a real impact.
3. Leadership and Collaboration – Build my internal network, establish thought leadership, create informal ties within the bigger organization as well as the key partner teams.

Given I was hired into an IC role, technical understanding of how things work was mandatory (albeit not sufficient) requirement for my role - and boy there was a lot to learn. I was onboarding in a team with over 150 engineers, dozens of teams, working in a whole variety of areas - but on top of that, I needed to understand what adjacent teams are doing, teams we are working with, teams which are upstream or downstream dependencies of our products - the list was nearly endless.

The general approach, in essence, was very simple: I started with a few “seed” people proposed by my boss, and spoke to them. Each person I asked:

• What are the things I really need to learn right now, early on?
• What documents/Workplace posts I need to review to get up to speed?
• Who are the key people I need to talk to?

So speaking to each person produced extra 3-5 people I have to talk to, and 5-7 documents I needed to review and understand. Each of these people suggested more people, and each document was linking to more docs … in short, very soon I had a list of 100+ people to speak to and a list of docs I could basically never finish reading in my lifetime.

Narrowing the Scope

It was clear that I had to limit myself to something– otherwise, I would drown in the sea of information. My approach was to start with a limited scope—initially, I focused on the team I was sitting with (~50 engineers or so). I spoke to all the managers and key TLs in the team, and I spoke to the PMs—with the end result being a moderately uncontroversial architectural diagram in my head, explaining how things work. Identifying key technical people, I explained to them what they had previously explained to me, focusing on closing the gaps and correcting what I didn’t get right the first time around. Then, I started repeating this process with other organizations - first reporting to my director, then to my director’s boss, and so on.

In parallel to this, I was going to different teams and was asking them for starter projects. At the moment of writing I already finished a few of them - from small things that took me 2-3 hours (and most of that time I spent navigating unknown codebase and unfamiliar tools) to the ones of moderate complexity, which involved 2-3 days of work and going backward and forward with the key engineering folks on those particular teams. Few more starter projects are on-going right now – they are large enough to warranty some careful thinking and consideration (and to the point, they blend seamlessly into the next section). I still did not understand everything - far from it, it would probably take me months if not years to get to that stage - but it allowed to progress to the next phase (which is still very much ongoing).

Securing Early Wins

If there’s one thing Watkins really hammers home, it’s figuring out how to balance learning with actually getting stuff done early on – but not too early. Securing early wins is key because it helps build credibility and momentum. By delivering tangible results quickly, you show you can make an impact, which boosts your confidence and earns the trust of your new colleagues and bosses. To nail those early wins, you have to dive head first into the company’s processes and culture, helping you navigate more effectively and set the stage for bigger achievements down the road.

This was a tough one—figuring out where to make an impact and then diving into piles of documents, codebases, data sources, and talking to people. During this stage, it’s super important to stay in touch with your boss. If you can get a handle on their priorities, you can make much better choices. I got really lucky because my boss straight-up told me what was keeping him up at night and how crucial it was for us to make progress there. So, I started by narrowing down the problem to smaller chunks, tackling the simplest, non-critical starter projects first, and then moving on to more complex ones.

Where am I at right now? Well, definitely not out of the woods yet :) The process isn’t finished, and it’ll probably take me a few more months to secure some of these early wins and move on to bigger things, so stay tuned, but to wrap it up: onboarding in a place like Meta is no walk in the park. Having a solid, flexible plan that focuses on mastering the tech, understanding the bigger picture, and building key relationships is a must. Narrowing your scope and nailing those early wins helps you build credibility and momentum, showing your team - and importantly - yourself, that you’re making an impact.

It’s not a quick process, and it’s definitely not done overnight, but if you stay focused on learning and contributing, you’ll make the transition smoother and set yourself up for bigger wins down the line. If you’re in a similar spot, trust me – having a plan is everything. More to come as I keep navigating this wild ride!