新晋 CTO 的工作总结：我在第一年学到了 14 个经验教训

在现在的公司，我担任首席技术官（CTO）已经有一年有余。值此岁末之际，对我这一年的工作做简单总结。回顾这一年的历程，过程很艰难，收获也很大。有些时候，我会认为我不具有领导能力，应该回去做一个个人贡献者。但是，非常感谢公司对我的支持以及我个人的学习 (书籍、博客、观察)，我开始享受这个角色，并直面它带来的挑战。

在谈论我获得的经验教训之前，先回顾下我的软件工程师职业生涯。

• 2005——2008：软件工程师

• 2008——2012：高级软件工程师

• 2013——2014：首席技术专家

• 2014——2019：首席工程师 / 架构师（在此期间，我的角色是总监，但我仍然会花很多精力在代码编写、系统构建和技术咨询方面)

• 2020——至今：首席技术官（我的第一个领导 / 管理职位）

这是我第一次担任领导和管理职务。从个人贡献者到首席技术官的转变不仅意味着压力变大，责任也变大了。

这次转变带来机遇的同时，也让我面临很大挑战。尽管如此，我还是冒险开始，并摸着石头过河。

当知道我将成为下一任 CTO 时，我的第一个想法是找一份指导手册，看看 CTO 要做什么，以及怎么做才能成为一名优秀的、成功的 CTO。我想为这个角色做好准备，于是去研究了网络上我能找到的所有与 CTO 相关的文章。你猜怎么着？这种指导手册压根就不存在。

直到今日，我仍然只能在工作中学习并确保同样的错误不要犯第二次。

我想知道的第一件事是首席技术官（CTO）的定义是什么。显然，这是最难以说清的首席类角色之一，每个 CTO 扮演的角色都稍有不同。对这个角色最好的描述我是在马特·塔克（Matt Tucker）的一篇文章中看到的。根据 Matt 的说法，CTO 角色由五个特征组成。

马特·塔克的 CTO 框架表格

我认为上述框架为我们理解 CTO 角色提供了一个很好的思维模型。大多数情况下，CTO 是上述两种或两种以上特征的组合。

介绍一下我的 CTO 职责。Matt Tucker 框架描述的 CTO 是产品研发公司的 CTO。我是一家提供 IT 服务公司的 CTO，因为下面的一些原因，这类职位更加碎片化和更具挑战性：

• 在任何组织中，人都是重要的资产。对于提供 IT 服务的公司来说，业务增长率与人员数量成正比。但如果你想成为好的服务提供商，情况就有所不同了。

• 你必须让那些还没有准备好应对变化的大型企业能成功应用先进技术。在过去 5 年中，大多数组织都在进行数字化转型。以我的经验来看，现阶段的组织比以往任何时候都更愿意尝试新的技术（React、Golang、Flutter、Cloud、Kubernetes）和架构风格（微服务、事件驱动、无服务器）。这是一个好消息，但是，很少有组织能理解采用先进技术栈要付出的代价。他们想成为他们行业领域的 Google，但基础工作做得并不够。这个在我的文章《使用微服务会失败的 11 个原因》中有所提及。

• 在先进技术领域，真正有经验的优秀软件工程师并不多。好的软件工程师都很昂贵，而且他们更倾向于去产品研发公司。作为 IT 服务公司，很难给出产品研发公司相同的薪水。

介绍 IT 服务组织 CTO 的文章并不多，也没有明确谁是你遵循的榜样，下面我将在 Matt 框架的基础上，结合自身情况，给出我对 IT 服务组织 CTO 的理解。

这是我结合自身情况对 Matt 框架做的修改，并且对于去年我在各部分花费的时间给出粗略的估计 。

修改后的 CTO 框架

正如你在上述表格中看到的，我无处不在。幸运的是，我在不同任务间切换所消耗的精力较少，这主要是因为同一时间我参与的任务不会超过两个。

在我担任 CTO 的这一年时间中，我建立了一套任务授权体系架构。希望在第二年，我能更专注于做一些重要的事情。

到目前为止，我分享了我的职业经历和对 CTO 角色的理解。下面我将和你一起回顾下这一年中的经验教训。

很多软件工程师都梦想有一天能成为 CTO，这被很多人视为软件工程师职业生涯的顶点。但是，公司并不会仅仅因为你是最有能力的软件工程师 / 架构师，就任命你为 CTO。你需要自己去争取。

我花了 2-3 年的时间去为 CTO 这个职位做准备。让我一直有所顾虑的原因之一是彼得原理。

彼得原理是一种经验理论，即在各种组织中，如一个公司，由于习惯于对在某个等级上称职的人员进行晋升提拔 ，因而雇员总是趋向于被晋升到其不称职的地位。

我一直以丰富的软件开发和架构经验而自豪。担心自己有一天会跟不上技术发展的脚步，所以我一直向着技术专家的方向努力，而非向管理方向发展。

后来，我想通了，如果我不竞争这个职位，其他人就会。我的优势是对公司有足够多的了解，并且具有领导能力，所以为什么不试一下呢？对我来说，最困难繁荣是主动争取。可悲的是，如果你不主动争取，别人就不会给你。

我发现了一个规律，大多数人因为羞于开口而错失很多良机。一直以来，我从没有碰到过不愿帮助自己的人，只要我开口，基本上没有人会拒绝我。——史蒂夫·乔布斯

几周前，一位同事问我， 在参加这么多会议的情况下，你还能完成需要投入较多精力的工作吗？我发现，一旦人们发现我在会议时间段没有安排，他们就会让我参加会议。在 2020 年上半年期间，我一直在会议的泥潭中挣扎，一天中大部分时间都在开会。在这段时间里，大部分需要思考的工作我只能在下班或周末完成。

下半年，在意识到需要对时间有自己的规划后，我改变了工作方式。现在，我每天会抽出几小时，甚至半天时间，专注于一些需要全身心投入的工作。这样，我就能够在制造者日程表（maker schedule）和管理者日程表（manager schedule）之间自如地切换。

另一方面，我也避免成为日程表的奴隶。我采用的方法是，和会议组织者确认是否有必要参加。其他情况下，如果有我团队的人已经参加会议，我就不参加了。

大多数新晋的管理者都会面临这个挑战。你知道这个任务自己可以做得又快又好，所以倾向于自己完成任务。但是这无法发挥团队的力量，你很快就会成为团队的瓶颈。

发挥团队力量的最好方式是充分授权。包含两个方面：授权什么和授权到什么地步。

确定哪些任务需要授权，珍妮·布莱克（Jenny Blake）将任务分为 6 类，她称之为 6T。

• 琐碎任务（Tiny）：非常小的任务，看起来不重要，但会慢慢累积。

• 无聊的任务（Tedious）：相对简单的任务，利用琐碎时间完成。

• 耗时的工作（Time-consuming）：虽然这些任务可能很重要、有点复杂、需要花费时间，但最初的 80% 的研究工作并不需要你做。

• 可指导的任务（Teachable）：乍一看很复杂，但可以被分成几个子任务的任务。这类任务可以分配后交给团队成员去做，你只要做好质量检查和最终裁判即可。

• 不擅长的工作（Terrible At）：不仅不是你的强项，而且也是你不想干的。

• 有期限的工作（Time-Sensitive）：当你手头有其他任务，而且没法在截止日期完成所有的任务，你需要把某些重要且有明确时间要求的任务分派出去，从而保证所有任务能在截止时间内完成。

像组织内部技术会议、办公网络环境的维护、代码审查、招聘初级工程师等任务，我都分派给其他人去做。

当你清楚了哪些任务需要分配后，接下来需要考虑的是分配级别。你需要明白按什么级别分配任务以保证任务能 100% 完成 。

我在网站“管理 30“中学到了 7 层分配级别。

• 告诉（Tell）：分配任务，并告诉下属一步步怎么做

• 转交（Sell）：我先做一部分，再移交给他们

• 顾问（Consult）：我作为顾问，并做出决策

• 协商（Agree）：我们一起做出决策

• 建议（Advise）：我给出建议，他们来决策

• 询问（Inquire）：他们决策后我询问结果

• 分派（Delegate）：只分配任务

到最后，你需要使用足够的管理手段来确保事情按计划进行。

不管你喜不喜欢，每个组织都会有混乱发生。混乱可能是软件交付出错、导致客户系统挂了的要命 bug、系统性能问题或者和人相关的问题。当你作为领导参加这样的会议时，人们期望在会议结束时，事情变得清晰，团队有一个可执行的计划。

作为领导者，你的工作就是减少混乱，让事情变得清晰。下面是我经常使用的减少混乱的操作步骤：

• 通过问问题来让事情变得清晰。这样可以去除不重要的信息直达问题的核心。作为领导者，你的目标是引导人们思考。所以，你需要问一些深刻而宽泛的问题，如你为什么选择这种设计？这个度量指标能告诉我们什么？现在用户在想什么？

• 创建一个小的、清晰的 todo 清单。例如，这是一个修复性能问题的 todo 清单：

  • 观察 APM 工具中的性能指标，找到问题原因

  • 在模拟环境重现问题

  • 看看需要性能调优的单元是否存在对应的测试，如果没有，就编写测试

  • 修正问题并保证单元测试通过

  • 部署到更底层的环境并观察补丁的效果

  • 发布到生产环境

  • 观察 APM 性能指标确认问题已解决

• 将任务分配给负责人

• 在 Wiki 上做记录

我发现另一件有趣的事情是，许多人无法靠抽象概念来开展工作。一旦有人在任务上开了个头，很多人就知道该怎么做了，你需要将事情分解成可操作的具体步骤。这意味着在你将任务移交给其他人前，你需要进行大量的思考。作为一名领导者，随着时间的推移，你会明白不同类型的任务，在开始之前需要思考到什么程度。

作为一个领导者，你不应该感情用事。我同意领导者在 90% 的情况下都不应该。但是，有些时候你需要表现出你对事情的不满。你不满的警戒值应该很高，不应该经常达到。如果有人把事情搞砸了，你必须做出反应。

举个例子，有一次，一位高级开发人员（接近 10 年的开发经验）在团队群里发了一条消息，说他们从昨天就被卡住了，一个 REST API java 客户端不能调用，但 Postman（一个 API 调试程序）可以。这个问题很奇怪，所以我和团队成员一起开会来研究这个问题。这位开发人员先是展示了 Postman 的调用情况，然后是 Java 代码。最终找到的原因是 JSON 格式的请求参数中有一个应该是 username，但 java 程序传递的是 userId，在 Postman 中传的是 username，所以可以工作。

我知道这件事微不足道，很多开发人员可能会犯同样的错误。但令我失望的原因是：如果 Postman 可以工作，而你的代码不能，你不应该在不检查代码的情况下就认定 API 有问题。你不能在一天什么也没干的情况下，在第二天的站会（standup）上告诉客户其他人写的 API 有问题，客户可没那么宽容。有一些自动生成 REST 客户端的工具（如 Insomnia）可以帮你验证假设。

我这里提到的表现出不满并不是要责骂某人。只是意味着你需要表明期望，让他们知道你希望他们把事情弄清楚。同时，教他们调试这类问题的方法。

同样的，也有其他情况下，你需要表现出不满，但正如我所说，你的警戒线应该更高，这样的情况不应该经常发生。

经常听到有人说应该从自己的失败中吸取教训。

如果你善于观察，就能从别人的失败中学习，从而减少自己的失败。换句话说，你可以从别人身上学到经验教训。这是非常有用的技能，而且它能帮你更快地达到目标。

但是，它要求你仔细地观察其他人，了解他们的特点和他们失败的背景。一旦你了解了这些人，知道了他们失败的原因，你就能够避免犯同样的错误。在组织中，多个领导都试图做出同样的改变，这很常见。理解前任领导为什么失败，可以帮助现任领导更容易实现成功。

我给自己施加了很大压力，为所有问题都提供答案。我调试错误，考虑问题的解决方案，并为别人做大量的研究工作。

我越努力解决问题，别人给我的问题就越多。我原以为人们会学着面对自己的问题。但是，人们更愿意从我这里得到完整的答案。

我意识到部分原因是我处理问题的方式有问题。我想成为一个无所不知的好领导。我们都知道这是不可能的，但当你成为一个领导者，就有这种成为英雄的倾向。所以，我改变了方法。我开始给人们一个谷歌文档模板，他们需要先填写，然后我才会与他们一起解决问题。这份文档需要他们写明 ：问题的定义、对问题的理解，做了哪些尝试以及哪些没有成功。

于是产生了三种结果：有一些问题，他们真的不能解决；我参与并给出建议，他们作为负责人解决问题；一些问题没有回音了（我认为他们写文档的过程中，把问题解决了）。

作为领导者，你的工作不是为人们寻找答案，而是帮助他们找到答案。说我不知道，让别人承担责任，是成熟领导的标志。

在过去几年中，我雇佣了很多有潜力的工程师。我和他们结对编程，指导他们，给他们机会。但是，他们后来离职了。对很多优秀的工程师来说，产品研发公司才是他们梦想的工作。这很无奈，但却是事实。

有时候，我甚至认为一个好的 IT 服务机构，其工作之一就是为产品研发公司培养工程师。

我认为以下是工程师想加入产品研发公司的原因：

• 他们希望有一天能创立自己的公司，而在产品研发公司工作能学到很多东西。

• 很少需要在不同的工程间切换。你可以在一个团队工作很多年。

• 你可以在某个领域持续钻研。

• 产品研发公司比 IT 服务组织工资高。

到目前为止，在我的职业生涯中，我主要是在 IT 服务机构工作。我认为在 IT 服务机构工作有一个好处是：

您可以在很短的时间内在多种技术和多个领域间都有所涉猎。我开发过 DevOps 工具、实时定价引擎、多租户 SaaS 应用系统、社交平台、帮助银行进行数字化转型（架构、DevOps 实践）等等。

如果你在网上读到讨论技术经理或者 CTO 是否应该编程的问题，你会发现很多人都反对编程。反对编程的两个理由是：

• 你有很多更重要的事情，而编程并不在其中。你可能不能及时完成任务，而这会拖累你的团队。

• 屈服于“对编程的爱”的危险在于，在追逐“令人惊叹”技术的欲望之下，会渐渐遗忘你的业务目标。

在我担任 CTO 的第一年中，我与交付团队一起工作，交付代码。这是在三个重要项目中我做的工作：

• 向交付团队明确我不是任务的负责人。如果我的时间允许，我会交付代码，但他们不能指望每次我都能按时完成。这意味着除我之外，每个项目都应该有一个技术负责人。

• 以防我没空，我总是和一个能推进任务的团队成员结对编程。

• 通过审查代码和工程设计文档而不是编写代码来贡献价值

• 优先为被困的人排忧解难。

我喜欢编程。为了编程技能不至于荒废，下班后我会参与项目。

很多客户希望他们的供应商能够提供：

1. 一个高质量的产品

2. 敏捷需求管理

3. 在约定的时间和费用内完成交付

我们都知道，构建满足这三个条件的产品是很困难的。

在这些条件中，当团队面临时间和成本压力时，质量是首先被牺牲的。质量需要花费时间和金钱，与功能相比，它的优先级并不高。

客户以为软件是以工厂模式交付的，在这种模式下，团队人数越多，功能开发越快。根据我的经验，按照工厂模式交付软件是有问题的，你并不能使用这个模式构建好的产品。

在我担任首席技术官的第一年里，这种情况发生过很多次，如果你和某人工作关系很好，他就希望你能向着他说话。

我意识到，职位越高就越孤独。在人际关系和工作关系间保持平衡是很困难的。当你和一个人关系好时，你很难在不伤害他的情况下质疑他。

我意识到只有少数问题是值得我解决的。去解决所有的问题，这只是你的美好愿望。我在卡米尔·弗尔涅（Camille Fournier）的文章中发现了这个流程图，它提供了一个很好的框架来帮助你选择要参加哪一场战斗。

这是作为领导者应该牢记的重要教训。你不应该成为系统中的瓶颈。有两种情况，你会成为瓶颈：

1. 停下系统并试图一次性修复它。这行不通。最终你会把自己压得喘不过气来，并且反对的声音会越来越多。你必须以一种小确幸的方式来做——朝着你的最终目标，每次只做一小步。你甚至不需要告诉别人你的最终目标。保持小的战术改变，并牢记大的战略目标。

2. 不要太快做出决定。如果你还没习惯做出的决定会影响到其他人，当你处于这种情况下，你会感到压力和不知所措。很多人都希望把决定推出去而自己一点都不要碰。作为领导者，你必须明白不是所有的决定都是一样的，不做决定也是一种决定。我喜欢杰夫·贝佐斯 (Jeff Bezos)，他是亚马逊决策心理模型 (mental model on decision making) 的创立者。他说，你应该问问自己，这个决定是可逆的还是不可逆的。

有些决定是顺序的、不可逆转的或几乎不可逆转的——这是一扇单向的门——这些决定你必须有条理、仔细思考后、缓慢地做出，并经过大量的审议和协商。

如果你推开门走出去，不喜欢你在另一边看到的风景，却无法回到原来的地方。我们称之为第一类决策。但很多决定不是这样的——它们是可变的、可逆的——它们是双向的门，这是第二类决策。

对于第二类决策，如果你的决定不是最好的，你不需要承受太长时间的后果。你可以再次打开门，重新再来。第二类决策应该由高判断力的个人或小团体迅速做出。

事实证明，我们做出的大多数决定都是可以逆转的。这样我们就能快速地做出决定，推动事物向前发展。

不要让别人强迫你做你不认同的决定。他们之后可能会追究你的责任，并且他们的做法是对的。做出决定需要承担责任。

编辑：场长