Problem Finding
Definition
Problem finding is the staff-engineer skill of identifying what the team or org should build, rather than executing what has already been assigned. Lalit Maganti’s account frames it as the opposite of scheduled strategic thinking: not blocked calendar time in front of a blank page, but sustained low-effort listening that turns ambient complaints into a small number of high-leverage projects.
The payoff he claims: the projects that made the biggest impression in his career were the ones where he found and solved an important problem his leaders did not yet know existed.
Core Ideas
Absorb problems, not requests
People already broadcast their problems — in meetings, chat threads, presentations, email. The input stream exists; you only have to receive it. When something overlaps your area, pull the thread: “if X existed, would that solve it?”, or point at an existing feature and ask how much of the use case it covers.
Users ask for a solution rather than describing a root issue. Take the request at face value and you build the wrong thing. Keep digging until you understand what they are trying to accomplish and why the existing products fail them — then go watch: sit with the team through their workflow, work one of their bugs yourself.
Seek out the people with wider organizational sightlines — owners of critical systems, engineers who span teams, anyone downstream of your work. They have often already seen the same issue in three places and started connecting the dots.
For an introvert this is cheaper than the alternative. No speculative meeting calendar; the information is already flowing past you during a normal week.
Let problems accumulate
The failure mode is moving fast on a vocal team’s request, building it, and watching them barely use it. Enthusiasm in the moment is not the same as importance relative to everything else the product must support.
So let potential problems pile up. Waiting is a superpower, because time supplies evidence you cannot get any other way:
| What waiting reveals | Why it matters |
|---|---|
| The same problem surfaces independently in another team | Raises real priority |
| Two problems that looked different share a shape | One solution covers several use cases |
| The requesting team stops caring | You saved the entire build |
Mental note or written list is a personal choice. What matters is keeping unresolved problems around long enough for evidence to arrive.
Find the common shape
Accumulated problems are a tangle: the requests, the constraints on each, and a handful of half-formed solutions. Forcing the untangle at a desk does not work; his connections come on long aimless walks.
The Perfetto example is the model. Over two years teams asked for small UI additions — pin these tracks, no, pin those tracks, open pre-zoomed on a region, show a custom aggregation. A few gave up and built bookmarklet workarounds. None of them wanted the feature they asked for. Each wanted to personalize the tool for their own workflow without imposing it on everyone else. The underlying need was extensibility.
The warning attached to that feeling: a common shape is only a hypothesis, and elegance is not evidence. He was once convinced a transparent query cache would solve both large-trace sharing and repeated queries; writing the RFC and building a prototype showed the two problems wanted genuinely different solutions, and the design split in two.
Pressure-test before building
Escalate effort with confidence, not with excitement:
- Useful and low-risk → just send the change, tell your manager.
- Unsure it works, or unsure of cost → build a throwaway prototype. It exposes failure points and gives others something concrete to react to.
- Big and you are convinced → commit to the full effort, including the unglamorous work of building support across teams. Perfetto extensions took two RFCs, several 1:1s, and a couple of talks.
You are convincing yourself as much as anyone else. If people don’t see the value, or you hit a technical wall, dropping it now beats a maintenance nightmare later. If the idea holds up but the timing is wrong, park it and wait for it to become an org priority.
You also do not have to be the one who builds it. Finding and shaping the right problem has impact even when someone else owns the implementation.
The loop compounds
Showing genuine interest in someone’s problem gets remembered. They bring you in earlier, and into conversations with others facing related issues. That widens your view, which makes patterns easier to spot, which produces better work, which brings you into more conversations.
Over time this converts into long-term stewardship: early on he had to ship these ideas himself to prove his judgment was sound; later his manager and org weighted his assessment enough that he could shape the roadmap without owning every project.
This cuts against the idea that becoming a staff engineer means trading technical work for meetings. Conversations are inputs into what you build, not the output.
Caveat
The author’s experience is infrastructure and developer tools at large companies, on teams with substantial bottom-up roadmap autonomy. A top-down environment leaves less room to work this way.
Relationships
- Engineering Leadership (CTO Checklist) — the responsibility surface this skill feeds; problem finding is how the roadmap items get chosen
- Stakeholder Analysis — eliciting the root need instead of the stated request, formalized
- System Thinking — seeing the shape connecting separate reports
- User Stories — where a validated problem lands as scoped work
- Software Engineering Practices — parent topic
- Work Culture & Management
References
- How I Find Problems to Solve as a Staff Engineer — Lalit Maganti, 2026-07-26