How I find problems to solve as a staff engineer
TL;DR
Lalit Maganti, who works on Google's Perfetto tracing tool, says staff engineers find their best problems by absorbing the complaints around them. They wait until several complaints turn out to share one cause. Maganti then tests that shared cause before building, because a tidy pattern can still be wrong.
The article
- Blocking out calendar time to "think strategically" rarely works for Maganti. He picks up problems from meetings, chat threads and email. He digs into what users are trying to do instead of building the feature they asked for.
- Maganti holds off at first. He has built features for an eager team that then barely used them. So he waits to see whether a problem shows up in other teams or shares a root with another one.
- In Perfetto, years of small requests came down to one need. They included pinned tracks, preset zoom, custom aggregations and bookmarklet workarounds. Each team wanted to customize the UI for its own workflow without forcing that on everyone else.
- A shared pattern is only a hypothesis. Maganti was sure one transparent caching layer would fix both large-trace sharing and repeated queries. Writing the RFC and a prototype showed the two needed separate designs.
- His commitment scales with confidence. He ships small low-risk changes and tells his manager. Uncertain ideas get a throwaway prototype. Big ones get RFCs, talks and 1:1s. For Perfetto, that process produced macros and extension servers, now used by dozens of Google teams and several other companies.
- Each solved problem earns trust and pulls Maganti into more conversations. Over time he shapes the roadmap without owning every project. He treats those conversations as input to technical work, not a replacement for it.
Why it matters
Read it if you are a senior engineer aiming for staff and keep hearing "be more strategic" without knowing what that means on a Tuesday. The Perfetto story walks the whole cycle from scattered requests to a shipped extension system, including the caching idea that fell apart. Maganti also says up front that the method assumes a team with bottom-up autonomy.
The discussion
A large and mostly skeptical thread, though few people disputed the method. The fight was over Maganti's own caveat: the top thread, a third of all comments, argued whether engineers still get bottom-up autonomy. Much of the rest was about politics, sponsorship and what the staff title is worth. A few commenters also accused the post of reading like AI output.
Is engineering autonomy shrinking?
Many said yes: one engineer found a team he had founded hierarchical and slow, and another saw new management relabel his wins as failures. Some blamed the end of cheap money, some said growth brings corporate structure, and others that business people now know enough to direct the work. A minority pushed back: a 35-year veteran saw a shift toward bottom-up, and infrastructure and tooling people said they have always had room. One commenter argued that serving the business is the engineer's job anyway, as long as it runs both ways.
This means that business folks have a stronger intuition of what's possible than before -- and that makes top-down direction much more likely. The innovation is commonly in the business strategy, not the tech itself.
With change in management all past successful projects are "failures" now.
There are always problems; choosing is the job
A long run of startup and senior engineers said they never have to look for problems, since the queue is always longer than their hours. Replies answered that a staff engineer must find problems a junior couldn't solve that pay off, like an architectural fix for a whole bug class. Others defended Maganti's sponge approach for problems nobody has noticed yet. People who build these general fixes said coworkers push back because they don't see them working the ticket.
General “bugs” are not staff worthy. Staff need to convince leadership to fix an architectural problem that removes a whole class of bug.
I find there's some overlap between being good at Root Cause Analysis and realizing that 3 of your most common problems are really all a 4th problem, some aspects of which have not hit you yet.
Politics, sponsors and the title
Several staff engineers said finding the problem is the easy half, next to finding sponsors and accepting that maybe one proposal in five gets funded. One said the key is to report to a director who manages managers, not a line manager. Cynics called many staff+ engineers "Google Docs engineers" who take the team's credit, and said promotion rewards how many people vouch for a problem. One camp said title-chasers make bad staff engineers, and another that at a bad employer, chasing the title is rational.
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.
In these cases, you may as well ruthlessly go-for-the-title, because they’re not going to change, so you may as well get something beneficial while you’re stuck somewhere shitty.
Talking versus shipping
One engineer said all the cross-team listening eats time he could spend shipping fixes fast. Replies called quick fixes a trap, since a staff engineer's one-day fix takes other engineers a week, and they learn from it. Others warned against the opposite failure, the IC who only talks, and said small hands-on fixes keep you in touch with reality. People shared routines too, such as months of mostly docs alternating with weeks of dozens of PRs, or sitting in other teams' support channels.
if they’re truly things I can knock out in a day or two, they’re things that other staff can knock out in a week or two, and learn from the experience
Solving little problems here and there is a great way to keep your finger on the pulse of what's actually going on. … But if you get totally bogged down in details, you are probably avoiding your leadership responsibilities.
Watch what users do, not what they ask for
Many single comments backed the post's point that users ask for solutions instead of describing their problem. People called it the XY problem, said to sit in on sales calls, and cited a classic post about watching a waiter use a screen. One commenter learned more from staffing a check-in tent than from writing the registration software. Another noted the catch: giving customers exactly what they ask for produces bad software that still sells, especially through RFPs.
Doing 2 gave me a VASTLY better understanding of who the users were and how they thought.
Except that sometimes a company giving the customers exactly what they want does optimize for sales in the market (especially in "enterprise sales", government contracts, and anything involving RFPs etc)... it just always also results in crappy software.
Consensus
The method is sound where engineers have room to set direction. At staff level the hard part is choosing problems with leverage and getting the org to back them, not finding problems at all.
Dissent
Many argued that kind of autonomy is rare and getting rarer. So the advice mostly fits well-placed big-tech infrastructure teams. Others said staff promotion rewards visibility and politics more than the problem-solving the post describes.