How to establish impact when assigned on non-priority projects?

Career growth comes from working on whatever is most important. So you have two options:

1. Figure out how to get allocated some of the more impactful projects that are considered more important.
2. Make a compelling case with data, narrative, or conversation that the work you're doing is actually undervalued.

Another dimension to this is "important to who?" Certain projects may be more important to the design or PM teams than to engineering. Within all the engineering-led projects, some projects will be more important to certain leaders than others.

Your job is figure out the landscape and then strategically decide what to work on. Use "Talk & Observe" as a way to do this as I talk about in the onboarding course.

One general rule of thumb is to work on projects which have fewer dependencies, which means there are fewer opportunities for things to go wrong. If the project you're working on requires zero input from design or PM, you don't need to rely on their (differing) opinion on project priority.

This is why internal tools for other developers is often a ripe area for impact and innovation. It was a big part of my own promotion to Staff Engineer at Meta: [Case Study] Building A Meta Internal Tool To Empower An Entire Org: Staff Promotion Story

One solution that hasn't been mentioned is to ask for higher-impact work. This may sound simple but you can't get something if you didn't ask for it.

What might this look like in practice?

First, talk to your manager about wanting higher-impact projects. But, more importantly, be specific and tie them to your strengths. So, if you're an expert at fine-tuning high-throughput databases, you would ask to be included when your expertise is needed.

If your manager isn't able to just give you this work, go to the next step.

Secondly, get involved in projects earlier. Start participating and contributing to more projects earlier in the development phase when possible. You could ask to sit it on a product requirement meeting or a design review.

The intent is to learn more about the product and contribute where you can. But, the more you do this, the more visibility you have. When it's time to distribute the work, you're more likely to get it if you're already familiar with the project and contributed earlier in the process.

Showing impact is the same regardless of the project: Work backwards from the goals and try to add logging - "How do you measure the impact of an initiative you are leading?"

In terms of how to claim a good amount of credit for it, that's tricky. You have a couple options:

1. Craft a narrative that these projects are more important than people think - Try to tie these projects to your organization's goals/North Star/KPIs/OKRs/etc. You need to come up with a connecting line they're not seeing. From there, I recommend making a nice doc or slide deck and presenting it to leadership.
2. Just ship it and see what happens - Sometimes you don't know the true impact of a project until you launch it. This is a common strategy I've seen from top engineers, especially those who got to Staff levels and beyond. They were able to finish their core roadmap work early (e.g. with just 35 hours out of 40 in a week) and essentially tried out these seemingly "lower impact" projects as an experiment (they often had some intuition on why these projects were undervalued). A lot of the time, their intuition was correct, and they looked like a hero.