作为首席技术官：第一年的经验教训

2020年为我们大多数人为我们的大多数人来说是一个困难的一年，因为我们与Covid-19战斗，并以偏远的工作方式来到了条款。当我们所有人都在我们的房子里锁定了我们手中有更多的时间，这是一年的，几乎没有旅行。我们被视为理所当然的事情取自我们，并担心失去亲人的恐惧。

我希望在2021年，我们恢复了自由自由。但是，这次具有责任感和意识。

自我当前的组织中成为首席技术官（CTO）以来，它现在几乎没有一年。而且，我认为这将是快速回顾我作为首席技术官的第一年的经验教训。这段旅程对我来说很艰难，但对我来说非常有益。有偶然的时候我认为领导角色不适合我，我应该回到个人贡献者。但是，在我的组织和学习（书籍，博客，观察）的支持下，我开始享有职位和挑战。

在我谈论我学到的课程之前，让我们来看看我的软件工程之旅。

2014-2019：主要工程师/建筑师（在此期间，我处于董事的角色，但我是颈部编写代码，建筑系统和技术咨询的领域

是的，这是我的第一个领导和管理角色。从一个CTO的个人贡献者的跃迁就像在责任方面雄心勃勃的那样越来越多。

当然，随着这个机会的份额，它的利弊份额。尽管如此，我拿下了暴跌，没有任何先入为主的概念的过渡。

当我被告知我将是下一个CTO时，我立即寻找一个将描述并提供最佳实践的剧本，并引导我成为一个良好，成功的首席技术队的规则。我想准备好角色，并研究网络上可用的整个CTO文献。你猜怎么着？没有这样的剧本。

在一天结束时，总是关于学习工作，而不是两次犯同样的错误。

我读过的第一件事是人们通常定义首席技术官的角色。显然，它是最令人困惑的C级角色之一，并且每个CTO都会有点不同。我发现的这个角色的最佳描述是亚特塔克的一篇文章。据马特，为了更好地了解角色，你应该闯入五种口味。

我认为上述框架为如何思考CTO的角色提供了良好的心理模型。主要是，它们具有两个或多个上述口味的组合。

让我分享我的角色，作为一名主要技术官员，看起来像。在我看来，Matt Tucker共享的框架（上文）来自产品组织的角度。我是IT服务组织的CTO，这种角色因以下其他因素而被摊薄，分散和挑战：

人们是任何组织的重要资产，但对于IT服务组织而言，增长与人数成正比。如果您想留在利基服务提供商，那么故事可能是不同的。

您必须为尚未准备好变化的大型企业提供现代技术。在过去的5年左右，大多数组织都有推动数字转型。在我的经验中，组织现在更加开放，以尝试新技术（React，Golang，Flutter，Cloud，Kubernetes）和架构风格（微服务，事件驱动，无服务器），比以往任何时候都更多。这是一个很好的消息，但很少有组织了解这些现代技术堆栈引入的复杂性。他们不是在域名成为下一个谷歌所需的基础工作。您可以阅读我的帖子11原因，为什么您将使用微服务将失败

市场上没有许多良好的软件工程师，这些现代技术具有真正的经验。良好的软件工程师昂贵，他们的财务和工作愿望与产品组织更加一致。对于IT服务组织，无法按产品组织的规模支付。

IT服务组织的CTO没有写作的撰写。它不清楚谁应该是你的榜样，所以我会拿马特的框架并为自己定义它。

在这里，您将看到Matt的框架凭借包含我的角色的口味修改。我对去年每次活动花了粗略的估计。

正如你可以在上表中看到的那样，我到处都是。幸运的是对我来说，我在上下文切换方面的开销较少。主要原因是我确保一次从未参与过2多个任务。

在我的第一年作为首席技术官，我建立了一些级别的代表性等级。希望在第二年，我将更多地侧重于这些口味。

到目前为止，我已经分享了我的旅程和CTO角色定义。接下来，让我走过我在第一年作为首席技术官学到的课程。

大多数软件工程师有一天梦想成为CTO。这是我们一些人如何定义成功的工程职业。有人不会让您成为CTO，因为您是您组织中最有能力的软件工程师/建筑师。你真的需要有饥饿。

在我觉得我觉得我准备成为一个首席技术官之前，我花了很近2 - 3年。我以为我没有准备好领导角色的原因之一是彼得原则。

彼得原则是一个观察到，大多数组织层次的趋势，例如公司的趋势，是每个员工通过促销，直到他们达到各自的无能程度。

我一直在为一个主管的软件工程师/建筑师而感到自豪。有一天变得无能的恐惧让我坚持下手的个人贡献者的角色。

我意识到的一件事是，如果我不打算做这个角色，别人会。自从，我知道这个组织足够长，我已经弄清楚了我的工程领导风格，所以为什么不给它一个尝试。对我来说最困难的部分是要求这个角色。悲伤的部分是如果你不问人，他们不会给你你应得的东西。

现在，我实际上总是发现一些非常真实的东西，这是大多数人都没有得到这些经历，因为他们从未问过。当我向他们寻求帮助时，我从未找到任何不想帮助我的人 - 史蒂夫乔布斯[1]

几周后，一位同事们问我如何在你参加这么多的会议时如何做深刻的工作。我发现人们会在您的日历中找到一个免费会议插槽时将您加入会议。我在2020年上半年挣扎着这一点。我大部分时间都在会议。我在这段时间内完成的大多数思维工作是在办公时间或周末之后。

在意识到我也可以安排自己的时间后，我改变了在下半场工作的方式。现在，每天我每天安排到半天到半天，并做一个深入的工作任务。这样我就可以在制造商计划和经理时间表之间管理[2]。

另一种方式，我避免成为我的日历的奴隶，是通过确保组织者，我在会议中的存在是否至关重要。在其他时代，当我团队的某人已经参加时，我拒绝会议。

这是大多数个人贡献者面临的挑战，当他们承担管理/领导力的角色时。你知道你可以更好，更快地完成任务。由此，您更愿意自己完成任务。这不会缩放，你很快就成为瓶颈。我打赌你已经知道了答案。

缩放自己的最佳方式是通过代表团。代表团有两部分：委派是什么以及申请哪些代表级别。

如何决定委派的任务[3]，珍妮Blake将任务分为6个类别，为6 Ts调用。

微小：这么小的任务，他们看起来无关紧要，但他们加起来。

繁琐：相对简单的任务可能不是最佳使用时间。

耗时：任务，虽然它们可能是重要的甚至有点复杂，但耗时，并且不要求您完成最初的80％的研究。

教育：任务，虽然起初并可能包括几个较小的子任务，但可以将复杂似乎和可能的较小的子任务转换为系统并通过您仍然提供质量检查和最终批准。

可怕的：不仅不仅不落入你的优势的任务，而且是一个你觉得没有难以的领域。

时间敏感：时间敏感但与其他优先事项竞争的任务;没有足够的时间立即完成它们，因此您委派了一个重要且时间敏感的任务，以便可以与您的其他基于项目的截止日期并行完成。

组织内部技术谈判等任务，操作内部内部，准则评论，聘请我聘请了我团队中的其他人。

一旦您知道要委派的任务，您必须使用获得最佳作业的委派级别。我在Management 30网站上了解了7级代表团[4]。

在一天结束时，您必须使用足够的管理来完成完成的事情。

无论您是否喜欢它，每个组织都会发生混沌情况。混乱的情况可能是一个软件交付出错了，这是一个关键的错误，占据了客户系统，系统性能问题或任何相关问题。当你作为领导者进入这样的会议时，人们期望在会议结束时，事情会更加清晰，并且将有一个彻底的计划可以遵循。

您作为领导者的工作是减少混乱并带来更多的清晰度。我为一个这样的情况使用的示例播放簿如下：

通过提出问题来简化问题。这通常涉及到问题的肠道并删除与之相关的所有不必要的信息。你作为领导者的目标是让人们思考。那么，你必须提出深刻和广泛的问题，就像为什么选择这个设计？这个指标要告诉我们什么？你认为用户在这一刻想什么？

使用清除操作创建一个小todo列表。例如，对于绩效修复，这是Todo列表：写一个测试如果不存在以了解我们必须进行性能调谐的功能

我观察到的另一个相关的是许多人不能与抽象想法合作。大多数人发现一旦有人完成了最初的努力，大多数人都会容易逐步增加价值。你必须蒸馏给人们可以工作的具体任务。这意味着在您可以处理对人民的任务之前必须做很多思考。作为一个领导，您可以随时了解需要多少前期思考。

作为领导者，预计您不会在情绪上对事物作出反应。我同意领导者不应该反应的90％的时间。但是，有时候你必须做出反应并表现出对事物的不满。您反应的酒吧应该如此之高，无法轻易达到它。有人应该真的很厉害，你必须做出反应。

让我分享一个例子，我们的高级开发人员（接近10年的经验）发布了一条关于球队渠道的留言，因为他们从前一天被困，因为它们无法从Java调用REST API但同样的API是从邮递员工作。这是奇怪的行为，所以我打电话给团队来看待这个问题。他先向我展示了邮递员，然后展示了Java代码。问题是JSON Body期待用户名作为字段，但开发人员在Java代码中传递了UserID。在邮递员中，他们使用的是用户名，所以它的工作正常。我想到了两分钟。而且，我肯定对他表示失望。我很失望的原因

如果邮递员正在工作并且您的代码无法正常工作，则无法使用任何能力的开发人员会说API出现问题而无需检查他们通过代码进行的请求。

在这一点上，我通常认为它们是无能的或懒惰。我希望他们是懒惰的..同样，您可以在其他情况下，您可以做出反应或表现出不满，而是因为我说，这条话应该更高，这种情况不会超过一次。

很常见，听到你应该从自己的失败中学习。如果您是观察者，您可以限制您的失败并从其他人的失败中学习。换句话说，您可以以牺牲他人的为代价来学习。这是非常强大的，它可以帮助您更快地达到目标。但是，它要求您密切地观察其他人，了解他们失败的特征和背景。一旦你了解周围的人并知道为什么他们失败了，那么你可以避免犯同样的错误。在多个领导人试图带来类似的变化的组织中，这是常见的。了解为什么以前的领导者失败可以帮助当前领导人了解这次如何成功。

我对自己提供了很多压力，为人们问的问题提供答案。我正在调试错误，思考解决问题的解决方案，并对他人进行很多研究。

我越试图解决问题，我从人们获得的问题越多。我期待人们学习并开始拥有他们的问题。但是，人们正在寻找我的完整答案。

我意识到了这个问题的一部分是处理这些问题的方法。我想成为一个拥有所有答案的良好领导者。我们都知道这不是真的，但是当你开始作为领导者时，有一个是英雄的倾向。所以，我改变了我的方法。我开始给人们提供一个谷歌文档模板，在我可以与他们合作之前，他们必须填写以解决他们的问题。该文件要求他们清楚地定义问题，他们对问题的理解，他们尝试了什么，而且没有工作。发生了三件事：很少有人能够自己解决问题;少数人，我和他们一起工作;而且剩下的我从未听过（我认为他们没有在文件上工作）。

作为领导者，你的工作不是为了找到人民的答案，而是为了帮助他们找到答案。说我不知道​​并让别人拥有所有权是成熟领袖的标志。

在过去的几年里，我雇用了许多具有潜力的工程师。我与他们配对，融合了他们，并给了他们机会。但是，他们决定离开。对于大多数良好的工程师来说，通常产品公司都是他们的梦想工作。这很伤心，但真实。

有几天我觉得一个很好的IT服务组织的工作之一是为产品公司构建工程师。

他们本身希望有一天开始一家公司，因此产品初创公司对他们来说是一个很好的学习环境

到目前为止，在我的职业生涯中，我主要与IT服务组织合作。我可以给予一个原因，支持IT服务组织是：

您可以在短时间内使用技术和域的广度。我已经建造了Devops工具，建立了一个低延迟定价引擎，建造了多租户SaaS应用程序，建成了一个社交平台，帮助银行在他们的数字转型（建筑，Devops实践）旅程中，还有许多其他事情。

如果您在网络上阅读了工程管理器或CTO应代码是否应读取，您会发现他们中的大多数建议对编码[5]。避免自己做代码的两个有效原因是：

您将有多个竞争优先事项，编码将经常占据一席之地。您可能无法按时完成任务，这可能导致您的团队放慢速度。

赋予“对编码的热爱”的危险正在失去渴望建立“惊人”技术和​​加强确认偏见的愿望下的业务目标。

在我作为首席技术官的第一年，我与我们的交付团队合作并发货代码。这是我所涉及的三个关键项目所做的：

送达送货团队，我不是任务的所有者。如果我的时间允许，我将发货代码，但他们不应该在他们的估计中考虑它。这意味着每个项目都应该与我分开的技术主人

始终与一名团队成员配对，谁可以在我变得不可用

我喜欢编码。我在办公时间后继续在一个方面的项目上工作，以保持我的编码技巧温暖。

我们都知道，难以建立所有这三个约束的产品。[6]

在所有的限制之外，质量是当团队正在进行的时间和成本压力时出门的第一件事。质量成本时间和金钱，它是一个优先考虑的一件事。

客户相信工厂型号的软件交付模式，团队中的人数与特征速度成正比。在我的经验中，软件交付的工厂模型有缺陷，您无法使用此模型构建良好的产品。

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

这在我的第一年里发生了多次，因为CTO有人希望你会在碰巧有一个良好的工作关系的情况下说出他们的语言。

我的实现是，当你向上移动时，它变得更加孤独。很难保持个人和工作关系平衡。当你喜欢某人时，很难在不伤害他们的情况下质疑。

我已经意识到只有一些问题值得定影。您无法解决所有最佳意图的所有问题。我在Camille Fournier帖子[7]中发现了这个流程图，它给出了一个很好的框架来决定你应该选择哪种战斗。

这是一个重要的教训，即领导人应该牢记。你不能成为系统中的瓶颈。有两种方式可以成为一个：

尝试通过停止它并在一次转到固定它来修复破损的系统。这不起作用。你最终会让自己压倒，并比朋友更加敌人。你必须以零碎的方式做到这一点 - 一小步，一段时间让人与你的最终目标保持一致。你甚至不必告诉你的最终目标。继续进行小的战术变化，并记住大规模的战略目标。

没有迅速做出决定。如果您不习惯采取影响他人的决定，那么当您处于这种情况时，它将压力和压倒性。大多数人都希望委托决定或完全拥有它们。作为领导者，您必须明白，并非所有决策都是平等的，而不是作出决定也是一个决定。我喜欢亚马逊精神模型的创始人杰夫贝罗斯决策制作。他说你应该问自己是否是可逆的或不可逆转的决定。

一些决定是后果和不可逆转的或几乎不可逆转的 - 单向门 - 这些决定必须在很大的审议和咨询方面进行有条不紊地，谨慎地慢慢地进行。

如果你走过而不喜欢你在另一边看到的东西，你就无法回到你以前的位置。我们可以称之为1型决策。但大多数决定不喜欢 - 它们是可变的，可逆的 - 他们是双向门。

如果您已经进行了次优类型的2型决定，您就不必居住在那段后果。你可以重新打开门，然后返回。 2型决策可以，并且应该由高判断个体或小组快速制作。

事实证明，我们必须采取的大多数决定是可逆的。所以，我们可以更快地做出决定，并保持移动。

不要让人们对你的决定压力你不相信。他们会稍后会对他们负责，他们将是正确的。决定是您的责任。