A Staff Engineer's Secret: Find Problems by Absorbing, Not Thinking
How I Find Problems to Solve as a Staff Engineer
Lalit, a staff engineer on Perfetto, explains how he discovers high-impact problems to solve. Instead of scheduling thinking time, he acts like a sponge, absorbing complaints and requests from meetings, chats, and 1:1s. He lets problems pile up, looking for common shapes that reveal deeper needs. He then pressure-tests ideas with prototypes and RFCs before building. This approach led to Perfetto macros and extension servers, used by dozens of teams at Google. He emphasizes that finding problems is a continuous, engaged process, not a separate strategic exercise.
By the time enough of these had piled up, my head was the usual tangle: the requests themselves, the constraints on each and a handful of half-formed solutions.
- stevepotter
I advise young people to seek out small companies, ideally ones going through product/market fit. Like, they recently came up with something to sell and have begun selling it. Resource-constrained, good growth, not super explosive. There are many of these companies. In this environment you will quickly learn how to do more with less, identify the real problems, deliver quickly, work directly with customers and how to build good products. After this, go ahead and work for a big company if you want and you'll be amazed how well you do.
- wpasc
The author notes:
> 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.
I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controlled environments. I would be curious to see how many tech companies (or the average engineer's experience) have changed from being tech led where engineers have autonomy to being more product management led. My suspicion without evidence is that the overall engineering autonomy has decreased over the years as the culture of tech has (in my opinion) shifted away from tech focus to more business, management, product focus with engineers just as the widgets who are tasked with fulfilling the goals of business, management, product.
all hypothesis, only anecdata
- 9dev
Funny people should have that problem. I have spent most of my career in the startup space, and my experience has consistently been that the amount of problems to solve is vastly larger than what I can reasonably achieve in my waking hours.
So I don't find problems to solve, I try to assess which problems are most urgent, or which solution solves several of them at once. Learning to get that kind of prioritisation right to keep all teams and customers happy and productive is what I'm very proud of in my career.
- CSMastermind
This is all very good advice, but I would caution anyone asking the question at the start of the essay that they probably shouldn't be a Staff Eng. Unless you're at a company where that title is simply a rung on the ladder that doesn't have differentiated responsibilities (there are lots of those out there).
Every person I've worked with who's been successful as a Staff+ Engineer, promoting them was normally more of a formality since they were already clearly doing the work. Every person I've seen 'rise to their level of incompetence' was striving to get the title/pay bump and looking to 'play the game' to get there.
If your motivation for solving people's problems is that it will get you a promotion, instead of the fact that you like solving problems, then it's probably not the right job for you.
- rr808
I wish our most senior staff eng/architects actually worked on stuff that is useful. They love playing around with new technology that has nothing to do with our current platform or where we're going. Sometimes they'll try to fix some thing the last architect started on before they too move on to another job.
- ronnier
I think almost all of tech is bloated and massive layoffs wouldn’t phase most companies (though it would be harmful to people’s lives so it seems cruel to do this). Fewer people per teams means less context switching and devs own more. They don’t have to look for work, it will be in front of their face. In so many of these big tech companies I’ve worked at I’ve seen too many not having enough work to do. They end up creating meetings and other wasteful things (doc writing) to occupy their time. Managers and directors seem to want big bloated teams, the larger their head count the more they can demand and push for a promo.
- intoXbox
The part I find challenging in the senior-staff twilight is that having deep technical knowledge means I can solve short term problems, just as requests, fast and effectively.
The author mentions that you should spend time understanding the frustrations from other teams, but that takes up loads of time and I don’t like being the person who talks and talks but doesn’t push code and ship features. I’d love to hear how others have experienced that
- napo
I worked at the Staff level for a while, I think the key is to report to a director who manages managers. Every time I did I had a good time, projects were easy to define and people were easy to convince. I had the same level with a few managers who were managing other ICs, and that never worked. Other ICs try to compete on tasks, people don't come to you with their needs, you learn about different projects often too late, other teams are territorial and don't really want you to intervene.