This article explains how staff engineers move beyond solving difficult assigned work to discover and define important problems the organization has not yet recognized clearly. The key is not forcing strategy from a blank page, but observing and accumulating problems from everyday work over time, then finding and validating their common causes. Through the example of Perfetto, the author shows why giving users a way to customize a tool can be better than building every small request as a separate feature.

1. The Problem-Finding Ability Staff Engineers Need

The article begins with a question from a senior engineer the author had been mentoring. The engineer realized that growth into a staff role required more than executing assigned work well; he needed to participate in deciding what the team and organization should build. He therefore asked how to find problems worth solving.

Someone had advised reserving calendar time to think about the big picture, but that did not help much. The author explains that his own method differs from trying to "think strategically." He describes himself as acting like a sponge: listening to difficulties people mention in the ordinary flow of meetings, chats, email, and presentations, absorbing them, and leaving them in the back of his mind for a long time.

"I rarely find good problems by staring at a blank page and trying to 'think strategically.' Instead, I act like a sponge."

Problems that initially appear unrelated begin to connect over time, while some disappear naturally. Through that process, he understands what is actually slowing people down and what he or his team could do about it.

Many engineers wait for managers or leaders to identify opportunities, then demonstrate value by solving the hardest assigned problems. That can certainly lead to promotion. But the most consequential projects in the author's career came from independently finding and solving important problems that even leaders had not yet realized existed.

This approach comes with a qualification. His experience centers on building infrastructure and developer tools at large companies where engineers can influence the roadmap from the bottom up. Organizations driven strongly by top-down plans may leave less room to work this way.

2. Absorb Problems, Not Requests

People frequently talk about their difficulties. In meetings they explain why work is hard; in chat they complain about obstacles; in email and presentations they describe features they wish existed. When these signals overlap with his area, the author follows the thread.

He might ask, "Would X really solve the problem?" Or he may demonstrate an existing capability in his product and investigate how much it addresses the other person's situation. The important point is that users often request a preferred solution instead of explaining the underlying problem. Do not accept the request at face value. Keep probing what they are actually trying to accomplish and why the current product is insufficient.

"Users often request a particular solution instead of describing their underlying problem."

As an introvert, the author finds this method of listening for ambient signals particularly suitable. There is no need to pack the calendar with speculative meetings whose sole purpose is generating ideas. An enormous amount of useful information already flows through an ordinary week inside an organization.

When a problem appears worthy of deeper examination, however, he becomes active. He shadows the team as it investigates a bug and moves through its workflow, and if possible attempts to fix the bug himself. Experiencing the problem firsthand makes it easier to distinguish what the team really needs from the solution it requested.

He also seeks people with a broader organizational view than his own: owners of critical systems, people working across many teams, and those who deeply understand the work downstream from his team. In one-on-ones or coffee chats, he asks about interesting problems. These people may already have seen the same issue in multiple places and connected the pattern, revealing relationships he might otherwise discover much later.

3. Do Not Rush to Turn a Problem into a Project

The author has failed several times by moving too quickly. Excited by a request from one vocal team, he built a feature that the team barely used. Its priorities had changed, or the request had arisen from a one-time investigation and was no longer important.

How urgently a team sounds in the moment is not the same as how important its feature is relative to everything else the product must support. Overinvesting in one request can obscure the larger picture.

"A team's enthusiasm in that moment was not the same as the feature's importance relative to everything else my product needed to support."

These experiences taught him to accumulate potential problems. Everyday listening uncovers far more problems than he can solve, and most are not important enough for immediate action. A problem need not become a project the first time it appears. For the author, waiting is almost a superpower.

While he waits, evidence can emerge:

• If the same problem recurs independently across different teams, its priority rises.
• If apparently different problems turn out to share a structure, one solution may address several cases.
• Conversely, even the requesting team may reveal that it does not consider the issue particularly important.

The author mostly stores these problems in his head and revisits them when they recur. Other engineers may record them more systematically. The tool is a matter of personal preference; the essential practice is to preserve unresolved problems long enough for more evidence to accumulate.

4. Find the Shared Structure Behind Many Requests

Accumulating problems does not immediately reveal what to build. You still need to decide whether the retained problems are truly related and whether one solution can address them together.

The author uses Perfetto, the performance-debugging tool he develops, as an example. Perfetto displays a timeline of system activity, with the screen divided into rows called tracks. Over several years, different teams requested their own small, specific UI features.

One team wanted to pin its preferred tracks to the top. Another wanted the same feature but for entirely different tracks. A third wanted Perfetto to open already zoomed into a particular trace interval and asked for custom aggregations tailored to its interests. Some teams became impatient enough to build complicated bookmarklet workarounds.

At first, the requests, their constraints, and vague possible solutions became tangled in the author's mind. He says his thinking becomes clearest during long, aimless walks around London rather than while sitting at a desk and forcing a solution. Connections often become more visible when he stops consciously trying to solve the problem. 🚶

Eventually he realized that the specific requested features were not the real objective. Every team wanted to personalize Perfetto for its own workflow without imposing its choices on other users. The core need was not track pinning or automatic zoom, but the ability to extend the UI.

"What these teams really wanted was not each specific feature they requested. They all wanted to personalize Perfetto for their own workflow without forcing their choices on everyone else."

The moment when several awkward requests collapse into one idea, opening possibilities that none could suggest alone, is exhilarating. Yet the author stresses the need for caution: a shared structure is only a hypothesis, and an elegant design is not evidence.

He once believed a transparent caching system could jointly solve problems with sharing Perfetto traces and repeated queries. While writing an RFC and building a prototype, he discovered that the problems merely looked convenient to combine; in practice, they required different solutions. Reluctantly he split the design in two, and both resulting products were later shipped.

5. Pressure-Test the Hypothesis Before Building

Finding a common structure does not mean beginning full-scale development immediately. The author varies his response according to his confidence that the idea will work, that people genuinely want it, and that its implementation cost is acceptable.

• For useful, low-risk work, he makes the change immediately and informs his manager.
• If impact or difficulty is uncertain, he builds a disposable one-off prototype. It exposes failure points and gives others something concrete to critique.
• If the idea is large but his confidence is high, he accepts weeks or months of development and the work required to gain support from several engineers and teams.

Validation is not only about persuading other people; it is also about persuading himself. If people cannot see the value he sees or he encounters a major technical barrier, it is better to abandon the idea early than build something no one uses or that becomes a maintenance nightmare.

"If people do not see the value I see, or if I hit a major technical wall, I would rather discard the idea now than build something nobody will use."

Sometimes an idea is sound but the timing is wrong. Rather than deleting it, put it on hold and act when it becomes an organizational priority. The person who finds and shapes a problem also need not be its implementer. The author may build it, another teammate may do so, or the discovery alone may redirect the organization's attention.

Perfetto extensibility was a case where the author judged long-term investment worthwhile. The team was already creating plugins to modularize the UI, but their internal use was limited. Many teams would have had to publish their plugin code as open source, which was not a practical requirement.

Before building, he brought the problem and proposal to his manager, peers, and customer teams. He wrote two RFCs, held several one-on-one conversations, and gave presentations, refining the design through feedback. The result was macros, a lightweight extension mechanism that automated UI behavior without requiring a plugin. He then added extension servers, allowing teams to share their macros.

Instead of directly implementing every feature request, this approach gave each team the means to adapt Perfetto to its needs. Dozens of teams inside Google now use macros and extension servers, and several other companies run extension servers internally.

6. The Trust and Flywheel Created by Problem Solving

The more often you repeat this process, the easier it becomes to find the next problem. When you show genuine interest in someone's difficulty, ask useful questions, or help solve it, people remember. They begin approaching you earlier and bring you into conversations with others facing similar problems.

You gain a wider view of what is happening across the organization, making it more likely that you will notice recurring patterns and build what people truly need. Solving one problem creates more conversations, which expose the next problem—a virtuous cycle. 🔄

This success builds trust grounded in sustained stewardship and care for a product and its problems over time. Early in his career, the author had to turn many ideas into reality himself to prove his judgment. As managers and the organization came to trust his assessment of what mattered, he could influence the roadmap without personally owning every project.

That differs from the common belief that becoming a staff engineer means replacing technical work with meetings and coordination. For the author, conversation is not the final output. It is an input into deciding what to build.

"For me, conversation is an input into what I make, not the final result."

7. Closing

The author's message to his mentee is clear: finding problems worth solving is not a separate strategic activity outside your regular job. It becomes possible by staying involved in people's real work and observing repetitions and connections long enough for patterns invisible in any single request to emerge.

Good staff engineering is not merely implementing requested work quickly. It means listening to many people's frustrations and objectives, resisting premature conclusions, validating common causes, and then identifying the problem that can create the greatest organizational impact.