大联盟（The Big Leagues）

高级管理者（senior manager）的日常工作在很大程度上取决于你所在的公司。如果我说我管理一家 70 人初创工程组织的日常工作，与一位在财富 500 强公司管理数千人的高级管理者的工作完全相同，那就太愚蠢了。关于大型公司的高级管理，从一般性视角出发写成的书已经浩如烟海。在本章末尾，我列出了一些推荐读物，供你获取通用型的高级领导力建议。所有这些书都是写给高级领导者的精彩且必要的指南。

但我们不是通用型的高级领导者。我们是技术类高级领导者（technology senior leadership）。这本书写给那些写了一段时间代码、最终转入管理岗、并沿着这条路成功发展出职业生涯的工程师。作为工程师，我们肩负着一些共同的职责，这些职责源自我们作为技术人员的角色，部分也来自我们在那个日新月异的世界里工作所受到的熏陶。

作为技术类高级管理者，我们为组织带来了特殊的技能。尤其是，我们带来了按需拥抱和推动变革的意愿。我们能够质疑我们目前做事的方式，如果当前运作方式行不通，就尝试不同的方法。我们明白技术演进很快，我们希望自己的组织也能随之演进以跟上这些变化。我们扮演着独特的角色，但我们仍然需要在通用高级管理职责上取得成功。仅仅做一个变革推动者（change agent）是不够的；我们必须打造一个能够成功贯彻我们想要推动的变革的组织。

你的首要工作是成为一名领导者。公司指望你指引方向：做什么、往哪里去、如何行动、如何思考、以及看重什么。你为组织内的互动定下基调。人们加入公司，是因为他们相信你、相信你招来的人、相信你参与塑造的使命。

你有能力在不掌握完美信息的情况下做出艰难决定，并愿意承担这些决定的后果。

你有能力理解业务的当前格局，也能看到它众多可能的未来。你知道如何为未来数月乃至数年做规划，使你的组织能以最佳状态应对那些可能的未来，并在机会出现时抓住它们。

你理解组织结构（organizational structure）及其对团队工作的影响。你知道建立一种强化而非削弱这种结构的管理体系的价值。

你能以建设性的方式玩转政治（politics），以推动组织和业务前进。你能与工程部门之外的同级同事良好合作，并在处理范围广泛的问题时寻求他们的视角。

你懂得如何对一项决定持有异议，却仍然承诺去执行它，即使你并不同意。

你知道如何让个人和组织对他们的产出负责。

在他所著的《格鲁夫给经理人的第一课》（High Output Management）[1] 一书中，安迪·格鲁夫（Andy Grove）把管理任务分解为四大类：

信息收集或信息共享（Information gathering or information sharing）

开会、读写邮件、一对一谈话、收集各方观点。强大的高级领导者能够快速综合大量信息、识别其中的关键要素，并以相关第三方能够理解的方式与他们分享这些信息。

轻推（Nudging）

通过提问而非下命令来提醒人们履行他们的承诺。大型团队的领导者很难强力地把团队推向任何方向，因此要依靠轻推团队成员，让整个组织保持在正轨上。

决策（Decision making）

面对相互冲突的观点和不完整的信息，确定一个方向，同时明白一个糟糕决定带来的后果既会影响到你，也可能波及整个团队。如果做决定很容易，对管理者和领导者的需求就会小得多。然而，任何花大量时间做管理的人都会告诉你，做决定是这份工作中最耗神、压力最大的部分之一。

以身作则（Role modeling）

向人们展示公司的价值观是什么。兑现你的承诺。即使你状态不佳，也要为团队树立最好的榜样。

无论你是首席技术官（CTO）、副总裁（VP）、总经理（general manager）还是工程负责人（head of engineering），你的每一天都由这四类任务塑造。

我的工作是什么？

我是从行业里所谓的「非传统背景」（nontraditional background）进入工程领域的。在与来自传统计算机科学背景的人打交道时，我深受（或许仍在受？）强烈的冒名顶替综合征（impostor syndrome）之苦。当我领导那些我认为比我更懂技术的人时，这尤其困难。

这种背景，加上渴望被看作聪明、「正确」的强烈愿望，有时会带来一些关于技术方向的低效对话。我会发现自己纯粹基于技术优劣去争论某个语言或技术的选择。发生这种情况时，我就变成了工程师堆里又一个争吵的工程师。

我花了很长时间才意识到，我的工作不是做房间里最聪明的人，也不是证明自己「正确」。相反，我的角色是帮助团队做出尽可能好的决策，并帮助他们以可持续、高效的方式实施这些决策。

我在乎技术——它是我们团队每项决策中的一个因素——但仅凭技术并不能造就一支高效而快乐的团队。一位优秀的领导者会引导技术讨论，注入战略目标，并考虑一项技术决策的非技术影响。重点不在于当首席工程师、追逐最新的语言或框架、或拥有最炫的技术。重点在于打造一支拥有合适工具和特质的团队，为我们的客户构建尽可能好的产品。

詹姆斯·特恩布尔（James Turnbull）

思考技术高级领导力的模型

对于 CTO 这份工作，我有非常鲜明的观点，尤其是它适用于以产品为核心的初创公司时。我坚持这个观点，但我也明白它并非所有公司 CTO 的通用模型。我也知道，高级管理层的职责划分存在大量模糊地带。工程副总裁（VP of Engineering）应该放在哪里？首席信息官（CIO）呢？那是一个我们必须填补的角色吗？产品团队呢？

我不打算试图覆盖高级领导层中所有角色变体，而是先从解释高级管理层最常见的几种角色开始，以及这些角色如何组合在一起。这些描述对你的公司可能说得通，也可能说不通。有些人能身兼数职，有些人只能扮演其中一两个角色，还有些公司根本不需要有人扮演所有这些角色。在公司足够大之后，所有这些角色都会被拆解，那时你往往必须按部门来审视这些角色。但通过呈现这样一套分类（taxonomy），我希望帮你思考在各类高级领导岗位上取得成功可能需要的技能。常见角色包括：

研发（Research and development，R&D）

有些公司专注于拓展技术前沿，因此技术组织里可能有一位专注于实验、研究和新技术生成的高级领导者。这个角色可能负责技术战略（technology strategy），也可能纯粹是一个寻找新想法的角色。

技术战略/愿景家（Technology strategy/visionary）

技术战略与产品开发交汇。这个人通常也管理产品组织。他专注于技术如何被用来推动业务增长，并致力于预测技术在该公司所处行业中的演进。这与研发不同，因为愿景家通常不专注于研究潜力；他用商业和技术趋势来指导自己的决策。

组织（Organization）

组织管理者引导组织中的结构和人员。她负责人员配置计划和组织结构，确保项目得到相应的人员配备。这个角色常与下文讨论的「执行」搭配出现。

执行（Execution）

通常与「组织」搭配，这个人确保事情真正落地。他帮助对齐路线图（roadmap）、规划工作、协调大型项目。他确保项目得到优先级排序。他扫除障碍、化解冲突、做出决定，让团队向前推进。

对外技术代言人（Face of technology，external）

当一家公司向其他公司销售基于软件的产品时，通常会有一位高级技术领导者被期望参与销售环节。她可能会出席客户会议、在大会上演讲，以鼓励人们使用产品。一家为了招聘目的而投入建设工程品牌的公司，也可能需要某位高级领导者通过参加会议演讲和招聘活动来扮演这个角色。

基础设施与技术运营管理者（Infrastructure and technical operations manager）

这是对所有技术基础设施及基础设施运营负责的人。根据公司和所处发展阶段的不同，这个角色可能以成本、安全或扩展（scaling）为重心。

业务高管（Business executive）

这是一个首先关注业务本身的人。这个人懂行业，也在较高层面理解业务的其他关键职能。他平衡内部发展需求与业务增长需求，并在较高层面主导项目的优先级排序。

以下是我亲身观察和隔岸观察到的这些角色的一些组合：

业务高管、技术战略、组织、执行：CTO 或工程负责人（VP/SVP）
研发、技术战略、对外技术代言人：CTO、首席科学家（Chief Scientist）、首席架构师（Chief Architect），有时是首席产品官（Chief Product Officer），通常适用于销售基于软件产品的公司
组织、执行、业务高管：工程副总裁、总经理
基础设施管理者、组织、执行：CTO/CIO，也可能是技术运营副总裁
技术战略、业务高管、执行：产品负责人（Head of Product）（或首席产品官），有时是 CTO
研发、业务高管：CTO 或首席科学家、联合创始人
组织、执行：工程副总裁，有时是幕僚长（Chief of Staff）

如你所见，组织可以根据业务需求以不同方式混搭和定义这些角色。尤其是 CTO 这个角色，其重心会随公司不同而剧烈变化，不过大多数出色的 CTO 麾下都有一项战略职能，无论是业务导向、技术战略导向，还是两者兼有。

什么是工程副总裁？

在一个由 CTO 担任整个工程部门执行管理者、负责战略领导和监督的组织里，工程副总裁做什么？一位出色的工程副总裁是什么样子的？

与 CTO 角色一样，工程副总裁的角色也随组织需求而千差万别。不过，副总裁角色与 CTO 角色有一个明显区别：副总裁通常是工程师管理职业阶梯（career ladder）的顶端。这通常意味着副总裁被期望是一位经验丰富的人、项目、团队和部门管理者。

随着公司成长，副总裁级别的角色从组织导向的职位转变为业务战略职位，这很常见。这些人通常扮演各事业部的「小 CTO」，平衡战略与管理。你最终可能会有多个人担任「工程副总裁」角色，各自负责工程团队的一部分。随着时间推移，他们的角色越来越偏战略，而组织管理职责则更多地落到他们手下总监（director）或高级总监（senior director）级别的副手身上。让我们把大公司的复杂性放在一边，聚焦于你在一个只有一人担任该角色的公司里最可能遇到的工程副总裁。

作为团队日常运营的负责人，一位优秀的工程副总裁对流程和细节有扎实的把握。她能够同时跟踪多个进行中的计划，确保它们都进展顺利。出色的工程副总裁常被形容为拥有扎实的「地面战」（ground game）能力——能够沉入细节，在低层级把事情做成。有些 CTO 也会这样做，但如果公司同时有 CTO 和工程副总裁，通常由副总裁推动想法的执行，而 CTO 专注于更大的战略以及技术在公司中的地位。

工程副总裁还承担着大量管理责任。她把开发路线图与招聘计划对齐，规划团队需要如何演进以适应预期的人员增长。她可能与招聘团队紧密合作、主持招聘流程，确保简历筛选和面试顺利进行。她应该是工程管理团队的教练，识别并提升现有人才，并与人力资源（HR）合作，为这些管理者提供培训和发展资源。

工程副总裁这份工作既庞大又注重细节。这也是它如此难以招聘的原因之一，尽管大多数公司都需要从外部招入这个角色。这个人必须善于快速理解组织中正在发生的事情。她必须赢得人们的信任，并在管理和领导中展现智慧。不幸的是，大多数工程师不愿信任没有技术可信度的人，而许多达到这个资历层级的管理者又不愿意经历严格的技术面试流程，只为接手一个主要聚焦组织管理岗位。

工程副总裁还需要在组织战略中有一定的话语权，而且她常常完全拥有这项战略。她会深度参与帮助团队设定目标以实现业务交付物，这意味着她需要与产品团队保持紧密对齐。她必须确保路线图是现实的，业务目标被转化为技术组织可实现的目标。她应该有很强的商业和产品直觉，有带领团队交付大型项目的记录，包括谈判交付物的能力。

我认识的那些在这个岗位上表现出色的人，都是关心团队、有能力、且宁愿远离聚光灯、专注于打造高绩效组织的工程师。他们对让人们有效协作的复杂性感兴趣。他们希望团队快乐，但他们知道必须把这种快乐与成就感挂钩。他们向其他高级领导者代表团队的健康状况，并培育一种健康、协作的文化。他们非常善于识别流程中的缺口，并且能在不被压垮的情况下管理高度复杂、细致的工作。

什么是 CTO？

在小公司或初创公司里，「高级管理层」往往意味着你的头衔是 CTO。然而，CTO 却是技术界定义最不明确的角色之一。如果你是 CTO，你应该做什么？如果你想成为 CTO，你需要做什么才能到达那里？

让我们先谈谈 CTO 不是什么。CTO 不是一个工程角色。CTO 不是技术阶梯的顶端，也不是工程师应该在其职业生涯中努力达成的自然晋升。对大多数热爱编码、架构和深度技术设计的人来说，这不是一个他们会享受的角色。由此可知，CTO 不一定是公司里最优秀的工程师。

那么，既然 CTO 不是最优秀的代码写手、也不是工程阶梯的自然顶点，他到底是什么？

定义 CTO 角色的挑战在于：如果你看看那些拥有这个头衔的人，会看到许多不同的形态。有些是技术联合创始人。有些是最优秀的老工程师。有些一进公司就带着这个头衔，而另一些人（比如我自己）是随着时间推移被提拔到这个位置的。有些人在担任工程副总裁之后成为 CTO。有些人关注工程的人员与流程、招聘与招募。另一些人关注技术架构或产品路线图。有些 CTO 是公司在外部技术世界的门面。有些 CTO 没有直接下属，而另一些则管理整个工程组织。

看过所有这些不同的例子后，我能给出的最好定义是：CTO 是公司在当前演进阶段所需要的技术领导者。对我而言，这个定义相当令人不满，它漏掉了这份工作最难的部分。展开来说，CTO 应该是公司在其当前演进阶段所需要的战略性技术高管（strategic technical executive）。

我说的「战略性」是什么意思？CTO 思考长远，帮助规划业务的未来以及使未来成为可能的要素。

我说的「高管」是什么意思？CTO 把这种战略思维变成现实和可运营的东西——拆解问题，指挥人们去执行。

那么，CTO 到底做什么？

首先也是最重要的，CTO 必须关心并理解业务，能够通过技术的透镜塑造业务战略。他首先是高管，其次才是技术专家。如果 CTO 在高管席上没有一席之地，不了解公司面临的业务挑战，他就无法引导技术去解决这些挑战。CTO 可能会识别出哪些领域可以用技术为公司创造新的或更大的业务线，使其与公司整体战略一致。或者，他可能只是确保技术始终演进，以预见并支撑业务和产品路线图的潜在未来。

无论如何，CTO 必须知道业务最大的技术机会和风险在哪里，并专注于从中获益。如果他聚焦于招聘、留任、流程和人员管理，那是因为这是当下技术团队最需要关注的事。我提出这个观点，是与「首席极客」（chief nerd）那种认为 CTO 应专注于纯技术问题的观念相对照的。

出色的 CTO 也承担着重要的管理责任和影响力。这不一定意味着他们深度参与日常管理，但保持你塑造业务方向和业务战略能力的一部分，就是把人员放到解决你认为会影响业务的问题上。其他高管会对技术有自己的想法和需求。CTO 必须保护技术团队，使它不至于变成纯粹执行他人想法的工具，而无暇顾及自己的需求和自己的想法。

当团队变得非常庞大、CTO 开始雇佣副总裁来管理所有人员时，事情就变得棘手了。许多 CTO 把所有管理职责都交给副总裁，有时甚至到了副总裁不直接向他汇报的地步。作为一个没有任何汇报权力的高管，要维持影响力和有效性极其困难。

我在前雇主那里清楚地看到了这一点：大型业务领域里最资深的技术人员常常拥有该领域的 CTO 头衔。这些人总是备受尊敬、技术过硬。他们懂业务及其技术挑战，经常被请去激励工程团队、帮忙招聘。然而他们很难取得成功，因为他们往往缺乏对任何团队的直接管理监督，而且技术常被视为执行工具，他们没有太多战略影响力。

如果你是一个对业务战略没有权力、也没有能力把人员分配到重要任务上的领导者，你至多只能仰赖你对其他高管和管理者的影响力，最坏情况下你只是个傀儡。你不能在放弃管理责任的同时不放弃随之而来的权力。

一个不拥有管理权威的 CTO，必须纯粹靠影响组织来推动事情。如果管理者们实际上不愿把人员和时间投入 CTO 认为重要的领域，他就等于被架空了。如果你放弃管理，你就放弃了你对业务战略曾拥有的最重要的权力，你实际上只剩下组织里的好人缘和你自己的两只手。

我对有志成为 CTO 的人的建议是：记住这首先是一份业务战略工作，同时也是一份管理工作。如果你不在乎你的公司所经营的业务——如果你不愿意为带领一大群人有效攻击这项业务承担最终责任——那么 CTO 这份工作不适合你。

问问 CTO：我该往哪走？

工程领导层的各种头衔让我很困惑。CTO、工程副总裁——有什么区别？我怎么知道自己想担任哪个角色？

我理解这种困惑。网上有大量流行文章讨论这些角色的区别，因为除了「视情况而定」，很难给出具体答案。当然，做这两份工作有非常多的不同方式。

要决定你想要哪份工作，你可以问自己几个问题。你有没有想过有一天会联合创办一家公司？你想帮助监督技术架构、并为其演进制定流程和准则吗？你愿意深入了解业务侧的事情，以便让技术架构扎根于公司增长吗？你愿意出席外部活动、演讲、向客户销售、招聘高级管理者和工程师吗？你愿意管理与辅导资深个人贡献者（individual contributor）吗？那你可能适合当 CTO。

那管理呢？你喜欢管理人吗？你喜欢让工程流程更高效吗？你喜欢对团队所做的工作有宏观视野、并参与为这些工作排定优先级吗？你对组织结构着迷吗？你擅长与产品经理合作吗？你愿意用对技术细节的深度关注，去换取对团队整体效能的关注吗？你更愿意坐在路线图规划会上，而不是架构评审会上？那你可能更倾向于走工程副总裁这条路。

有些人的答案会两者兼有。我当过工程副总裁，也当过 CTO，两次都是被提拔上来的。我一直在思考技术架构，但当工作有需要时，我也乐于聚焦组织。不过对我来说，只有组织层面的关注不足以让我保持动力。我喜欢思考组织结构，但会厌倦流程细节和路线图规划，我需要有一些技术和业务战略层面的监督才能投入其中。

成为 CTO 最快的路径是成为技术联合创始人，但这只能保证在你和初创公司共同成长期间你拥有这份工作。成为工程副总裁最快的路径，是在更大的组织里获得管理经验，然后加入一家成长中的初创公司。

最后送你一句我自己的工程副总裁曾经给我的建议：「想当 CTO（或工程副总裁）就像想结婚。记住，重要的不只是头衔，公司和人也同样重要。」头衔绝对不是一切。

优先级变更

某天早晨，CEO 醒来，在清新的晨光中灵光一现。她看到公司有机会开发一条新产品线，可以把业务推向新的增长阶段。她花了一些时间勾勒这个愿景，并向其他高级领导团队展示。大家认可了这个变革，开始采取行动让愿景成真。但事情不会很快发生。还有进行中的项目需要操心。有些事已接近完成，在完成前取消它们太可惜了。所有这些顾虑意味着团队迟迟无法聚到一起投入这项新计划，直到突然有一天，问题砸下来：所以，你们为什么不做最高优先级的事？

高级管理层的优先级变更有时会毫无预警地发生。那些远离团队日常日程表的领导者会忘记：团队有长长的优先级清单，这些清单可能是在几周或几个月前排定的，也可能需要几周或几个月才能完成。所以当这些领导者看到机会、或觉得组织的优先级需要改变时，他们往往期望改变立即发生，而不考虑当前事态的现实。

这个问题可能会被问向每一层级的管理者，但最常见的源头是高级管理层。准备好从你的老板那里听到这个问题。当你自己觉得需要向你的团队提出这个问题时，问问自己：为什么他们不明白优先级是什么、应该砍掉哪些工作来应对这些优先级？

你知道最高优先级是什么吗？你的团队知道吗？团队里的开发人员知道吗？有时这个问题的答案仅仅是沟通问题。你不知道最高优先级是什么，或者你没有清晰而紧迫地传达给你的管理团队，而他们也没有清晰而紧迫地传达给各自的开发团队。你没有明确地过一遍进行中的工作清单，杀掉或推迟一些工作，为这个优先级腾出空间。如果它真的紧急，你需要这样做。说某件事是最高优先级是一回事，但在日程上做出实际的取舍、让人们真正动起来去做它，则完全是另一回事。

我们会忘记：我们上面的人或别的组织里的人，对我们团队目前在做什么、为什么这么做，并没有同样详细的理解。我不认为有必要向你的同级和经理不断提供你大组织中每个团队的细枝末节。然而，当你因为没有聚焦正确的优先级而被问责时，这说明你和 CEO 对现实的理解出现了错位，你们需要对齐。你的团队可能正在拼命稳定一个频繁引发故障的系统，或者正处于一个持续很久的大项目最后的冲刺阶段。如果你认为团队需要在转向新的最高优先级之前完成当前工作，你必须清楚地说明这一点。

准备好向上和向下双向推动，以维持或改变焦点。如果你认为一个大项目应该在插入新工作之前完成，那就尽可能多地收集关于该项目价值、当前状态和预期时间线的细节。要现实一点。如果上面有人改变了业务焦点，而且急切到愿意进行这场对话，那么你要预期：你可能需要就当前进行中的工作做出妥协，砍掉一部分，或者把一些人调离。你的团队可能对变化不满意。人们通常不喜欢因为高管的突发奇想而被从手头工作中拽走，尤其是当他们相信自己当前的工作很重要时。

你在公司里担任的管理和领导职位越高，你的工作就越变成确保组织朝它需要去的方向前进——包括在需要时改变方向。你通过向团队清晰传达方向、确保他们理解并正在采取必要步骤来改变航向来做到这一点。向你的团队要一份该变革将影响的项目清单，以便你向上传达。这会迫使你的管理团队真正思考这项新计划并开始为之规划。向这项计划的发起人询问它的目标，看看你如何能把这些目标与已经在进行中的工作结合起来。

最后，永远不要低估一件事要被说多少遍、用多少种方式说，才能真正深入人心。在大组织里沟通很难。根据我的经验，大多数人需要至少听三遍才能真正记住。你要告诉你的高级管理层和领导团队，你会开全体会议（all hands meeting），可能还需要发一些邮件详细说明这些变化。在这种情形下，一点沟通规划就能起到很大作用。试着预判你可能遇到的问题并准备好答案。尽可能清楚地说明将要改变的项目或结构，减少混淆的空间。而且别忘了把这项变革当作一件好事来推销！

向上沟通时你同样需要重复信息。当你希望老板对某事采取行动时，预期你需要把同样的话说三遍他才会真正听进去。前两遍，问题可能自己就解决了；但到了第三遍，就说明有更大的事情需要发生。你可能会惊讶地发现，你对团队也开始采取同样的方式。许多问题被提上来后自己就解决了，所以你可能会决定：需要团队持续挣扎到一定程度，才轮到你介入。我并不是建议你把「三遍法则」当作一项政策来采纳，但无论你计划与否，它确实倾向于发生。

组织越大，快速改变优先级就越难。如果你在一家由创始人担任 CEO 的成长型初创公司工作，这种缓慢会让他沮丧。管理这种情况你能做的最好的事，就是主动让 CEO 了解正在发生什么以及为什么。尽最大努力表明你理解他的优先级，并告诉他你为达成这些优先级正在采取的具体步骤。

制定战略

2014 年夏天，作为 Rent the Runway 的工程高级副总裁（SVP），我面临一个大挑战。我的 CEO 告诉我，她想在下次董事会会议上提名我晋升为 CTO，但作为晋升的一部分，我需要向董事会呈报技术战略。她把我提交的每一版战略都打了回来，直到我终于做出了一版符合她标准的东西。而接下来的事，正如他们所说，就是历史了。

我怀疑她其实不必为了提拔我而让我经历这番磨炼。董事会对我把团队做大、把技术发展到稳定且功能交付高产的境地已经非常满意。然而，我非常感激她确实逼我走完了这个过程。在那段过程中，我从对「制定战略」只有模糊的概念，进步到拥有一个具体、有前瞻性的战略——它包含了一套思考技术架构和工程团队结构的方式，而这一切最终还影响了公司自身对整体结构的思考方式。

当我谈论高级领导力时，我强调战略是一个关键要素。大多数人在高级层面制定战略时，甚至不知道从哪里开始。我知道我自己就是这样。我得到了辅导，来自 CEO，也来自一位与我合作的高管 CTO 教练。我向高管团队里的同级们征求了意见。我向工程团队的高级成员提出理论性问题，借助他们看到一些具体的问题。我当然不是独自完成的。那么，制定技术战略是什么样子的？

做大量研究

我先从考虑团队、我们已构建的技术和公司开始。我问工程团队他们的痛点在哪里。我问了几个不同领域的高管，他们认为未来增长会来自哪里。然后，我问了自己几个问题。我思考了扩展挑战现在在哪里、未来可能在哪里。我审视了工程团队，找到它的生产力瓶颈。我研究了技术格局，思考它在不远的将来会如何变化，尤其是与个性化和移动开发相关的部分。

把你的研究与想法结合起来

带着对现有系统、团队和瓶颈的结论，并想象了那些我们可以提高效率、扩展功能或改善业务的地方之后，我用这些数据构思了一个关于可能的未来的粗略想法。我花了一些时间独自待在房间里，面对白板或纸张，画出我们公司的系统，按照各种常见属性对系统和团队进行切分。例如，我区分了面向客户的系统与面向内部运营的系统（如仓库和客服工具）；我区分了后端与前端。因为我们的技术必须对大部分业务数据建模才能运转，我意识到我对数据的流动和变化方式、以及可能的演进轴线有着独特的洞察。

起草一份战略

一旦我绘出了这些数据，我就能规划出可操作的想法，以提高运营效率、扩展功能、增长业务。我考虑了那些我们可能想要限制或扩大系统间信息共享的地方。我们是想要始终尝试基于实时世界状态运行的个性化系统，还是想要更像对数据子集做视图调整的个性化系统？我们如何在数据流的各部分利用各种产品和运营属性，让运营和个性化都能输入到客户体验中？所有这些思考迫使我考虑业务的结构、客户的需求——包括内部和外部客户——以及可能的未来演进。通过这项研究和推测，我得以设计出一份能在未来支撑这些因素的技术战略。

考虑你董事会的沟通风格

我之前说过，CEO 打回了我许多次为这项工作所做的尝试。实际上，她否定了两样东西。第一份是一个欠成熟的战略计划，几乎完全关于系统和架构细节，除了未来 6 到 12 个月之外几乎没有任何前瞻性想法。它当然没有尝试回应那些对团队成功至关重要的业务驱动力。第二个是我的幻灯片。作为演讲者，我受过的训练是做出信息稀疏的幻灯片，以配合认真聆听的观众。而这块董事会需要信息非常密集的幻灯片。公司董事会常常会在开会前通读幻灯片，这样会议可以更聚焦于细节而非演示，这并不罕见。我当时不懂这一点，所以浪费了大量精力去做出纸面上信息量不足的东西。教训学到了。

从这个故事可以看出，好的技术战略在这里意味着几件事。它意味着技术架构，没错。它也意味着团队结构。它意味着理解业务的根基及其前进的方向。我喜欢把面向产品公司的技术战略描述为「支撑业务众多潜在未来的东西」。它不只是应对当前问题的被动文档，而是预见并支撑未来的增长。如果你身处产品导向的业务，这就是你技术战略的核心。它的重点不是真正决定产品的方向，而是让更大的路线图得以顺利落地。

从很多方面来说，最难的部分是起步。第二难的部分是学会在信息高度不完美的情况下坦然地对未来做出猜测。经历这个过程，区分了我以被动方式领导的能力——观察已知环境并制定计划去适应它——和我以前瞻方式领导的能力。现在我对我们作为架构、作为团队、作为公司需要走向何方有了概念。

当我自己厘清了这套架构之后，领导在很多方面变得容易多了。我可以向工程团队展示一个我们作为技术平台将走向何方的愿景，而不仅仅是产品路线图长什么样。我有了一些可以推进公司向前、而不只是让技术正常运转的工作想法。这套架构引领了技术组织的战略，而后者最终引领了公司组织战略的一部分——能够影响这些，是我相当自豪的事。

挑战性情境：传达坏消息

我们都有必须向团队传达坏消息的时候。也许公司要裁员。也许团队要被解散，以便为其他项目提供更多支持，每个人都四散到其他团队。也许有一项你知道会不受欢迎的政策变更。我们刚才讨论的那些路线图变更，有时也属于这一类。你，作为管理者，必须充当传声筒传达这个消息，但你知道团队不会高兴。

在这种情境下你该怎么办？沟通是关键。作为高级领导层的一员，你需要擅长向大群体传达敏感信息。以下是一些该做和不该做：

不要向一大群人群发一封没人情味的消息。 传达坏消息最糟糕的方式是通过电子邮件和聊天这类没人情味的媒介，尤其是带有评论功能的媒介。你的团队理应直接从你嘴里听到这个消息；而如果没有你来引导消息，你可以预期会出现误解和逐渐发酵的敌意。话虽如此，传达这类消息第二糟糕的方式——尤其是传达给你知道不会高兴的大群体——是把他们一次性全叫到一个房间里。你可能会认为，一次性地把坏消息告诉所有人，是防止消息在所有人都听到之前扩散开来的最好办法，但结果仍然是没人情味的。你很难看到每个人的反应，而且一两个深感不满的成员可以在消息来得及被消化之前迅速煽动起整个团队。
尽可能与个人单独交谈。 与其采用没人情味或群体式的沟通，不如尽最大努力与人们单独交谈这条消息。想想那些反应会最强烈的人，试着把消息针对他们量身裁剪。给他们一对一的空间去反应、提问、直接从你这里得到答案。必要时，明确说明这是命令（marching orders），你需要你的人们支持这些变革，即使他们不喜欢。当你需要把消息传达给整个组织时，先与你的管理者们谈，给他们谈话要点，然后让他们在与全体人员聚齐之前先与各自的团队分享。
不要强迫自己传达你无法背书的消息。 你可能很难传达这条消息，因为你自己也不喜欢它。也许你强烈反对这项政策变更。也许你讨厌团队要被拆散这个事实。如果你绝对无法在不背叛自己强烈异议的情况下传达这条消息，你可能需要别人帮你传达。也许你请另一位高管介入，或者请人力资源的人。根据你团队的大小，你可以把信息交给一位可信赖的副手，让那个人帮助分享。作为高级领导层的一员，你必须学会成熟地处理你不同意的决定，但这并不意味着你必须独自硬扛。
要对可能的后果诚实。 你自己越能投入于消息所指定的方向，这件事就越容易。如果裁员了，承认这个过程不好受，但每个人都需要公司活下去。如果团队要被解散，尽管指出团队迄今为止的成就，以及使这成为正确前进道路的变化，并强调现在有许多新的学习和成长机会。对人们坦诚，会帮助他们更信任你，也会让他们更有可能平静地容忍这条令人不快的消息。
想想你希望自己被怎样告知。 有一天你可能不得不传达的一条消息，是你自己要离开的消息。事实上，你可能已经有过辞职或从一个团队转到另一个团队的经历。你是怎么传达那条消息的？你发了一份备忘录吗？嗯，也许对人力资源发了，但对团队里的其他人，你大概会把人们拉到一边当面告诉他们——如果你觉得他们想在公开之前知道的话。你可能办过告别派对、写过告别信、或者给团队上了最后一课，讲讲你在公司期间学到的东西。在某些情况下，庆祝这些令人伤感的转变是可以的，只要你能优雅地做到。所有这些经验都适用于向你的团队传达艰难的消息。

问问 CTO：我有一个不懂技术的老板

这是我第一次有一个不懂技术的老板，结果真的很难。我该如何有效地管理这段关系？

我第一次经历完全不懂技术的管理者，是从我开始向 Rent the Runway 的 CEO 汇报时开始的。向不懂技术的管理者汇报可能完全是一场文化冲突。幸运的是，有一些最佳实践可以帮助你管理这段关系：

不要用行话藏住信息，对细节要谨慎。 你的新老板可能非常聪明，但他可能没有耐心听技术行话，而且他极不可能想听一大堆关于微妙技术决策的细节。这个过程的一部分，是学会区分哪些类型的信息值得沟通、哪些不值得。
预期你需要主导与老板的一对一（1-1s）会议，所以带着话题清单来。 忙碌的高管可能难约得令人沮丧；就连争取到一对一的时间都是个挑战，所以不要浪费你拥有的时间。在此之前你可能期望双方都会带一些具体话题来开会，但现在未必如此了，所以永远要准备好再来。如果你的一对一时间难以落实，提前发送议程以提醒你的老板她需要关注你——而且与掌管她日程的执行助理（executive assistant）搞好关系永远没坏处！
尽量带解决方案来，而不是带需要解决的问题。 CEO 们通常不想听事情如何失败，也不想听你与同级的争执或你管理上的烦恼。如果你的 CEO 不想听太多问题，那就尊重这一点：你不会从他那里得到太多管理方面的辅导，去找另一个人获得这种辅导。话虽如此，不要回避传达坏消息。
征求意见。 这听起来与我「带解决方案」的建议相矛盾，但没有什么比征求某人的意见更能表达尊重。你的老板可能不想陷在你的问题里，但你可以肯定，如果你把它表述为需要建议，她会乐于给出反馈。
不要害怕重复自己。 如果你提出了一个似乎被遗忘的重要问题，而它真的很重要，那就再提一次。你可能需要这样做好几次才能获得任何进展。三次往往是那个神奇的数字。
保持支持。 总是问是否还有更多你能帮忙的事。尽你所能表明你在这里是为了支持你的老板和公司。
积极在别处寻找辅导和技能发展。 你不再有管理者（manager）了；你只有一个老板（boss）。第一次担任高级领导职位时，你可能仍然需要发展一些技能，所以找一个教练、申请培训、在公司之外建立一个同级圈子，来支持你走过这个勇敢的新世界。

其他职能的高级同级

随着我进入高级管理层，许多重大的顿悟都与我和高管及领导团队中其他人需要建立的关系有关。我有机会与许多职能中我尊敬的人共事，而且因为我们有一个庞大而多元的领导团队，我认识了许多不同类型的高级领导者。我与一些人比与另一些人相处得更好，我从两种互动中学习，不断进化自己的视角。

在公司里，高级领导者比任何其他群体都更需要积极践行「第一团队」（first-team）思维（在第 6 章介绍过）。他们首先致力于业务及其成功，其次才是自己部门的成功——把它作为对整体业务成功的一种贡献。帕特里克·兰西奥尼（Patrick Lencioni）的《团队的五项机能障碍》（The Five Dysfunctions of a Team）[2] 等领导力书籍谈到了这种关系。虽然我们许多人是从与其他工程管理者组成「第一团队」开始实践这类领导的，但高级领导层往往是第一次你的同级都以与你习惯的方式非常不同的方式运作，而你的第一团队里几乎没有或根本没有同为工程师的同级，这会让人感到非常孤立。

那么，与跨职能同级良好协作是什么感觉？首先，你让他们拥有自己的领域，他们也让你拥有你的。我们许多人在职业生涯早期就学会了这一点——当时必须与资深设计师、产品经理或其他业务团队成员合作——但如果你还没学会让同级拥有她的专长，现在就是时候了。在她的地盘上给予她尊重的让步是根本性的。如果你不同意她的管理风格或她在并不直接影响你团队的领域里运用技能的方式，你就把这种异议当作对待一个恰好约会你不喜欢的人的好朋友那样处理。除非她征求你的建议，否则尽量置身事外，而且当然要用善意来对待你选择讨论的任何分歧。愿意让那些差异搁置。

当然，你会与同级意见不合。表达这种分歧的场合要么是一对一，要么是在你的领导团队会议上。这些会议就是你们就战略、公司面临的挑战以及方向设定的细节反复磋商不同意见的地方。如果数字讲不通，就在这些会议的语境下问首席财务官（CFO）。也要预期在这个场合为自己技术决策和路线图辩护。

这把我们带到信任的第二个要素——超越对某人能力的信任。在《团队的五项机能障碍》中，兰西奥尼指出，缺乏信任（absence of trust）是一项根本性的机能障碍。在这里，缺失的是这样一种信任：你的同级都在积极为组织尽最大努力，他们没有试图操纵局面、暗中破坏你，或以其他方式一意孤行。所以，除了对你的同级在其地盘上的所有权建立基本尊重、尊重他们作为职能专家的能力之外，你还必须放下这样一个念头：当他们不同意你或做了你不喜欢的事时，他们是在非理性或自私地行事。

建立这种根本信任真的很难。你可能会与某些——如果不是全部——同级发生一定程度的文化冲突。造就一位伟大 CTO 的价值观，可能与造就一位伟大 CFO、首席营销官（CMO）、运营副总裁等人的价值观略有不同。一种非常常见的冲突，发生在极度分析驱动的人与更偏创意或直觉的人之间。另一种冲突，发生在喜欢拥抱敏捷与变革（是的，有时还有混乱）的人，与推动更多长期规划、截止日期和预算的人之间。你必须弄清楚如何理解并信任光谱上每个人的风格。

工程师常常难以过渡到尊重并与多元化同级良好沟通。我认为这种尊重上的挣扎是当前技术文化的副作用——它告诉我们工程师是房间里最聪明的人。怎么说都不为过：你的那些非分析驱动的同级并不愚蠢。反过来，当我们没能用不懂技术的同级能听懂的方式说话时，我们也是在削弱自己。向不熟悉行话的人——而且根本不需要熟悉行话的人——抛行话，会让我们在他们眼里显得愚蠢。因此，我们需要想办法以一种聪明但不搞技术的同级能够理解的方式，传达我们工作的复杂性。

这种第一团队的信任与尊重的最后一个要素是「沉默之墙」（cone of silence）。在领导团队语境中发生的分歧，对更广泛的团队来说是不存在的。一旦做出决定，我们就承诺支持这个决定，并在工程团队和公司里任何其他人面前保持统一战线。说起来容易做起来难——我经常在隐藏自己与同级的异议上苦苦挣扎。当你没有如愿以偿时放手，尤其当你觉得自己的反对意见没有被听到时，是很难的，而这种事时不时就会发生。尤其是在这个层级，你必须决定是要站队服从，还是离开。中间地带——公开与同级唱反调——只会让每个人的处境都变得更糟。

回声效应

作为组织中最资深的人，你被注视的程度将超过你一生中被注视的任何时候。你的在场会让人们把全部注意力集中在你身上。他们寻求你的认可，回避你的批评。把你的心态从「团队的一员」转变为「管事的人」，尤其是如果你是从团队里成长起来、亲手把团队带大的，对许多处于这个层级的人来说都是一项挑战。

你不再是团队的一员了。你的第一团队由领导层/高管层的同级组成，而你的汇报结构现在成了你的第二团队。如果你成功转变了心态，你可能会开始从整个组织里稍微抽离社交。当有欢乐时光（happy hour）时，你去喝一杯，然后留下团队自己社交。和整个组织一起喝到酒吧打烊，往往会给每个人带来糟糕的后果，所以我强烈建议你不要经常那样做。工作时间之外与团队重度社交的日子已经过去了。

你需要抽离有几个原因。第一，如果你不抽离，你很可能被指责偏袒（playing favorites）。事实上，如果你与团队里向你汇报的人保持非常紧密的社交纽带，你确实会偏袒。这很伤人，但这是真的。也许你不在乎，但就我个人而言，我发现让团队相信我在偏袒，会让整个团队不开心，也让我的工作难做得多。

第二，你需要抽离，因为你需要学会如何有效领导，而有效领导要求人们认真对待你的话。在这个层级领导的坏处是：随口一句评论，就能让人们改变整个焦点。这很糟糕，除非你意识到这一点并真的加以恰当利用。如果你试图维持「哥们儿」（buddy）的形象，你的下属将很难区分他们的哥们儿在自言自语，和他们的老板在要求他们聚焦某件事。

抽离还意味着对你的时间花在哪里要深思熟虑。作为高级领导者，你常常会吸走房间里所有的氧气。仅仅你的在场就会改变你参加的会议的氛围和结构。如果你不小心，你会因为在一场你决定临时旁听的一次性会议上冒出一个绝妙想法，就长篇大论并改变一个项目的方向。这太糟糕了！我知道！很令人沮丧的是，你不再能成为团队的一员，让你的想法被评估、甚至可能被否决——但你确实不再是那个人了。

如果你和任何与史蒂夫·乔布斯（Steve Jobs）在苹果共事过的人合作过，你很可能听那个人谈起过「史蒂夫」以及他对某个项目的影响。苹果员工用史蒂夫的幽灵来支持或反对决策，作为组织应该做什么的道德罗盘。你建立并强化的文化会对你的公司产生类似的效果。他们可能不会指名道姓地提起你，但当你选择在团队面前示范哪些行为时，他们会学到这些行为并加以复制。如果你吼叫，他们就学到吼叫是可以的。如果你公开犯错并道歉，他们就学到犯错是可以的。如果你总是对项目问同一套问题，人们就开始自己问这些问题。如果你公开看重某些角色和职责高于其他角色，有野心的人就会去追求那些被看重的职位。把这种力量用在好的地方。

你需要抽离还有其他原因。你将参与影响整个业务的艰难决定，而这些决定可能给你带来巨大压力。与公司里的其他人讨论这些决定是不合适的。向汇报团队中你视为朋友的人吐槽你职位的挑战，极具诱惑力，但这是个坏主意。作为他们的领导者，分享他们无力缓解的担忧，很容易削弱他们的信心。在较低管理层级可能无害甚至可能有帮助的透明，在这个层级可能变得对你团队的稳定极具破坏性。

你可能不再是「团队的一员」，但这不意味着你应该停止把团队成员当作个体来关心。事实上，我鼓励你更加关心作为个体的人，至少以一点小方式。花时间去尽可能多地了解人们作为人的一面——问问他们的家庭、爱好或兴趣——是帮助他们感到自己属于一个关心他们的群体的好方法。

随着你与团队越来越疏离，你很容易开始把人物化（dehumanize），把他们当作齿轮（cog）。人们能察觉这种情况什么时候发生，能察觉他们的领导者何时不再关心组织中的个体。如果他们觉得没有人在乎他们个人，他们就不太可能感到有承诺全力以赴、承担风险、在艰难处境中坚持下去。培养那种联结，即使看起来肤浅，也有助于强化你确实在乎他们，而不只是在乎他们当前的项目或工作产出；表明你知道工作之外他们也是活生生的人。它让你脚踏实地，又不至于与个人绑得太紧。作为高管你必须做出艰难的决定，但你的团队值得一位即使在做出艰难决定时也能保持善意的领导者。

你是一个榜样。你想培养出什么样的领导者？你想留下什么样的遗产？

以恐惧统治，以信任引导

卡米尔（Camille）认为自己是一位好领导者：懂技术、有魅力、能拍板、能成事。她有时也脾气急躁，当人们达不到她的期望或事情出错时，她会明显地恼火、公开地发怒。她没有意识到，这种强硬和急脾气正在让人们害怕她。他们不想冒被归咎于失败或因为犯错而公开挨批的风险，所以他们减少冒险、隐瞒错误。卡米尔无意中创造了一种恐惧文化（culture of fear）。

迈克尔（Michael）也是一位好领导者：懂技术、有魅力、能拍板、能成事。他还很擅长保持冷静。当事情似乎进展不顺时，他不会紧张和愤怒，而是变得好奇。他的第一本能是提问，而这些提问往往让团队自己意识到哪里出了问题。

你可能会惊讶地发现，你刚读到的故事是真的：这是我自己成为高级领导者时无意中创造恐惧文化的亲身经历。以下是我作为高级领导者的第一份评审报告的摘录：

即使团队里爱你的人也承认害怕你和你可能的批评。人们害怕在你面前冒险或失败，因为他们害怕当着同级的面被公开训斥。你的攻击行为所造成的，是一种团队成员不敢与你接触、不敢问你问题、不敢向你寻求反馈的文化——这继而导致一个恶性循环：你不信任他们，他们犯错误。

可以想象，这些话听上去令人震惊和不舒服。虽然我可以为它找出一打借口——人们更严苛地对待女性的批评、我来自金融行业那里这种文化很正常、每个人都需要坚强起来——但这显然是个问题。人们害怕冒险，而如果你想要一支能够自主定方向、自我鞭策的独立团队，你需要他们去冒险。

你怎么知道自己是否在制造恐惧文化？它可能源于高度重视「正确」和遵守规则，以及对基于等级的领导有强烈偏好。我还认为，来自一个公开容忍——如果不是积极鼓励——冲突的环境，让我更有可能制造这种文化。工程文化对以公开辩论解决冲突有很高的容忍度，所以来自重度工程背景的领导者，可能会尤其习惯于就问题与他人激烈交锋。不幸的是，当你成为领导者时，动态就变了：那些在你还是个人贡献者时会还击的人，会感到你作为领导者带来的威胁。

纠正恐惧文化

练习亲近感（relatedness）。 恐惧文化的一个标志是倾向于没人情味地对待人。在我管理生涯早期，我有一个过度聚焦效率的习惯。我想直接切入手头的问题，进入智力讨论、状态更新、需要解决的问题。我不会花太多时间闲聊，不会把团队当作人来了解，也不会让他们看到我作为人的一面，结果我与他们几乎没有个人关系。如果你想要一支敢于冒险和犯错的团队，核心条件之一就是归属感和安全感。这意味着你需要花一点时间闲聊。问问人们关于他们自己的事，把他们当作人来了解，让他们了解你。大多数人在他们认为失败就会被拒绝的人面前，是不敢冒险的。无论有意无意，因为忽略了与许多团队成员建立哪怕最基本的个人关系，我让他们害怕我会如何反应于错误、问题和失败。
道歉。 当你搞砸了，道歉。练习真诚而简短地道歉。「对不起，我不该对你吼叫，我为我的坏行为没有任何借口。」「对不起，我没有听你说话，我知道我加剧了你对这个局面的沮丧。」「对不起，我疏忽了没有告诉你鲍勃（Bob）的事，这是我的错。」道歉不需要拖得很长。一段简短、为你在制造负面局面或伤害他人中所起的作用承担责任的话，就足够了。如果你说得太长，它往往就变成借口或转移注意力。道歉的目标是向人们展示你知道自己的行为对他人有影响，并为他们示范：犯错没关系，但当你伤害他人时你应该道歉。你在向团队展示，道歉不会让你变得更弱——它让整个团队变得更强。
变得好奇。 当你不同意某件事时，停下来问为什么。不是每一次分歧都是对你权威的挑战。当你花时间就你不同意的事情寻求更多信息时，你往往会发现，你只是在反应一些你并没有真正理解的东西。对于我们这些在乎做正确的事或做出最好决定的人来说，攻击我们不同意的东西会让这件事更难。当我们攻击时，许多人会逃避或关闭自己，他们学会对我们隐瞒信息是个好主意，这样我们就不会攻击或批评他们。当你变得好奇、学会把分歧转化为真诚的提问时，你能从团队那里了解到更多关于这个问题的其他视角，因为他们会敞开。这是你获得最多信息、帮助所有人做出最好决定的方式。
学会在不把人变坏的情况下追究责任。 作为领导者，你希望你的团队做好他们的工作。如果他们未能履行责任，你就是那个追究他们责任的人。但责任不是从责任开始、以后果结束的。沿途还需要其他要素。你如何衡量成功？团队拥有成功所需的能力吗？你在过程中提供反馈了吗？我认为许多领导者忘记了这些要求，他们希望只靠把目标设清楚就让一支初级团队达成某件事，或者认为一支更有经验的团队永远不需要反馈。想想那些因为你（或他们）失败而把一个人或一个团队说成「坏」的时刻。你是否在为自己是否为他们创造了成功条件而负责？当一切都很清楚、你们都尽了最大努力时，我敢打赌你会发现，问责伴随着远少的人格评判，因为你们都清楚地看到了发生了什么。

恐惧文化在技术界相当普遍，而且它在其他方面进展顺利的环境中活得最好。不要被那些纵容你坏行为的外部环境所欺骗。如果你被畏惧但被尊重、公司在增长、团队在做有趣的问题，你可能会安然度过一段时间。然而，如果你失去这些要素中的任何一个，你就可以预期那些有更好选择的人会奔向更绿的牧场。我第一手知道，当团队被周围发生的其他事情困扰时，拥有一支畏惧但尊重你的团队是不够的。所以，努力磨平你的棱角，练习把你的团队当作人来关心，变得好奇。建立信任文化需要时间，但结果非常值得。

真北

高级领导层的一个核心角色有时会被忽视。这个角色由某个职能领域的高级领导者扮演（CTO 为技术扮演，CFO 为财务扮演，以此类推），它设定了这个职能中「卓越」的基线。我称之为「真北」（True North）。

真北代表一个职能角色的人在做他的工作时必须牢记的核心原则。对于产品领导者，真北包括：首先且最重要的是思考用户及其需求，尽可能多地度量和实验，并对不解决团队既定目标的项目提出异议。对于 CFO，真北包括审视数字、工作的成本和潜在价值，确保你考虑过如何让这些数字对公司有利，确保公司不会意外超支，确保团队知道什么时候有超预算的风险。

对于技术领导者，真北意味着确保你尽到了让事情准备好进入生产（production）的职责。它意味着你遵守了你们约定好的评审、运营监督和测试政策。它意味着你不会把一件你并不认为准备好让用户体验的东西放入生产。它意味着你在创造你为之自豪的软件和系统。

技术领导者必须帮助在其组织中为不同类型的项目和风险敞口设定真北标准。另一种思考方式是透过风险分析（risk analysis）的透镜。风险分析并不意味着我们不承担风险。一些通常被视为「坏」的东西在某些情况下是可以接受的。其中包括：

存在单点故障（single point of failure）
存在已知的缺陷和问题
无法承受高负载
丢失数据
发布测试不足的代码
性能缓慢

有些情境和公司里，所有这些风险都是可以接受的。话虽如此，真北帮助我们理解：当我们将代码投入生产时，所有这些问题都必须被仔细考虑。仅仅因为这些规则有例外，并不意味着我们忘记它们的存在。

我把这个概念称为真北，是因为把它理解成一种潜在的牵引力很重要——一种我们作为领导者随着时间培养出来的引导直觉，并且努力帮助我们的团队整体也培养出来。当我们的团队培养了这种直觉，他们就可以被信任去独立遵循这些准则，而无需太多指示或轻推。

每个职能领域的真北都略有不同，所以组织中会有自然的张力。产品经理可能更关心用户体验，而不那么关心生产支持负担。财务团队可能更关心基础设施的总体成本，而不那么关心可用性风险。这种张力是健康的，因为它迫使我们正视所有的风险，而不只是我们特定职能所在意的那些。

当你审视自己作为领导者的角色时，看看你设定真北的方式，可以帮助你理解自己的优势和所有权的领域。如果你认为自己是一名技术领导者，你工作的一部分应该是为关键技术的大块面设定真北。作为一家商业公司的 CTO，我为大多数最基础的技术决策设定了真北，涉及生产就绪、扩展、系统设计、架构、测试和语言选择。这并不意味着我做了所有这些决定，但我引导了评估这些决定的标准。我把移动和 UI 特定开发事务的真北委托出去，但推动那些领域的资深技术人员阐明标准是什么样的。

真北领导者依靠他们随时间培养的智慧，在没时间深究所有细节时快速做出决定。如果你想成为这种领导者，你必须在职业生涯早期花足够的时间磨练这些直觉，以便能自如地做出快速判断。这意味着保持技术手感；把项目、语言或框架跟到底，学到超越皮毛的程度；即使你的日常工作不涉及写代码，也要鞭策自己不断学习新东西。

评估你自己的经验

在这个层级，你的辅导和指导很可能来自公司之外的人。你不再有管理者，你有一个老板。你是否有一位专业教练，无论是公司提供的还是自己付费的？即使你的工作不为此买单，这也是一项好的投资。教练能给你指导和直接的反馈，而且与你的朋友不同，她是拿了钱来听你说话的。
除了教练，你公司之外的同级支持网络怎么样？你认识你所在地区的其他公司的高级管理者吗？一个同级圈子能帮你看到这份工作在别家公司是什么样的，也是你分享经验、获得建议的地方。
你特别钦佩哪些技术高级管理者？你钦佩他们身上的什么？如果有的话，你可以做些什么来变得更像他们？
回想你上一次需要为部分或全部团队变更优先级的时候。进行得怎么样？哪些做得好，哪些不好？你如何向团队传达这个变更，他们的反应是什么？如果重来一次，你会做的一件不同的事是什么？
你对业务在可预见的未来走向哪里的理解有多深？你理解那个能帮你到达那里的技术战略吗？团队需要演进的关键关注领域是什么，比如功能交付速度（feature velocity）、性能、技术创新和招聘，才能达成公司目标？技术演进推动业务前进的瓶颈或机会在哪里？
你与公司高级领导团队其他成员的关系如何？哪些关系好，哪些不好？你能做些什么来改善不好的关系？你对这些团队成员的优先级理解有多深，你认为他们对你的优先级理解有多深？
如果我问你的团队你与哪些高管相处融洽、讨厌哪些高管，他们能毫不犹豫地告诉我吗？当 CEO 或领导团队做出你不同意的决定时，你能放下分歧、向公司其他人支持这个决定吗？
你表现得像团队的榜样吗？如果人们每天都在模仿你的行为，你会高兴吗？当你列席团队会议时，你是主导对话，还是更愿意倾听和观察？
你上一次问你平时不常交谈的人工作之外的生活是什么时候？上一次有人发邮件说她病了来不了，你有没有花一分钟祝她早日康复？
你希望你的资深工程师在评估工作和做决定时考虑的基本原则是什么？或者，如果你更关注组织而非技术，你希望你的管理者在带领团队时遵循的基本管理原则是什么？

[1] Andrew S. Grove, High Output Management (New York: Vintage Books, 1983).

[2] Patrick Lencioni, The Five Dysfunctions of a Team: A Leadership Fable (San Francisco: Jossey-Bass, 2002).