Taro Experts

Alex covered a ton, I can’t hit a lot else, but will mention this: In my experience and in a ton of examples in Larson’s Staff Engineer book… a “Staff project” is about 50/50 in promotions. Looking for such a project, and setting your sights on it, could end up not having as much impact and visibility than other cross-org or company programs you could set up, or work you could do. Focusing on a “big bang” project isn’t necessarily Staff behavior, doing the really challenging work that others won’t or can’t, seeing around corners, and making everyone better are. I know you didn’t say this would be all you would do, I’m just saying that if you’re doing everything else, and getting deep knowledge of product and team, a project opportunity may come up. If you are focused hard on finding a project you may not be doing everything else.

I think the most important risk to be aware of is that by speaking up you either demonstrate you know what’s going on in the meeting, what the other people are trying to accomplish, and how it all ladders up to the team and company goals OR not.

But by asking questions and listening first you figure that out before making an assertion or suggestion. By explaining your point clearly and concisely you have the highest chance of it making sense while respecting the time of people in the meeting. And by being either tentative, or 100% speaking in line with the direct goals of the other folks in the meeting and therefore being assertive, then you can’t really go wrong for throwing something out there

You sound like a multi-faceted, interesting person, with doubts about whether you will find your calling in a field that you perhaps entered on whim.

That sounds just like most of us out there, at your age!

I would say that it's definitely worth trying out other careers and see what else you might be more interested in, but don't be surprised if you came back to software either (as others have said, it's a deep field). Definitely go out there and pursue your interests, whatever they may be. There's plenty of part-time gigs and volunteer work that you could do in your free time to explore how to provide value to the world while doing the things you already love.

Ultimately, you will need more than just "interest" or "passion" to be truly great at any profession. Specifically, you are going to need personal dedication. And you probably want to be great, not only because it gives us "status", but also because it deeply satisfies our human needs to be provide meaningful value to the world.

This is my story. When I was ~3 years out of college, I was contemplating getting into policy making and non-profit as I was kind of getting sick of the "tech bubble" and how insulated it felt to be surrounded by people who worked in the industry. I thought I was very "woke" at the time and just might have the keys to fix everything that was wrong w/ our society (or at least, with tech).

So I went and I tried some stuff out along these lines. I volunteered w/ a city board and joined a cross-sector immersion program. And through it, I realized that while I did care about these things, (1) I just didn't have a ton to give to the people there skillsets wise (2) I didn't actually care enough about the problems they were going through to dedicate so much of my personal time into it. I...would rather play games at home. So after several months of this, I knew, deep down, that it wasn't my calling.

I came back to tech and software and gave it one more shot. I did change my team away from Ads because I hated ads. I re-learned clean code and programming paradigms about ~5 years into my career, and I found the material finally making sense as I had experienced enough pain in my own life (it all sounded like a boatload of BS before). Coupled with an amazing manager that cared about me, coding actually felt fun.

I also knew that I had a strange tendency to react very strongly to bad management and bad teams. At almost every stop in my career (and really, in college too) I was always raising hell whenever things were going poorly, but I typically also never really saw my complaints through to actually fix the problem. So when I ended up on a disaster of team after another reorg, I realized I actually wanted to see if, this time, I could be the person that can turn this disaster around. And I did. This in turn helped me to realize that I loved building great teams more than building great software. Which has been key part of what's led me to Engineer Management.

I guess what I'm trying to say is, there's a personal timing to everything in your life. Maybe software just ain't it for you. Maybe it just ain't it for you, right now. You won't know, and that's ok. Go try some of the other possibilities, and take some time to look inwards to discover your own reasons for pursuing a career.

Good luck!

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.

Like Alex said: 20 hours is impossible nowadays (it might have been doable duruing the pandemic), but it's possible to work 30-40 hours (leaning to 30) if you know what you're doing. I've been doing this quite a bit recently since I've been a bit burnt out, but it requires very strong foundations for:

• Reputation: you need a track record that immediately convinces people you know what you're doing.
• Influence: you need to be able to use your reputation to get teammates to do work for you & you need to know where the bar is for that work. You also need to be able to advocate for yourself to be involved in the most impactful projects.
• Technical fundamentals: you need to have strong technical fundamentals you can rely on to get code out faster and better than the company average.
• Prioritization: you need to know what work is valuable for your team/org and what work matches expectations of your level.

The higher the level, the more each category is structinized. At senior level and beyond, you need to be on point with all of these categories. All it takes is a bit of doubt to cause everything to fall down.