一位想从 Senior 走向 Staff 的工程师曾问 Lalit Maganti：怎么找到值得做的问题？他的困扰很典型：已经意识到这个阶段不能只等任务分下来，还要判断团队和组织下一步该做什么；也试过在日历里留出时间思考大方向，却发现对着空白页硬想没什么效果。
Lalit 在一家大型公司长期做基础设施和开发者工具，并参与 Perfetto 性能调试工具的开发。他将自己的方法整理成一篇经验文章：与其等别人告诉你该做什么，不如在日常交流中吸收问题，让线索自然地积累，再找出它们背后的共同形状。
这篇文章适合正在向 Staff 或 Tech Lead 方向走的工程师，也适合想理解「技术负责人如何选题」的团队。读完后可以带走一套可复用的思路，同时意识到这套方法有自己的适用前提。
吸收问题，而不是吸收请求
很多人会自然地在会议、聊天、演示和邮件里描述自己的困难：为什么某个工作很慢、什么流程拖住了他们、他们希望系统能多做什么。这些内容看起来像抱怨，其实是最便宜的需求信号。
当问题与自己的领域重合时，Lalit 会顺着线索追问。他可能问「如果有了 X，你的问题是否就解决了」，或者把对方指向自己负责的已有功能，再请他判断覆盖了多少场景。用户常常直接给出一个方案，他会继续问清楚真正想完成什么，以及现有工具为什么做不到。
这种「环境式倾听」对内向的人也适合。他不需要为了找灵感而安排大量会议，正常一周里已经有很多信息在流动。真正值得跟进时，他会变得主动：坐到对方旁边看完整工作流和排查过程，甚至自己动手复现一两个 bug。亲眼看到问题，比只听到请求更容易区分真实需求和表面方案。
Lalit 还会主动找看得更远的人聊天，比如关键系统的负责人、跨团队工作的人，或下游使用方。他们会分享自己见过多次的同类问题，有时已经连成了模式，这能让他少走很多弯路。
让问题先积累起来
太快行动也有代价。Lalit 提到自己曾被一个声音很大的团队说服，很快做出了功能，结果对方几乎没有使用。那个请求可能来自一次性的调查，或者团队优先级后来已经变化；当时对方表现出的热情，并不能代表这件事相对于其他需求有多重要。
于是他学会了让候选问题先堆积。听到的问题会远远多于能解决的问题，多数也不必马上变成项目。等待本身就是一种筛选方式：
- 同一个问题在不同团队重复出现，优先级会自然提高
- 表面不同的需求，可能最后指向同一个底层能力
- 当初很积极的团队，之后也许不再关心
他通常只在心里记一笔，等问题再次出现再认真处理。也有人用笔记或清单做系统记录，方式因人而异。关键不是如何记录，而是让未解决的问题保留足够久，让更多证据有机会出现。
找出共同形状，但要警惕漂亮的假设
等待积累证据还不够，还需要判断这些线索是否真的相关，以及它们能否被一个方案同时解决。
Perfetto 提供了一个很好的例子。它在时间轴上用 rows 展示系统活动，不同团队陆续提出过很具体的小需求：把某组 track 固定到顶部、打开时直接定位到某段记录、做针对自己关心的自定义聚合。有人甚至等不及，用 bookmarklet 写脚本绕过官方 UI。
这些请求单看各自不同。Lalit 发现自己很难坐在桌边硬想，反而是在伦敦的长期散步中把线索理清了。最后他意识到，各个团队真正想要的并不是某一项具体功能，而是按自己的工作流个性化 Perfetto，同时又不想把自己的选择强加给别人。底层需求归结为「扩展 UI」。
这个顿悟很舒服，但也很危险。共同形状仍然只是一个假设，优雅不能替代证据。他后来曾确信透明缓存能同时解决大型 trace 的多次查询和大文件分享，直到写 RFC、做原型时才发现两个问题的解法其实不同。最终方案被拆成保持会话热度和流式表格导出两部分，两种能力后来都交付了。
投入前先做压力测试
发现一个共同形状后，Lalit 通常不会马上开建。他会根据自信程度选择不同投入：
- 有用且风险低，就直接提交变更并告诉经理
- 不确定效果或工作量，就做一个可丢弃的原型，让失败点暴露出来
- 想法大且自己确信，才投入数周或数月，并在跨团队沟通中争取支持
这个过程不只是说服别人，也在说服自己。如果别人看不到同样的价值，或遇到重大技术障碍，他宁愿现在就放弃，也不做没人用或变成维护负担的东西。有时想法成立但时机不对，他会先放起来，等组织优先级改变再启动。
他也不要求自己一定成为实现者。团队其他人做、改变组织关注点，都可能让这个问题的价值落地。找到并塑造正确的问题，本身就值得投入。
Perfetto 扩展 UI 的提议最终走到了完整投入。当时已有的插件需要把代码开源，很多内部团队做不到。Lalit 带着问题和方案找经理、同事和客户团队沟通，写了两个 RFC，做了几次一对一和分享，再根据反馈逐步收敛。最终他设计了 macros 作为轻量扩展，并让 extension servers 支持团队之间共享这些 macros。Google 内部数十个团队开始使用，一些外部公司也在内部部署了 extension servers。
解决一个问题，会带来下一个
这个循环会越来越顺。当你认真听别人讲困难、问出有用的问题，或真的帮他们解决了问题，他们会记住。之后会更早来找你，也会把你带进其他相关对话。
于是你会看到更完整的组织图景，更容易发现模式，也更容易做出别人真正需要的东西。解决一个问题的成果，又会带来更多对话和信任。早期 Lalit 需要亲手把很多想法做出来，用结果证明判断可靠；后来经理和组织会越来越多地参考他的判断，他也无需拥有每个项目，就能影响路线图。
这正是 Staff 角色容易误解的地方：晋升到这个层级，常规工作会多一些跨团队沟通，但这些对话更像是做技术判断的输入，而不是最终产出。
方法的边界
Lalit 明确给出一个前提：他的经验主要来自大型公司里的基础设施和开发者工具团队，这些团队通常有较大的自下而上自主权，工程师能影响路线图。在更自上而下的环境里，个人发挥的空间可能会小一些。
即使如此，方法中的基本动作仍然可以在小范围内使用：认真倾听团队的真实困难、把线索保留一段时间、识别重复模式，再用低成本方式验证。如果你所在的组织允许你对一个小领域负责，这套做法仍然有用。
总结
找到值得解决的问题，不需要单独安排一段「战略时间」。它来自持续参与别人的工作，并愿意让看似无关的信号停留得更久。真正的价值往往藏在几串独立请求之间，等你看到它们的共同形状，再谨慎地用原型、讨论和证据检验它。
如果你也在往 Staff 方向走，可以试着先把「今天听到的困难是什么」当作日常工作的一部分。等它自然重复、长出共同形状，再决定是否值得你投入。
如果你对这类工程组织与产品判断话题感兴趣，Aide Hub 会继续分享 AI 助手、开发工具和软件工程实践。