一位想冲击Staff Engineer的资深工程师问了个很多人都卡住的问题：到底该怎么找到值得做的事？Lalit Maganti——Google性能调试工具Perfetto的核心维护者——给出的答案不是“把日历空出来做战略思考”，而是反过来：像海绵一样，把日常噪音里的抱怨、请求、workaround全部吸收进去，让它们在脑子里沉淀，等某天几个看似无关的问题突然拼出同一个形状。这篇文章发布后因为读者反馈做过修订，本身就说明原始表述踩到了一个行业老争议：找问题到底是工程师的主动修行，还是管理层该负责却没负责的事。
Maganti讲得很坦诚，他的经验主要来自大公司的基础设施和开发者工具团队，团队对路线图有很强的自下而上的话语权。这句自我限定容易被读者一扫而过，但恰恰是整套方法论能不能用的前提。
四步找问题:吸收、沉淀、找形状、压力测试
Maganti的方法拆开看其实很朴素。第一步是吸收问题而不是吸收请求——别人要什么功能不重要，为什么要才重要。第二步是让问题沉淀，不急着响应第一个提需求的团队，因为热情和重要性是两回事。第三步是找共同形状，比如Perfetto团队陆续收到“帮我固定几条track”“帮我打开时自动缩放到某个区间”这类零散请求，攒了两年才发现所有人真正要的是给UI做扩展的能力，而不是某个具体功能。第四步才是压力测试：写RFC、做原型、拉相关团队对齐，确认这不是自己一厢情愿的“优雅假设”。
这套流程本身没什么好挑剔的，问题出在它默认了一个前提：你所在的组织愿意让你花时间“吸收”，而不是把你的日程排满交付任务。
争议点:自己找问题,还是被要求自己找问题
Hacker News和Reddit上关于这篇文章的讨论比原文本身更值得看。一种声音认同Maganti的转型逻辑：升到Staff后还等经理派任务清单，说明思维方式没跟上职级。但另一种声音更尖锐——如果公司不提供战略语境、不给决策权限、不保护资源，仅凭个人主动性根本造不出组织级的影响力，事后再拿“你没找对问题”来评判并不公平。
r/ExperiencedDevs上还有个描述很扎心：不少Staff角色被“随机化”了，变成所有模糊问题、跨团队冲突、突发事故的默认责任人，同时还得完成常规交付，结果是精力被拆得到处都是。r/EngineeringManagers那边则点出一个结构性死结——晋升要求先证明你有Staff级别的影响力，但真正高价值的项目所有权，往往早就被别的Staff或经理占着了。
- 风险.“自己找问题”的说法一旦脱离资源授权和战略语境，很容易变成管理失职的遮羞布，工程师的主动性反而成了被追责的把柄。
自主权不是天上掉下来的，是谈出来的。
区分健康自主和披着授权外衣的忽视，关键不在“有没有被分配任务”，而在管理层给出的问题定义留白多少——是“降低跨团队部署风险”这种有方向的开放式命题，还是干脆什么都不说，等出了事再问你为什么没提前发现。
晋升委员会看的六件事,原文一件没提
Maganti通篇讲的是怎么找到好问题、怎么验证它，但完全没碰一个现实问题：晋升委员会到底怎么判断“你找到了对的问题”。据检索到的讨论，委员会实际参考的维度至少有六层——问题选择、影响范围、无职权情况下的跨团队影响力、技术判断质量、成果的持久性，以及最后一层常被回避的可见度和叙事：同样一个贡献，讲得清楚和讲不清楚，评级可能完全不同。
这层政治现实原文一字未提，却是很多工程师卡在Senior到Staff之间的真正原因——他们确实解决了好问题，但没人知道，或者知道了也没被讲成一个完整的故事。
对正在冲Staff的工程师来说，实际可做的是两件事同时进行：一边练“吸收”，留意反复出现、跨团队出现、已经有人搭workaround绕过去的问题；一边主动去和经理要战略语境、要资源承诺、要在关键场合把自己的判断讲出来，而不是被动等着证据攒够。对管理者而言，把“自己找问题”当成放养的借口之前，先问问自己有没有把方向和资源给到位——这比工程师主动不主动更决定结果。