How I find problems to solve as a staff engineer
A staff engineer shares a non-obvious method for discovering high-impact problems: act like a sponge, absorb daily frustrations, and patiently look for overarching patterns. This contrasts with traditional assigned tasks and requires environmental autonomy, a point that sparked much discussion among Hacker News readers. The strategy emphasizes identifying root causes and system-level improvements over fulfilling direct requests.
The Lowdown
Lalit Maganti, a Staff Engineer, outlines his unconventional yet effective approach to identifying valuable problems. Instead of dedicated strategic thinking sessions, he advocates for an 'ambient listening' method, absorbing the day-to-day 'noise' of colleagues' frustrations and complaints. This passive data collection allows connections to emerge over time, revealing fundamental issues that single requests might obscure.
Key takeaways from his strategy include:
- Absorb Problems, Not Requests: Don't take user requests at face value; dig deeper to understand the underlying pain points. Maganti emphasizes actively observing workflows and talking to people who have a broader organizational view.
- Let Problems Accumulate: Resist the urge to solve every problem immediately. Waiting allows for more evidence to gather, reveals if a problem is recurring or widespread, and helps filter out transient issues or low-priority requests.
- Find the Common Shape: Synthesize seemingly disparate problems into a single, broader solution. He recounts how many small UI requests for Perfetto coalesced into the idea of building an extension framework, allowing users to personalize the tool.
- Pressure-Test Before Building: Validate ideas through prototypes, discussions, and RFCs before committing to full-scale development. This helps confirm genuine need and technical feasibility, and knowing when to abandon an idea is crucial.
- The Virtuous Cycle: Solving impactful problems builds trust and credibility, leading more people to share their challenges, which in turn provides a wider view for spotting new patterns and influential work.
Ultimately, Maganti argues that finding significant problems isn't a separate task for a staff engineer, but an organic outcome of continuous engagement and deep understanding of an organization's operational landscape.
The Gossip
Autonomy Ado
Many commenters resonated with the author's caveat about environment, noting that bottom-up autonomy, crucial for this approach, is a luxury. Several users, especially those not in large, tech-led companies or experiencing shifts in company culture, reported a decrease in engineering autonomy over time, moving towards more top-down, product-managed environments. This made it challenging to proactively seek out and tackle problems as described in the article.
Staff Scrutiny
The discussion often revolved around the definition and expectations of a Staff Engineer. Some argued that truly effective Staff Engineers are already doing this type of problem-finding work before the promotion, suggesting that aspiring Staff Engineers shouldn't just 'play the game' for the title. There was also a strong emphasis on the shift from solving immediate, assigned tasks (which could be delegated to junior engineers) to identifying complex, systemic problems that require a broader perspective and longer-term thinking.
Problem Prioritization Predicament
While the article focuses on *finding* problems, many HN users, particularly those from startup backgrounds or fast-paced environments, countered that the problem isn't finding them, but prioritizing an overwhelming abundance of *known* issues. For them, the real staff-level skill lies in assessing urgency, impact, and finding solutions that address multiple problems simultaneously, rather than passively observing to discover new ones.
Practicalities and Pitfalls
Commenters brought up the practical challenges of applying the advice, including organizational politics, lack of proper incentives that can lead to incomplete work (e.g., hitting deadlines over quality), and the 'XY problem' where users request solutions instead of describing root issues. There was also a cynical view on 'work theater' in bloated organizations, where people create work or meetings to justify their roles rather than solving genuine problems, and the general difficulty of distinguishing between a genuine problem and a solution looking for one.