高阶工程师也常被称为 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 岗位时这种更长的工作周期可能会让你非常沮丧。作为高阶工程师有时一天结束时感觉自己一事无成是很正常的。请坚持下去。影响力和个人成长往往体现在更长的时间跨度中。虽然我交流过的每一位高阶工程师都希望自己偶尔能有更多时间写代码也都承认有时会担心自己没有取得多少成就但他们中没有人后悔转型到现在的岗位。