Staff Engineer：如何主动发明工作
A Staff Engineer's Guide to Inventing Work
在Platform团队中，没有产品经理递来的Roadmap，也没有明确的收入指标，工作往往需要工程师自己去“发明”。这篇文章分享了从四个维度捕捉工作信号的方法：系统发出的信号（如Crash-led Discovery、Cost和Toil）、用户发出的信号（如Continuous Discovery和Overloaded Use-cases）、组织发出的信号（如OKRs和Manager-Repetition Heuristic）以及行业发出的信号（如Descriptive Writing和Lag Arbitrage）。作者强调，真正的挑战不在于缺乏信号，而在于如何在众多信号中做出明智选择，避免被最响亮的噪音（如最近的故障）带偏，从而构建出真正有价值的平台功能。
发明工作与其说是寻找信号，不如说是能够解释为什么选择这一个信号，而不是其他十个。
HN 评论区
41- dabedee
> 平台团队是由工程驱动而非产品驱动的。几乎从来不会有产品经理给你一份路线图，没有营收线可遵循，也没有市场会流失。
正是这种定位和心态，导致平台团队实际上无法很好地服务他人，往往沦为高塔式的人员堆砌，专门发明工作。
解决“没有市场”这一问题的办法，就是假设你服务的团队随时可能离开。这篇文章列举了各种信号，却唯独没有提到这一点。被垄断并不意味着用户或内部团队没有其他选择，也不代表他们察觉不到。产品驱动意味着关心你的用户。平台团队应当是产品驱动的，而不是在狭隘意义上由工程驱动。否则，你就会像这篇文章精彩揭露的那样，陷入发明工作的怪圈。
- dirtbag__dad
> 持续的挣扎在于寻找提升平台为用户系统提供价值的方法。
就我作为资深平台工程师（Staff+ Platform Engineer）的经验而言，什么能提升用户价值其实显而易见。真正的挑战在于，当平台离客户最远时，如何构建一个叙事来说明为什么任何工作都值得去做。
我之前曾与一位来自 FAANG 的资深产品经理共事，他技术能力平平，却不知为何坐上了平台工作的最终决策者位置。
他不断阻挠我反复详细描述的工作：数据质量堪忧、延迟糟糕透顶等等。但他却说：“数据模型有问题？我们的客户会在乎我们的数据模型和那些难以维护的流水线吗？”
直到我展示了一些基本图表，显示我们的核心数据库已超负荷运行，面临更严重事故的风险。那时，我们终于在最高层面对问题达成了共识，我也（哈哈）获得了批准。
说实话，我花了将近一年才琢磨透这一点。其他人则直接信任我的判断。不过我从中收获颇丰：即使是技术人员，可能也完全搞不懂你领域里到底发生了什么，而指标能让所有人达成共识，因为数字和图表很容易理解。
* “平台”这个词用得过于宽泛，很难说作者具体指什么。
- fsloth
"除非工程师去发明它，否则这项工作就不存在。"
这太奇怪了。在我看来，公司雇佣工程师的唯一目的就是支持业务。资深工程师（Staff Engineer）不应该需要项目经理来告诉他什么对业务方面有趣——尽管目标可能主要是技术性的。
我意识到这一点并非总是成立。但在我看来，如果你无法用业务指标为你的工作提供理由，那你就是在参与一场学术练习。
- aristofun
这篇文章很好地展示了当今企业 IT 中根深蒂固的问题。也解释了为什么任何规模够大的公司迟早会腐烂，以及为什么如今在这样的公司工作感觉如此毫无意义且平庸。
例如：
> 幸运的是，帮助我们发明工作的信号已经存在，它们来自四个方向：系统、用户、你的组织以及行业。接下来是解读这些信号的指南。
在一个理想的“好”组织中，需求的唯一来源应该是用户，也就是客户，也就是真实的人、面向用户的产品、团队等。
绝不应给推测和“工程化”（即过度工程化）留有余地，也不应存在由绩效评估驱动的开发。
我个人会解雇任何“发明”工作的人。哪怕那个人是我自己。
- juancn
我奉行“什么会接下来搞死我们”的哲学。
找出那个东西，然后采取措施避免它。
洗、冲、重复。