资深工程师之路（一）
之前的专栏文章都是偏技术介绍方向的，比如之前的《算法工程师技术路线图》，受到了不少同学的关注。不过作为工程师的职业发展，显然不仅仅是只有技术的部分，尤其是发展到工作五年后逐渐成为资深工程师后，会碰到进一步职业晋升的路线选择问题。在 management track 方向，我们有很多极其优秀的管理方面的著作可以参考学习，也有一些针对技术管理的书例如《知行》也是相当上乘。但对于另一个 technical track 的方向，却很少能找到相应的参考资料来学习。个人在平时工作中也花了一些时间对这方面做了一些思考，所以接下来打算挖一个新坑，跟大家聊聊这些偏“务虚”的思考，欢迎大家来一起交流探讨。
开篇故事
最近有一个比较火的新闻，说的是著名的 Infra 软件公司 Hashicorp 的创始人和 CTO Hashimoto，在推特和 公司博客 上宣布他将退出公司的 executive 团队，不再担任 CTO，而转成一名全职的 Individual Contributor（下文简称 IC）。你或许没有听过 Hashicorp，不过你一定用过他们开发的软件，比如 Vagrant，Consul，Terraform 等……这些耳熟能详的软件都是由两位创始人主导开发的。Hashimoto 在 2012 年创办公司后，先后担任过公司的 CEO 和 CTO，而现在，他终于决定卸任 CTO，回归自己最为热爱的产品和软件开发工作。
从这个故事中，我们可以发现几个有启发的点：
- 如何选择你想要从事的方向？最重要的永远是跟随你的激情和兴趣，找到那些能带给你无比的成就感，让你找到生活的非凡意义，能真正驱动你每天早上起来充满能量投入的事情中去。这跟 乔布斯当年演讲 中的建议也非常类似，keep looking，don't settle。
- Management track 跟 technical track 并不是完全隔离的两条路。一位工程师完全可以在两条道路之间切换，而且后面我们还会讨论到，这两条道路在很多方面都是极其相似的，我们需要从两方都吸取有用的知识，才能走得更远。
- Management 并不是天然就高出一等的工作，更多是职责分工的不同。尤其在国内会有很多根深蒂固的思想，感觉做管理就等同于升职。我觉得大家需要更理性的来看待和分析这两条路线。
职业发展路线
接下来我们先简单介绍一下 management track 和 technical track 的内容。
Management Track
从 title 上来看，management track 一般是 manager -> director -> VP -> CXO 的晋级序列，大家应该都比较熟悉了。从人类社会诞生之日开始，管理就以各种形式渗入到社会的运作中。对于企业组织的管理，从工业时代开始就受到了极大的关注，并形成了专门的研究学科。快进到现代化时代知识工作者的出现，对传统体力工作者的管理方法提出了更多的挑战。而技术型科技公司，是当前知识型工作者密集型组织的典型代表，因此也出现了非常多的专著来讨论“技术管理者”相关的话题。德鲁克在他著名的《卓有成效的管理者》一书中甚至对管理者做了更宽泛的定义：
在一个现代组织里，如果一位知识工作者能够凭借其职位和知识，对该组织负有贡献的责任，因而能实质地影响该组织的经营能力及达成的成果，那么他就是一位管理者。
看这个描述，是不是觉得资深工程师天然就是一名“管理者”？后续我们也会多次来印证这两个 track 有所融合的部分。
不过话说回来，只要我们仍然需要人来运作组织，沟通协作，执行任务，那么对于“人”的管理，仍然是一个极其重要的话题。在我的理解中，management track 跟 technical track 中最大的侧重点的不同，就在于经理们一般会更关注人相关的问题，而资深工程师在这方面的要求会相对较低。
Technical Track
Technical track 的 title 名称可能在不同公司会比较多变，比较常见的是 senior -> staff -> principal -> distinguished -> fellow。对于每个技术职级所需要达到的要求，各个公司都会进行详细的定义。一般会包括技术，执行（拿结果），沟通协作，影响力和领导力等几个方面。不过今天我们暂时不涉及这块的细节，或许在后续讲晋升这块时再详聊。
一般以工程师身份加入到一家公司后，在 senior 到 staff 这个阶段（对应国内可能是阿里的 P7~P8），会出现第一次选择发展 track 的机会，也就是人们常说的“要不要转管理”。这里很多个人，组织都会有些纠结，出现各种踩坑现象，例如迫使让技术最强的工程师去当 manager 之类。我觉得这里有个比较大的问题是很多人其实并不了解从 staff 级别开始，资深工程师所做的工作到底是什么样子的，跟经理路线有什么区别？所以我们这个系列文章主要的思考内容会关注于在 staff 级别之上所面临的具体问题和挑战。
资深工程师的类型
从毕业进入职场成为一名工程师开始，我们平时主要的工作职责还是比较明确的，高效高质的完成各种开发任务，把软件交付上线，并持续维护和迭代。大多数人都会逐渐在这个时期积累更多的技术知识，不断提升技能熟练度，当你已经能达到 senior 工程师的平均水平，独立负责一些较为复杂的开发设计任务时，一般就能很自然的晋升到 senior engineer。截止到这里，我们的职业发展路线还是相当清晰的，大部分的精力只需要投入在技术导向的工作上就可以。在很多成熟公司，也是允许员工在整个职业生涯都停留在 senior level，贡献自己的开发成果即可。
但当你想要往下一个 level 晋级时，把代码写的更快更好，debug 更强，可能就不一定够用了。这一节我们先来看看 staff 级别以上的工程师有哪几种典型类型，一般会具体做一些什么样的工作。
技术主管
这个类型的资深工程师是最常见的一类，在作为有经验的开发者基础上，需要进一步负责一个小组的技术路线和执行。例如与产品和其它研发团队的沟通协作，方向探讨，拆解复杂项目的 timeline 和需要达成的 milestone，设定团队的工作规范和流程，参与各类评审/复盘会议，mentor 新人解答问题等。有一个很形象的比喻就是会有很多 glue work（打杂），技术主管的目标不再是个人具体的代码贡献量，而是要帮助整个团队来更高效的工作和产出，以实现组织目标的最终达成。
看到这里你可能会觉得，这不就是技术经理吗？的确，在很多 10 人以内的小团队中，这两个角色很可能就是同一个人。但当团队规模大了之后，一个人就很难做到比较好的兼顾，会出现经理和技术主管的双核组合。对于经理来说，会有更多人事管理上的侧重，例如定期的 one on one 会议与激励反馈，团队结构和人才资源的规划，招聘，绩效考评，职业发展规划，培训等等。而对技术主管来说，更大的团队一般也会在技术领域会有更大的复杂性和挑战，在经理的帮助下可以花更多的时间在技术方面的思考上，例如技术债管理，创新方向探索，架构规划，工程师文化建设，领域知识的增强等。
技术专家
这类资深工程师是技术深度优先路线的典型，他们一般会在某个领域达到非常精深的掌握程度，帮助公司解决关键的技术难点问题。举个例子比如微软的 tech fellow，C#之父 Hejlsberg 就是一位典型的此类 IC。凭借他在编程语言领域的世界级大师能力，帮助微软在 dotnet 和 TypeScript 等开发者生态都取得了巨大的成功。另外像阿里的多隆也有些类似，与之不同的是多隆解决问题的方向会更多样一些。但他们都是能够为公司的战略规划执行进行前沿探索和扫清技术路障的“扫地僧”，其 impact 也是显而易见的。
咋一看感觉这个类型的资深工程师就是 senior level 的自然延伸嘛，是不是埋头做技术就可以了？曾经我也有类似的想法，但后来发现想要成长为大师，想要以大师的能力来创造足够的影响力，沟通等方面的软技能仍然是必不可少的。你需要与公司的管理层或其它部门密切的沟通，才能明确我们共同的目标方向是什么，闭门造车的技术是没有用的。你也要和整个研发组织进行沟通，让大家在一些大的技术方向，技术架构上达成共识，才能真正推动落地，光靠一个人就能写出来的项目，很可能只是个 toy project。你还需要跟类似方向的技术同僚持续交流，吸取行业的先进经验知识，并输出你的思考和实践，才能树立起足够的行业影响力，推动行业的进步。这里有另一个例子就是算法领域的李飞飞，她主导构建的 ImageNet 并不是在技术上多么复杂的一件事，但她提出了正确的问题，进行了良好的执行，并推广影响了整个社区。
架构师
这类角色与技术专家有些类似，不同的是架构师是技术广度优先的方向。他们或许没有技术专家在某个领域做到那么深入的了解，但会对公司某个方向的技术栈，架构设计，业界的整体趋势有更广泛的了解。而与技术主管的不同之处在于他们一般不会附属于某个具体的小组，而是跨越更多的组，持续投入在公司战略路径中较为关键的技术创新焦点上，负责各种架构的设计，推广与执行。
这里自然要给我司的首席架构师宝哥打个广告了。宝哥就是持续在数据分析，云原生，分布式系统等方向深耕与开拓，为我司设计和打造了一系列行业领先的系统架构，支撑我们服务了数百家客户超大规模的数据分析与智能决策业务应用，对于公司整体的战略方向也起到了很大的影响作用。宝哥也经常在他的公众号上分享一些他的技术思考，感兴趣的同学可以搜索关注“架构 587”，一键三连一下 :)
技术顾问
最后一个类型是技术顾问，一般只有在比较大型的公司才会有。常见的形式是会有一个类似 CTO Office 的组织，其中就会有一些资深工程师担任技术顾问。他们一般没有直接的管理方面的职责，主要是给 CTO，技术 VP 的决策提供一些技术视角的信息输入，同时在执行过程中，也会帮助这些技术高管扩大感知范围，例如参与各种业务，技术，管理，流程，企业文化等相关的会议或协同过程，确保整体执行的上下一致，以公司高层的视角和思路来帮助一些决策的发生。
这种类型的角色我个人也了解的不多，也就不展开讨论了。值得注意的是这里提到的公司上下战略思考方面的 alignment 在前面几个类型的介绍中也有反复提到，也是资深工程师在思想上非常需要重视的一点。后续我们或许也会单独写一篇来进行讨论。
小结
总体来看，资深工程师相比初级工程师，会需要很多思维方式的转变。例如从个人的执行落地，转向关注整体组织的执行。从完全技术导向，转向客户视角，业务目标导向。所以他们具体的工作内容和形式跟之前相比会发生不小的变化。
资深工程师的很多思考和行动方式上，都会很接近经理路线。如果我们简单概括两者的职责内容为技术+业务(产品，项目等)+人(组织，协同，文化等)，那么资深工程师一般在前两者会有所侧重，而经理则会在后两者担起更多责任。
如何选择路线
看完这几种类型介绍，大家可能会想了解自己该选择哪一种作为努力的方向呢？
- 首要的原则还是开头提到的，哪种类型的工作最能够激发你，就应该是最优先考虑的方向。不过资深工程师有一个比较共通的特点是工作中的正反馈其实相对初级工程师来说会少得多，且反馈回路也会长得多。如果一直觉得能把代码提交就很爽，其实会有一直处在自己舒适区的问题。很多时候，挫折与挑战，和最后的成就感的回馈是相辅相成的，还是需要把自己的目标定的高一些，才能看到更广阔的世界，更壮丽的景观。
- 其次需要思考所在公司最需要什么类型的人才，做什么样的工作最能给公司带来提升。比如初创阶段的公司很可能不需要技术专家或技术顾问的角色。另外有一点，很多初级工程师会倾向于把个人成长跟公司成长分开来看，会觉得工作的内容好像没有给自己的能力带来什么提升。但是越资深的工程师，越应该意识到自身发展跟公司发展的绑定关系其实是很强的。只有通过实际检验，真正给客户带来价值的技术，才是你真正学会的最有价值的本领，也是你在这家公司最能获得成长的部分。
- 最后实在拿不定主意的话，其实也跟 management track 跟 technical track 的选择类似，你完全可以都尝试一下。一方面，大家的职业生涯长达 30-40 年，时间上绰绰有余，不用着急。另一方面，各种类型角色的技能点有很多也是共通的，比如前面提到的沟通能力。多尝试一下说不定还能互相汲取经验，帮助你更好的做其它类型的工作。
今天先聊到这里，感谢阅读！大家如果有什么想法和问题欢迎评论留言，一同探讨。如果有什么想要了解的话题也可以提出，可以作为我们后面几篇文章的内容储备 :)
