How I Find Problems to Solve as a Staff Engineer

作为主任工程师，我是如何发现值得解决的问题的

“How do you find problems worth working on?” a senior engineer I mentor asked me recently. He’s trying to make the jump to staff engineer and realized that the role isn’t just about doing the work he’s assigned. He also needs to get involved in figuring out what his team and org should be building. 最近，一位我指导的高级工程师问我：“你是如何发现值得投入精力去解决的问题的？”他正试图晋升为主任工程师，并意识到这个角色不仅仅是完成分配的任务，还需要参与规划团队和组织应该构建什么。

Someone else had suggested blocking out time in his calendar to think about the bigger picture. He’d tried that, but hadn’t found it productive, so he asked if I had any alternatives. 有人建议他在日程表中预留时间来思考大局。他尝试过，但觉得效率不高，所以问我是否有其他方法。

I told him I rarely find good problems by staring at a blank page and trying to “think strategically.” Instead, I act like a sponge. I listen to the stream of day-to-day noise, absorb the problems people are having and let them sit in the back of my mind. Over time, some fade away while connections begin to appear between others that initially seemed unrelated. Eventually, I start to see what’s really slowing people down and what my team or I can do about it. 我告诉他，我很少通过盯着空白页面试图“进行战略思考”来发现好问题。相反，我像海绵一样行事。我倾听日常工作中的各种声音，吸收人们遇到的问题，并让它们在脑海中沉淀。随着时间的推移，一些问题会逐渐消失，而另一些最初看起来无关的问题之间开始出现联系。最终，我开始看清到底是什么在拖慢大家的工作进度，以及我和我的团队能为此做些什么。

I’ve worked with many engineers who’ve never really tried this. They wait for managers or leads to identify opportunities, then demonstrate their value by solving the hardest assigned problems. That can absolutely lead to promotion. But the projects that have made the biggest impression in my career were the ones where I found and solved an important problem my leaders did not yet realize existed. 我曾与许多从未尝试过这种方法的工程师共事。他们等待经理或主管来确定机会，然后通过解决分配的最困难的问题来证明自己的价值。这当然可以带来晋升。但在我的职业生涯中，给我留下最深刻印象的项目，往往是我自己发现并解决了一个领导层尚未意识到的重要问题。

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. 需要说明的是：我的经验主要来自在大公司从事基础设施和开发工具的工作，在这些团队中，工程师拥有很大的自下而上的自主权来影响路线图。在更自上而下的环境中，这种工作方式的空间可能会更小。

Absorb problems, not requests

吸收问题，而非需求

People love talking about the problems they are facing: in meetings, chat threads, presentations and email. They explain why their work is hard, complain about what slows them down and describe what they wish they could do. 人们喜欢谈论他们面临的问题：在会议、聊天记录、演示文稿和电子邮件中。他们会解释为什么工作很困难，抱怨是什么拖慢了进度，并描述他们希望能够实现的目标。

When something overlaps with my area, I start pulling on the thread. I might ask, “If X existed, would it solve your problem?” or point them at an existing feature in a product I own and ask how much of their use case it covers. 当某些问题与我的领域重叠时，我就会顺藤摸瓜。我可能会问：“如果存在 X，能解决你的问题吗？”或者向他们指出我负责的产品中现有的功能，并询问它覆盖了他们多少用例。

Users often ask for a particular solution instead of explaining their root issue. Rather than taking the request at face value, I keep digging until I understand what they are trying to accomplish and why existing products do not work for them. 用户通常会要求特定的解决方案，而不是解释他们的根本问题。我不会照单全收，而是会不断深挖，直到我理解他们想要达成什么目标，以及为什么现有产品无法满足他们的需求。

As a natural introvert, this sort of ambient listening works particularly well for me. I don’t need to fill my calendar with speculative meetings just to find ideas; there is already an enormous amount of useful information flowing around me during a normal week. 作为一个天生的内向者，这种“环境式倾听”对我特别有效。我不需要为了寻找灵感而把日程表填满各种推测性的会议；在正常的一周里，我周围已经有大量有用的信息在流动。

When a problem seems worth exploring, though, I become more active: I need to see how it affects the team’s day-to-day work. I’ll sit with them as they walk me through their workflows and the bugs they’re investigating. When I can, I’ll try working through some of those bugs myself. Seeing the problem firsthand makes it easier to separate what the team actually needs from the solution they asked for. 不过，当一个问题看起来值得探索时，我会变得更加主动：我需要观察它如何影响团队的日常工作。我会和他们坐在一起，让他们带我了解他们的工作流程和正在调查的 Bug。如果可以，我会尝试自己去解决其中一些 Bug。亲眼看到问题所在，更容易将团队真正需要的与他们所要求的解决方案区分开来。

I also seek out people who see more of the organization than I do: those who own critical systems, work across several teams or have particularly deep insight into the work downstream of my team. I’ll arrange a 1:1 or coffee chat and ask about interesting problems they’ve come across. They may have already seen the same issue in several places and started connecting the dots, giving me a head start on patterns I might otherwise have taken much longer to notice. 我还会寻找那些比我更了解组织的人：那些负责关键系统、跨多个团队工作，或者对我团队下游工作有特别深刻见解的人。我会安排一对一交流或喝咖啡，询问他们遇到过的有趣问题。他们可能已经在多个地方看到了同样的问题并开始建立联系，这让我能比预期更早地发现那些原本可能需要更长时间才能察觉的模式。

Let problems accumulate

让问题积累

Several times, I’ve been burned by moving too fast. I became excited by a request from a vocal team, built the feature and watched them barely use it. Their priorities had changed, or the request had come from a one-off investigation that no longer mattered. How eager a team was in that moment wasn’t the same as how important the feature was relative to everything else my product needed to support. By hyperfocusing on their request, I lost sight of the bigger picture. 有好几次，我因为行动太快而吃了亏。我被一个活跃团队的需求所打动，构建了功能，结果发现他们几乎没怎么用。他们的优先级变了，或者这个需求只是源于一次不再重要的临时调查。团队当时表现出的迫切程度，并不等同于该功能相对于我产品需要支持的其他所有事项的重要性。由于过度关注他们的需求，我忽略了大局。

That taught me to let potential problems pile up. Listening the way I do leaves me with far more of them than I could possibly solve, and not all deserve action. Most don’t need to turn into projects the first time I hear about them; waiting can be a superpower. 这教会了我让潜在问题堆积起来。我这种倾听方式让我收集到的问题远多于我能解决的，而且并非所有问题都值得采取行动。大多数问题在我第一次听到时并不需要立即转化为项目；等待有时是一种超能力。

Why? Because I don’t want to overfit on a single team or solve something that, in the grand scheme, turns out to be unimportant. If I wait, the same problem might pop up independently in different teams, making it a higher priority to solve. Or problems that look different on the surface might turn out to have the same shape, so I can address several use cases in one shot. Or the team asking for it might realize they didn’t actually care that much and don’t need the solution at all. 为什么？因为我不想过度适配单一团队，也不想解决那些从大局来看并不重要的问题。如果我等待，同样的问题可能会在不同团队中独立出现，从而使其成为更高优先级的解决对象。或者，表面上看起来不同的问题，最终可能具有相同的本质，这样我就可以一次性解决多个用例。又或者，提出需求的团队可能会意识到他们其实并没有那么在意，根本不需要这个解决方案。

Instead, I make a mental note and revisit the problem if it comes up again. Other engineers I know write this sort of thing down more systematically. The mechanism is a personal choice: everyone has to figure out what works for them. What matters is keeping unresolved problems around long enough for more evidence to accumulate. 相反，我会记在心里，如果问题再次出现，我会重新审视它。我认识的其他工程师会更系统地记录这类事情。机制是个人的选择：每个人都必须找到适合自己的方法。重要的是让未解决的问题保留足够长的时间，以便积累更多的证据。

Find the common shape

寻找共同的本质

Waiting helps me collect evidence, but that alone doesn’t tell me what to build. I still need to work out whether the problems I’ve retained are genuinely related and what, if anything, could address them together. 等待有助于我收集证据，但这本身并不能告诉我该构建什么。我仍然需要弄清楚我保留的问题是否真的相关，以及是否有办法能一并解决它们。

By this point, my head is usually full of spaghetti: possible solutions, constraints and half-formed connections. I like going for long, aimless walks around London and letting my mind wander through the mess. I find that connections come more easily when I’m not trying to force them. 到了这一步，我的脑子里通常是一团乱麻：可能的解决方案、约束条件和尚未成形的联系。我喜欢在伦敦漫无目的地长距离散步，让思绪在混乱中游荡。我发现，当我不再强求时，联系反而更容易浮现。

Once an idea begins to take shape, I try it against other problems I’ve been thinking about. Sometimes I discover that features we already have can be combined in a new way. Other times, the idea changes shape entirely: instead of doing exactly what one team asked for, it becomes a general capability that solves their underlying problem another way. 一旦一个想法开始成形，我就会用它来对照我一直在思考的其他问题。有时我发现我们现有的功能可以以一种新的方式组合起来。另一些时候，这个想法会彻底改变形态：它不再是完全按照某个团队的要求去做，而是变成了一种通用的能力，以另一种方式解决了他们的根本问题。

The most promising ideas make several individual requests unnecessary. When one… 最有前景的想法往往能让多个单独的需求变得不再必要。当一个……