How to identify complex and vague problems at work?

Is there some issue that's annoying a lot of people that everyone is also running away from like it's radioactive? Congratulations, you have identified a complex, vague, and high-impact problem. 😀

I have taught a lot of engineers on how to create their own scope, and the gap I usually have to bridge is their awareness and sensitivity. Engineers who are junior, mid-level, and on the earlier end of senior tend to have a default numbness to certain issues. Something in their environment will suck and be horribly inefficient, but they just accept it. They don't consciously realize that as a solvable problem and an opportunity.

My go-to example with this numbness is build speed:

• Back at PayPal, we had build speeds of >2 hours on a fresh build. But there wasn't this sense of urgency to make it better. People just said "That's just the way it is" because PayPal is a multi-billion dollar company with 20+ years of history. One of those people was me.
• At Meta, a >2 hour build speed would make everyone's heads explode. This is why a bunch of brilliant Senior Staff+ engineers moved heaven and earth to build extremely powerful and complex build infra to reduce build speeds down to as little as 2 minutes. Back when I was at Instagram, I was able to do my daily "fresh" build of the entire Instagram Android app in 2 minutes. Incremental builds could be as fast as 5 seconds.

Unless your current engineering team is literally perfect (which there's 0 chance of, especially at a top Big Tech company like Grab), then there is opportunity. You just need to distill it down into something actionable. See where people are complaining and run towards them as fast as you can.

I highly recommend going through this entire playlist if you haven't already: [Taro Top 10] How To Create Scope As An Engineer

When it comes to identifying technical complexity, check this out: "How do you choose an opportunity for technical depth?"

If such problems don't exist in my team or if they exist but don't generate high outcome, should I look for outside my team to solve such problems?

Yes! This is classic staff-level behavior, finding problems outside of your immediate team's domain, ideally a problem that affects both your team and outside teams. Something I noticed for engineers at Meta starting at E6 (Staff) and especially at E7 (Senior Staff) is that their manager connection on the org chart almost felt like a formality. These engineers were constantly finding scope outside of their immediate team. This was very, very apparent for E7s where they would just find random big problems that were completely disconnected from their direct manager's team charter. It was magical to see.