I just joined Target at a Principal level. 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. My plan is to create an Onboarding doc and share it with my manager. I'm going to use this doc to manage expectations and use it to review together 3 months down the line. How can I structure this doc? What pieces of information are more relevant/vital for such a doc. Any pointers?
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.
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.
Some additional pointers:
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:
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:
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.
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.