What’s the most effective way to switch domains in tech?

First, I recommend this in-depth breakdown of how to write great code faster. This applies to every software engineer at any stage in learning a tech stack, but the advice is still very applicable (and even more urgent/important) here.

That being said, here are my thoughts on onboarding into a new tech stack:

• Meta is all about incentives. It's crucial to understand what engineers are looking for when they approach any interaction. For your situation in particular, you have a lot of power as an E5 as you can create an incentive for more junior engineers to help you ramp up. "I helped a senior engineer on my team reach 100% productivity quickly" is a PSC gem for the people axis.
• Specifically, find a strong E4 who's been on the team for a while to help you quickly understand the codebase. This can be built into a strong, longer-term relationship (i.e. recurring 1 on 1 meetings) as you absorb the codebase mastery from this engineer and you can teach them more senior engineer fundamentals.
• Use the "Lego Model" to understand what to learn and master first. There are going to be some components that are extremely important and common across execution.
• In the end, all tech frameworks and languages are sort of the same. Try to map the new domain's components into your existing understanding you have of your prior system.
• Use your fundamentals, particularly around shipping quality, scalable software. You're on a team where this matters a lot.

Related resources:

• "How to learn a new programming language when you join a new company?"
• The Lego Model
• Rockstar SWE Story With SW2 -> Principal Promotion In 4 Years (covers Pareto principle)

Feel extremely comfortable failing and losing face. That's a key trait to learn quickly in a domain you don't know much about. Do that as early as possible.

If there's a question you are too afraid to ask in your first 90 days because "would that make me sound stupid", think about what happens after 12 months. It's likely that you still don't know much about that subject and now you feel horrified about someone figuring that out. That will negatively impact your capability to make an impact. Looking back from that future the only rationale choice is to ask that stupid question and make sure you learn well from the answer even if it's very uncomfortable.

This is based on the observation I had from Meta Bootcampers I mentored. I've seen a staff engineer who was a deep expert in one subject but wasn't comfortable and proactive enough when ramping up to random subjects in the Bootcamp, and almost got fired from the lack of progress in Bootcamp. I've seen a manager (with no prior iOS experience) picked a simple Apple Watch bug, followed the wiki to set up XCode (and other Meta-specific iOS development environments), and fixed the bug in a week.

The best Meta engineers I saw with this trait of fast learning usually had prior experience as early engineers (sometimes CTOs) of successful startups. In hindsight that makes sense. In an early-stage startup environment, if you fail to learn something quickly, build a prototype tonight, and demo it to the investor tomorrow morning because the situation requires that, your company is dead in the water. Losing face is the last thing to worry about.

Lose the pride of "I'm a senior engineer". Be a noob.