Staff工程师的四种原型
大多数职业阶梯为Staff工程师的工作内容定义了一个单一的，统一的期望值。有一个清晰明确的预期值对大家都是有好处的，但职业阶梯这个工具更适用于一群人，而不是具体的某一个人。这一点对于一些拥有同样名号但是工作内容截然不同的Staff工程师来说尤其如此。
我和越多的人谈论过员工以上的工程师在他们公司的角色，他们的经验就越集中在四种不同的模式上。大多数公司强调其中的一种或两种模式，而一种模式只存在于拥有数百或数千名工程师的公司。一些公司没有任何技术领导模式，而是把他们所有有经验的工程师都推向了工程管理。在文学作品中，重复出现的角色模式被称为原型，如“英雄”或“恶魔”，而"原型"这个术语有助于标记这些Staff-plus工程师的不同种类。
我所遇到的四种常见的Staff-plus角色原型是:
Tech Lead 指导特定团队的方法和执行。他们有时与某特定主管紧密合作，但有时他们与两个或三个主管在一个重点领域合作。一些公司也有Tech Lead经理的角色，这与Tech Lead原型类似，但处于工程经理的岗位路径上，职责中包括了人员管理。
架构师对关键业务的方向、质量和方法负责。ta们需要对技术瓶颈、用户需求和组织级别领导有深入了解。
Solver会深入研究任意复杂的问题，并找到合适的前进路径。有些人长期专注于某一特定领域。另一些则在组织领导的引导下从一个热点跳到另一个热点。
Right Hand延伸了高管的注意力，借用他们的范围和权力来运营特别复杂的组织。ta们为大型组织的领导者提供了额外的处理能力。
这种分类方式更侧重于实用性而不是完整性上。但到目前为止，我已经能够将与我交谈过的每个staff +工程师归入其中一个类别。当然我得承认，有些人比其他人更容易归类。
Tech Lead
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工程师不仅仅是一个工作角色，它是角色、行为、影响力以及组织对这些因素认可程度的交集。
架构师
架构师原型案例: Joy Ebertz, Katie Sylor-Miller, Keavy McMinn
在许多公司中，架构师这个头衔已经过时了，但是架构师这个角色仍然存在，并且是一个很好的Staff+的工作。架构师负责公司内特定技术领域的实现，例如公司的API设计、前端堆栈、存储策略或云基础设施。一个架构师若想在某个领域有所成就，这个领域必须足够难，而且对公司能否成功具有长期和核心的作用。
有一种错误的先入为主的印象是，架构师是自己一个人设计系统，然后把他们的设计传递给其他人来实现。这种情况在某些情况下确实会发生，但我采访过的架构师肯定会对这种刻板印象非常不满。有影响力的架构师致力于保持对业务需求、用户目标和相关技术局限的深刻理解。他们利用这种洞察力来识别和提倡在他们关注的领域内的有效方法，并通过展示稳定且良好的判断力而获得的组织内的威望。
架构师角色更有可能出现下面几种公司里：相对较大的公司；具有异常复杂或耦合的代码库的公司；以及在为满足产品市场需求，在一开始的Sprint冲刺开发中留下了太多技术债务，现在需要艰难地这些偿还技术债务的公司。一些公司要求架构师深入到代码库中，而另一些公司则明确要求架构师不能写代码:这两种模型都有适用的场景。
Solver
Solver原型案例: Bert Fan, Nelson Elhage
Solver是组织中值得信赖的代理人，他深入研究棘手的问题，不断尝试解决它们，直到它们被解决。这一角色的Staff被转移到领导层认定为关键的问题上，这些问题要么没有清晰的解决方案，要么在执行层面有很大的风险。
大多数Staff平时经常需要做很多组织协调工作，而Solver通常是在已经确定为组织内高优先级的问题上操作，因此相对而言不怎么需要去给组织结构做"按摩"。另一方面，一旦问题规模被控制住，他们通常就会停止自己的工作内容，这可能会给人一种"怎么变卦了!"的感觉，这就需要一种温和的方式来避免激怒遗留下来的团队，因为还需要他们维护“已解决的”问题。
Solver常见于那些将个人，而非团队视为Ownership基本单位的公司。在这样的公司中，很容易看到Solver取代了Tech Lead的地位。在传统的以管理Sprint为中心的公司，你不太可能遇到这种角色，除非这些公司变得相当大或年限足够长到产生各种特定的技术债务。
Right Hand
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年的职业生涯中，你将有足够的时间去尝试每个原型。
最后更新于
