我担任首席技术官的第一年学到的经验教训
对于我们大多数人来说，2020年是艰难的一年，因为我们与COVID-19作战，并接受了远程工作方式。那一年，我们有更多的时间在手，因为我们所有人都被锁在了几乎没有旅行的房屋中。我们认为理所当然的东西是从我们手中夺走的，人们一直担心失去亲人。
我希望我们在2021年恢复自由生活的自由。但是，这次带着责任感和意识。
自从我成为当前组织的首席技术官（CTO）以来，已经过去了不到一年的时间。而且，我认为现在是对我作为首席技术官的第一年所学到的教训进行快速回顾的好时机。旅途很艰难，但对我来说却是深刻的收获。有时我认为领导角色不适合我，我应该回到成为个人贡献者的角度。但是，在我的组织和学习（书籍，博客，观察）的支持下，我开始享受这个角色及其挑战。
在谈论我学到的课程之前，让我们先看一下我的软件工程历程。
2014-2019年：首席工程师/建筑师（在此期间，我担任主任一职，但是在编写代码，构建系统和技术咨询方面我非常专心）
是的，这是我的第一个领导和管理角色。从个人贡献者到CTO的跨越既令人不安，又在职责上雄心勃勃。
当然，随之而来的是它的优缺点。尽管如此，我还是大跌眼镜，没有任何先入为主的观念就经历了这一转变。
当我被告知我将担任下一任CTO时，我立即寻找了一本能描述和提供最佳实践并指导我成为一名成功的CTO规则的剧本。我想为这个职位做好准备，并研究网上提供的所有CTO文献。你猜怎么了？没有这样的剧本。
归根结底，这始终是关于在工作中学习并且不会两次犯同样的错误。
我读的第一件事是人们通常定义首席技术官的角色。显然，它是最混乱的C级角色之一，每个CTO的扮演都略有不同。我发现这个角色的最好描述是在Matt Tucker的一篇文章中。根据Matt的说法，为了更好地理解角色，您应该分为五类。
我认为上述框架为如何思考CTO的角色提供了一个很好的思维模型。通常，它们带有两种或多种上述风味的组合。
让我分享一下作为首席技术官的角色。我认为，Matt Tucker共享的框架（以上）是从产品组织的角度来看的。我是IT服务组织的CTO，由于以下其他因素，该角色变得分散，分散和具有挑战性：
人员是任何组织中的重要资产，但是对于IT服务组织而言，增长与人员数量成正比。如果您想保留利基服务提供商，那么情况可能会有所不同。
您必须使尚未准备好进行更改的大型企业可以使用现代技术。在过去的五年左右的时间里，大多数组织都在推动数字化转型。以我的经验，组织现在比以往任何时候都更开放尝试新技术（React，Golang，Flutter，Cloud，Kubernetes）和体系结构样式（微服务，事件驱动，无服务器）。这是一个好消息，但是很少有组织了解这些现代技术堆栈带来的复杂性。他们没有为成为自己网域中的下一个Google做必要的基础工作。您可以阅读我的文章微服务失败的11个原因
市场上没有多少具有这些现代技术实际经验的优秀软件工程师。优秀的软件工程师很昂贵，他们的财务和工作愿望与产品组织更加一致。对于IT服务组织，不可能按产品组织的规模付费。
IT服务组织的CTO并没有写太多关于它的文章。目前尚不清楚谁应该成为您的榜样，因此我将采用Matt的框架并为自己定义。
在这里，您将看到Matt的框架根据构成我角色的口味进行了修改。我对去年在每项活动上花费的时间进行了粗略的估算。
如上表所示，我无处不在。对我来说幸运的是，我在上下文切换方面的开销更少。主要原因是我确保我一次不会参与超过两个任务。
在担任首席技术官的第一年，我建立了一定级别的授权等级。希望在第二年，我将更加专注于其中一些口味。
到目前为止，我已经分享了我的旅程和CTO角色定义。接下来，让我引导您完成第一年作为CTO所学的课程。
大多数软件工程师梦想着有一天成为一名CTO。这就是我们中某些人定义成功的工程职业的方式。仅仅因为您是组织中最有能力的软件工程师/架构师，否则就不会让您成为CTO。你真的需要饥饿。
我花了将近2-3年的时间才能确定自己已准备好担任CTO。我认为自己尚未准备好担任领导角色的原因之一就是彼得·普莱斯。
彼得原理是一种观察，即在大多数组织层次结构（如公司）中，趋势是每个员工都通过晋升在层次结构中上升，直到达到各自的无能为止。
我一直以能胜任软件工程师/架构师而感到自豪。担心有一天会变得无能为力，这使我坚持动手做个人贡献者的角色。
我意识到的一件事是，如果我不去担任这个角色，那么其他人会做。从那以后，我对组织有了足够的了解，并且我已经弄清了我的工程领导风格，所以为什么不尝试一下。对我来说最困难的部分是要求角色。可悲的是，如果您不问别人，他们就不会给您您应得的东西。
现在，我实际上总是发现有一个非常真实的事实，那就是大多数人因为从未提出要求而无法获得这些经验。当我向他们求助时，我再也找不到任何不想帮助我的人–史蒂夫·乔布斯[1]
几周前，一位同事问我，当您必须参加如此多的会议时，您如何做得更好。我发现人们一旦在日历中找到空闲的会议空档，就会将您添加到会议中。我在2020年上半年为此感到挣扎。大部分时间我都在开会。在此期间，我所做的大部分思考工作都是在下班后或周末进行。
在意识到自己也可以安排自己的时间后，下半年我改变了工作方式。现在，我每天要安排几个小时到半天的时间来完成一项深层次的工作。这样，我就可以在制造商进度表和经理进度表之间进行管理[2]。
避免成为日历的奴隶的另一种方法是，与组织者一起确保我参加会议是否很关键。在其他时间，当团队中的某人已经在参加会议时，我会拒绝会议。
这是大多数个人贡献者在担任管理/领导职务时面临的挑战。您知道可以更好，更快地完成任务。因此，您喜欢自己完成任务。这无法扩展，您很快就会成为瓶颈。我敢打赌，您已经知道答案了。
扩展自己的最佳方法是通过委派。委派分为两个部分：委派什么以及要应用哪个委派级别。
珍妮·布莱克（Jenny Blake）在《如何决定要委派的任务》 [3]中将任务分为6类，她称这6种T。
微小：任务很小，似乎没有必要解决，但总会增加。
乏味：相对简单的任务可能不是最佳利用时间。
耗时：尽管任务可能很重要，甚至有些复杂，但它们却很耗时，不需要您进行最初的80％的研究。
可教学：尽管最初看起来很复杂并且可能包含几个较小的子任务的任务，但是可以转换为系统并传递给您，而您仍然可以提供质量检查和最终批准。
糟糕的地方：不仅不属于您的长处，而且不适合您的领域。
时间敏感：时间敏感但与其他优先级竞争的任务；没有足够的时间一次完成所有任务，因此您委派了一项重要且时间紧迫的任务，以便可以与其他基于项目的截止日期同时进行。
我已经委派给团队中的其他人员，例如组织内部技术讲座，操作内部基础设施，代码审查，初级工程师招聘。
一旦知道要委派哪些任务，就必须使用委派级别来完成最佳工作。我在Management 30网站[4]上了解了7个级别的授权。
最终，您必须使用足够的管理来完成任务。
无论您是否喜欢，每个组织都会发生混乱的情况。混乱的情况可能是软件交付出错，导致客户系统故障的严重错误，系统性能问题或任何与人相关的问题。当您作为领导者参加这样的会议时，人们会期望在会议结束时事情会变得更加清晰，团队将有一个可以遵循的全面计划。
作为领导者，您的工作是减少混乱，并提高清晰度。我曾在一种情况下使用的示例剧本如下：
通过提问来简化问题。通常，这涉及到问题的实质，并删除与之相关的所有不必要的信息。作为领导者的目标是使人们思考。因此，您必须提出广泛而广泛的问题，例如为什么选择这种设计？这个指标将告诉我们什么？您认为用户此刻在想什么？
创建一个具有清晰动作的小型待办事项列表。例如，对于性能修复，这是待办事项列表：如果不存在测试，请编写测试以了解我们必须进行性能调整的功能
我观察到的另一件相关的事情是，许多人无法处理抽象的想法。一旦有人做了最初的努力，大多数人就会发现很容易增加价值。您必须将所做的工作提炼为人们可以完成的具体任务。这意味着您必须进行很多思考，然后才能将任务移交给人们。作为领导者，您会随着时间的流逝学习需要多少前瞻性思维。
作为领导者，期望您不会在情感上对事情做出反应。我同意领导者90％的时间不应该做出反应。但是，有时您必须做出反应并表现出对事物的不满。您做出反应的门槛应该很高，以至于很难轻易达到。有人真的应该把事情搞砸，以至于您必须做出反应。
让我举个例子，我们的一位资深开发人员（接近10年的经验）在Teams频道上发布了一条消息，说他们从前一天就被困住了，因为他们无法从Java调用REST API，但是相同的API是在邮递员那里工作。这是奇怪的行为，所以我打电话给Teams来研究问题。他首先给我看了邮递员，然后给了我Java代码。问题在于JSON主体希望将用户名作为字段，但是开发人员正在Java代码中传递userId。在Postman中，他们使用用户名，因此工作正常。我在两分钟内就知道了。而且，我当然对他表示失望。我感到失望的原因
如果Postman在工作，而您的代码在工作，则任何有能力的开发人员都不会在不检查他们通过代码发出的请求的情况下说出API出了问题。
在这一点上，我通常认为他们要么不称职，要么懒惰。我希望他们是懒惰的。类似地，在其他情况下，您可能会做出反应或表现出不满意，但正如我所说的，更高的标准是，这种情况每月最多发生一次。
经常听到您应该从自己的失败中学习。如果您观察的话，可以限制自己的失败，并从别人的失败中学习。换句话说，您可以以牺牲他人为代价来学习。这非常强大，可以帮助您更快地实现目标。但是，这需要您密切观察其他人并了解他们失败的特征和背景。一旦了解了周围的人并知道他们为什么失败了，您就可以避免犯同样的错误。在组织中，多位领导者试图带来类似的变化是很常见的。了解以前的领导者为什么失败可以帮助当前的领导者理解他们这次如何能够成功。
我给自己施加很大压力，要求他们回答人们提出的问题。我正在调试错误，思考问题的解决方案，并为他人做了大量研究。
我越努力解决问题，从人们那里得到的问题就越多。我期望人们能够学习并开始拥有自己的问题。但是，人们一直在寻找我的完整答案。
我意识到问题的一部分是我处理此类问题的方法。我想成为一个有所有答案的优秀领导者。我们都知道这是不对的，但是当您开始担任领导者时，就会有成为英雄的倾向。因此，我改变了方法。我开始给人们提供一个Google文档模板，他们必须填写这些文档，然后我才能与他们合作解决他们的问题。该文档要求他们清楚地定义问题，对问题的理解，他们尝试过的一切以及未解决的问题。发生了三件事：很少有人能够自己解决问题。与其他几个人一起，我与他们一起工作是所有者；其余的我从没听说过（我认为他们从未处理过该文档）。
作为领导者，您的工作不是为人们找到答案，而是帮助他们找到答案。说我不知道，让其他人拥有所有权是领导者成熟的标志。
在过去的几年中，我聘请了许多有潜力的工程师。我与他们配对，指导他们，并给了他们机会。但是，他们决定离开。对于大多数优秀工程师来说，产品公司通常是他们的梦想。这是可悲但真实的。
有时候，我觉得一个好的IT服务组织的工作之一就是为产品公司建立工程师。
他们自己想有一天创办一家公司，因此产品创业公司对他们来说是一个很好的学习环境
到目前为止，在我的职业生涯中，我主要与IT服务组织合作。我可以推荐一个IT服务组织的原因是：
您可以在短时间内使用广泛的技术和领域。我建立了DevOps工具，建立了低延迟的定价引擎，建立了多租户SaaS应用程序，建立了社交平台，帮助银行进行了数字化转型（架构，DevOps实践），以及许多其他事情。
如果您在网上阅读有关工程经理或CTO是否应该编码的信息，您会发现其中大多数建议不要编码[5]。避免自己编写代码的两个有效原因是：
您将有多个相互竞争的优先级，并且编码通常会排在后面。您可能无法按时完成任务，这可能会导致团队变慢。
屈服于“编码之爱”的危险在于失去了建立“惊人”技术并强化确认偏差的渴望的业务目标。
在担任首席技术官的第一年，我曾与我们的交付团队合作并交付了代码。这是我参与的三个关键项目的工作：
向交付团队明确表示我不是任务的所有者。如果时间允许，我将提供代码，但他们不应在估算中考虑它。这意味着除了我以外，每个项目都应有一个技术所有者
总是与团队成员配对，以防我无法工作
我喜欢编码。在下班后，我继续进行一项附带项目，以保持编码技巧的温暖。
我们都知道，要在所有这三个约束都到位的情况下构建产品很难。[6]
在所有约束中，当团队面临时间和成本压力时，质量是第一要务。质量要花费时间和金钱，这是一件事，其优先级低于功能。
客户相信软件交付的工厂模型，其中团队人数与功能速度成正比。以我的经验，软件交付的出厂模型存在缺陷，您不能使用这种模型来构建好的产品。
第10课：我喜欢你，但我不必讲你的语言
在我担任首席技术官的第一年里，这已经发生过多次，人们希望您碰巧拥有良好的工作关系，就能说自己的语言。
我的认识是，当您爬上梯子时，它会变得更加孤独。很难保持个人和工作关系的平衡。当您喜欢某人时，很难在不伤害他们的情况下质疑他们。
我已经意识到，只有几个问题值得解决。您不可能全力以赴地解决所有问题。我在Camille Fournier帖子[7]中找到了此流程图，该流程图提供了一个不错的框架来决定您应该选择哪种战斗。
这是领导者应牢记的重要教训。您不会成为系统的瓶颈。有两种方法可以成为一种：
尝试通过暂停并修复它来修复损坏的系统。这是行不通的。您最终会不知所措，结交的敌人多于朋友。您必须以零碎的方式做到这一点–每次只需一步，就可以使人们与您的最终目标保持一致。您甚至不必说出最终目标。不断进行小的战术变更，并牢记大型战略目标。
没有迅速做出决定。如果您不习惯做出会影响他人的决定，那么当您处于这种情况下时，这将是压力很大且不堪重负。大多数人想委托决策或不完全拥有决策。作为领导者，您必须了解并非所有决策都是平等的，并且不做决定也是决定。我喜欢杰夫·贝佐斯（Jeff Bezos），他是亚马逊心智决策模型的创始人。他说，您应该问自己一个决定是可逆的还是不可逆的。
有些决定是必然的，不可逆的或几乎不可逆的，即单向门，这些决定必须有条理，谨慎，缓慢地进行，并要经过深思熟虑和协商。
如果您不喜欢另一面的景象，就无法回到原来的状态。我们可以将这些称为第一类决策。但是大多数决策并非如此-它们是可变的，可逆的-它们是双向的。
如果您做出的2型决策不理想，那么您就不必忍受这么长的后果。您可以重新打开门，然后回去。高判断力的个人或小组可以并且应该迅速做出2类决策。
事实证明，我们必须做出的大多数决定都是可逆的。因此，我们可以更快地做出决策并保持进展。
不要让别人向您施加压力，让您做出您不相信的决定。他们会让您对他们负责，然后他们才是正确的。决定是您的责任。
