The reading room · Digna Legi
How I Find Problems to Solve as a Staff Engineer
/100
80–100: high value. 70–79: worth the time. Below 70: below the usual publication threshold.
Evidence-reviewed score based on available publisher text. Full text is available, but the experience is mainly from infrastructure and developer tools at large companies.
Scores reflect one reader’s profile, not an objective quality rating. Best is a separate personal selection.
How scoring works →This brief · about 3 min with detail
Why read this
Staff-level problem finding starts with repeated organizational friction, then tests whether patterns reveal a real root problem.
AI brief · Checked against source text
The main idea
The author argues that strong staff-engineering work often begins by absorbing day-to-day organizational friction, separating root problems from requested solutions, and letting patterns emerge over time. The method works because repeated, independent signals expose what matters beyond one vocal team’s urgency, while prototypes, written design proposals, and stakeholder feedback test whether an elegant unifying idea is real.
Some background helpful. Some familiarity with software teams, developer tools, design proposals, and extensible user interfaces.
Go a little deeper
Requests are noisy evidence
The author treats user requests as clues, not requirements. A team asking for a feature may really be exposing a workflow gap, a missing product capability, or a failure of an existing tool to fit their task. The practical move is to ask what the requester is trying to accomplish, compare that against existing features, and watch the work directly when the problem seems important.
Waiting improves judgment
The essay’s strongest mechanism is delay as filtration. Immediate enthusiasm can reflect a one-off investigation, a temporary priority, or the loudness of a single team. Letting problems accumulate reveals whether the same pain appears independently, whether several surface-level complaints share one structure, or whether the original request was never important enough to deserve product work.
Elegant unification still needs testing
Finding a common shape is only a hypothesis. The author distinguishes the satisfying moment when several awkward requests collapse into one idea from the separate question of whether that idea should be built. Depending on uncertainty and risk, the test might be a small change, a throwaway prototype, or a fuller design process using written proposals, conversations, and talks to expose failure points.
Problem finding compounds through trust
The process becomes more powerful after useful interventions. People who feel heard bring problems earlier and connect the engineer to related conversations, expanding the engineer’s view of the organization. That creates a feedback loop: better signal produces better judgment, better judgment earns more trust, and trust lets the engineer influence direction without personally owning every implementation.
A case from the article
Perfetto extension work
Perfetto, a performance-debugging tool that shows system activity over time, received many feature requests: pinning preferred timeline rows, opening a recording at a chosen zoom point, and custom summaries. The author concluded the shared need was not any one feature but the ability for teams to adapt the interface. After proposals and feedback, macros automated interface actions, and extension servers let teams share those automations.
How the case is made
The case is made through lived engineering experience, especially infrastructure and developer-tools work around Perfetto.
Where the idea has limits
The author explicitly limits the method to environments with enough bottom-up roadmap autonomy; in more top-down organizations, engineers may have less room to discover and shape problems this way.
A question to take away · from Digna Legi
Which unresolved complaints around you are recurring signals rather than isolated requests?
What the original adds
The source adds concrete tactics: observe workflows, try bugs yourself, consult people with cross-team visibility, wait for recurring signals, and use prototypes or design proposals to test uncertain ideas.
About this brief
AI-written, then separately checked for source support, useful detail and clarity. The author’s claims and our editorial question are kept separate. The original remains the author’s work. How we select and summarise →
How was this brief?
Rate this summary, separately from the author’s article.
Optional. Saved in this browser; shared only if you allow analytics.
How was the original article?
Rate the author’s original after reading it.
Optional. Saved in this browser; shared only if you allow analytics.
Digna legi. Worth reading.