走技术路线需要些什么？

荐语

本文要介绍的是O’Reilly在2022年出版的书籍，《The Staff Engineer’s Path》。

书中主要介绍走技术路线的工程师，或者说技术专家（Staff Engineer），需要具备哪些能力他们不仅仅要会写代码、做系统设计这么简单，技术能力只是基础，还要具备大局观、执行力和影响力。

如果你想走技术路线，那么本书值得一读。

前言

程序员的发展，总会遇到一个分叉路口，走技术路线，或者管理路线。

程序员总有股技术情怀，相信很多人最初都有坚定走技术路线的想法，但走着走着，最后都走上管理路线。

一方面，管理路线是清晰的，且有着大量成功的案例。对于沟通能力强、临危不乱、善于帮助周边同事成长的人来说，似乎成为管理者是一个常见，也是默认的职业发展规划。

另一方面，走技术路线，在很多人的理解里，就是不断提升技术能力。但是，这样走了一段路后，很可能就会遇到了向上发展的瓶颈，而转向管理路线。于是就有了所谓“不能一直搞技术”的结论。

然而，走技术路线遇到发展瓶颈的原因，并非是“不能一直搞技术”，而是“不能只搞技术！”

要走好技术路线，成为一名技术专家，拥有扎实的技术功底只是基础。除此之外，还需要具备全面的大局观、强大的执行力、良好的影响力三大能力支柱。

下面，我们将从技术专家的角色定位讲起，随后介绍这三大能力支柱，让你对“技术路线”有更深刻的理解。

技术专家是个什么角色？

提到技术专家的角色定位，我们可能首先会想到“关键方案设计和开发”、“疑难问题解决”、“技术决策”，但还不止这些。

不是Manager，但也是个Leader

首先，技术专家也是一个Leader。

在技术路线上，深入技术领域只能让你走到高级工程师这一步，要想成为技术专家，主导更大的项目，你需要与更多的人沟通协作、说服他们接受你的方案、成为他们的榜样。

所以，技术专家不可避免地要成为一个Leader。

与Manager不同，技术专家通常没有直接下属，不负责人员管理，但他们同样需要在技术决策、设计和代码review等方面表现出领导力。

是个技术牛人

技术专家是一个高度专业化的角色。

你提出的设计和代码review意见，要有指导意义，能够让产品的代码和架构变得更好；做技术决策时，要理解各类因素的权衡，必要时能够深入代码细节，提出正确的问题。

所以，技术专家必须要有扎实的技术基础。

但这并不意味着技术专家要写大量的代码。为了高效地解决问题，很多时候，他们负责方案设计、指导中高级工程师完成编码，可能更有意义，这也是给其他人更多的成长机会。

牢记一点，技术专家最重要的是解决问题，而不是如何解决，代码、文档，都是一种方式。

了解了技术专家的角色定位，接下来本文将介绍技术专家所需要的，除技术基础之外的，三大能力支柱：大局观、执行力、影响力。

大局观

一个不断发展的组织，总会进行各种各样的决策：选择什么技术、打造什么产品、继续投资或者否决它。一个好的决策需要有详细、准确、全局的上下文知识来支撑。

一名技术专家很可能只是负责组织下某个产品或特性的技术方案，因此，很容易陷入局部最优的困境。

为保证能做出前瞻性的决策，技术专家需要成为一个纵观全局的人。而建立下面的这三张地图，也许能够帮你构筑大局观。

定位图（Locator Map）：广阔的视角

要避免局部最大化，需要建立一张定位图（Locator Map）以获得更广阔的视角：

• 认清组织目标，找到真正重要的是什么。程序员很容易陷入唯技术论，技术专家要避免这一点。技术只是达成目标的手段，最重要的是搞清楚目标，是组织的目标，不是某个特性或小团队的目标。
• 理解客户的真正痛点。产品是为用户服务的，就算你的产品能够提升XX百倍性能，没有用户用，一样是没有价值。
• 了解领域行业动态。你正在解决的问题，很可能业界已经有人解决过。时刻了解你所在行业的动态，才能更高效地解决问题，更好地实现创新。

地形图（Topographical Map）：正确的导航

即使你有很强的技术能力，也可能会遇到好想法得不到重视、风险/困难无法提前识别、项目进展难以推动的情况。这时，你需要建立一张地形图（Topographical Map），帮助你实现技术落地、项目成功：

• 理清组织结构，建立良好关系。了解你所在组织的结构，理清每个子团队所负责的业务以及关键角色，并于他们建立良好的关系。没错，技术专家也需要懂得“搞政治”，这样才能更好地开展工作。
• 了解组织文化。你的组织是倡导口头汇报还是书面汇报？鼓励快速试错还是深思熟虑后的变革？了解并融入你所在组织的文化，金子才能更好地发光。
• 保持地形图更新。为了更好地支撑商业成功，组织结构和人员的变化很正常，时刻更新你的地形图。

藏宝图（Treasure Map）：长远的目标

最后，你需要一张藏宝图（Treasure Map），找到自己的长远目标（通常是组织目标或者能够支撑组织目标的达成），并为之奋斗。

人们很容易过度关注短期目标，比如，当前版本发布的功能、某个用户对产品的差评等。寻求短期成功可能会限制你的发展。

要从更宏观的角度思考：

你想要达到什么目标？

你为什么要做这些事情？

这些事情能支撑你的目标达成吗？

本周的工作是否偏离了你的目标？

你是否还在不断接近你的目标？

执行力

技术专家需要很强的自驱力，要学会自己给自己安排任务，主动、提前为组织出谋划策，而不是等待被安排。

所以，技术专家通常会参与多个项目，处理很多事情。但人的精力总是有限的，学会时间和价值管理很重要。

可以尝试按照以下几个维度，为你所参与的项目/事宜进行打分，在有限的时间内完成最有价值的事情：

• 能量（Energy）：这件事情将会耗费你多大的精力。
• 生活质量（Quantity of Life）：如果你的工作恰好是你的兴趣，那么你每天的生活质量将会非常的高。但这种机会是可遇不可求的，很多时候工作会降低你的幸福感。
• 信誉（Credibility）：信誉是领导力的一种体现，主导重要的项目、解决关键的难题，都能帮你提升在组织里的信誉。
• 社交资本（Social capital）：花时间与他人相处、与他们一起工作，建立良好的社交关系，互为战友。
• 技能（Skills）：技能是一种需要反复练习才能长久拥有的东西，你的工作内容一定程度上决定了你拥有哪些技能。

如何进行事情的优先级排序，一方面是要契合组织的目标，另一方面，也是你自己的职业规划。

项目难免会遇到一些阻塞点，技术专家拥有强大的执行力的另一个重要体现是，能够及时推动项目关键问题的解决。

首先要搞清楚阻塞点是什么（理解和解释），然后是做一些力所能及的事情（让事件变得更容易），再不行就上升求助（获得组织支持），行不通就换个方向（指定替代计划）。

举个例子，假如项目正阻塞在另一个团队迟迟未能交付某个特性上，那么，你可以尝试按以下几个步骤去推动：

1. 理解和解释。首先要沟通，弄清楚实际情况，他们是否不理解原始需求？或者有其他事情阻碍了他们？再次向他们解释项目的重要性，并澄清需求和交付时间。
2. 让事情变得更容易。如果是他们忙不过来了，能否进行需求裁剪？或者考虑帮他们解决某些关键难题？
3. 获得组织支持。上升求助组织的领导，让具备更大全局观的领导完成优先级的排序。
4. 制定替代计划。如果真的交不出来，能否有其他方法绕过这个特性？

总之，推动问题解决不仅是Manager的责任，技术专家也要为达成目标而“不择手段”。

影响力

技术专家除了做好本职工作外，还要不断构筑自己的影响力，可以分成两个维度，自我提升和扩大影响范围。

在自我提升方面，要做好以下几点：

• 保持学习。快速构建并持续丰富你所在领域的知识体系，然后通过项目实践，在解决问题过程中去学习和巩固。
• 认识自己。对自己的能力有一个深刻的认知，知道自己能做什么、能做到什么程度、需要多长时间、哪些是不擅长的。只有这样，才能不断发展自己的长处，修复短板。
• 严于律己。敢于承认自己的不足和错误，可以多发表观点，寻求建设性的批评建议。

在扩大影响范围上，要做好以下几点：

• 敢于担责。要敢于成为项目的第一负责人，解决项目的关键阻塞问题，成为一个可靠的人。
• 培养团队。你可能是解决问题最快的人，但不一定是最合适的人，多留些机会给中级/高级工程师，给他们足够的试错空间。
• 分享经验。通过写作、演讲等形式分享你的经验和知识，必要时提供一对一的指导帮助。

《On Being A Senior Engineer》这篇文章里有一句话，

“作为一名工程师，其他人愿意与你合作的程度，直接反映了你的职业生涯的成功程度。”

努力成为一名每个人都想与你共事的技术专家吧！

最后

你可能已经发现，走技术路线也并不能一直安安静静地写代码、做系统设计。

它需要你去了解整个组织结构，与周边团队建立良好关系，建立起大局观；

它需要你具备强大的执行力，主动推动问题解决，为达成目标“不择手段”；

它需要你持续提升自我，扩大影响力范围；

读到这里，你还会走技术路线吗？

文章配图

可以在 用Keynote画出手绘风格的配图 中找到文章的绘图方法。

参考

[1] The Staff Engineer’s Path, Tanya Reilly

更多文章请关注微信公众号：元闰子的邀请