Switching workstreams as an E3?
Hi all, recently during Q1 roadmapping I chose to move on to a new workstream from a growth/independence point of view as part of working my way up to E4. (My earlier effort was a 1->100, this one is 0->1 and was decided by me, my TL and EM together), and I had a couple of questions about this move.
- I have spent the past 6 months gaining context on a set of technologies and tools (internal to Meta) that perhaps only 2 other engineers on the team have context on.
- Should I do a knowledge transfer session or write up a doc to ensure all the context I have doesn't get lost?
- Should I allocate some time to supporting the team until I'm here on areas I gained context on?
- There is some possibility of scope thrash since I'm also long-term supporting one of the projects part of the earlier workstream (I delivered the v0 and have been making iterative but small changes since then). Should I talk to my manager about this?
- This is a very n00bish question: from a growth perspective, is it better to go 110% on the new workstream and all its nuances/open problems or go 80 and 20? As far as allocations go, I'm slated to be 100% on the new workstream as part of the roadmap.
- Bonus question: should I do a year-in-review/look-back post in tandem with my self review? (This is a very Meta-specific question in a way, but would love to hear other views too!)
Discussion
(1 comment)- 1a year agoRobinhood, Meta, Course Hero, PayPal
Thanks for sharing all this context!
Should I do a knowledge transfer session or write up a doc to ensure all the context I have doesn't get lost?
Why not both? You can write the doc and use it as a pre-read for the knowledge transfer meeting, so people can ask questions on stuff they're unsure about.
Should I allocate some time to supporting the team until I'm here on areas I gained context on?
You can, but be careful: The classic failure mode is that you get sucked into this, preventing you from achieving good impact on your new thing. You can make it formal like, "I'll be formally around to support this with 10% of my time for the next 1.5 months". You can work with your manager to negotiate these "terms".
If there's 2 other engineers who have this knowledge, you could also just let them handle it.
There is some possibility of scope thrash since I'm also long-term supporting one of the projects part of the earlier workstream (I delivered the v0 and have been making iterative but small changes since then). Should I talk to my manager about this?
Whenever you think of the word "thrash" for anything, talk to your manager about it. 😄
This is a very n00bish question: from a growth perspective, is it better to go 110% on the new workstream and all its nuances/open problems or go 80 and 20? As far as allocations go, I'm slated to be 100% on the new workstream as part of the roadmap.
Is the idea of 80/20 that you have this 20% time to spin up side projects and find creative, new sources of impact? If so, I personally prefer this as you're hopefully going to be focusing on the E4 -> E5 promo soon, and E5s are generally expected to create scope.
That being said, things will vary based on your team and manager - I have seen Meta engineers get promoted to E5 with a "hyper-focus" style as well. Run this by your manager.
Bonus question: should I do a year-in-review/look-back post in tandem with my self review? (This is a very Meta-specific question in a way, but would love to hear other views too!)
Is the idea to make a Workplace post? If so, I think these posts make sense for a project/workstream (e.g. "Here's the year-end look-back of our team's snapshot testing workstream and the impact it achieved") but would be sort of weird if it was about your personal contributions entirely. For the former, I actually recommend making these posts - It's always good to retrospect, and I've seen many E4+ engineers cite these posts in their PSC (myself included).
