What should be part of an Onboarding doc?

One high-level point to begin: Since you're a principal engineer, having an agreed-upon onboarding doc is really important, since your output won't be as tangible in the first few months.

• As a very senior engineer, your job is to lay the foundation for broader team or org level impact, which generally means building relationships and networking (as your manager said).
• Unlike a junior engineer, you may not have a concrete number of bugs fixed or lines of code written in the first month. Having the onboarding doc gives you protection and feedback to ensure you're on getting ramped up.

I switched teams about 3.5 years into my time at Meta, and my new manager created an amazing onboarding doc for me. I'll share what that doc consisted of, but it won't apply directly to you since you don't have as much context as your manager. I'd leave areas in the doc where you're looking for input from your manager -- this is an easy way to collaborate and deepen your relationship.

Sections:

• Team charter. Your team likely has a mission and some existing KPIs to measure progress. Put this in your own words and invite feedback on if your manager agrees.
• People to meet. Should include engineers, managers, and partner teams. (Ask for feedback here.)
• Expectations at 2 weeks, 4 weeks, 6 weeks, 2 months, 3 months, and 6 months. Try to phrase these goals in a way where it's clear if you've achieved the outcome or not.
• Project ideas with T-shirt sizing. These can be pretty rough, just talk about the observations, current staffing, and the impact you can have.
• Write down engineering expectations for your level, and add commentary on where you feel strong vs where you want more guidance and feedback. e.g. at Meta, I talked about my goals in each of the areas: Project Impact, Direction, Engineering Excellence, and People.

Some additional pointers:

• Most important things to work on as a new engineer
• Who should I set up 1 on 1s with after joining a team?
• Follow this advice from Boz (CTO at Meta): Career Cold Start Algorithm

This is a great instinct! I'm glad you're taking the initiative here - It's very important to be proactive instead of reactive, especially at your level. By creating this document yourself and then sharing it, you give your manager something to anchor against to make the discussion around your performance far easier. Use it as a core discussion point in each of your 1 on 1 meetings.

My manager is spread very thin and wants me to take initiatives and has told me to start networking heavily in the first few weeks.

It looks like you should have the following 2 sections at least then, which Rahul also mentioned in some form:

• Who to get to know
• What initiatives to take on

For the initiatives, it could be interesting as since you're leveled so high, the expectation might be that you are also creating scope and not just taking on initiatives that are already scoped out. I recommend asking if your manager if this is expected of you and reading through this discussion on how to come up with big new initiatives.

As Rahul mentioned, it's very important that you understand what the expectations are at your level. There's a couple ways to do this:

• Observe other principal engineers - The less tenured they are at Target the better as that means they're more similar to you. Understand their output, behavior, and impact. Are they writing a ton of code? Are they putting together system design docs? Are they running giant meetings? Whatever they're doing, try to emulate that as much as possible. I would also put 1 on 1s on their calendars if you can to see how they think about the engineering landscape, understand what projects they're working on, and figure out potential opportunities for collaboration (maybe they have extra principal-level work scoped out already).
• Read through Target's career matrix - At Target's scale, I'm sure they have one (we had one at Robinhood, and Robinhood is far smaller than Target). Read through it and talk to your manager to really understand it as these resources are generally very high-level and hard to convert into concrete action items.

Also, similar to what Rahul said, if there are formal axes to judge engineering performance, that's probably a good way to organize the expectations in your document. That's how I organized my expectations plans for both myself and my mentees back at Meta.

Lastly, I highly recommend this case study I did about how I became a tech lead again in just 1 month after switching into Robinhood from Meta.

I think taking this initiative is appropriate, but I’d definitely make some tweaks. I am coming off a “failure to launch” experience at Meta where I tried what you’re suggesting and it could have gone better.

First, ask your manager or skip (and get them on a mail thread or a chat room or whatever so you are all on the same page) what timeline they expect you to be contributing, and what. If no one knows, this isn’t great, but certainly proceed with making your own plan and having it ratified by this group.

The other bit I’d be careful with is waiting 3 months. Even if your manager is busy, I really hope they can check in with you, even if it’s asynchronously, once every 2-4 weeks. You can go WAY astray in 3 months. You’re going to want to course correct.

If your plan has dates attached, and none of them are slipping at all, I guess maybe longer time periods, but it still makes me nervous. Again, my reason is I made this kind of plan, worked on it for six weeks, then my manager gave me a different, wholly dissimilar plan and said I was really behind on it after about six weeks. I may be conservative for this reason.

In that doc, I would organize it around whatever the principal tenets or role guide pillars are. If it’s like people, technical excellence, teamwork, and community building, set up how you will build up each. For people, have 1:1s with the engineers you’re responsible for and see where you can help them develop. For technical excellence, how you’ll learn the code your team owns, and the systems it interacts with, and identify 2-4 areas of improvement to prioritize over the next few halves. For teamwork, identify the processes your team is using that need people siloed or causes conflict and gather ideas to fix them. For community see if remote folk are always considered, what social activities are happening, how people socialize their work, and so on. These are obviously made up, but I think aligning to a scope that is right for you based on the role, and to guiding principles will show dedication to the company’s values.

As for pointers: 0xc48ad17b 0xdeadbeef 0xcafeeat5 0xa7edca7d

Edit: There were no responses when I started this =) enjoy going through three long replies.

I agree with what Lee said about waiting too long. Even a busy manager should be able to check in every few weeks. Something that may help is figuring out your manager’s communication preferences and tailoring your doc to that. For example, if your manager prefers email, I would use email. If they prefer a wiki like Confluence, I would write the doc in that medium.