During "How Rahul's Compensation Went From $400K to $800K at Meta" session, Rahul mentioned only a few projects are important. I would love to get some concrete examples from Rahul or others on what that looks like. This is my very first question that I am posting in Taro forum. Thank you for the encouragement Alex. Looking forward to everyone's answers.
What's most important really depends on:
Oftentimes these are the same, but sometimes they are not. I would argue 1 is better to pursue as it actually makes the company better. However, if you're more focused on internal promotions and recognition, 2 is better for the short to medium term.
If you are going to pursue an important problem that aren't getting the recognition they deserve, you should advocate for it so it enters category 2. For example, if you believe that a lack of internal tooling is causing devs to be less productive and bugs to me more apparent, you need to contextualize that for the business. You would want to show the extra cost to development time, the cost of fixing bugs, and have a concrete number for that. Also, have a concrete number for the opportunity cost, and then show the cost and impact of your proposed solution. If you're persuasive and have good management, this means you will be able to work on something you care about, is recognized by the company as important, and actually helps the company.
There may already be tons of things in category 2 you can work on. For example, if conversion is a problem your product is having, you can work on improving the, user experience, analytics, building/implementing a/b testing frameworks, etc. You can show how important your project is with obvious metrics like improved conversion rate. Decreasing cost and increasing revenue are always low hanging fruit, but there may be more interesting problems like hiring processes, dev processes, etc.
If you're having trouble finding important problems, it's good to talk to other teams, looking at overall company goals, and hearing from department heads or skip managers are great places for inspiration. People in your company who have been promoted quickly will have some more tangible advice and experience for your org. Keep in mind that these often don't align with your regular daily tasks unless you are already working at a cross team level like Staff, Principal, etc. So, try not to just look at your immediate team's needs, as that will lead you to solve problems in your team's subdomain and not larger more impactful problems.
Some easy things to look at to gauge how important a project is are:
Hope this helps. One thing to keep in mind is that I have more experience with medium sized companies or ones that prioritize autonomy and independence. I assume since you are at Amazon there is complex structure and politics (call it stakeholder management if you prefer) that you will have to navigate. Someone here with more FAANG experience would be better advising you how to make this advice actionable given your specific large company.
This is a really good and important question - Thanks for asking! It's especially relevant once you get to senior as 90% of engineers hit diminishing returns with improving their raw coding ability on their journey to staff. Since you're at Amazon, most of the stuff I learned here at Meta should be applicable to you.
I have a lot of thoughts here, so I'll split it up across 3 separate responses:
Here is my process:
Now let's expand on #2.
For "required time", give a score from 1-3 where 1 is bad and 3 is good. As a heads up, the times I outline below are at Big Tech scale (like Amazon/Meta); they will be much smaller in a startup:
For "estimated impact", we do something similar:
Impact is highly subjective and varies based on team, so I will cover how to figure out if something is high/medium/low impact in my next response.
When each work item has these 2 scores, you can now multiply them together to generate a final score of 1 to 9.
This will reduce everything on your plate to the only metric that matters: Impact gained per unit of time
After you do this exercise, you can do something like this:
I'm curious about the numbers you assigned based on time commitment. Senior software engineers usually work on longer projects (3+ months). How would the numbers for the time commitment vary based on the level?
So you now have a tidy list of tasks, properly prioritized by impact yield. This is only the 1st step. It is so easy, especially at a high-performance Big Tech company like Amazon, to go off-track from this plan and get distracted by random things.
Here's my advice to avoid that:
Here's a bunch of other good resources on how to get stuff done as well:
At a Big Tech company like Amazon, you should have metrics to gauge the progress (or lack thereof) of your team on its business objectives. I'll use my previous team Instagram Ads as an example.
The goal of an ads team in a social media company is to make $$$, so our primary metric was pretty straightforward: "Event Based Revenue" or EBR. Event-based primarily refers to the event of a user clicking on the ad. So at a high-level, our goal was to display ads in a more appealing way to convince users to click on the CTA (call to action) button and consider the product.
Now let's assume my team's goal is +5% EBR for the half. When it comes to understanding high/medium/low impact, I used something like this:
This will be especially common at smaller companies and less mature orgs in Big Tech. If this is your situation, strive to do the following:
Defining the success metrics for a team is easily a senior -> staff project. If your team doesn't have clear direction because of this, this is a huge opportunity for you!
Here's a bunch of other good resources on the topic: