一个真实的问题
“你是怎么找到值得解决的问题的？”
一位正在从 Senior Engineer 晋升 Staff Engineer 的 mentor 问我。他发现 Staff Engineer 这个角色不只是做分配下来的任务，还需要主动参与决定团队和组织应该做什么。
有人建议他“在日历上留出时间思考大局”。他试了，但发现这样做没啥用。
不是“战略思考”，而是“海绵模式”
作者的回答很反直觉：
“我几乎从来不是通过盯着空白页‘思考战略’来找到好问题的。相反，我像海绵一样，从日常的噪音中吸收人们遇到的问题，让它们在脑子里沉淀。”
这个过程听起来不高级，但很有效：
- 吸收问题，而不是响应请求：人们在会议、聊天、邮件里不断抱怨他们的困难。作者不是被动接受需求，而是主动追问：“如果 X 存在，能解决你的问题吗？”
- 让问题堆积：不要一听到问题就立刻动手。等一等，同样的问题可能会在不同团队独立出现，那时候优先级就更高了。或者，看似不同的问题可能有相同的本质。
- 找到共同的“形状”：当足够多的问题堆积后，模式会浮现出来。作者的最佳“解谜”时刻不是在办公桌前，而是在伦敦街头漫无目的的散步中。
一个真实案例：Perfetto 插件系统的诞生
作者开发的性能调试工具 Perfetto 遇到了各种零散需求：
- 一个团队想要固定某些轨道在顶部
- 另一个团队想要完全不同的轨道固定方式
- 还有人想要打开时自动缩放到特定区域
- 甚至有人开始用 bookmarklet 做 workaround
所有这些需求的共同形状是什么？用户想要个性化 UI，但不想影响其他人。
解决方案不是一个个实现这些功能，而是构建了 macros 和 extension servers——让用户可以自己自动化 UI 操作，而不需要写插件或开源代码。
结果：Google 内部几十个团队在使用，外部公司也在采用。
职业生涯的关键洞察
成功建立信任的正循环
- 当你表现出对他人问题的真正兴趣，他们会记住
- 他们会更早把你拉进相关对话
- 你看到组织里更广的画面
- 更容易发现模式和构建真正需要的东西
- 解决问题后，你会进入更多对话……循环继续
Staff Engineer ≠ 会议机器
“很多人以为 Staff Engineer 就是用会议和协调取代技术工作。对我来说，对话是我构建的输入，不是输出本身。”
这是关键区别：会议不是工作成果，而是发现问题的渠道。真正的产出是解决那些之前没人意识到的问题。
三条实用建议
1. 不要当“功能工单处理器”
很多工程师等待 manager 或 lead 分配任务，然后通过解决最难的问题来证明自己的价值。这可以晋升，但真正留下印记的项目，是你发现并解决了一个领导层还没意识到的重要问题。
2. 让子弹飞一会儿
作者承认自己多次因为太快行动而踩坑：为声音最大的团队做了功能，结果他们根本不怎么用。需求可能是临时的，优先级可能已经变了。
等待是一种超能力。
3. 优雅不是证据
当你发现几个问题有“共同形状”时，会很兴奋。但作者警告：
“共同形状只是假设。优雅不是证据。”
他举了一个例子：曾以为构建透明缓存系统能同时解决大 trace 共享和重复查询两个问题。写了 RFC、做了原型，才发现这两个问题真正需要的解决方案完全不同。最终拆成了两个独立设计，都成功上线了。
写在最后
这篇文章最有价值的地方在于它的“反套路”：
- 不是“战略时间管理”
- 不是“季度规划工作坊”
- 不是“领导力培训”
而是一个内向的工程师分享他如何通过“持续倾听、耐心沉淀、模式识别”来找到真正有价值的问题。
这个方法不太“高级”，但很真实。而且，它确实有效。
推荐给：
- 正在冲击 Staff Engineer 的 Senior Engineer
- 想在团队中发挥更大影响力但不知道从何下手的工程师
- 已经在 Staff+ 位置但想优化自己方法论的人
延伸阅读：
- Perfetto 文档：UI 自动化
- Perfetto 文档：Extension Servers
引用链接
[1] How I find problems to solve as a staff engineer: lalitm.com/post/find-problems-staff-engineer/
[2] Perfetto 文档：UI 自动化: perfetto.dev/docs/visualization/ui-automation
[3] Perfetto 文档：Extension Servers: perfetto.dev/docs/visualization/extension-servers
发表于 4 天前
|
查看: 1|
回复: 0
