Tech Lead 生存指南

原文链接：Tech Lead Survival Guide

3 年前，当我第一次在 Moveon 担任首席技术官时，我立刻被淹没了：在我第一天登录的几个小时内，我收到了 100 封未读的电子邮件，一种全新的、完全远程的组织文化，以便找出并导航，我陷入了一个高风险平台和数据迁移的过程中，而我还没有任何背景或历史，我继承了一个无文件记录的预算和遗留代码库，我的任务是雇佣一个团队，建立一个数据仓库，并弄清楚 “我们应该如何处理这个网站”。

或多或少，我坐在我的座位上，融入了英特尔的收集模式-与每个人交谈，制定组织结构，制定系统和结构，以及我继承的期望。我参与了一些项目，包括运行招聘流程、构建数据仓库、共同领导正在进行的平台和数据迁移，同时做出巨大的、高风险的决策，并且很难只用部分信息来逆转决策。在我最初的 5 个月之后，我有了一个团队，一个数据仓库，一个成功启动的迁移平台。我对工具和内容管理生态系统有一个清晰的概念，我想保留哪些工具，哪些工具我想日落，以及我的团队接下来应该构建什么。这段时间充满了兴奋、激动和肾上腺素，最后我为我的团队和我所取得的成就感到骄傲。然后，我想知道，从这里变得容易吗？

答案可能是否定的。领导一个团队，直接为许多其他团队服务，在一个有着十多年历史、流程和传统代码的知名组织中，这个组织在全国范围内开展宣传工作，这意味着总有新的、巨大的挑战，而且总是比任何一个人在任何给定时间都能处理的更多的工作。我很快意识到，我需要非常谨慎地对待我的时间和团队的时间，并且非常清楚地沟通我们正在做什么和没有做什么，以便我们能够以可持续的速度工作，确保我们在正确的时间进行正确的工作。

这段时期令人兴奋，势不可挡，正是我准备迎接的挑战，但同时也很有压力，因为对于如何从混乱中摆脱清晰，如何处理压倒性的沟通和无数的竞争优先事项，没有剧本。这篇文章是 3 年前写给我自己的一封信-我希望存在的指南。我希望这对其他进入新技术领导职位的人有帮助。

一种不同的问题解决方法

当我是一名软件工程师时，当我还是一名软件工程经理时，我通常有过这样的经历，即我在代码库，项目或领域工作的时间越长，我就越了解它，我能够更有效地工作。编码经验复合，升级我可以编写更多代码，编写更复杂的代码，或承担风险重构项目，或学习如何扩展系统。我工作的知识空间是清晰的，自我记录的：如果我不知道代码的哪一部分，我可以运行它并进行调试和检查。如果我想了解代码库中过去决策的完整背景，我可以查看已签入更改的历史记录。一般来说，如果我深入研究细节，我可以询问的关于软件系统的大多数问题我可以自己回答。

作为一名 CTO 则恰恰相反：每个月都有一些全新的高风险挑战来自左场，这与之前的重大挑战毫无关系，有时在作出决定之前无法获得完整或甚至足够的信息。挑战的知识空间几乎从未被清晰地记录下来。如果我想了解过去决策的完整背景，我必须找到做决定时的人，有时我不能。我做出的每一个决定都有难以估计的权衡，不仅影响我，而且影响整个团队，有时影响整个组织。

虽然我已经准备好应对这一新的挑战，但我已经成熟了典型的技术行业文化，这种文化崇拜 “牛仔编码员”，并且通常不尊重管理层，所以我没有语言可以解释我的角色是什么或应该是什么。我最好的猜测是，我会成为一个解决组织技术问题的人，并为软件工程师带来麻烦。最初我曾假设我会像招聘我的团队那样做一些前期管理引导工作，然后我们将大部分时间花在一起编码。很快我意识到作为 CTO 的生产单位不是编写的代码行，而是做出了决策。做出决定很难。

规划组织并评估期望

在新组织中担任技术领导角色的第一步与在新组织中担任任何类型领导角色的第一步相同：您需要规划组织的工作方式，特别是规划对您自己和您的角色的期望。当前流程是什么？谁担任哪些角色？您将继承、使用或创建的流程和项目的决策者和利益相关者是谁？

我的第一直觉是尝试将对这个角色的期望从与关键组织利益相关者的谈话中逆转出来。我向一组最初的利益相关者提出了一系列开放式问题，跟踪下一组问题的答案，跟踪团队和项目对下一组要交谈的人的引用，并重复直到我回答了所有开放式问题。我也很幸运能有几个小时的时间，接触到以前的首席技术官进行知识转让。由于我加入了一个有着悠久历史的成熟组织，过去曾做出过许多决策，其中许多决策都具有财务影响，因此我发现，从向前首席技术官提出有关继承预算和账户的问题开始，这一点很有帮助：

对于每个预算行项目，为什么要购买此服务以及它的用途是什么？是谁做的决定？它服务于哪些团队或流程？
对于您以前管理的每个帐户，为什么存在此帐户？谁决定采用它，它服务于哪些团队或流程？
对于预算和账户问题确定的每一个流程，其实施时间有多长？一年中什么时候？涉及哪些团队和利益相关者？
您个人负责管理哪些流程？
你必须签署哪些程序？
你被要求参加哪些会议或工作组？你对什么说是？为什么？你拒绝了什么？为什么？
你还记得把时间花在我应该知道的事情上吗？

在收集了以前 CTO 的团队和流程信息之后，我会见了 CTO 答案中确定的每个利益相关者，并讨论了他们参与的流程、他们过去与技术的互动、他们的经验和他们的期望。

我写下了所有的东西，并特别注意了关于技术和组织其他部分如何交互的隐含规范。总的来说，这些早期的会议，对于理解组织是如何工作的，以及技术团队在组织中是如何工作的非常有帮助。

我还发现，我不需要为这些利益相关者会议做太多的准备，我只需要展示议程项目“你认为我应该知道什么？”“准备好倾听。

考虑组织的阶段

对于任何新的领导者来说，《The First 90 Days》值得一读。这是一个指导，在新的领导职位的前90天内要问什么问题和做什么。我发现以下提示特别有用：

该组织处于什么阶段？ 本书使用 STARs 模型：启动、周转、重新调整和持续成功。组织的阶段很重要，因为它将决定可用的组织资源，组织的最高优先级，可能遇到的问题类型以及团队的组成和人员配置。
我怎样才能将策略与情况相匹配？ 有很多领导力策略，特别是如果你过去一直担任领导角色，要避免的一个常见陷阱是推出过去有效的流程，而不仔细考虑这个组织所处的阶段，这个特殊的团队和情况。
我可以获得什么“早期胜利”？ 将新领导者带入组织始终是一种风险：新领导者具有重要的地位权力，而且最初没有足够的背景来理解组织面临的当前和过去的挑战。新领导者必须迅速建立信任并获得组织成功的信心。一个直截了当的方法就是确定并推出 “早期胜利” - 显示您的优先事项的变化，并且是对长期运行会产生什么样的影响的早期一瞥。

在我与潜在客户和利益相关者的早期对话之后，我确定 MoveOn 的技术根据 STARs 模型处于重新调整状态。使用 The First 90 Days 剧本，这意味着我需要重新定义技术在这个组织中的作用，重组和重新聚焦技术资源，处理不再有用的根深蒂固的文化规范，并以一种尊重的方式谨慎地改变牧羊人的变化。当前流程和组织历史。

我也承认，虽然我曾在创业，周转和持续成功阶段的组织工作，但我以前从未参与过一次调整，因此需要注意不要重复使用有效的策略。在以前不合适的情况下。我决定专注于规划一些“早期胜利”，这些胜利证明了技术流程的变化是一件积极的事情，它使组织的其他成员受益并参与进来。

创建个人路线图

在确定了我认为 MoveOn 所处的组织阶段，制定组织项目、流程、角色、责任，并确定过去拥有什么技术以及为什么，我现在已经配备了足够的信息，来创建我自己的建议。我应该拥有什么，以及我的团队将拥有什么。

我将这个提案发布给了我的老板，领导团队以及我之前遇到过的主要利益相关者，得到了反馈，并将其作为我的个人路线图批准了。我特别注意自己和之前的首席技术官以及新聘用的技术团队之间的角色和责任是如何不同的。以下是本路线图的一些摘录。

前任 CTO 管理的事情我也将管理：

年度预算计划
核心系统和服务的管理员级帐户管理
法规数据政策管理：FEC 报告，PCI 合规性，GDPR
为核心技术系统构建或购买选择

我确定我将创建和管理的流程需求：

技术团队招聘
技术团队管理
围绕员工和组织网络安全的政策和标准
新的技术支持/快速响应技术问题解决系统
如何与技术团队互动的新论坛和规范

我会落日的过程：

通过直接编辑和检查 HTML 使员工更新基于 perl 的 Intranet - 替换为自助服务内部 wiki
通过直接编辑和检查 HTML，让员工更新基于 perl 的面向公众的网站 - 替换为 Wordpress 并培训如何使用 Wordpress 的管理界面
技术领域：我们将集中管理所有开发，项目管理和产品管理，而不是每个项目 1 名工程师，我们将集中项目和产品管理，所有开发人员都将在所有系统上工作

现在我清楚地意识到我的工作涉及的领域，我将拥有和不拥有的领域，以及我需要做出决策的地方。作为 CTO 的生产力单位不是编写的代码行，而是做出的决策。但即使有明确定义的领域，制定决策仍然很难。

征服时间管理

为了能够做出正确的决定，首先你需要控制你的时间。你需要弄清楚什么是可能性，并得到必要的上下文来定义和衡量权衡。

在一个著名的组织中担任权力职位的一个伟大而可怕的事情是，突然间每个人都想和你交谈！在成为 MoveOn 的首席技术官的一个月内，我发现我的日历一周又一周地填满了会议，这些会议对另一方有着模糊的价值，但对我来说却没有明确的价值。我不知道该对哪些会议说是或否。我发现，花大量的时间花在与渐进式组织空间相关的大量沟通和相关新闻上是很容易的，但是在处理紧急的团队问题上却没有时间。或者反过来说：我很容易把所有的时间都花在团队上，然后感觉与更大的组织或运动的工作脱节。如何平衡？

我很快意识到，我的时间是我拥有的最宝贵和最稀缺的资源，我需要策略来有意和公平地利用它。我负责一个新的、不断变化的责任格局。

建立跟踪时间的习惯

在 Laura Vanderkam 的时间追踪体验启发下，我开始详细跟踪我的时间。有各种各样的工具，如谷歌电子表格和 toggl。工具本身并不重要，只是追踪时间的习惯。每周，我都会跟踪我从头到尾选择完成的每项任务，以及任务所属的工作类别。我跟踪了我早上的电子邮件时间，与员工的 1 对 1 会议、技术团队会议、花费时间进行审查代码和结对编程，研究不同的框架选项，以便即将进行的设计决策。在每一天结束时，我都记录了我的时间。

我开始跟踪任务和任务类别。当我跟踪我的任务时，我发现我工作的大部分任务都属于以下类别：软件管理、跨团队沟通、跨组织工作组、技术战略和架构研究、动手技术工作，如结对编程和技术思想的领导，比如在会议上发言和写这篇文章。

在每周结束时，我查看了我的时间日志并寻找模式。我是否把时间花在了回想起来并不重要的任务上？我没有得到什么是重要的？上周我能说什么不对？我是否为重要的事情腾出空间，还是让我的日子充满了不太重要的任务？

然后我分析了我按类别花费时间的地方：我花了多少时间用于沟通？管理？我是否有足够的时间进行实际技术工作？我的重点是多么明确或分裂？

分析时间并寻找见解

回顾我的每周时间日志，我很快就发现了一些模式，这些模式让我可以深入了解默认情况下的时间，我真正想要的时间。这有助于我围绕自己所做的事情制定更多有意识的目标，并且在任何特定时间都没有能力承担，委派什么，以及说什么不对。

例如，我很快意识到，在我的电子邮件收件箱中保持100％是不值得的，但很难让自己远离恐惧错过重要的事情。渐进式组织空间完全是关于书面文字 - 许多组织者通过电子邮件进行规划和协作，大部分员工的工作产品最终都是通过电子邮件或博客发布的 - 因此我在一周的漫长工作中每周收到大约 800 封电子邮件。我需要浏览这些电子邮件中的至少一半，以便掌握新的广告系列，这些广告系列会影响我的技术团队所做的工作或受其影响。跟踪我的时间，我意识到默认情况下我每周会花 8 到 12 个小时的电子邮件 - 超过一整天的时间！与其他团队不同，电子邮件通信与我的实际工作产品相关，即技术问题解决，软件系统构建和扩展。我无法在电子邮件中花这么多时间。所以我想出了一个时间管理干预：我不再按顺序阅读电子邮件，而是开发了一个个人电子邮件过滤算法，该算法使用gmail过滤器将电子邮件按项目和主题放入优先级。如果我只有 5 分钟，我只会阅读优先级最高的电子邮件。如果我有更多的时间，我会按照优先级排序。在调整过滤器几周之后，我最终得到了一个足够好的系统，并设法保持最佳工作的电子邮件通信，每 1-2 周一次浏览其他所有内容，让我减少到 3 个小时花在电子邮件上的一周 - 每周节省一整天！

每周跟踪时间也有助于我了解需要花多少时间来承担不同类型的项目和责任。我发现作为参与者，参加任何跨组织工作组的成本是每周 2 小时，如果我领导该组，则为 4 小时。结果，我决定我一次只能承载这些类型的项目之一，这有助于我提高我的专注力，并拒绝额外的工作组职责。

我发现员工绩效评估每季度花费 20 个小时来编写和交付，每年预算编制过程花费 10 个小时，招聘流程需要 6 个星期 25 个小时，团队管理人员每周花费 10 个小时非可协商的团队会议和1-1时间。有了这种更清晰的经常性义务和所需时间的意识，我开始明白我的时间有多少，然后能够更有意识地开始消费。

时间管理策略

我发现 Cal Newport 的《Deep Work》和 David Allen 的《Getting Things Done》对于制定时间管理策略非常有帮助。

《Getting Things Done》鼓励您将正在进行的工作和项目跟踪为 “开环” （open loops）。当人们要求你做事或回答问题时，如果不到两分钟，那就去做吧。如果需要更长时间，找出最终目标是什么，什么是可操作的并将其捕获为 “开环”。在将注意力从开环转移之前，请记下下一个可操作的步骤，这样当您返回任务时，它立即可以操作，您不必浪费时间将自己拉回到项目的完整环境中。当 “工作” 不仅涉及代码而且涉及通过电子邮件跟踪通信时，这很有用，并且您有大约 10-20 个定期需要跟进的活动项目。

《Deep Work》鼓励您将认知要求严格的 “深度工作” （Deep Work）与不认知要求的 “浅层工作” （Shallow Work）分开，首先优先考虑 “深度工作”，创建成功完成深度工作所需的适当焦点时间，并极力保护这一时间。对我来说，路线图，制定或购买决策，危机干预研究，预算编制以及编写单词和代码都是深度工作。代码审查，电子邮件，咨询其他团队，行政管理，如费用报告，利益相关者跟进和社交媒体都是浅薄的工作。很容易让你的一天充满 Shallow Work，所以反而积极地为 Deep Work 焦点会议留出时间（对我而言，这需要一次 90 分钟），并让 Shallow Work 填写这些焦点会议。这类似于许多管理哲学中的“大岩石第一”概念。

专注于极其重要的事物

一旦你有适合你的时间管理系统，并在你的个人路线图的指导下，接下来要弄清楚的是如何度过你日常的宝贵时间。

默认情况下，作为领导者，您可以轻松地将大部分时间用于捕获需求和需求，从而增加您的待办事项列表。大多数电子邮件都在寻求一些东西：建议，时间，决定，许可，资源。大多数会议都是讨论但未完成工作的地方。您可以在一整天内轻松完成将项目添加到待办事项列表中的活动，或者阻止您处理待办事项列表。结果是一种压倒性的感觉，并且不断变得越来越落后。该怎么办？

每天的每个小时，您都会决定花时间做什么是最重要的 - 每次执行此操作时，您都会将自己的个人决策算法应用到您的时间。无论您的决策制定算法是什么（或者您认为自己的算法是否合适），您都需要知道它的表现如何，并随着时间的推移将其调整为更好。您需要设定明确的目标，专注于这些目标，并参与反馈循环，告诉您在实现目标方面的表现如何。

设定明确目标：

在每周开始时设定目标：本周你必须完成的2或3件事情是什么？您的日历上是否有空间来完成这项工作？如果没有，取消或推迟会议，直到有。
在阅读电子邮件之前每天设定目标：今天你必须完成的一件事是什么？在检查电子邮件或走进办公室之前写下来，并在开始互动时继续关注它，并开始接收新的工作请求。

为与目标相关的工作留出时间：

在日历上获取工作区：其他人通过安排与您的会议来消磨时间。您可以通过安排日历上的工作块来节省自己的时间，以便为重要工作留出时间，并确保您有足够的时间开始并完成认知要求高的工作。
做或委派？虽然大多数工作要求都会流经您，但您不仅要对自己的工作计划负责，还要对团队的工作计划负责。它可能很容易意外地囤积或瓶颈工作，然后不堪重负。尽可能默认为委派。一个好的经验法则是只做你能做的事情。委派你只会做得更好的事情。为您的团队提供真正的所有权和责任

专注于您的目标：

如果不知所措或不确定，请保持现在最重要的事情的清晰度。有什么选择可以推动您实现每日或每周目标？当您完全休息并以合理的速度工作时，您具有评估整个选项范围并做出谨慎决策的认知能力。但如果你在忙碌的消防日的第 12 小时，你可能会遇到决定疲劳。当你处于这种状态时，不要试图做出更多或新的决定，只关注那个最重要的事情，然后在休息时重新调整并重新评估情况。
相信你的判断：当精疲力竭或不堪重负时，很容易开始怀疑或猜测你的判断。这可能会导致您无法在任务之间来回切换，或导致您以非生产性或混乱的方式重定向您的团队。明智地制定战略重定向，因为团队环境转换导致生产力成本高昂。请记住，在新工作几个月或新项目几周后，您确实拥有做出正确决策所需的背景。

反馈回路：

在一天结束时，检查您是否遇到了今天的一个目标。写下来，不要花费超过 5 分钟来考虑它。如果是这样，你做了什么使得这成为可能？如果没有，你怎么能重新安排你的一天来实现这个目标呢？
在本周末，检查您是否达到了本周 2-3 个目标。如果是这样，你做了什么使得这成为可能？如果没有，你怎么能重新安排你的一周来实现这个目标？有会议你可以推迟到另一周吗？你应该委派的问题？不要花费超过 15 分钟。
特别是，我发现继续运行 “绝对值得花时间的东西” 和 “绝对不值得花时间的东西” 的列表是有帮助的 - 当我遇到它们时，我会记下新项目，如果我是面对什么感觉像是一个新的困境，或者我已经厌倦了，只是简单地决定疲劳，我在做出决定时遇到了困难，略读这些列表有助于我寻找新任务可以适应的模式，以指导我的决定。

调整个人决策算法最重要的部分不是你设定的目标，而是花时间进行反馈循环。有了反馈，随着时间的推移，你会变得越来越好。

调整个人路线图

在研究，定义和批准我的个人路线图之后，现在我有了一大堆我将拥有的东西以及我的团队将拥有的东西，我有一个明确的领域，我将成为关键的决策者。有了时间管理策略和个人反馈流程，每天我都觉得我更有意识地花时间。审核我的时间在特定类别中的位置，我意识到特别是对于技术领导职位，我需要非常仔细地，有意识地弄清楚我的时间如何在软件工程、软件管理和组织领导的关键领域之间分配。

软件工程的世界总是在变化和发展，但是或多或少有一个关于软件工程工作所需要的标准手册 - 架构、构建、测试、扩展、修复，在一些编程语言和框架中启动代码。大多数工程师都有类似的典型日常工作，而且大多数管理人员都会让工程师明确期望他们应该做什么工作，以什么方式，在什么时间表上。

软件管理更加模糊，但通常涉及人员管理，技术决策，Building a Software Engineering Culture Where Everyone Can Thrive，每个人都可以茁壮成长，并且取决于组织的规模，一些项目，程序和产品管理。

组织领导涉及定义团队与其他团队的交互方式，定义团队在大型组织中的角色，并涉及一定数量的“驾驭船舶”，参与讨论组织应关注的内容，应该解决的问题解决，它应该如何成长。

这里没有一个正确的答案 - 在不同的时间，技术领导者可能不得不在一个领域花费更多的时间，然后随着项目启动和组织环境的改变，焦点可能会发生变化。与时间管理策略一样，这里的重要部分是有意识地花时间在哪里。特别值得注意的是，要了解哪些区域适合您。您自然会倾向于舒适区域，特别是在疲劳或压力时。编码是否比决定如何实施即将发生的法规变更更准确？您可能会通过一个非常有趣的编码挑战来拖延监管决策，这个挑战突然出现在您的板块上。重要的是要知道哪些区域是舒适区域，哪些区域是增长区域，并确保您在正确的时间有意识地将时间花在正确的区域，特别是您在增长区域花费了足够的时间。

可能是大多数新技术领导者在组织领导方面缺乏经验的领域。提高组织领导力的最佳方法就是做更多的组织领导。

但这可能是非常耗费精力的，因为总有更多需要监督的项目，需要干预的问题，以及希望吸引您提供帮助的团队。我经常面临的一个关键挑战是弄清楚如何在保持技术的同时做出重要的组织领导。

保持技术

技术领导力不仅要充分利用您的时间，还要掌握快速发展的工具，系统和标准。每隔几年就会改变生态系统标准，以确定哪些问题容易或困难，昂贵或便宜，可扩展或瓶颈。对我来说，这是从事科技工作最激动人心的部分，但它也带来了独特的领导力挑战。作为技术领导者，不可能实际阅读所有代码，监控所有变更，管理所有系统，试验所有新工具和框架，阅读所有文章。即使你设法克隆了几次并尝试做所有事情，你也可能会让你的团队疯狂地进行微观管理。

面临的挑战是弄清楚与委托相关的技术工作，以及在没有瓶颈工作或微观管理的情况下保持参与技术细节的水平。以下是我发现有用的一些策略。

寻找复杂性并预先加载它：您的团队在未来 6 个月内将面临哪些最大的技术挑战？这可能是称重生产系统的遗留代码的定时炸弹，需要扩大 10 倍的系统，将影响团队工作方式的新监管变更，是否投资新系统或生产线。你可能无法自己解决这个领域的所有问题 - 你需要整个团队来解决它，但是你需要精通足够的可能解决方案，以便能够指出它们正确的方向，构建关键问题，并在与空间相关的权衡中充分流利，以便能够引导利益相关者。您通常可以将这些区域标识为您的待办事项列表中看起来最无限或可怕的内容。在您的日历上获取深度工作重点块，并开始深入挖掘。通过安排与利益相关方的会议，向他们介绍他们以后必须做出决策的挑战和权衡，为这些挑战创建最后期限和问责制。

如果你进行实际的技术工作，优先考虑解除大多数人阻碍的工作：虽然当你是个人贡献者或技术工作时，你可能很喜欢倾向于最有趣的技术工作，但你最有信心你知道该怎么做，如果你接受其他团队成员也可以做的技术任务，你很容易就会最终囤积或者瓶颈工作，最糟糕的是让你的团队失去权力，他们也想要从事有趣的工作。保存为您的团队带来最多技术荣耀的任务，而是集中精力完成解锁大多数人日的任务 - 每个人都在回避的怪物 Pull Request，令人烦恼的数据库迁移需要几个小时来照看孩子，构成或购买决策带来的风险最大。您在技术领导岗位上所能提供的最大价值不是您团队中软件工程师的编码速度快2倍，而是找到解锁或简化整个团队的方法，这将对网络团队生产力产生更大的乘数效应，而不是您更快或更有经验的实践技术工作的增量值。通过巨大的乘数效应来挑选烦人的任务，也为团队提供了关于领导角色的良好榜样。

找到插入有双重用途的技术环境的方法。您永远不会有时间阅读所有代码库，浏览所有变更集，并保持所有架构决策的流畅性，而且您将永远没有足够的时间将所有质量时间花在您想要的每个团队成员上，因为时间是你最稀缺的资源。抵制向你不断增长的待办事项清单添加 “学习框架X” ，或者 “弄清楚 Y 功能如何工作” 等 “追赶” 任务的冲动 - 通常情况下你不能完成这个 “追赶” 任务。在技术系统中越来越多地感受到这种情况可能会令人生畏，特别是如果您患有冒名顶替综合症，并且您习惯于比其他人更努力地工作以建立和维持基线技术可信度。因此，找到方法逐步赶上有双重目的的技术背景。为此，我喜欢预定的结对编程和重复代码审查。

预定结对编程：只需将其安排为与您的一名工程师会面并显示即可。忘了知道一切，感到愚蠢，为不知道所有事情而道歉。你不可能像工作人员那样在杂草中（因为在他们深入的时候，你的工作是广泛的），但你可以出现，提出问题，一起工作。故意模特正在问’愚蠢’的问题。配对可以让您的工程师对他们的工作给予关注和欣赏，并且他们可以成为专家。随着你的共同努力，定期回复以确定你明白。这将帮助您更快地赶上代码库，而不是自行完成代码阅读代码，这反过来又为您的工程师建立了有效的学习模型。

复述代码和架构检视：当你试图成为一项优秀的运动时，该怎么做，并拿起其他人都在避免的怪物代码审查，但后来你意识到你缺乏能够判断设计决策或风格选择的背景？安排与提交代码审查的工程师进行“谈话代码审查”会议 - 这不必超过 20 分钟 - 并逐节讨论他们的变更集。让他们引导解释，每隔 5 分钟左右停下来 “重复” 他们用你自己的话所描述的内容。解释的性能方面确保您将成为一个积极的倾听者，并将迫使您自己澄清您是否理解他们做了什么以及为什么做。它也总是比阅读代码库或修补系统以获得所需的上下文更快。阅读代码并修补它总是很有趣，但有时你只需要 20 分钟就可以选择 2 小时，并且必须使用你所拥有的东西。与预定结对编程一样，这不仅可以节省您的时间并为您提供所需的背景，还可以让您的工程师对他们的工作给予关注和欣赏，并且他们可以成为专家。

管理信心并为自己创造安全的空间

为您的团队创建安全的空间，是 Building Software Engineering Environments Where Everyone Can Thrive 的重要组成部分，每个人都可以茁壮成长，但除了确保您的团队有安全的空间，来提出 “愚蠢” 的问题并获得反馈之外，您也需要这样做。您的技术领导力越大，团队规模越大，您做出决策的次数就越多，但您对决策的反馈越少，您解决问题的权利就越多，或者无法做出权衡。明确的先例或正确或错误的答案。这最终会让人感到孤独和畏惧。您可以尝试从您的团队获得反馈，但由于持有位置权力的动态，您不可能获得直接，直接的反馈 - 您的直接报告不会拥有相同的上下文，并且每个人总是有点害怕批评他们的老板。

因此，走出去寻找一些 Tech Lead 的同行，建立关系，并为自己建立安全的空间，在那里你可以交换故事并得到你需要感到自信和负责任的真实反馈。我喜欢与其他进步组织的同行定期举行签到会议。

跟踪和监控自己的信心也很重要 - 了解您何时感到自信，什么时候不信任以及这有什么迹象，并为自己创建一个工具箱，让您自信地建立干预措施，您可以部署干预措施来支持自己你需要它。

如果我感到疲倦或恐惧，当人们向我提问或向我提出问题时，我会开始变得更加反应，特别是当我累了时，我倾向于怀疑问题比实际上更复杂。因此，当我意识到我立刻说是或者试图立即解决所提出的问题而不进行范围界定和理智检查时，我会理智地检查自己。

当我需要干预并加强我的信心时，我会尝试以下一些策略：

我喜欢教人们编写代码 - 没有什么比向某人展示自动化的魔力更有趣，并帮助他们意识到他们也可以利用代码的力量，特别是如果他们以前被吓倒了。因此，我尝试定期为组织提供志愿服务，以便教人们编写代码，例如我在本地的 GirlDevelopIt 章节。教学帮助我记住我最喜欢的软件工程，帮助我巩固自己对核心概念的理解，并让我进入一个我已经是专家的论坛 - 所有这些都带来了信心。
我会做一个心态干预（来自 Kelly McGonigal 的优秀书籍：The Upside of Stress: Why Stress Is Good for You, and How to Get Good at It）就像花 15 分钟写下我的价值观，重新构思我的思维方式什么对我很重要，为什么，以及我的价值观如何与我的技术领导相关。
庆祝成功：给自己一个金星，写下你最近为自己感到骄傲的胜利，并将其放在冰箱上，打电话给家人或朋友告诉他们。无论以何种方式对您有意义，明确表示您已经完成的工作。我剪辑了引用 MoveOn 活动或项目的新文章，我特别自豪，把它们挂在我身后的墙上，然后每当我进行视频会议时，我都会看到它们。
帮助他人：在任何时候，我都会指导 1-2 名初级开发人员，或者有兴趣开始科技事业的人。这不是服务，而是增长的互利机会。当我们谈论目标，斗争，焦虑，前进的道路，而不是想知道我是否足够好时，我突然想起了我的心态，让我的学员放心，事实上他们已经足够好了，我记得成功是不是为了好或是完美，而是关于勇气和努力实现明确的目标。突然之间，我记得自己的自信，因为我需要建立信心，以帮助他人找到并增强他们的信心。

你有这个

开始一个新的技术领导角色将是艰难和压力，但也非常有益。

随着您在软件工程领域的进步，您将学习编码，然后学习更好，更快的代码，然后您将学习如何解决要解决的编码挑战，以及问题中简单和优雅的价值取景。在美好的日子里，有时候你的个人速度可能比预期快 10 倍，你会感觉自己像个巫师。

随着您在软件管理职业生涯中的进步，您将了解到，按正确的顺序，在正确的时间，对正确的工作进行排序，使整个团队能够有效地解决问题。您将了解构建每个人都可以茁壮成长的软件工程环境的重要性。您将了解到，确保团队中的人员能够倾听并感受到尊重，从而提升员工的能力，使他们更加自信和富有成效。您将学习如何支持您的团队的专业发展。当您的团队满意时，您的团队流程正在运作，您的团队目标明确，您将解锁并提高整个团队的工作效率。这种倍增效应比你个人在真正好日子里工作的速度快 10 倍。

随着您在技术领导职位上的进步，您可以指导整个组织使用技术来扩大他们的工作，使以前不可能解决的问题成为可能，并扩展系统以产生国家或甚至全球影响。组织领导能够影响，扩大和支持 100 或 1000 人的工作。在正确的时间用技术放大的正确想法可能会影响数百万人。即使是效率最高的开发人员或开发人员团队可以做的工作，这种乘数效应也要高出几个数量级。

这是很大的力量。您可以使用它，并且可以使用它来创建和扩展使世界变得更美好的项目！

techlead

Tech Lead Toolbox