The Best Staff Engineering Work Often Starts Before Anyone Assigns It

Lalit Maganti's "How I Find Problems to Solve as a Staff Engineer" describes a way of working that feels very familiar to me. Maganti doesn't set aside an hour to sit somewhere and "think strategically." He listens.

"I act like a sponge."

He pays attention to complaints in meetings, chat threads, emails, and conversations. A single request might not mean much; the same frustration appearing across several teams probably does. Eventually the shape of a larger problem starts to emerge.

I tend to work this way too. Being remote makes the old water-cooler version harder—I don't accidentally overhear two people talking while getting coffee—but the chatter is still there if you listen for it. Standups, support questions, tickets, chat threads, meetings, the small comments people make about something taking longer than it should. Someone performs the same tedious step every morning. Someone else cannot get data they need. Another team has built a strange workaround. Those are often more interesting to me than the request itself.

The first question shouldn't always be, "How do I build what they asked for?" It should be, "Why do they need this?" Sometimes helping means showing someone that the thing they need already exists. Sometimes it means fixing a small problem. Sometimes several apparently unrelated complaints turn out to be symptoms of the same missing capability. And sometimes the right answer is to do nothing yet and see whether the problem appears again. Maganti deliberately lets problems accumulate before deciding they deserve a project, because a loud request is not necessarily an important one. That is a useful discipline—there will always be more problems than time.

His caveat matters. The experience comes from infrastructure and developer-tool organizations where engineers have substantial bottom-up influence, and he acknowledges that more top-down organizations may simply leave less room to operate this way.

That made me wonder whether engineering organizations are becoming more top-down generally. I don't have evidence that they are—mostly anecdata—but I wonder whether some of the culture has shifted from strongly technology-led toward increasingly business-, management-, and product-led.

Product management is not the problem. Understanding customers and business priorities is part of building useful software, and engineers shouldn't disappear for six months to solve technically fascinating problems nobody needs. Post-ZIRP tightening made some prioritization inevitable. What worries me is when that sensible pressure mutates into something else: the engineer stops being someone expected to discover problems and becomes someone expected to implement solutions already selected above them. Product decides what, management decides when, planning assigns the work, engineering estimates and builds. That may produce predictable roadmaps. It can also throw away one of the most valuable information sources in a software company—the people who spend every day inside the systems.

DORA's research has repeatedly found that high-performing teams have meaningful autonomy. The guidance is unusually direct: don't treat technical staff as order-takers. That doesn't prove autonomy has declined across the industry. I would like to see good longitudinal research on that question.

There is also a less charitable version of top-down planning that has nothing to do with profitability. Sometimes organizations optimize for work that is easy to describe upward. Estimate becomes schedule becomes status report. Predictability becomes more important than eliminating the problem. Finishing in half the estimated time should be excellent news; in an unhealthy organization it becomes awkward because the estimate was already baked into staffing and quarterly commitments. That is work theater—almost the exact opposite of Maganti's process. Hard to put on a quarterly roadmap before the discovery has happened. Also where a lot of valuable engineering work comes from.

You aren't only supposed to solve difficult technical problems—you are supposed to notice which problems are worth solving. If you keep hearing the same thing from different directions, there is probably something underneath it worth pulling on. The organization just has to give engineers enough room to pull.

Read Lalit Maganti's full post, "How I Find Problems to Solve as a Staff Engineer."