“How do you find problems worth working on?” a senior engineer I mentor asked me recently. He’s trying to make the jump to staff engineer and realized that the role isn’t just about doing the work he’s assigned. He also needs to get involved in figuring out what his team and org should be building.

Someone else had suggested blocking out time in his calendar to think about the bigger picture. He’d tried that, but hadn’t found it productive, so he asked if I had any alternatives.

I told him I rarely find good problems by staring at a blank page and trying to “think strategically.” Instead, I act like a sponge. I listen to the stream of day-to-day noise, absorb the problems people are having and let them sit in the back of my mind. Over time, some fade away while connections begin to appear between others that initially seemed unrelated. Eventually, I start to see what’s really slowing people down and what my team or I can do about it.

I’ve worked with many engineers who’ve never really tried this. They wait for managers or leads to identify opportunities, then demonstrate their value by solving the hardest assigned problems. That can absolutely lead to promotion. But the projects that have made the biggest impression in my career were the ones where I found and solved an important problem my leaders did not yet realize existed.

One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way.

Absorb problems, not requests

People love talking about the problems they are facing: in meetings, chat threads, presentations and email. They explain why their work is hard, complain about what slows them down and describe what they wish they could do.

When something overlaps with my area, I start pulling on the thread. I might ask, “If X existed, would it solve your problem?” or point them at an existing feature in a product I own and ask how much of their use case it covers.

Users often ask for a particular solution instead of explaining their root issue. Rather than taking the request at face value, I keep digging until I understand what they are trying to accomplish and why existing products do not work for them.

As a natural introvert, this sort of ambient listening works particularly well for me. I don’t need to fill my calendar with speculative meetings just to find ideas; there is already an enormous amount of useful information flowing around me during a normal week.

When a problem seems worth exploring, though, I become more active: I need to see how it affects the team’s day-to-day work. I’ll sit with them as they walk me through their workflows and the bugs they’re investigating. When I can, I’ll try working through some of those bugs myself. Seeing the problem firsthand makes it easier to separate what the team actually needs from the solution they asked for.

I also seek out people who see more of the organization than I do: those who own critical systems, work across several teams or have particularly deep insight into the work downstream of my team. I’ll arrange a 1:1 or coffee chat and ask about interesting problems they’ve come across. They may have already seen the same issue in several places and started connecting the dots, giving me a head start on patterns I might otherwise have taken much longer to notice.

Let problems accumulate

Several times, I’ve been burned by moving too fast. I became excited by a request from a vocal team, built the feature and watched them barely use it. Their priorities had changed, or the request had come from a one-off investigation that no longer mattered. How eager a team was in that moment wasn’t the same as how important the feature was relative to everything else my product needed to support. By hyperfocusing on their request, I lost sight of the bigger picture.

That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower.

Why? Because I don’t want to overfit on a single team or solve something that, in the grand scheme, turns out to be unimportant. If I wait, the same problem might pop up independently in different teams, making it a higher priority to solve. Or problems that look different on the surface might turn out to have the same shape, so I can address several use cases in one shot. Or the team asking for it might realize they didn’t actually care that much and don’t need the solution at all.

Instead, I make a mental note and revisit the problem if it comes up again. Other engineers I know write this sort of thing down more systematically. The mechanism is a personal choice: everyone has to figure out what works for them. What matters is keeping unresolved problems around long enough for more evidence to accumulate.

Find the common shape

Waiting helps me collect evidence, but that alone doesn’t tell me what to build. I still need to work out whether the problems I’ve retained are genuinely related and what, if anything, could address them together.

By this point, my head is usually full of spaghetti: possible solutions, constraints and half-formed connections. I like going for long, aimless walks around London and letting my mind wander through the mess. I find that connections come more easily when I’m not trying to force them.

Once an idea begins to take shape, I try it against other problems I’ve been thinking about. Sometimes I discover that features we already have can be combined in a new way. Other times, the idea changes shape entirely: instead of doing exactly what one team asked for, it becomes a general capability that solves their underlying problem another way.

The most promising ideas make several individual requests unnecessary. When one clicks, it feels unexpectedly elegant: several awkward problems fall into place at once, unlocking possibilities I hadn’t considered before.

I have to take care not to let that feeling get ahead of the evidence, though. In one recent case, I was convinced I’d found a single approach that would solve two problems at once. But as I wrote an RFC and built a prototype, it became clear I’d forced together problems that were better handled separately. In the end, I reluctantly split the design in two; happily, both parts have now shipped.1

That experience reinforced that seeing a common shape only gives me a hypothesis: I still need to test whether the problems really fit together and whether the resulting idea is worth building.

What I do next

You’d think this would be the moment when I start building, but it usually isn’t. How far I go from here depends on how sure I am that the idea works and that people actually want it.

Some opportunities are useful and low-risk enough that I act straight away, sending a change and letting my manager know. When I’m unsure whether an idea will work or how much effort it will take, I build a throwaway prototype instead. It exposes potential failure points and gives me something concrete to discuss with others.

Larger ideas might take weeks or months to implement and require support from other engineers or entire teams. If I believe in one enough, I put in the hard yards to build that support and work through people’s feedback until the idea has a real chance of happening.

Through this process, I’m not just trying to convince other people. I’m also trying to convince myself that the idea works and that there’s enough appetite to make it worth building.

Sometimes what I find tells me to stop. If people don’t see the same value I do or we run into some major technical hurdle, I’ll happily drop the idea; I’d rather find out now than build something that no one uses or that ends up becoming a maintenance nightmare.

At other times, I’ll find the idea makes sense, but it isn’t the right time to work on it yet. In these cases, I keep it on the back burner, ready for the day when it becomes an org priority. That moment may never arrive, but if it does, I’m ready to spring into action with a concrete proposal.

When everything does line up, though, a new project is born: maybe I implement it, maybe someone else on my team does, or maybe it changes what the org as a whole focuses on; I don’t necessarily need to own the implementation to have an impact.

One recent project exemplifies how all of these pieces can come together.

From feature requests to extensions

Perfetto is the performance debugging tool I work on. It displays recordings of system activity on a timeline made up of rows called “tracks.” Over the years, many teams asked us to add highly specific features to our UI for their own workflows. Several wanted a command that would keep their preferred tracks at the top of the screen, but every team cared about a different set. Others wanted Perfetto to open already zoomed in on a particular part of a recording or display a custom aggregation tuned to what they cared about.

Eventually, I realized that many teams were asking for the same thing in different ways: the ability to extend the UI. Some had even built elaborate workarounds involving bookmarklets.2 Each request made sense in isolation, but the specifics varied from team to team. Taken together, the underlying need was not any one feature. Teams needed ways to personalize Perfetto without imposing their choices on everyone else.

We were already building plugins to modularize the UI, but they weren’t enough; teams had to open source all their plugin code, which wasn’t an option for many internal use cases.

Before building anything new, I discussed the problem and my proposal with my manager, teammates and the client teams. I wrote two RFCs, set up several 1:1s and gave a couple of talks, refining the proposal as feedback came in.

In the end, I designed and implemented macros as “lightweight extensions”: a way for people to automate actions in the UI without writing a plugin. Extension servers took the idea further by letting teams share their macros.

Instead of implementing every requested feature ourselves, we gave teams ways to adapt Perfetto to their own needs. Dozens of teams inside Google now use macros and extension servers, and several other companies use extension servers internally too.

Solving useful problems helps me find the next one

The more often I go through this process, the easier it becomes. When I show genuine interest in someone’s problem, ask useful questions or help solve it, they remember. They start coming to me earlier and bring me into conversations with other people facing related issues.

That gives me a wider view of what is happening across the organization, making it easier to spot patterns and build things people actually need. Solving one of those problems brings me into more conversations, and the loop continues.

Those successes build the kind of trust that comes from long-term stewardship. Early on, I had to turn many of these ideas into something real myself to prove that my judgment was sound. Over time, my manager and org gave more weight to my assessment of what mattered. That allowed me to influence the roadmap without needing to own every project.

This differs from the idea that becoming a staff engineer means replacing technical work with meetings and coordination. For me, conversations are inputs into what I build, not the end result.

Conclusion

That is what I wanted my mentee to understand: finding problems worth solving isn’t separate from the rest of the job. It comes from staying engaged with people’s work long enough to see what no single request can show you.