Note: this post was revised after publishing for increased clarity, based on
reader feedback.
“How do you find problems worth working on?” a senior engineer I mentor asked me
recently. He’s trying to make the jump to staff engineer and realized that the
role isn’t just about doing the work he’s assigned. He also needs to get
involved in figuring out what his team and org should be building.
Someone else had suggested blocking out time in his calendar to think about the
bigger picture. He’d tried that, but hadn’t found it productive, so he asked if
I had any alternatives.
I told him I rarely find good problems by staring at a blank page and trying to
“think strategically.” Instead, I act like a sponge. I listen to the stream of
day-to-day noise, absorb the problems people are having and let them sit in the
back of my mind. Over time, some fade away while connections begin to appear
between others that initially seemed unrelated. Eventually, I start to see
what’sreallyslowing people down and what my team or I can do about it.
I’ve worked with many engineers who’ve never really tried this. They wait for
managers or leads to identify opportunities, then demonstrate their value by
solving the hardest assigned problems. That can absolutely lead to promotion.
But the projects that have made the biggest impression in my career were the
ones where I found and solved an important problem my leaders did not yet
realize existed.
One caveat: my experience comes mainly from working on infrastructure and
developer tools at large companies, on teams where engineers have a lot of
bottom-up autonomy to influence their roadmaps. In a more top-down environment,
there may simply be less room to work this way.
People love talking about the problems they are facing: in meetings, chat
threads, presentations and email. They explain why their work is hard, complain
about what slows them down and describe what they wish they could do.
When something overlaps with my area, I start pulling on the thread. I might
ask, “If X existed, would it solve your problem?” or point them at an existing
feature in a product I own and ask how much of their use case it covers.
Users oftenask for a particular solutioninstead of explaining their root issue. Rather than taking the request at face
value, I keep digging until I understand what they are trying to accomplish and
why existing products do not work for them.
As a natural introvert, this sort of ambient listening works particularly well
for me. I don’t need to fill my calendar with speculative meetings just to find
ideas; there is already an enormous amount of useful information flowing around
me during a normal week.
When a problem seems worth exploring, though, I become more active; I need to
see how it affects the team’s day-to-day work. I’ll sit with them as they walk
me through their workflows and the bugs they’re investigating. When I can, I’ll
try working through some of those bugs myself. Seeing the problem firsthand
makes it easier to separate what the team actually needs from the solution they
asked for.
I also seek out people who see more of the organization than I do: those who own
critical systems, work across several teams or have particularly deep insight
into the work downstream of my team. I’ll arrange a 1:1 or coffee chat and ask
about interesting problems they’ve come across. They may have already seen the
same issue in several places and started connecting the dots, giving me a head
start on patterns I might otherwise have taken much longer to notice.