How to figure out what the most important projects are?

What's most important really depends on:

1. What are the company problems that need to be solved
2. What the company recognizes as important problems

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:

1. How many people or teams it effects
2. How long the positive benefits will impact the org
3. How many people will need to work on it for it to be successful
4. The highest level of stakeholder who will have visibility

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:

1. Figuring out the most impactful projects
2. Understanding impact
3. Adhering to the battle plan

Figuring Out The Most Impactful Projects

Here is my process:

1. Go through all your tasks and projects and put them in a personal central source (Notion doc, JIRA, etc)
2. For each item, figure out the dot product of their required time and estimated impact
3. Stack rank the items from #2 based on their scores, only caring/working on the top 2-5 items

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:

• 3 = Low time commitment (1 day - 2 weeks)
• 2 = Medium time commitment (2 weeks - 4 weeks)
• 1 = High time commitment (1 month+)

For "estimated impact", we do something similar:

• 3 = High impact
• 2 = Medium impact
• 1 = Low impact

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:

• Anything with 9 is low-hanging fruit which is high-impact, low-time commitment. You probably won't have any of these, but if you do, congratulations!
• Anything with 1 sucks as it's low-impact, high-time commitment. At Big Tech, you'll probably have a ton of these. Toss them out.
• Discuss with your manager and team (+ use your personal intuition) to figure out what to do from the 4 to 6s.

Understanding Impact

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:

• High: Contributes 30%+ to the goal - Projects needs to be +1.5% EBR or better
• Medium: Contributes 10 - 30% to the goal - Project needs to be +0.5% EBR or better
• Low: Contributes 1 - 9% to the goal - Project should add some EBR (obviously)

But what if my team doesn't have any metrics?

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:

1. Add metrics - At Amazon-scale, everything should be logged. And given that you're a Data Engineer, you should be particularly well-equipped to instrument this 😉.
2. Talk to leadership - In particular, talk to product and engineering leadership to understand what they think is important. This could be the only way to establish success criteria for a team if your roadmap is entirely ship-based (this is mostly what it was like working on Portal). When in doubt, just talk to people!

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:

• "I want to become the "data guy" in my company - How can I do that?"
• "How can I demonstrate the impact of migration projects in a platform team?"
• "How do you measure the impact of refactoring your codebase to use a new pattern?"

Adhering To The Battle Plan

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:

1. Learn how to say "No" - You're inevitably going to get asked to do "side missions" by other people in the company, especially as a senior engineer. Never automatically say "Yes" to a task to be nice. Do the same impact/time calculation and weigh it against your current tasks. If it doesn't stack up, politely decline the task, explain your current priorities, and route them to your manager if they want to discuss more.
2. Refresh the plan regularly - Priorities change. Estimates change. It's important to reflect that, and you do this by refreshing your priorities list every 1-2 months. It should be a living document.
3. Align with your manager - Your priorities list is an excellent discussion topic for your recurring manager 1 on 1. While it would be exhausting to bring it every week, every 3-4 weeks seems fine. Adjust up or down based on the chaos level of your org - It's entirely possible that you need to reevaluate priorities every week if your org is currently going through a period of massive turmoil (which many Big Tech orgs do).

Here's a bunch of other good resources on how to get stuff done as well:

• "How does one effectively handle pressure especially when the stakes are high?"
• "How to improve at multi tasking at work?"
• [Taro Top 10] Time Management And Productivity