How I Find Problems Worth Solving

A senior engineer I mentor asked me how I find problems worth working on. He has the technical half covered. What he does not have is an answer to the question staff engineers actually get judged on, which is not "did you solve it" but "was it worth solving at all". Someone had told him to block two hours a week in his calendar to think strategically. He tried it for a month and produced nothing except a recurring meeting with himself.

That has never worked for me either. Staring at an empty document waiting for a big idea is a bad use of a good brain. Almost everything worth building that I have found came out of the ordinary noise of a normal week: a standup aside, an incident channel, a complaint in a retro that nobody wrote down, a question buried in a PR thread. I do not generate problems. I collect them.

Collect, do not brainstorm

People will not stop telling you what is hard about their job. They do it in meetings, in Slack, in the half sentence before the demo starts. Most of it is not addressed to you and most of it goes nowhere, which is exactly why it is useful: nobody is performing. When something lands near the systems I own, I pull on it.

The pulling matters more than the listening. What people bring you is a solution, not a problem, because they have already done the translation in their head and thrown away the original. Someone asks for a config flag. What they mean is that they cannot deploy on Fridays without a rollback story, and the flag is the smallest thing they could imagine you agreeing to build. If you ship the flag you have solved nothing and you have added a flag.

So I ask what they were doing when they hit this, and what they did instead. When it looks worth the time, I sit with them and watch. Reading someone's workaround tells you more about the real constraint than any amount of requirements gathering, because the workaround is the honest version of the request.

Being an introvert helps here rather than hurting. I do not need a calendar full of speculative coffees to find ideas. There is already more signal moving past me in a normal week than I could act on. The one thing I do deliberately is talk to people who see more of the org than I do, the ones who own something everybody depends on, because they have usually seen the same complaint from four teams and have started joining the dots without realising it.

Let them pile up

I have been burned by moving fast on a single loud request more than once. A team pushes hard for something, I believe the urgency, I build it, and then it sits there unused because their priority moved two sprints later or the whole thing came out of a one-off investigation nobody repeated. Enthusiasm in the moment is not importance. It is just volume.

Now I let problems accumulate without doing anything about them. This feels lazy and it is the opposite. Waiting is the cheapest filter I have. A problem that only ever surfaces once was probably never real. A problem that shows up independently in three teams that do not talk to each other is real and is bigger than any of them described. Some people keep a document for this. I mostly keep it in my head and trust that the ones worth remembering will come back. The mechanism does not matter, keeping the unresolved things around long enough for evidence to arrive does.

Look for the shape

Waiting collects evidence. It does not tell you what to build. The interesting move is realising that four requests that sound nothing alike are the same request wearing different clothes.

One team wants a bespoke view. Another wants to reorder the default one. A third wants the tool to open already filtered to their service. A fourth gave up on you and wrote a browser script. Ship all four and you have four features and a maintenance problem. Look again and none of those teams wanted a feature at all, they wanted to bend the tool to their workflow without forcing their choices on everyone else. That is one thing to build, and it is not on anyone's list.

When that click happens it is the best feeling in the job, and it is also the moment to be suspicious, because a common shape is a hypothesis and elegance is not evidence. I have merged two problems into one beautiful design, started writing it up, and discovered halfway through that the two halves wanted genuinely different solutions and I had unified them because the diagram looked nice. Splitting it back apart was the right call and it cost me a week to admit. The merge is a claim about reality; it has to be tested like one.

Pressure-test before you build

The size of the response should match how sure I am, and I am rarely sure enough to go straight to a project plan.

If it is small and reversible I just do it and tell people afterwards. If I doubt the idea works at all, I build something throwaway, because a bad prototype settles arguments that three meetings cannot. If it is large and I believe in it, the work is not the code, it is the writing and the conversations: a proposal, the people it affects, the ones who will have to maintain it, the manager who has to fund it.

Through all of that I am trying to convince myself as much as anyone else. Sometimes the honest outcome is that people do not see what I see, or the technical wall is real, and dropping it now is cheaper than shipping something nobody uses and somebody has to maintain for three years. Sometimes the idea holds up and the timing is wrong, in which case I park it with the evidence attached and wait for the quarter where it becomes obvious to everyone else.

The part that took me longest to accept is that I do not have to be the one who builds it. Finding and framing the problem is the scarce contribution. Handing a well-shaped problem to someone who will do a better job with it than I would is not giving away credit, and if you are still measuring your impact in commits you will fight this instinct for years. It connects to something I have written about before, which is that owning a project end-to-end is about the outcome, not the keyboard time.

The loop pays for itself

Do this a few times and it starts compounding without any effort from you. When you take someone's problem seriously, ask a question they had not thought of, or fix something that was quietly ruining their week, they remember. They come to you earlier next time, and they bring other people. That gives you a wider view of the org, which makes the patterns easier to see, which makes the next thing you build land better.

Early on I had to build most of these ideas myself to prove my judgment was worth anything. That is fair, and the shortcut people look for here does not exist. Once the track record is there, my read on what matters starts carrying weight on its own, and I can move a roadmap without owning the project. That is very different from the version of the staff role where technical work is replaced by meetings and coordination. The conversations are inputs to what I build, not the output.

What I wanted my mentee to take away is that finding problems is not a separate activity you schedule around the job. There is no two hours on a Thursday where strategy happens. It comes from staying close enough to people's work, for long enough, to see the thing no single request can show you.

I write about system design and the senior-to-staff transition every week in Monday BY Gazar on Substack, and I break down architecture and engineering decisions on Gazar Breakpoint on YouTube.

If you are an engineer targeting staff or principal and want this kind of thinking applied to your actual situation, I do 1:1 mentorship.