How I Find Problems to Solve as a Staff Engineer - Lalit Maganti
Note: this post was revised after publishing for increased clarity, based on<br>reader feedback.<br>“How do you find problems worth working on?” a senior engineer I mentor asked me<br>recently. He’s trying to make the jump to staff engineer and realized that the<br>role isn’t just about doing the work he’s assigned. He also needs to get<br>involved in figuring out what his team and org should be building.<br>Someone else had suggested blocking out time in his calendar to think about the<br>bigger picture. He’d tried that, but hadn’t found it productive, so he asked if<br>I had any alternatives.<br>I told him I rarely find good problems by staring at a blank page and trying to<br>“think strategically.” Instead, I act like a sponge. I listen to the stream of<br>day-to-day noise, absorb the problems people are having and let them sit in the<br>back of my mind. Over time, some fade away while connections begin to appear<br>between others that initially seemed unrelated. Eventually, I start to see<br>what’s really slowing people down and what my team or I can do about it.<br>I’ve worked with many engineers who’ve never really tried this. They wait for<br>managers or leads to identify opportunities, then demonstrate their value by<br>solving the hardest assigned problems. That can absolutely lead to promotion.<br>But the projects that have made the biggest impression in my career were the<br>ones where I found and solved an important problem my leaders did not yet<br>realize existed.<br>One caveat: my experience comes mainly from working on infrastructure and<br>developer tools at large companies, on teams where engineers have a lot of<br>bottom-up autonomy to influence their roadmaps. In a more top-down environment,<br>there may simply be less room to work this way.<br>Absorb problems, not requests<br>People love talking about the problems they are facing: in meetings, chat<br>threads, presentations and email. They explain why their work is hard, complain<br>about what slows them down and describe what they wish they could do.<br>When something overlaps with my area, I start pulling on the thread. I might<br>ask, “If X existed, would it solve your problem?” or point them at an existing<br>feature in a product I own and ask how much of their use case it covers.<br>Users often<br>ask for a particular solution<br>instead of explaining their root issue. Rather than taking the request at face<br>value, I keep digging until I understand what they are trying to accomplish and<br>why existing products do not work for them.<br>As a natural introvert, this sort of ambient listening works particularly well<br>for me. I don’t need to fill my calendar with speculative meetings just to find<br>ideas; there is already an enormous amount of useful information flowing around<br>me during a normal week.<br>When a problem seems worth exploring, though, I become more active; I need to<br>see how it affects the team’s day-to-day work. I’ll sit with them as they walk<br>me through their workflows and the bugs they’re investigating. When I can, I’ll<br>try working through some of those bugs myself. Seeing the problem firsthand<br>makes it easier to separate what the team actually needs from the solution they<br>asked for.<br>I also seek out people who see more of the organization than I do: those who own<br>critical systems, work across several teams or have particularly deep insight<br>into the work downstream of my team. I’ll arrange a 1:1 or coffee chat and ask<br>about interesting problems they’ve come across. They may have already seen the<br>same issue in several places and started connecting the dots, giving me a head<br>start on patterns I might otherwise have taken much longer to notice.<br>Let problems accumulate<br>Several times, I’ve been burned by moving too fast. I became excited by a<br>request from a vocal team, built the feature and watched them barely use it.<br>Their priorities had changed, or the request had come from a one-off<br>investigation that no longer mattered. How eager a team was in that moment<br>wasn’t the same as how important the feature was relative to everything else my<br>product needed to support. By hyperfocusing on their request, I lost sight of<br>the bigger picture.<br>That taught me to let potential problems pile up. Listening the way I do leaves<br>me with far more of them than I could possibly solve, and not all deserve<br>action. Most don’t need to turn into projects the first time I hear about them;<br>waiting can be a superpower.<br>Waiting means the same problem might pop up independently in different teams,<br>making it a higher priority to solve. Or problems that look different on the<br>surface might turn out to have the same shape, so I can address several use<br>cases in one shot. Or, as I’ve learned painfully, the requesting team didn’t<br>even care that much in the first place.<br>Instead, I make a mental note and revisit the problem if it comes up again.<br>Other engineers I know write this sort of thing...