我不喜欢‘高级工程师原型’这种说法Why I don't like the "staff engineer archetypes"

过去十年中关于资深工程师最具影响力的文章无疑是 Will Larson 的《资深工程师原型》。他认为“资深工程师”这一头衔至少涵盖了四种截然不同的角色：团队负责人、架构师、问题解决者和左膀右臂。这一分类常被引用，作为希望成为高效资深工程师的人们的指导建议。在我两次晋升为资深工程师的过程中，当时的经理都会向我推荐“资深工程师原型”，并让我思考自己希望朝哪个方向发展。

这些原型确实存在。然而，我认为告诉工程师们试图瞄准这些原型并不是好的实用建议。

原型不应作为目标

为什么这么说？让我们以“团队负责人”原型为例。Larson 将其描述为一种非正式的技术领导角色：不一定是明确的权威人物，但擅长界定工作范围、规划项目，以及维护成功交付所需的关系（例如与其他团队的关系）。如果你想承担这个角色，难道不应该开始尝试做这些事情吗？不！你并不会通过拼命想当技术领导者而成为技术领导者，就像你不会通过拼命“想成为作家”而成为作家一样。你是在做好技术工作的过程中，直到你的技能和关系自然显现时，才真正成为技术领导者。

我在《大型公司中工程师声誉由“滚雪球效应”决定》一文中详细描述了这个过程。要擅长交付大型复杂项目，必须从交付微小的工作开始，直到你对系统足够熟悉，并建立足够的信任，才能承担稍大一些的任务。在每个阶段，只要你做出“好工作”——这里的“好工作”指的是“为股东创造价值”——你就会自然而然地获得处理更复杂、更重要事务的机会。如果你试图跳跃式前进，会遇到各种问题：

其他原型也是如此。如果你想成为一名成功的架构师，你不能仅仅通过抽象地学习软件架构来实现，因为你无法设计你不参与工作的软件。“问题解决者”和“左膀右臂”这两个原型都依赖于巨大的信任和影响力。你不能直接瞄准这些原型，因为信任和影响力是随时间积累的。事实上，“瞄准”某个特定资深工程师原型的想法，反映了对资深工程师角色本质的误解。那么，资深工程师角色的本质究竟是什么？

什么是资深工程师？

高级工程师必须对公司有用。当然，资深或中级软件工程师也应该有用，但他们只需完成眼前的工作即可。如果他们最终未能创造价值（也许项目本身不重要，或者他们得不到成功所需的资源支持），那是其管理者的责任，而非他们自己的问题。相比之下，高级工程师则必须始终创造价值：要么让项目成功，要么在项目确实无法挽救时，另寻其他有价值的事情去做。

这种期望并不公平。很多时候项目失败并非你的过错，有时也确实不可能凭空变出有用的工作。这其实是设计使然：高级工程师的角色本就不该公平。许多工程师没有意识到的是，所有高级管理和执行领导职位同样不公平——方式相同。这就是交易的一部分：高管获得权力和丰厚薪酬，作为交换，在恶劣天气来临时他们会被抛下船去。从“高级工程师”这一角色开始，你就必须对那些你无法控制的结果负主要责任。

因此，培养“高级工程师思维”与原型人设几乎无关。相反，你应该：

起初，你可能看起来不像任何一种高级工程师的原型。你更像一个头脑冷静、值得信赖的工程师，能最小化摩擦地推进项目，且能在不抱怨的情况下被重新分配任务。你也更关注管理者真正的优先事项，并认真思考如何达成这些优先事项（而不是你自己的目标）。

只要你坚持这样做下去，最终你会发现自己落入某一种高级工程师的原型之中。但很可能不是你“瞄准”的那个。成为高级工程师的关键在于，你愿意填补公司当时需要的任何一种角色。

最后的话

在 Larson 最初关于高级工程师的文章中，他明确指出这些原型更多是对高级工程师所承担的各种角色的人类学描述，而非如何在该角色中成功的操作指南。当时“高级工程师”这一职位还比较新，人们仍在摸索它的真正含义。指出该角色存在多种不同的成功路径，是一项真正新颖的观察。

高级工程师的原型确实列出了工程师如何能为组织做出巨大贡献的方式——但前提是已与组织的领导层建立了深厚的信任关系。关于如何成为一名成功的高级工程师的建议，应聚焦于如何建立这种信任，而非在已拥有信任之后该做什么。

如果你喜欢这篇文章，请考虑订阅我的新文章邮件更新，或在 Hacker News 上分享它。

这是另一篇与此文共享标签的相关文章的预览。

工程师越资深，结果就越重要。根据我的经验，人们往往高估了升职到组织架构图上的更高位置会如何改变工作的基本性质。作为一名 staff engineer，我做的或多或少和做实习生时一样：编写代码、回复工单、为自己需要处理的工作创建工单，并交付项目。我的工作更快更好，因为我掌握的工具更多，而且更频繁地在不同项目间切换，但本质上并没有不同。我的工作仍然更像一个软件工程师实习生的工作，而不是一个同等职级的 product manager 的工作。继续阅读...