导读：某IT服务公司CTO一年的经验教训，在这里分享给大家。祝各位开工大吉。

差不多，我担任现在公司的首席技术官 (CTO) 已经一年有余。

现在，我认为现在是回顾我担任 CTO 第一年经验教训的好时机。

这段旅程很是艰难，对我来说却是收获颇丰。在这个过程中，我甚至认为领导角色并不适合我，我应该重新成为一名个人贡献者。但是在我的公司和学习（书籍、博客和观察）的支持下，我开始享受这个角色和它带来的挑战。

在分享我学到的经验教训之前，让我们先回顾一下我的软件工程师之旅。  

我的软件工程之旅：

• 2005-2008：软件工程师

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

• 2013-2014：首席技术传播者

• 2014-2019：首席工程师/架构师（在此期间，我担任总监的角色，但我忙于编码、构建系统和技术咨询）

• 2020 年至今：首席技术官（我的第一个领导/管理角色）

是的，这是我的第一个领导和管理角色。从个人贡献者到 CTO 的飞跃既令人伤脑筋，又承担着雄心勃勃的责任。

当然，伴随着这个机会也有其优点和缺点。尽管如此，我还是冒险尝试了这一转变，没有任何先入为主的想法。  

CTO 角色的定义

当我被告知将成为下一任 CTO 时，我立即寻找一本手册来描述和提供最佳实践，并希望它指导我成为一名优秀、成功的 CTO 的规则。

我想为这个角色做好准备，并研究网络上提供的全部 CTO 文献。你猜怎么着？并没有这样的剧本。 

归根结底，最重要的是在工作中学习，不要重复犯同样的错误。 

我读到的第一件事是人们通常如何定义首席技术官的角色。显然，这是最令人困惑的 C 级角色之一，每个 CTO 扮演的角色都有些不同。

后来，我发现对这个角色最好的描述是马特·塔克的一篇文章。马特这样认为，为了更好地理解这个角色，你应该被分成以下五种风格。

我认为上述框架为如何思考 CTO 的角色提供了一个很好的思维模型。大多数情况下，它们带有两种或多种上述口味的组合。 

让我分享一下我作为首席技术官的角色经历。

在我看来，Matt Tucker 分享的框架（上图）是从产品型公司的角度出发的。

而我是一家 IT 服务企业的首席技术官，由于以下额外因素，这一角色被稀释、分散且充满挑战：

• 员工是任何组织中的重要资产

  但对于IT服务组织来说，增长与人员数量成正比。如果你想继续成为一个利基服务提供商，那么情况可能会有所不同。 

• 你必须让尚未准备好变革的大型企业能够使用现代技术。

  在过去 5 年左右的时间里，大多数组织都在推动数字化转型。根据我的经验，组织现在比以往任何时候都更加愿意尝试新技术（React、Golang、Flutter、云计算、Kubernetes）以及新架构风格（微服务、事件驱动、无服务器）。这是一个好消息，但很少有组织了解这些现代技术堆栈带来的复杂性。他们没有做好成为所在领域下一个谷歌所需的基础工作。 

• 市场上拥有这些现代技术实际经验的优秀软件工程师并不多。优秀的软件工程师价格昂贵，而且他们的财务和工作愿望与产品组织更加一致。对于IT服务组织来说，不可能按照产品组织的规模来付费。 

关于 IT 服务组织的技术负责人或CTO的文章并不多。目前还不清楚哪些人物应该成为我的榜样，我将采用 Matt 的框架，并将它为自己重新定义。

下面，你将看到 Matt 的框架，并根据我自己的角色风格进行了修改。我还粗略估计了去年我在每项活动上所花费的时间。 

第一年的经验教训

现在，我已经分享了我的旅程和 CTO 角色定义。接下来，我带大家回顾一下担任 CTO 第一年的经验教训。

第0课：你必须相信自己，并要求自己扮演好这个角色

大多数软件工程师都梦想有一天成为首席技术官，这是我们中的一些人定义成功的高级别职业。但是，不会仅仅因为你是组织中最有能力的软件工程师/架构师而让你担当 CTO。

你确实需要有强烈的饥饿感。 而我花了将近 3 年的时间才确定自己已经准备好成为一名 CTO。

我认为自己还没有准备好担任领导角色的原因之一是彼得·普林普（Peter Principle）。 

彼得原理观察：大多数组织等级制度（例如公司的等级制度）的趋势是，每个员工都通过晋升在等级制度中晋升，直到达到各自不称职的水平。

我意识到的一件事是，如果我不去扮演这个角色，其他人也会去做。既然我对这个组织了解得足够久了，而且我已经弄清楚了自己的领导风格，那么为什么不尝试一下呢。

对我来说最困难的部分是这个角色的要求。可悲的是，如果你不要求别人，他们就不会给你应得的回应。 

现在，我实际上总是发现一些非常真实的事情，那就是大多数人没有获得这些经历，因为他们从不询问。

当我向他们寻求帮助时，我从来没有发现任何人不想帮助我。

– 史蒂夫·乔布斯

第1课：安排属于自己的时间

几周前，一位同事问我，当你必须参加这么多会议时，你如何能够进行深入的工作？

我发现人们一旦在日历中找到空闲的会议空档就会把我加到会议中。

在2020 年上半年我一直在为此苦苦挣扎，一天的大部分时间我都在开会。这段时间我所做的大部分思考工作要么是下班后，要么是周末。

在意识到我需要安排自己的时间后，我在下半年改变了工作方式。现在，我每天都会给自己安排几个小时到半天的时间，做一项深度工作任务。这样我就能够在供应商、开发计划和管理计划之间进行有效协调。

另一种避免成为日历的奴隶的方法，是向组织者确保我参加会议是否至关重要，非我不可。有时在我的团队中有人已经参加时，我会拒绝会议。 

第2课：不做事就完成事情

这是大多数个人贡献者在担任管理/领导角色时面临的挑战。

你知道自己可以更好更快地完成任务，因此你更喜欢自己完成任务。但是这无法扩展，你自己很快就会成为瓶颈。

我打赌你已经知道答案了。 

扩展自己的最佳方法是通过授权。授权分为两部分：授权什么以及应用哪个授权级别。

都授权什么

在如何决定委派哪些任务中，Jenny Blake 将任务分为 6 个类别，她称之为 6 Ts。

• 细小：任务很小，看似微不足道，但相加起来却很重要

• 乏味：相对简单的任务，可能无法充分利用自己的时间

• 耗时：尽管任务可能很重要，甚至有些复杂，也很耗时并且不需要你完成最初 80% 的内容

• 可培训：任务虽然一开始看起来很复杂，并且可能包含几个较小的子任务，但是可以转化为系统并传递，而你仍然可以提供质量检查和最终的审批

• 糟糕的任务：这些任务不仅不属于你的强项，而且是你感觉能力不足的领域

• 时间敏感：对时间敏感但与其它优先事项竞争的任务。没有足够的时间一次完成所有这些任务，因此你委派了一项重要且时间敏感的任务，以便可以与其它基于项目的截止日期，要注意是并行完成。

例如，我已经将诸如组织内部技术讲座、运营内部基础设施、代码审查、初级工程师招聘等任务委托给团队中的其他同事。 

一旦你知道要委派哪些任务，您就必须使用能够更好地完成工作的委派级别。

一共有以下 7 个级别的授权：

1. 告诉：我会告诉他们 

2. 销售：我会尝试销售给他们 

3. 咨询：我会咨询然后决定 

4. 同意：我们将共同同意 

5. 建议：我会建议，但由他们决定 

6. 询问：他们决定后，我会再次询问 

7. 代表：我将完全委托

综上所述，你必须使用足够的管理精力来完成工作。

第3课：减少混乱

无论你喜欢与否，每个组织中都会发生混乱的情况。

混乱的情况可能是软件交付出错、导致客户系统瘫痪的严重事故、系统性能问题或任何与人相关的问题。当你作为领导者参加这样的会议时，人们期望在会议结束时，事情会更加清晰，并且会有一个团队可以遵循的彻底计划。 

作为领导者，你的工作是减少混乱并带来更多清晰度。我在这种情况下使用的示例手册如下：

• 通过提问来简化问题。这通常涉及深入问题的本质，并删除与之相关的所有不必要的信息。作为领导者，你的目标是让人们思考。因此，你必须提出深刻而广泛的问题，例如为什么选择这种设计？这个指标会告诉我们什么？你认为用户此时此刻在想什么？

• 创建一个包含明确操作的小待办事项列表。例如，对于性能修复，以下是待办事项列表示例：

• 观察 APM 工具中的性能指标以确保存在的问题

• 在较低级环境下重现该问题

• 如果不存在，请编写一个测试来了解我们必须进行性能调整的功能

• 修复问题以确保测试仍然运行

• 在较低环境中进行测试并查看性能修复的影响

• 部署到生产环境

• 观察 APM 工具指标以确保修复正确工作

• 将所有者分配给任务

• 知识库中的文档创建与更新

我观察到的另一个相关的事情是，许多人无法处理抽象的想法。我在大多数情况发现，一旦人们完成了最初的努力，就可以轻松地增加价值。你必须将所做的事情提炼成人们可以完成的具体任务。这意味着你必须做很多思考才能将任务分配给人们。

作为一名领导者，随着时间的推移，你会了解到需要多少预先思考。 

第4课：有时你必须做出反应，并表达你的不满

作为领导者，我们希望你不要对事情做出情绪化的反应。

我同意领导者在 90% 的情况下不应该做出反应。但是，有时你必须做出反应并表达对事情的不满。你做出反应的门槛应该很高，以至于不容易达到。

那就是，有人真的把事情搞砸了，要务必做出反应。 

让我分享一个例子。我们的一位高级开发人员（接近 10 年的经验）在 Teams 频道上发布了一条消息，说他们从前一天开始就陷入困境，因为他们无法从 Java 调用 REST API，但相同的 API 使用 Postman却是正常的。

这个确实是奇怪的行为，因此我致电 Teams 来查看问题。他首先向我展示了 Postman，然后是 Java 代码。

后来我发现问题在于 JSON 主体期望username作为字段，但开发人员在 Java 代码中传递的是userId 。在 Postman 中，他们使用的是 username，所以效果很好。我知道这看起来像是一个微不足道的例子，大多数开发人员都犯过类似的错误。

我感到失望的原因如果 Postman 正常而代码无法工作，那么开发人员不应该在不检查代码的情况下就认为 API 有问题。你不能取消一天的工作，然后在下一次每日站立会议中告诉客户 API 出现问题。客户侧并不会那么宽容。可以使用 Insomnia 等工具自动生成 REST 客户端的方法，可以帮助验证你的假设。

另外，当我说表达不满时，并不意味着伤害某个人，它只意味着设定明确的期望，并让他们知道你希望他们解决这些问题。另外你可以同时教他们调试此类问题的方法。

同样，在其他情况下，你也可以会做出反应或表现出不满，但正如我上面所说，这种情况不能经常发生，门槛应该定得更高。

第五课：从别人的错误中学习

人们经常说你应该从自己的失败中学习。

如果你善于观察，你就可以控制自己免于失败，并从别人的失败中学习。换句话说，你可以以牺牲他人为代价来学习。这是非常强大的能力，它可以帮助你更快地实现目标。

但是，它需要你仔细观察其他人，了解他们的特质以及失败的背景原因。一旦你了解周围的人并知道他们为什么在某件事上失败，那么可以避免犯同样的错误。在组织中，多名领导者试图带来类似变革是很常见的。了解前任领导者失败的原因可以帮助现任领导者了解他们这次如何才能成功。

第六课：你不会得到所有的答案。而且这些都没有关系

为了回答人们提出的问题，我给自己施加了很大的压力。我正在“调试”这些错误，思考解决他们的问题的方法，并在其他人身上做了大量研究。 

我越努力解决问题，别人给我带来的问题就越多。我期望人们能够自己学习并开始承认自己的问题。

但是，人们都在向我寻求完整答案。 

我意识到部分问题在于我处理此类问题的方法。我现在想成为一名拥有所有答案的优秀领导者。

我们都知道这不是真的，是不现实的，但是当你开始担任领导者时，就有成为一位英雄的倾向。

所以，我改变了方法。我开始为人们提供一个 Google 文档模板，他们必须先填写该模板，然后我才能与他们一起解决问题。这份文件要求他们清楚地定义问题，他们对问题的理解，已经尝试过什么，以及什么没有奏效。

这期间发生了三件事：很少有人能够自己解决问题；与其他少数人一样，我作为所有者与他们一起工作；其余的我从未收到过回复（我认为他们从未处理过该文档）。

作为领导者，你的工作不是为人们寻找答案，而是帮助他们找到答案。

说“我不知道”，并让其他人掌握主动权是成熟领导者的标志。

第七课：你会培养人才，但他们会离开

在过去的几年里，我聘请了许多有潜力的软件工程师。我与他们结对合作，指导他们，并给他们更多表现机会。但是他们仍然决定离职。对于大多数优秀的工程师来说，产品型公司往往是他们梦想的工作。

这很悲伤，但却是事实。

有那么几天，我觉得一个好的IT服务组织的工作之一就是为产品型公司培养工程师。 

我认为工程师想要加入优秀的产品型组织有足够充分的理由：

• 他们自己也想有一天创办一家自己的公司，所以产品型初创公司对他们来说有一个很好的学习环境

• 项目之间的切换较少。你可以在一个团队中工作多年

• 你可以在一个领域建立更多深度

• 他们支付的工资比 IT 服务组织高得多

迄今为止，在我的职业生涯中，我主要与 IT 服务企业合作。我可以给出的支持 IT 服务企业的理由之一是： 

你可以在短时间内使用广泛的技术和相关领域。

我构建了 DevOps 工具、构建了低延迟的定价引擎、构建了多租户 SaaS 应用程序、构建了社交平台、帮助银行完成数字化转型（架构、DevOps 实践）之旅以及许多其他成功案例。

第 8 课：编码很好。但是，请不要做出承诺

如果你在网上阅读有关软件工程经理或 CTO 是否应该编码的信息，会发现他们中的大多数人都建议不要编码。

避免自己编写代码的两个正当理由是：

• 你将面临多个相互竞争的优先事项，而编码通常会退居其次。你可能无法按时完成任务，这也会导致团队放慢开发速度。

• 屈服于“对编码的热爱”的危险在于，在构建“令人惊叹的”技术的愿望和强化确认偏差的情况下失去了业务的目标。

在担任首席技术官的第一年，我与团队合作愉快并交付了代码。以下是我参与项目的3个关键点：

• 向交付团队明确表示我不是任务的所有者。如果我的时间允许，也会发布代码，但他们不应该在评估中考虑它。这表示着每个项目都应该有一个除了我之外的技术负责人；

• 始终与一位可以推进任务的团队成员结对合作，以防我不能参与工作

• 参与代码和工程设计文档审查，而不是编写代码来提供价值

• 优先解锁其他人，以防他们被相关问题卡住

但我喜欢编码。下班后我继续从事一个业余项目，以保持我的编码技能鲜活。

教训＃9：只有少数客户真正重视质量

大多数客户希望他们的软件供应商构建：

1. 高品质的产品 

   
   

2. 具有敏捷的项目需求 

3. 在固定成本和期限内交付

我们都知道，构建一个同时满足所有这三个约束的产品是很困难的。如下图示：

出于一些限制，当团队面临时间和成本压力时，质量是首先要考虑的事情。质量需要时间和金钱，而且它的优先级低于功能。 

客户相信软件交付的工厂模型，其中团队中的人数与功能速度成正比。根据我的经验，软件交付的工厂模型是有缺陷的，你无法使用这种模型构建好的产品。

第10课：我喜欢你，但我不必说你的语言

在我担任首席技术官的第一年里，这种情况已经发生过多次，如果你碰巧有良好的工作关系，人们希望你能说和他们一样的语言。

我的认识是，当你向上攀登时，你会变得更加孤独。保持个人和工作关系的平衡是很困难的。当你喜欢某人时，很难在不伤害他们的情况下质疑他们。

第十一课：明智地选择你的战斗

我意识到只有少数问题值得解决。

你不可能用所有最好的意图来解决所有问题。我在 Camille Fournier 的帖子 中找到了这个流程图，它提供了一个很好的框架来决定你应该选择哪场战斗。

第十二课：不断调整事物

这是领导者应该牢记的重要教训。

你不能成为系统中的瓶颈。可以通过两种方式成为其中一员：

1. 尝试通过停止并一次性损坏的系统来做修复，这是行不通的。你最终会压垮自己，树敌多于朋友。你必须以渐进的方式进行——一次一小步，让人们与你的最终目标保持一致。你甚至不必告诉最终目标。不断进行小的战术改变并牢记大的战略目标。

2. 不迅速做出决定。如果你不习惯做出影响他人的决定，那么当你处于这种情况时，你将会感到压力和不知所措。大多数人希望将决策权委托给别人，或者不完全拥有决策权。作为领导者，你必须了解并非所有决定都平等，不做出决定也是一种决定。我个人喜欢杰夫·贝索斯，他是亚马逊决策心智模型的创始人。他说你应该问自己一个决定是可逆的还是不可逆的。

有些决定是结果性的、不可逆转的或几乎不可逆转的——单向门——而这些决定必须有条不紊、仔细、缓慢地做出，并经过深思熟虑与协商。 

如果你走过并且不喜欢另一边看到的东西，你就无法回到原来的地方。我们可以将这些称为第一类决策。但大多数决定并非如此——它们是可变的、可逆的——它们是双向的门。 

如果你做出了次优的第 2 类决定，就不必长期承受后果。可以重新打开门并返回。第 2 类决策可以而且应该由具有高判断力的个人或小组快速做出。

事实证明，我们必须做出的大多数决定都是可逆的。因此，我们可以更快地做出决策并保持进展。

第十三课：你所说的话对人们很重要，你将被追究责任

不要让人们迫使你做出你自己都不相信的决定。他们稍后会让你对这些决定负责，他们是对的。做慎重的决定是你的责任。

作者：史蒂芬&周

网址：

https://shekhargulati.com/2021/01/03/being-chief-technology-officer-lessons-learned-in-my-first-year/