🚂 Meta CTO's Onboarding Algorithm

Welcome to the tenth issue of the Software Mastery newsletter.

In this issue, I want to share a tip on onboarding from Andrew Bosworth, Meta’s current CTO. In A Career Cold Start Algorithm, Bosworth explains how he handles the initial thirty-minute meetings he has with people after joining a new team:

As Bosworth explains in his blog, the purpose of the first 25 minutes is to help direct your attention to critical pieces of information you should know immediately. The next three minutes give you ideas of how to make a positive impact, and the last two minutes help you figure out each person’s area of expertise.

In my experience applying this algorithm, the first 25 and the last 2 minutes are the most critical for early-career software engineers. For busy teams that own large legacy systems, the team’s biggest challenges are not usually easy to solve, so I would focus on:

1. Learning about your team’s software system.

2. Understanding each team member’s sphere of influence.

Learning About Your Team’s Software System

The best way to learn about your team’s software system is to schedule a meeting with an onboarding buddy, team member, or manager and have them walk you through the architecture.

Depending on the size of the software system, this might mean getting in front of a whiteboard and drawing boxes, or it could mean looking at design docs and digital system diagrams together.

After I get a rough understanding of how things work end to end, I like to ask for links to resources I expect to reference day-to-day:

1. Wiki pages

2. Design documents

3. Code repositories

4. Deployment pipelines

5. Service dashboards

I recommend collecting and bookmarking these links for future reference (see 🔗 Why You Should Bookmark Links).

Understanding Each Team Member’s Sphere of Influence

You will still have conceptual and practical knowledge gaps even after learning about your team’s software systems from your coworkers.

These gaps are inevitable, as developing an accurate mental model of your team’s work takes months, if not years, of hands-on experience.

For the parts of a system you don’t understand well, identify the person who does so they can help you if/when you need to learn more.

Just like how you don’t need to memorize everything because you can look it up on Google, you don’t necessarily need to know everything about your team’s software systems, as long as you know who you can reach out to or where you can get this information.

Your Turn!

I hope this issue taught you something about onboarding to a new job or team.

Do you have any tips on onboarding for software engineers? Reply to this email or comment below to let me know!

Until next time,

Sammy