高阶工程师，也常被称为 Staff Engineer 或 Staff-plus Engineer，其角色很大程度上取决于团队的需求，以及工程师自身的优势。根据我的经验，高阶工程师的职责会随着时间不断变化。不过，通常来说，他们的主要工作是参与对公司具有战略价值的项目，推动关键技术设计，并提升整个团队的工程水平。

任何曾在家庭聚会上被亲戚围住，问“软件工程师到底是做什么的”的人都知道，要解释这份工作并不容易。也许你已经能给亲戚们一个足够有说服力的答案，但当同事问你“高阶工程师到底是做什么的”时，很多人反而会一时语塞。

最直接的回答是：高阶工程师仍然在做很多让他们成为优秀工程师的事情，例如建立影响力、编写软件、协调项目。然而，这种说法并不完整，甚至有些误导。

高阶工程师确实还在做这些事，但这些工作的性质已经发生了变化。过去，它们可能是工作的核心；到了高阶工程师阶段，它们更多变成了支撑性工作。不同类型的 Staff-plus 岗位，日常安排会有所差异，但它们通常都有一些共同基础：设定和调整技术方向，提供指导与赞助，将工程视角带入组织决策，探索未知问题，以及承担 Tanya Reilly 所说的“粘合剂”工作。

高阶工程师的核心职责一：设定技术方向

当我能够帮助团队为某个领域设定技术愿景，并引导大家朝着这个愿景前进时，我会觉得自己最有价值。我们大概都会同意，希望代码架构变得更好，或者希望某些方面有所改进。但我发现，人们常常只是模糊地想要“变好”，却并不清楚自己真正想要什么。我喜欢帮助团队就目标达成共识，即使最终无法完全实现也没关系，并制定一个实现目标的大致路径。

——Joy Ebertz

就像儿童读物《老雷斯的故事》中，老雷斯为树木发声一样，高阶工程师也需要代表公司的技术发声。技术本身不会说话，它需要有效的代言人。

那些能够成功推动技术演进的人，往往务实、深思熟虑，并且更关注长期趋势，而不是把每一个单独的技术决策都看作成败攸关的危机。你可以把他们想象成某种“兼职技术产品经理”。

有些高阶工程师被明确任命负责某个特定领域，例如 API 设计；另一些情况下，他们需要编辑、协调并整合多个技术领域的方案。无论是哪种情况，设定技术方向的本质，都是理解并解决组织的真实需求，而不是优先推动你个人最感兴趣的技术或方法。

在职业生涯早期，你可能会试图影响技术决策，让它朝着自己感兴趣的方向发展。但到了高阶工程师阶段，你首先要对业务和组织负责，其次才是对自己的偏好负责。

高阶工程师的核心职责二：指导与赞助

在我目前的工作中，每当看到我指导过的人发布项目成果，或者看到我帮助某个工程团队重塑了他们对重要问题的理解模型时，我都会感到非常振奋。真正日复一日构建和维护技术的是这些团队，而不是我。我衡量自己影响力的标准，是他们是否取得了进展，更重要的是，他们是否朝着正确方向前进，以及他们的工作是否与公司目标保持一致。

——Michelle Bu

人们普遍喜欢讲述英雄式领导力的故事：某个卓越个人做出了改变公司未来的关键决策，最终扭转局面。然而，这类故事大多经过精心包装，目的是塑造一个足够吸引人的形象。

相比个人英雄主义，培养身边的工程师，往往更能有效改变公司的长期发展轨迹。而培养团队成员最有效的方式之一，就是积极开展指导和赞助。

有时，人们在职业发展路径中看到“导师”这一要求，就机械地把它当成一项待完成任务。这其实很可惜，因为导师制是高阶工程师最有价值的工作之一。分享经验和建议，建立持续关系，并真正理解对方的背景，是一项极具影响力的工作。

最优秀的高阶工程师，会将适度的导师制与大量的赞助式支持结合起来：他们会主动帮助和支持身边的人获得成长机会。Lara Hogan 曾写过一篇关于赞助和导师制区别的经典文章：《赞助是什么样子的？》

高阶工程师的核心职责三：提供工程视角

我会参与更高层级的工程讨论，这些讨论通常已经超出了单个项目或团队。我们会定期召开 Staff 工程会议，讨论涉及多个团队的技术和非技术问题。

——Dan Na

高效组织会尽量简化日常决策流程。一个很好的例子是审核潜在企业客户的合同。

在早期阶段，产品和工程团队可能会对某些已经签署的合同感到不安，因为这些合同会带来难以支持的承诺。经历几次之后，审核流程通常会纳入更多利益相关者，最终确保合适的人在合适的时间参与到合适的环节。

即便是那些擅长处理日常决策的公司，在遇到突发情况时也常常手足无措。这类决策往往既紧急又重要，而且在决策做出之前，甚至很难及时召集到合适的人。

组织架构调整常常在缺乏充分工程意见的情况下推进，而这些意见本来可能会改变最终结果。同样，对于一些不常见岗位，例如初创公司一年可能只招聘一名高管或一名高阶工程师，面试流程中也常常遗漏对候选人的关键评估维度。对某些公司来说，就连产品路线图规划也可能落入这一类。

身处关键位置的工程师，常常会在重要决策节点被临时拉进会议室。这使他们有机会在决策结果仍然可能改变的时候，将工程背景和工程视角带入讨论。

这些短暂的发言机会非常重要，因为它们让你有机会在原本可能被忽略的地方提出工程观点。但请记住：你代表的是整个工程团队的利益，而不仅仅是你自己的看法。

在这类决策中，高阶工程师最需要的不是更多零散信息，而是完整的研发上下文。比如借助 PingCode 这类智能化研发管理工具，将目标、需求、任务、开发、测试、发布和 Wiki 知识沉淀串联起来，并打通研发过程中使用的其他工具，就能让高阶工程师更清楚地看到技术决策如何影响交付效率、质量风险和团队协作成本。

高阶工程师的核心职责四：探索未知问题

我现在在孵化器的工作主要是做原型设计，但在之前担任技术负责人时，我做过很多不同类型的事情。

——Ritu Vincent

爬山算法是一种简单的优化算法。想象一下，你站在一座山上，想要到达山顶。你原地转一圈，找到附近最高的点，然后走过去。到达那里后，你再转一圈，继续找到当前位置附近最高的点，再走过去。只要一直这样做，最终就能到达你所在这座山的顶峰。

但是，想象一下你在雾天这样做。由于能见度有限，你可能已经到达了附近最高的点，却后来才发现，视线之外其实还有一座更高的山。

爬山式策略不能解决所有问题，但它足够有效，以至于许多公司很难采用其他方法。例如，一家面向消费者的公司可能很难支持企业级交易；一家成熟公司可能很难跟上规模更小的竞争对手的发布节奏。甚至还有一种情况：你当前业务创造的价值很高，即使增长率已经开始下降，也很难优先投入新业务。

从长远来看，公司要么学会探索，要么被淘汰。这不是一个可以忽视的挑战。

仅仅指派一支擅长爬山式优化的团队去做探索性工作，并不能保证成功。因此，许多公司会采取不同方法：他们找到几位值得信任、能力全面的人，投入一些资源，几个月后再回头看看他们发现了什么。这些人中，通常会有一位高阶工程师。

探索并不总是业务问题。它也可以是任何模糊但重要、而公司现有系统无法有效处理的问题。例如，大幅降低基础设施成本；制定一个只需要六个月、而不是三年才能完成的多区域部署战略；或者突然发现主数据库只剩下三个月磁盘容量，而且无法再升级到更大规格。根据我的经验，这在快速成长的初创公司中意外地常见。

这是公司里最有成就感、也最具风险的工作之一。要胜任这项工作，你需要获得组织的高度信任。也就是说，公司要足够尊重你，相信即使探索失败，也是问题本身足够困难，而不是个人能力不足。

高阶工程师的核心职责五：承担“粘合剂”工作

Tanya Reilly 写过一篇很精彩的文章《成为粘合剂》。文中提到，优秀高阶工程师的另一个核心能力，是承担那些必要但往往不被看见的工作，确保团队持续推进，并按时交付成果。

这些工作通常并不光鲜亮丽，但在高影响力组织中，常常会有一位或多位高阶工程师在幕后默默推进。他们帮助最重要的工作加速落地，确保事情真正完成。

高阶工程师还会继续写代码吗？

讨论高阶工程师的角色时，如果不谈那个高阶工程师们聚在一起时最常问的问题，就不完整了：

“你还有时间写代码吗？”

答案当然是：这要看情况。

Ras Kasa Williams 说：

“我仍然定期贡献代码，当然比团队里的其他工程师少。但重要的是，我要坚持‘双手放在键盘上’的工作，这样才能确保我的技术战略以及其他宏观层面的决策，仍然建立在团队实践经验之上。”

Katie Sylor-Miller 说：

“我是一名前端架构师，但最近我写得最多的是 SQL，因为我做了很多数据分析。我一直在研究我们的性能指标，找出需要改进的地方，以及哪些问题最能有效提升性能和业务指标。我偶尔也会写一些 JS 或 PHP 代码，但主要是为了帮助团队解决问题，或者做一些小型性能实验。”

Joy Ebertz 说：

“职位越高，你的工作与代码的直接关系就越少。当然，和人员管理者不同，你仍然会非常关注技术。即使是首席技术官，也可能至少会写一些代码。然而，职位越高，你的工作就越侧重于指导和培养周围的人，以及更广泛的人群；通过打造公司公开的技术品牌来建设团队；发现需要改进或纠正的更广泛技术趋势；帮助团队或公司制定技术愿景；并为解决技术债务争取资源。”

大多数高阶工程师仍然会写一些代码。有些人则几乎完全不写。但没有人能像职业生涯早期那样写那么多代码。

偶尔你可能会有一整周几乎都在编码，但这不会成为常态。如果这种情况太频繁，通常说明你正在做一些相对轻松的工作，而不是真正重要的工作。

即使你写的代码不多，你也会阅读大量同事的代码，并进行相当多的代码审查。

高阶工程师的工作节奏：更慢，但回报更大

高阶工程师工作的一个共同特点，是工作周期更长。

在职业生涯早期，人们很容易习惯软件开发中快速的反馈循环：编写代码、测试、发布、重复。到了高阶工程师阶段，你所做的大部分工作，会被耗时数周、数月，甚至数年的过程取代。

当你刚开始担任 Staff-plus 岗位时，这种更长的工作周期可能会让你非常沮丧。作为高阶工程师，有时一天结束时感觉自己一事无成，是很正常的。请坚持下去。

影响力和个人成长，往往体现在更长的时间跨度中。虽然我交流过的每一位高阶工程师，都希望自己偶尔能有更多时间写代码，也都承认有时会担心自己没有取得多少成就，但他们中没有人后悔转型到现在的岗位。