How does technical onboarding differ as you go up the ladder?

First, I highly recommend going through our masterclass on succeeding in a new environment. A lot of it is targeted towards software engineers, but I would say most of it applies to everyone, namely the materials around building relationships and asking questions.

For my initial comment, I'll just go through my high-level take on this: The more senior and closer to people-management you get, the more relationship-driven your onboarding will become. This means:

• You're going to move farther away from the code and understanding the nitty-gritty of technical systems
• You're going to have way more meetings
• You need to be extremely precise around identifying crucial stakeholders for your work and quickly befriending them

Software Engineer

• I'm using this to refer to junior and mid-level engineers (so L3 and L4 by FAANG leveling standards).
• For folks in this bucket, they're largely focused on building a familiarity with the codebase and training up that muscle of landing code.
• On top of the general onboarding session, if these engineers follow the advice in our "How To Write Better Code Faster As A Software Engineer" masterclass, they should be just fine.

Senior Software Engineer, Tech Lead, Staff Software Engineer, Principal Engineer

• I'm putting these all in one bucket as they're all similar-ish from a high-level perspective.
• Onboarding is harder for engineers at this level as they need to both familiarize themselves with the codebase and spend a lot of time building relationships.
• If you're explicitly labeled as a tech lead, then the people-driven part is absolutely crucial. People won't follow you if they don't like you.
• For a great case study demonstrating this, I recommend my case study of how I onboarded into Robinhood after leaving Meta, becoming an acting tech lead again in just 1 month.
• For general relationship building advice, I recommend our masterclass on how to build deep relationships quickly in tech.

Head of Engineering, Director of Engineering, Vice President, CTO

• This one I have the least visibility into as I was never remotely close to this level, but I'll take a stab at it. 😜
• At this level, you shouldn't be getting involved with the "on-the-ground" details about the codebase. That should be delegated to front-line managers and tech leads. You should only understand broad strokes engineer problems like, "Since we're currently a monolith, our system reliability is poor. We need to migrate to microservices."
• You're going to have a lot of meetings, and you should really get to know the people reporting to you as your entire job is to exert your influence through them to carry out your version and solve org-wide problems.
• Something I noticed several folks at this level do at this onboarding was do a round of intro meetings with folks "on the ground" to build trust and get concrete data on what problems they face. When a new Senior Director of Engineering joined my org at Instagram, they did a lunch with every team in their org. During that lunch, we all had a friendly chat, they would ask us about what challenges we were facing, and we could ask them questions back.

Hopefully someone who is at this level can leave a much better answer than me 😅

One way to think about it is, how many people are you influencing? An entry-level engineer might influence 1 or 2 people, but the CTO should influence the whole company.

Now, based on that, the people you talk to and the context you try to gather in onboarding should match that.

Mo talks about the expectations at each level in his talk: https://www.jointaro.com/lesson/Tr3bHl6mIVsmZZ6BAQLc/session-9-how-to-become-a-data-guru-as-an-engineer-w-senior-director-of-ds-mo-shahangian/