大多数职业发展通道，都会为公司内部的高阶工程师设定一套统一的职责期望。清晰的角色预期当然对每个人都有帮助，但职业发展通道更适合描述一类群体，而不是描述具体个人。

对高阶工程师来说尤其如此。很多公司的职业发展通道，往往会把多种不同的角色压缩在同一个头衔之下，从而掩盖这些角色之间的差异。对于想了解 Staff Engineer、Staff-plus 工程师，或者高级工程师职业发展路径的人来说，理解这些角色差异非常重要。

我与越多人讨论公司中 Staff-plus 工程师的角色，就越发现他们的经历大致可以归纳为四种截然不同的模式。大多数公司会重点依赖其中一到两种模式；其中有一种模式，通常只会出现在拥有数百甚至数千名工程师的公司中。少数公司则没有真正的技术领导模式，而是把所有经验丰富的工程师都推向工程管理岗位。

在文学中，反复出现的角色模式被称为“原型”，例如“英雄”或“骗子”。“原型”这个词，也恰好适合用来描述高阶工程师中常见的几类角色。

我观察到的四种常见高阶工程师角色原型是：

技术负责人负责指导一个特定团队的工作方式和执行落地。他们通常会与一位工程经理紧密合作，有时也会与某个领域内的两三位经理合作。一些公司还设有技术负责人经理，也就是 Tech Lead Manager 角色。这个角色与技术负责人类似，但属于工程管理层级，并承担人员管理职责。

架构师负责关键技术领域的方向、质量和方法。他们需要深入理解技术限制、用户需求，并具备组织层面的领导力。

问题解决者能够深入挖掘极其复杂的问题，并找到合适的解决方案。有些问题解决者会长期专注于某个特定领域，另一些则会在组织领导层的指导下，在不同的热点问题之间灵活切换。

高管副手能够扩展高管的注意力，借用高管的权限和影响力，帮助运转特别复杂的组织。他们为大型组织的领导者提供额外的领导资源。

这种分类方式更注重实用性，而不是追求绝对完整。但到目前为止，我接触过的所有高阶工程师，都大致能归入其中一种类型。当然，有些人比另一些人更容易归类。

高阶工程师角色一：技术负责人

以技术负责人原型为主的故事包括：Diana Pojar、Dan Na、Ritu Vincent。

技术负责人是最常见的 Staff-plus 角色。他们负责领导一个或多个团队，并主导项目的方法设计和执行落地。

他们能够轻松规划复杂任务，协调团队解决问题，并清除推进过程中的障碍。技术负责人通常非常了解团队的整体情况，并维护团队成功所需的许多关键跨团队和跨职能关系。他们是团队产品经理的重要合作伙伴，也通常是产品路线图需要调整时第一个被联系的人。

在团队规模扩大、跨团队依赖增多之后，技术负责人尤其需要看到完整的研发上下文，而不是只盯着某几个任务或代码变更。借助 PingCode 这类智能化研发管理工具，团队可以把目标、需求、任务、开发、测试、发布和 Wiki 知识沉淀串联起来，并打通研发过程中使用的其他工具，让技术负责人更容易判断项目推进中的风险、依赖和优先级。

在职业生涯早期，他们可能负责过团队中最复杂的技术项目。但到了高阶工程师阶段，他们通常会把这类项目分配给团队其他成员。这样做一方面是为了培养团队成员，另一方面也是因为他们意识到：随着技术负责人亲自写代码的时间减少，团队整体影响力反而会提升。

虽然他们写代码的时间变少了，但他们仍然是团队技术愿景的制定者。在处理复杂问题时，他们也会积极协调团队，确保团队形成共识。

对很多人来说，技术负责人是他们进入高阶工程师阶段后的第一个角色。这背后有几个原因。

首先，在团队意识较强的公司里，技术负责人这个角色往往很早就会出现。而采用敏捷方法的公司通常具备这种团队意识，大多数公司也都会在某个阶段尝试敏捷方法。

其次，技术负责人的日常工作与高级工程师的工作最相似，因此过渡起来相对自然。

最重要的是，一个组织大约每八名工程师就需要一名技术负责人，这使得技术负责人比其他类型的高阶工程师角色更常见。

令人有些困惑的是，有些公司把“技术负责人”作为正式职级头衔，而另一些公司则把它视为一种临时角色。在这份原型列表中，“技术负责人”是高阶工程师的一种工作方式。但在现实中，也有很多人虽然担任技术负责人角色，却并未达到高阶工程师应有的影响力。

事实上，你会发现，一些并非高阶工程师的人，也可能表现出这些原型中的某些行为。成为一名高阶工程师，并不只是拥有某个角色或头衔，而是角色、行为、影响力，以及组织对这些影响力的认可共同作用的结果。

高阶工程师角色二：架构师

以架构师原型为主的故事包括：Joy Ebertz、Katie Sylor-Miller、Keavy McMinn。

在许多公司里，“架构师”这个头衔已经不再流行，但架构师这个角色对高阶工程师来说依然重要。

架构师负责公司某个特定技术领域的成功，例如 API 设计、前端技术栈、存储策略或云基础设施。一个领域要配得上架构师的投入，必须既复杂，又对公司的成功至关重要。

人们常有一种有害的偏见，认为架构师会孤立地设计系统，然后把设计方案交给别人实施。这种情况确实存在，但如果把这种刻板印象套在所有架构师身上，是对真正优秀架构师的误解。

真正有影响力的架构师，会努力深入理解业务需求、用户目标，以及相关的技术限制。他们会运用这些洞察，在自己关注的领域中识别并倡导有效解决方案。他们之所以能够推动这些方案，并不是因为头衔本身，而是因为他们通过持续展现良好判断力，逐步赢得了组织信任和组织权威。

架构师角色往往更容易出现在几类公司中：规模较大的公司；代码库异常复杂或耦合度较高的公司；以及那些正在努力偿还产品市场早期快速冲刺阶段所积累技术债务的公司。

有些公司鼓励架构师深入代码库；另一些公司则明确要求架构师不要写代码。这两种模式在不同公司中都可能成立。

高阶工程师角色三：问题解决者

以问题解决者原型为主的故事包括：Bert Fan、Nelson Elhage。

问题解决者是组织中值得信赖的人。他们会深入研究棘手问题，并持续跟进，直到问题得到解决。

担任这一角色的人，通常会被安排处理组织领导层认定为关键的问题。这些问题要么没有明确解决方案，要么执行风险极高。

大多数职能型高阶工程师岗位都需要大量组织协调工作。但问题解决者通常处理的是已经被明确列为组织优先事项的问题，因此他们往往不需要花太多精力去重新对齐组织共识。

另一方面，一旦问题得到控制，他们通常就会停止介入。这可能会让他们的工作显得有些短暂，也需要谨慎处理，否则容易让那些留下来维护“已解决问题”的团队感到不满。

在那些以个人而非团队作为规划和责任基本单元的公司中，问题解决者这一角色最为常见。在这样的公司里，问题解决者往往会取代技术负责人的位置。

而在传统的、以迭代开发为中心的公司中，除非公司规模足够大，或者运营时间足够长，已经积累了一定数量的技术债务，否则你不太可能经常看到这种角色。

高阶工程师角色四：高管副手

以高管副手原型为主的故事包括：Michelle Bu、Rick Boone。

高管副手是所有原型中最少见的一种，通常出现在拥有数百名工程师的组织中。他们类似于不直接承担管理职责的高级组织领导者。

Rick Boone 曾将自己的角色比作《权力的游戏》中的“国王之手”，以及《白宫风云》中的 Leo McGarry：他们借用高级领导者的权力行事。

然而，借用权力也意味着你必须与这位领导者的理念、信念和价值观保持高度一致。

担任这个角色的人，会参加领导者的 Staff 会议，并通过分担领导者的重要工作来扩大其影响力。这个层级要处理的问题，绝不是纯粹的技术问题，而是处在业务、技术、人员、文化和流程的交叉地带。

高管副手常常会迅速投入紧急工作，调整方案，将执行任务委派给最合适的团队，然后又赶往组织内另一个需要解决的问题。

这类角色的好处在于，你几乎总是在处理关键问题。它的坏处也在于，当一个关键问题终于解决时，你很快又会投入下一个问题。

哪种高阶工程师角色更适合你？

在思考哪种原型适合自己时，首先要反思：哪类工作会让你充满能量？然后，再考虑公司里有哪些实际职位空缺。

所有公司都需要能够胜任技术负责人角色的工程师，这使得技术负责人成为最容易获得的第一个高阶工程师角色。

强调个人责任而非团队责任的公司，通常会很早设立问题解决者这一类角色。另一方面，采用严格迭代开发或敏捷方法的公司，往往很晚才会设立这类角色，甚至根本不会设立。

在最近一批快速发展的科技公司中，架构师和高管副手角色通常会在公司分别达到约 100 名和 1000 名工程师规模时才出现。在此之前，这些角色往往并不存在。具有其他文化基因的公司，可能会更早设立这些角色，也可能根本不会设立。

要在这些岗位上取得成功，你需要保持积极投入。因此，了解哪些类型的工作能让你充满能量至关重要。

技术负责人和架构师，往往会与同一批人一起，多年来持续处理相同领域的问题。这会培养出紧密的团队意识和共同目标感。有时，他们的工作会成为公司的首要任务；有时，他们的工作又会推进得如此顺利，以至于高管们甚至忘记了他们的存在。

问题解决者和高管副手则往往奔波于不同事务之间，每周与同事的互动也更多是任务导向的。他们与高管优先级高度绑定，也可能因为解决领导层最紧迫的问题而获得认可。另一方面，虽然他们名义上也属于某个团队，但他们与团队其他成员的工作重点往往很少重叠，因此也更容易缺乏归属感。

每一种原型，都会有人热爱，并从中获得极大满足感；也会有人觉得它令人绝望。找到适合自己的原型当然很重要，但也要记住：在长达三四十年的职业生涯中，你有足够时间去体验每一种原型。