How do I find projects for myself at work?

I can't tell if you are looking for promotion into senior or staff, so I'll link this very recent question about staff level promo here. Rachel's discussion on staff engineers literally discusses how at Staff, you have to find your own projects.

In general though, I think this is fantastic question because figuring out what problems exists and how to solve them are inherently important to your growth as an engineer. While there are top-level directives that results in big projects with huge impacts, often projects start with smallish estimates and become bigger projects and bigger impact, because the engineers on them are looking out for the correct risks and ways to leave things better than when they started.

There's a couple ways I've personally seen people of all levels find projects, and one key insight is that often people weren't aware these projects.

1. Pain points during development: the software we work on is never perfect, so as you execute, you are bound to find specific patterns that slow you down. Are there some much needed refactor, or re-achitecturing that needs to be done? Is there some tooling or patterns that you've seen and learned elsewhere that would help with the pain points you yourself have encountered? Start there - if you are feeling the pain, you (and your peers) may be more internally motivated to solve it.
2. Pain points for users: similarly, the products our software power are far from perfect. Are there some critical user scenarios or some obvious missing pieces that doesn't take long, but everyone has been moving so fast that this has never been prioritized? Is there a pattern within user feedback that the org isn't focused on? Figure out why - and maybe some of these require small amount effort but have decent sized returns. These high-leverage items are great things to focus on.
3. Pain points for organizations. Is your organization struggling to deliver because the lack of, or sometimes too much of, process? Do people in your team or organization trust each other? See if you can do anything here - potentially these things don't even involve any coding, but are extremely rewarding projects to go after.
4. Look consistent patterns of negligence. Have there been recently outages, complaints, lost deals or revenue to the company or product, due to internal or external factors? Are there things your senior people are putting off because there's other, more important things? Take a deeper look at those issues and maybe there's something you can do to help while your senior people are (maybe correctly distracted).

Lastly, you want to prioritize these projects by leverage - the impact the project would have divided by the amount of effort it takes. Impact doesn't have be material or necessarily measurable (it could be trust earned with important members of organization, more trust in the product or people in the org, etc), but it's good for you to have an expectation for what would the impact be if you invested your time and energy.

Alex actually has a great talk about finding scope with an example from his time at Instagram: https://www.jointaro.com/lesson/WYk4J05iBqOuPtD0CYKX/session-1-solving-a-multi-million-dollardollar-instagram-bug/

On top of Kuan's excellent answer, I recommend going through these discussions too:

• "How do I come up with innovative, impactful ideas and bring them to my team?"
• "How can I come up with big initiatives, especially those at a Staff level?"

In general, finding a good project isn't too different from building a good product: Work backwards from problems. Be acutely aware of pain points (there will be a boatload in any good engineering team), and from there you just need to evaluate solutions and stack-rank them based on the dot product of time required and impact.

You already have the first step in solving this problem which is realizing that you need to find these opportunities instead of waiting for your manager to hand them to you. The next step is to go out there and start exploring the problem space!