软体工程师的职涯路径概览

过去有不少读者提问一些职涯发展的问题，在跟读者们聊的过程中，发现有部分读者对于工程师的职涯发展路径有一些困惑。因此，希望透过这篇主题文，概览式地解说业界常见的工程师职涯发展路径。

特别注意，软体工程师的职涯，可以有很多发展方向，甚至可以不用局限在工程师这个职位，例如可以转去做产品经理 (PM)，或者技术专案经理 (TP)，甚至过去看过不少工程师转去行销或销售职位，也发展很好的案例。但本文会主要聚焦在，如果你决定要持续在工程师的职位上发展，可以有哪些不同的发展方向。

工程师的职涯框架

当谈到工程师的职涯框架，就不能不提 Dropbox 公开的《Dropbox Engineering Career Framework》。之所以这样说，是因为过去这类职涯框架，虽然在各大公司行之有年，但并没有在业界与社群中流传，而过去 Dropbox 公开后，才有了在社群中广泛流通的版本。

虽然在那之后，有许多公司也都公开自己的版本，但当大家谈到这类资源时，第一个会想到的还是 Dropbox 公开的。事实上，目前业界在这类职涯框架的订定上，有越来越收敛的趋势。换句话说，虽然每间公司的细节会不同，但是多半在概念上是互通的。

因此，本文所写的内容，虽然不必然会跟你待过的公司一模一样，但是从概念上来看，应该都会是通用的。

通则上来说，软体工程师的职涯，会是在成为资深工程师开始，会有一个分流。换句话说，在初阶 (junior) 与中阶 (mid-level) 的阶段，基本上都会是做为个人贡献者 (Individual Contributor，也就是大家很常会听到的 IC)，接下来我们会用工程师来指称这个路线。

所谓的工程师，是对比工程经理 (Engineering Manager) 这个路线；前者会专注在技术，后者则会是专注在人。工程师路线的顶点会是一间公司的技术长 (CTO)，而管人路线的顶点会是一间公司的工程副总 (VP of Engineering)。

你可能会问，技术长跟工程副总在做的事情，有什么差别呢? Meta 的工程副总 James Everingham 曾经写过一篇贴文分享两者的差异。

他提到当年在 Instagram 时，技术长负责技术愿景、技术发展路径、研究最新的技术、跑实验、与产品端共同制定计划；而他则是负责流程、绩效、职涯成长、招聘，以及确保团队有使用最佳实践。

技术长与工程副总彼此合作，但是当团队中的人遇到问题时，不同的问题需要找不同人。举例来说，如果是团队想要增加人手、团队成员间有冲突，会需要找工程副总；而如果要展开一个新项目需要人给架构面的输入、想要实验一个新技术需要回馈，则是要找技术长。

如果要对应职级，两者的路径分别会是有以下阶段

初阶工程师 (junior software engineer)
中阶工程师 (mid-level software engineer)
资深工程师 (senior software engineer) / 工程经理 (engineering manager)
主任工程师 (staff software engineer) / 资深工程经理 (senior engineering manager)
首席工程师 (principal software engineer) / 工程总监 (engineering director)
资深首席工程师 (senior principal software engineer) / 资深工程总监 (senior engineering director)
杰出工程师 (distinguished software engineer) / 工程副总 (VP of engineering)
技术长 (CTO) / 资深工程副总 (SVP of engineering)

备注：以上仅为概要式的以职级比对，不同公司可能会有不同的职级对照、职位称呼

不同的职级，有什么区别?

在大致了解工程师可以有什么样的职涯路径，以及工程师与工程经理的差异后，接着我们拉回从最初阶的工程师，一路到开始分流的资深工程师与工程经理，这些不同的职级，具体上有什么差别?

我们会从技术 (technical excellence)、方向 (direction)、团队 (team)、商业影响力 (business impact) 三个角度来切入。不同公司使用的词汇可能不一样，但从概念来看，影响能否往上走的，最主要为是这些因素 (当然，与公司文化的契合也是，但由于每间公司的文化不同，这边就不展开这面向)。

具体来说，这四个角度分别衡量以下的内容

技术：衡量你的系统设计、程式码品质、对团队与公司做出的技术面优化贡献等
方向：衡量你的策略思考、长期愿景能力。具体来说，会看你的目标设定能力、排定优先顺序的能力，例如你是否都做重要的事，而不是做很多但不重要的事
团队：衡量你对团队协作面的贡献，例如有没有协助指导他人、有没有在别人需要时跳出来帮忙、有没有促成团队正向的文化
商业影响力：衡量你的产出，对于团队与公司要达成的目标，带来多少贡献。如果是做产品开发，会看你的产出对于终端使用者的影响；如果是做基础设施，则会看你的产出帮助到其他工程师多少

初阶工程师

技术：能在资深工程师指导下，开发好被交派的功能，负责的范围会是在 2 周内能完成的。不会被预期要做复杂的系统设计，但会被预期写出高品质的程式码
方向：能在资深工程师的协助下，排定好优先顺序，且会专注在重要的事情上。
团队：会参与技术评审、程式码审查，，在最开始不会被预期能贡献太多，但随着加入团队的时间变多，也会被预期有所贡献。此外，会被预期能协助新加入的实习生
商业影响力：能贡献到团队要完成的目标上

中阶工程师

技术：能在没有资深工程师的协助下，独立完成开发，负责的范围会是一季 (3 个月) 内能完成的。会被预期做有一定复杂度的系统设计，程式码面不仅要维持高品质，还会被预期主动改进程式码库、帮忙做程式码审查 (code review)
方向：拆解被分派到的专案，成多个子任务，并设定合理的时程，并时时与利害关系人更新进度，确保专案能被顺利完成。
团队：协助指导团队中的初阶工程师，且开始能有跨部门 (cross-functional，俗称 XFN) 的协作
商业影响力：具备产品思维，知道什么对终端使用者好，且会主动去追相对应的指标，确保开发出的成果对指标有所贡献。当成果不如预期时，也会主动去追原因出在哪，并提出改善的方案

资深工程师

技术：在系统设计与程式码品质，都能达到带领团队的层级，举例来说，如果只是自己重构和清理程式码，是属于中阶工程师的等级。而资深的等级则是需要，更进一步带领团队来共同优化程式码。负责的专案是以半年度 (6 个月) 为单位的大型专案，且会是当别人有技术相关问题时，第一个会找的人。
方向：设定团队等级的技术方向，甚至开始做到跨团队层级的方向设定。能够辨别做什么东西有影响力，并带领团队往该方向前进。与中阶工程师的差异在于主动性，中阶工程师仍属于被分配专案，但资深工程师则需要进一步推动团队规划，并建立多个中到大型功能的专案路径图
团队：有效与工程经理协作，让工程经理知道什么重要，以帮忙争取资源。同时协助指导团队的初阶、中阶工程师在技术面的成长，例如透过技术评审、程式码审查的回馈来协助其他工程师成长
商业影响力：总是会把终端使用者需求放在脑中，能带着产品思维，来确保技术决策有对终端使用者的影响力。当没能达成预期指标，能迅速辨别原因，并带领团队一同改善

从上面的描述可以看出

初阶工程师是在有他人协助下能顺利完成任务
中阶工程师是可以独立完成被交付的任务
资深工程师则是不仅能完成，还能协助团队中的其他人把任务做更好

工程经理

技术：在技术设计上给予回馈，确保团队能有高品质的技术设计，确保该考量到的面向都没有遗漏；同时，能预判技术设计有的潜在风险，并确保团队有相对应的解决方案
方向：能够发掘机会点，并帮助团队争取到更大范畴的专案，且能确保团队不受琐事分心，能专注在最重要的事情上
团队：能独立带领一个团队，打造健康的团队文化、高效率的协作流程，同时协助个别团队成员发展出理想的职涯。能预判团队的需求，提前完成调度支援、跨团队协调、招募人力等事项
商业影响力：清楚知晓公司层级的目标，并确保团队顺利交付成果，同时确保所交付的成果，能够达到预期的商业成果

如上面提到，在资深工程师与工程经理后，还有能继续往上走的职级，但本文暂时不展开，有兴趣的人，推荐可以看文末的各公司的框架，来进一步了解再往上的职级，具体有什么差别。