# Staff工程师的四种原型 大多数[职业阶梯](https://lethain.com/perf-management-system/)为Staff工程师的工作内容定义了一个单一的，统一的期望值。有一个清晰明确的预期值对大家都是有好处的，但职业阶梯这个工具更适用于一群人，而不是具体的某一个人。这一点对于一些拥有同样名号但是工作内容截然不同的Staff工程师来说尤其如此。 我和越多的人谈论过员工以上的工程师在他们公司的角色，他们的经验就越集中在四种不同的模式上。大多数公司强调其中的一种或两种模式，而一种模式只存在于拥有数百或数千名工程师的公司。一些公司没有任何技术领导模式，而是把他们所有有经验的工程师都推向了工程管理。在文学作品中，重复出现的角色模式被称为原型，如“英雄”或“恶魔”，而"原型"这个术语有助于标记这些Staff-plus工程师的不同种类。 我所遇到的四种常见的Staff-plus角色原型是: * **Tech Lead** 指导特定团队的方法和执行。他们有时与某特定主管紧密合作，但有时他们与两个或三个主管在一个重点领域合作。一些公司也有Tech Lead经理的角色，这与Tech Lead原型类似，但处于工程经理的岗位路径上，职责中包括了人员管理。 * **架构师**对关键业务的方向、质量和方法负责。ta们需要对技术瓶颈、用户需求和组织级别领导有深入了解。 * **Solver**会深入研究任意复杂的问题，并找到合适的前进路径。有些人长期专注于某一特定领域。另一些则在组织领导的引导下从一个热点跳到另一个热点。 * **Right Hand**延伸了高管的注意力，借用他们的范围和权力来运营特别复杂的组织。ta们为大型组织的领导者提供了额外的处理能力。 这种分类方式更侧重于实用性而不是完整性上。但到目前为止，我已经能够将与我交谈过的每个staff +工程师归入其中一个类别。当然我得承认，有些人比其他人更容易归类。 ## Tech Lead ![一个典型的Tech Lead 每周的日程安排](/files/-MZ_YhgLtrlkGAn74bw0) Tech Lead原型案例: Diana Pojar, Dan Na, Ritu Vincent Tech Lead是最常见的Staff原型，在他们的方法和执行方面领导一个团队或一群团队。他们擅长确定复杂任务的范围，协调团队来解决这些问题，帮助unblock团队。Tech Lead通常负责团队的context，并维护许多必要的跨团队和跨职能的关系，这是团队成功的必要条件。他们需要与团队产品经理密切合作，当路线图需要调整时，他们会第一时间上线。 在他们职业生涯的早期，他们将实现团队中最复杂的技术项目，但同时，他们默认将此类项目委派给整个团队。他们这样做既是为了培养团队成员，也是承认一点，那就是团队的影响力是随着Tech Lead的代码量减少而增加的（也就是TL不能光顾着写代码）。虽然他们编写的代码更少，但他们仍然是定义团队技术愿景的人，并在团队内部针对复杂项目构建共识。 对于许多人来说，Tech Lead的角色是他们第一次作为Staff工程师的经历——这有以下几点原因：首先，在那些有着团队概念的公司中，Tech Lead这一角色出现的很早，这在使用敏捷方法的公司中很常见，而且大多数公司在某些时候都尝试过敏捷方法。另一个因素是，Tech Lead的日常工作与你作为Senior工程师所做的工作非常相似，所以这样的过渡也非常正常。最重要的是，**一个组织大约每八个工程师需要一个Tech Lead**，这比其他原型更常见。 有些公司把Tech Lead当作头衔，有些公司把它当作工作角色，这有点令人困惑。在这个原型列表中，Tech Lead是作为Staff工程师的一种方式，但做着Tech Lead的工作而没有Staff工程师对应的影响力也是很常见的。实际工作中，你会发现有些非Staff工程师也会做一些Staff的工作。Staff工程师不仅仅是一个工作角色，**它是角色、行为、影响力以及组织对这些因素认可程度的交集。** ## 架构师 ![“Example calendar for Architect archetype](/files/-MZ_ZHXyTSM38btua8O8) 架构师原型案例: Joy Ebertz, Katie Sylor-Miller, Keavy McMinn 在许多公司中，架构师这个头衔已经过时了，但是架构师这个角色仍然存在，并且是一个很好的Staff+的工作。架构师负责公司内特定技术领域的实现，例如公司的API设计、前端堆栈、存储策略或云基础设施。一个架构师若想在某个领域有所成就，这个领域必须足够难，而且对公司能否成功具有长期和核心的作用。 有一种错误的先入为主的印象是，架构师是自己一个人设计系统，然后把他们的设计传递给其他人来实现。这种情况在某些情况下确实会发生，但我采访过的架构师肯定会对这种刻板印象非常不满。有影响力的架构师致力于保持对业务需求、用户目标和相关技术局限的深刻理解。他们利用这种洞察力来识别和提倡在他们关注的领域内的有效方法，并通过展示稳定且良好的判断力而获得的组织内的威望。 架构师角色更有可能出现下面几种公司里：相对较大的公司；具有异常复杂或耦合的代码库的公司；以及在为满足产品市场需求，在一开始的Sprint冲刺开发中留下了太多技术债务，现在需要艰难地这些偿还技术债务的公司。一些公司要求架构师深入到代码库中，而另一些公司则明确要求架构师不能写代码:这两种模型都有适用的场景。 ## Solver ![Example calendar for Solver archetype](/files/-MZ_Z_DkYVf3mywbivDR) Solver原型案例: Bert Fan, Nelson Elhage Solver是组织中值得信赖的代理人，他深入研究棘手的问题，不断尝试解决它们，直到它们被解决。这一角色的Staff被转移到领导层认定为关键的问题上，这些问题要么没有清晰的解决方案，要么在执行层面有很大的风险。 大多数Staff平时经常需要做很多组织协调工作，而Solver通常是在已经确定为组织内高优先级的问题上操作，因此相对而言不怎么需要去给组织结构做"按摩"。另一方面，一旦问题规模被控制住，他们通常就会停止自己的工作内容，这可能会给人一种"怎么变卦了!"的感觉，这就需要一种温和的方式来避免激怒遗留下来的团队，因为还需要他们维护“已解决的”问题。 Solver常见于那些将个人，而非团队视为Ownership基本单位的公司。在这样的公司中，很容易看到Solver取代了Tech Lead的地位。在传统的以管理Sprint为中心的公司，你不太可能遇到这种角色，除非这些公司变得相当大或年限足够长到产生各种特定的技术债务。 ## Right Hand ![Example calendar for Right Hand archetype](/files/-MZ_Zl40GpKC5LzJkII3) Right Hand原型案例: Michelle Bu, Rick Boone Right Hand是最不常见的原型，会出现在一个拥有数百名工程师的组织中，类似于一个没有直接管理责任的高级组织领导。瑞克·布恩将他的角色比作《权力的游戏》中的国王之手，以及《白宫风云》中的里奥·麦格瑞(Leo McGarry)，借用高级领导人的权限来运作。当然，由于权限是借来的，就有义务与领导者的方式、信仰和价值观保持深度一致。 这一职位的员工会参加领导的员工会议，通过解决重要问题来扩大领导的影响力。在这个级别上解决的问题从来不是纯粹的技术问题，而是涉及业务、技术、人员、文化和流程的交集。Right Hand经常会到处救火，修改解决方案，把执行任务委派给最合适的团队，然后继续跳到公司里的下一个困境中。这些角色的乐趣在于你只处理最重要的问题。比较悲惨的则是你永远处在从一个问题奔向下一个问题的过程中。 ## 哪一种适合你? 当你考虑这些原型中哪一个适合你的时候，你可以先扪心自问一下哪一种工作类型能让你充满动力，然后再考虑在你的公司中有哪些角色是可用的。 所有公司都需要能够担当Tech Lead角色的工程师，这是你最容易取得的Staff原型角色。强调个人Ownership而不是团队Ownership的公司通常会较早地解锁Solver角色；严格遵从“Sprint”或敏捷方法的公司往往较晚发展出Solver角色。在最近一批快速增长的技术公司中，架构师或Right Hand角色通常分别出现在达到一百或一千名工程师的组织中，在达到这个规模之前一般不会有这两种角色。拥有其他文化DNA的公司有的更早开发出这些角色，有的则完全没有。 要想在这些岗位上取得成功，就必须保持参与其中;了解什么样的工作能让你充满动力是很重要的。Tech Lead和架构师倾向于与相同的人在相同的问题上工作数年，形成紧密的团队意识和共同的目标。有时候，他们的工作重点是也是公司的高优先级任务，有时他们只是不知道在捣鼓啥以至于高管们甚至忘记了团队的存在。 Solver和Right Hand会在不同的领域来回切换，经常更多地与他们的同事互动交流。他们随时跟进管理层的高优先级事项，因而更有可能因为解决了领导层最紧迫的问题而获得领导认可。另一方面，虽然他们名义上是和其他人一起在一个团队中，但他们和团队的工作内容通常很少或没有交叉，他们的集体意识也很有限。 对于每一个原型，你会发现有人喜欢它并觉得它非常有成就感，也有人觉得工作令人绝望。虽然瞄准适合自己的原型很重要，但也要记住，在你30或40年的职业生涯中，你将有足够的时间去尝试每个原型。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://yucliu.gitbook.io/staff-engineer/gai-shu/staff-gong-cheng-shi-fen-lei.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.