// HACKER NEWS — CYBERSECURITY
How I find problems to solve as a staff engineer
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’s really slowing 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 often
ask for a particular solution
instead 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.