How a staff engineer finds problems worth solving

A staff engineer who works on the Perfetto performance tool has written up the answer he gives when engineers preparing for promotion ask how to find problems worth working on. His method is not blocked-out “strategic thinking” time, but a habit of listening like a sponge and letting problems accumulate.

Absorb problems, not requests

People explain their difficulties constantly — in meetings, chat threads, presentations and email. When something touches his area, the author pulls on the thread: he asks whether a hypothetical feature would solve the problem, or how much of a use case an existing feature already covers, rather than taking a request at face value. Users, he notes, usually ask for a specific solution instead of describing the underlying issue.

When a problem looks worth exploring he becomes more active: sitting with the team, watching their workflows, reproducing the bugs they are investigating. He also seeks out people who see more of the organisation than he does — owners of critical systems, engineers working across teams — because they have often already spotted the same issue in several places.

Let problems accumulate

He has been burned by moving too fast on a request from a vocal team, building a feature they then barely used. So he keeps a mental note and waits. A problem that resurfaces independently in several teams is a stronger signal; problems that look different may turn out to share a shape that one solution can address; sometimes the team that asked realises it does not need the feature at all.

When an idea starts to take shape, he tests it against the other problems in his head — often on long walks around London. He is careful about the feeling of elegance: one idea he believed would solve two problems at once was split in two after an RFC and a prototype showed they were better handled separately, and both halves have since shipped.

From feature requests to extensions

Perfetto displays recordings of system activity on a timeline of rows called tracks. Over the years, teams asked for narrow UI features: keep this team's tracks at the top, open already zoomed into part of a recording, show a custom aggregation. The underlying need, he concluded, was not any single feature but the ability to extend the UI without imposing one team's choices on everyone else. Plugins existed, but required open-sourcing all plugin code, which many internal teams could not do.

He discussed the proposal with his manager, teammates and client teams, wrote two RFCs, held one-to-ones and gave talks, then designed and shipped macros as lightweight extensions, plus extension servers so teams could share them. Dozens of teams inside Google now use macros and extension servers, and several other companies use extension servers internally.

Why it matters

How far he goes next depends on confidence: some changes he simply makes, unsure ideas get a throwaway prototype, and larger ones take weeks or months of building support. The payoff compounds: engineers who have been helped come back earlier and bring colleagues, His caveat: the approach depends on bottom-up autonomy over roadmaps, which not every company offers.