Taro Experts

There are, as I think of it, levels or stages of mentorship and multiplying impact.

1. You can’t really help anyone, you’re just learning yourself. How you can have impact is writing down every question you have while learning and their answers, noting everything that didn’t work (and what you had to do instead) while following the on-boarding documents, anything that wasn’t easy to understand, and so on, then make sure your notes are correct and codify them by publishing a “read-along” of the onboarding tools, updating the onboarding documentation, etc. Contributing to future onboarding success as a new team member is great.
2. You are comfortable helping new team members with their onboarding. You can walk them through tricky parts, answer their questions, etc.
3. You’re comfortable mentoring/coaching 1-2 people 1:1, helping them improve, move toward promotion, making better choices, etc. You are comfortable with 1-2 people pairing with you on a project and directing their work.
4. You coach or mentor many people, have an understanding of needs across your team and make improvements, you are able to teach others how to effectively mentor or lead a small project, and you can lead larger projects with 4+ other engineers, making all of them better as they work with you.
5. You are coaching many people to coach effectively. You are teaching people to lead large projects. You are able to delegate large project ownership to others with the right level of involvement to make them succeed at delivery and making the other participants better. You have cross team focus for engineer experience and making improvements.
6. You can teach people to teach people how to coach. You can coordinate multiple large projects led by others and make sure they are all working well together. You focus on an org, and improving things for everyone.
7. You can codify coaching, teaching coaching, teaching teachers, etc in a standard program. You may run this program initially, but should hand off ownership. People can take these classes and become better leaders, regardless of knowing you or being in your org. You help others codify their own areas of expertise to teach at scale. You improve experience for engineers across orgs, or a whole company depending on size.

I’m sure it can scale to industry-wide impact, too.

You need to learn to put practices in place that work without you there. You want to be the “top” of a coaching tree, where people you taught are prolific, people they taught are strong leaders, and so on.

If you hand someone something and they don’t follow through, it’s their loss. You can give them another shot but you partner more closely, or hand it to someone else and let them know you’re happy to help them again when they can commit.

If you aren’t able to communicate details and that’s why they didn’t succeed, then you know you don’t actually have that ability down, and you either shadow really closely to fill in gaps next time, or you do it yourself more and document more completely, assuming you need to show someone starting from zero how to do it.

My experience was quite similar in the sense that I had several internships where I asked tons of questions and received no return offers. Personally I had little if any positive impact for the team. I assumed that since I had done well in school I would be high performing at a tech company. The reality was that I needed to learn a lot from scratch:

• How does shipping a product work? How do tech companies make money?
• How is code built at scale on the client and server side?
• Who are these non engineers I’m collaborating with?
• How do I learn on the job while delivering value?
• How do I work with my mentor and manager and collaborate with other engineers in general at a business?
• What is a perfomance review and how will I be evaluated?
• How do I have effective 1:1s?

Tldr: answering these questions for ANY company you pick is the key, by finding as SUPPORTIVE of a team as possible in your next role, while in return for their support you work as hard as possible to level up on your side. Because this is hard. But you can do it. And in general you have a huge leg up: you can learn a lot of info about all of this stuff on Taro!

Here was my experience:

My formula for getting out of this was to first build self confidence with side projects. I proved to myself that I could imagine something useful and solve it to some degree with just myself, my laptop, and the internet. I still asked a couple questions on stack overflow, and if chat gpt had been around and Taro I would have used that on that a lot.

Step two was finding a job with the #1 important parameter being excellent friendly senior engineers on the team open to mentoring me. (With an interesting product and tech stack distant 2nd and 3rd factors)

Step three was working nights and weekends for two years at that company so that I could survive and become great at the craft. I started on a Thursday, and took as many notes as possible immediately for two days. Then I treated myself to a Saturday brunch and followed that by sitting in a coffee shop trying to figure out the code base, what my first task involved, and how to get everything running. I had failed before but was not going to fail this time.

In the office I worked long days doing my best to collaborate asking good questions, and then at night kept going to keep figuring it out. After the 3 month open window on asking endless questions closed, I kept a journal of 3 columns:

1. First column was “I am stuck”
2. Second was “I worked for 2 hours on it and had to ask for help”
3. Third was “I worked for 2 hours on it and figured it out”

For context it took me 6 weeks to ship my first feature which was complicated but this was too slow. And after 3 months people liked my work but I was also too dependent. So at the 3 month mark I had that sheet going and shared the results in 1:1s to show my boss I was having less blockers overall and solving more and more blockers every week and month independently. At the same time my goal was to learn as much as possible quickly to be able to ship my next feature. For the first year at the company this was basically doing something new every sprint across our full stack android and node js app. But I tried to be relentless about tracking improvements like landing more PRs and shipping more results. Very painful but I landed a promotion after 1.5 years and kept going pushing and then became a senior / team lead a year after that.

You got this!

3 uses that jump to me:

• A GPT4 copilot that can watch your screen and help you pair program/debug
• Real time mechanic to help you correct your car or something
• Real time fitness coach to help you correct your form while training

https://www.youtube.com/watch?v=wfAYBdaGVxs
Here they show a real time interview coach 🤯. Would be an amazing tool for system design and DSA prep

Getting to SDE3 was one of the hardest steps of my career. It ultimately took 4 years to get there from the time I was hired. I went through a lot of frustration because I either didn't understand the process, didn't have enough buy-in at the start of projects or had to navigate circumstances outside my control (descoped projects, canceled roadmaps, etc).

So, I wanted to share some things I learned along the way.

There are a few key things that need to align to get the SDE3 promo:

1. Being a solid SDE2 performer. Work with someone you trust to assess your readiness for the next level. I personally struggled here because I tried to get to SDE3 while I had significant gaps to fill at SDE2.
2. Having a good manager. This isn't always within your control but I believe a good manager is responsible for up to 40% of your promotion success. Promotions at Amazon are manager-driven. The groundwork starts long before your promotion panel. There are two parts to this:
   1. How experienced and comfortable they are with the promotion process. They have to line up the projects, get stakeholder buy-in, write the promotion doc and ultimately advocate for you in front of the review panel. I've seen multiple botched promotions where the manager was either underprepared, failed to gather the right data or wasn't confident enough when challenged by the panel.
   2. The quality of the data they're able to gather to support your promotion. Part of this comes from you. You have to provide the right quality, delivery and performance metrics of your projects. The rest comes from them gathering the right feedback from key stakeholders and their own assessment of your performance.
3. The right scope of technical work for SDE3. This is one of the most challenging parts. Unfortunately, there's no magic formula for this. But, there are a few things you can do to help yourself in this process.
   
   First, you need to understand what SDE3 scope looks like. You can do this by reviewing designs from current SDE3s, talking to more senior engineers and getting feedback from your manager.
   
   The next step is finding the right scope project. This is where most people struggle. Below are some ideas but by no means an exhaustive list:
   1. Finding the right project in the existing roadmap. You can work with your manager to assess the complexity of planned projects and which ones will fit the SDE3 bar.
   2. Finding projects that can be expanded in scope. The right scope can come from the way you deliver a project and not the initial set of requirements. Even with limited initial functionality, you can propose a bigger technical vision that can support the future expansion of the product. You don't have to deliver on the whole vision to get credit for the design. The key is to keep the initial deliverable simple but showcase the considerations that went into making it scalable and expandable.
   3. Look for problems with large impact that no one else is solving. I've seen Principal-level projects dealing with metrics improvements. The difference was in how they solved it. Instead of solving the problem for a single team, they solved it for the whole company.
   4. Networking with other engineers and managers. If your team doesn't have the scope you need, you want to be on the radar of other teams that may have the right scope. This requires visiblity into other teams.
   5. There's a "hidden" option that I'll discuss in the bullet point on documentation.
      
      Lastly, make sure to get any proposed project vetted and approved before you start it. This is crucial. When I was still at Amazon, there was an official process for doing this (although it wasn't required). This will save you a lot of frustration dealing with last-minute disagreements about scope.
4. Demonstrating LPs at the L6 level. As you already know, LPs are at the center of all roles at Amazon. Having the technical skills and projects isn't enough. You need to demonstrate the key LPs required at the L6 level. This includes Think Big, Are Right a Lot, Hire and Develop the Best, and Invent and Simplify. These are the major differentiators at the L6 level but all the others are important as well.
   
   SDE3 is a team lead role at Amazon (although there's no official team lead role at Amazon). You have to demonstrate the ability to deliver through others, force multiply and drive influence within and outside your team.
5. Getting buy-in from key stakeholders. This is a "behind the scenes" thing most people don't realize. Not only do you need other SDE3s to validate the complexity of your projects but you need other key L6+ stakeholders to provide feedback that you're operating at the L6 level. I forget the exact number (Alex's statement that it's 6 people may be right).
   
   But, the important part is that you have to demonstrate this through your limited interactions with these people. The stakeholders include PMs, TPMs, SDMs of partner teams and senior managers. The more the better. You can't ask for this feedback directly so you have to work through your manager to solicit and process this feedback.
6. Having the right documentation. You need a solid portfolio of work to demonstrate your growth. This is particularly important if you've switched multiple teams and projects as you're working on your SDE3 promo. Your manager won't have visibility into your past work. They will talk to your previous SDMs (if they're still around) but it's always better to create all the necessary documentation in real time than hope you can gather it later.
   
   There is also an option to get promoted based on "portfolio complexity" rather than individual projects. This is what happened to me. After working on multiple projects that didn't hit the complexity bar on their own, my manager was able to make a case for promo based on my portfolio of work. I hit all the right checkboxes in at least one of my projects.

There is a lot more I could say on this topic but I will leave it here for now. If you have any questions, feel free to post a reply.

I use a wooden kitchen chair that my family's had for 20+ years.