第一次成为高管，应该如何快速进入角色？
当我准备加入海外某家公司，担任工程副总裁时，查德·迪克森主动提出，要给我一些建议。
此前我们曾在海外某家互联网公司共事，当时他担任 CEO。在成为 CEO 之前，查德曾多次担任 CTO。他知道，高管职位对我来说是一个全新的挑战，因此希望帮我理清方向、打好基础，让我能够更从容地完成从工程领导者到公司高管的角色转型。
起初，我完全不知道他会在邮件里写些什么。收到邮件后，我才发现，其中的内容不仅极其丰富，而且结构清晰、建议具体。我甚至为它整理了一份目录。
正式上任后，这些建议给了我很大帮助。此后的许多年里，我也会经常重新翻阅这封邮件。无论是在担任工程高管期间，还是后来辅导那些正在考虑成为高管、或者即将进入高管团队的人时，我都会反复引用其中的观点。
后来，我询问查德是否愿意公开这些建议，因为我很希望能将它们分享给更多有潜力的领导者。我们共同对原文做了一些编辑，删除了部分人名，并将一些过于具体的案例进行了概括，使这些建议能够适用于更多公司。
以下是给新任高管的九条建议：
- 寻找或组建一个同级高管互助小组；
- 与产品负责人建立极其紧密的合作关系；
- 专注于产品路线图的执行；
- 主动帮助其他高管减轻负担，尤其是 CEO；
- 必要时明确表达自己的立场；
- 始终为团队讲述一个有意义的故事；
- 广泛阅读管理和领导力经典著作；
- 意识到自己的情绪和行为会影响整个组织；
- 与董事会成员建立良好的关系。
下面是查德给我的完整建议。
1. 新任高管需要建立同级互助小组
同级高管互助小组非常有价值。
在这样的群体中，人们往往会私下讨论许多不会公开发表在社交媒体或博客上的问题，而这些问题通常恰恰是最真实、最复杂，也最值得讨论的。
你可以通过两种方式建立这样的支持网络，而且两种方式完全可以同时采用。
加入正式的高管互助组织
你可以加入一个正式的 CTO、工程副总裁或高管互助小组，并与成员保持定期联系。
几年前，我加入过一个 CEO 互助小组，它对我的帮助非常大。这个小组的运作方式比较正式：我们每个季度会安排半天时间集中讨论，每个人都需要提前准备一些具体议题。
我们讨论的内容非常广泛，包括组织架构、关键人才招聘、融资，以及更宏观的战略问题。
我发现，与这样一群经验丰富的人共同分析难题，往往能够帮助我作出更好的判断，并提高解决问题的成功率。现在，我已经很难想象，如果没有这样一个小组，我会如何应对那些复杂的挑战。
自己组建一个非正式互助小组
你现在已经是一家备受关注的公司的工程副总裁。这意味着，其他公司的资深工程领导者大多愿意与你交流。
因此，只要你愿意，完全可以邀请几位处于相似阶段的同行，自己组建一个非正式的互助小组。
不需要复杂的组织形式。只要能够定期见面、坦诚交流，并愿意分享那些难以在公司内部讨论的问题，这个小组就会很有价值。
2. 工程高管要与产品负责人紧密合作
你需要确保自己充分理解公司的产品优先级，同时也要确保产品负责人真正理解工程层面的成本、限制和取舍。
如果你与产品负责人始终保持步调一致，你的工作会轻松很多。
我曾在多家公司看到，产品负责人和工程负责人之间的关系逐渐变得紧张，最终引发一系列问题，而工程团队通常会首当其冲。
原因其实并不复杂。
制定高层产品目标和路线图，往往比真正开发复杂的软件容易得多。产品团队可以不断提出新目标、新需求和新项目，但工程资源永远有限。
因此，你们必须保持充分沟通，并共同建立一套双方都认可的工作机制，例如：
- 如何制定和评审路线图；
- 如何安排迭代开发；
- 如何确定需求优先级；
- 如何进行工作量预估；
- 如何处理临时需求和范围变更；
- 如何对外解释延期、风险和资源冲突。
你们还需要维护清晰、易懂的辅助文档，例如共享路线图、资源规划、项目状态和关键决策记录。
对于规模较大的研发组织，这些信息如果长期分散在会议、表格和聊天记录中，很容易出现目标与执行脱节。借助 PingCode 这类覆盖目标、需求、项目、测试、发布和知识沉淀的研发管理工具，可以把产品路线图、需求优先级和实际交付状态关联起来，让产品与工程团队基于同一套信息讨论取舍，而不是反复争论“谁掌握的数据更准确”。
商业世界仍然依赖交付日期和工作量预估。你需要找到一种尽可能可靠、同时又不会让团队不堪重负的执行方式。
我很清楚，有些人推崇“不做预估”的理念。但恕我直言，在真实的公司经营环境中，完全不做预估通常是行不通的。
人们有时会嘲笑某些研发方法论被执行得过于教条，仿佛变成了一种不可质疑的信仰。我的意思并不是让你照搬某个框架，而是你必须拥有一套稳定、一致、能够被各方理解的工作流程，并辅以清晰的文档。
如果工程团队不能主动推动产品开发节奏，产品需求就会反过来控制工程团队。
我不太喜欢使用体育比赛的比喻，但在这里很适用：
你必须主动进攻，否则就会一直处于被动防守的状态。
有一个简单的判断标准：如果你经常听到有人问“这些工程师到底都在做什么”，那就说明你还有工作没有做到位。
你永远不会拥有足够多的工程师，而想做的项目也永远会超过实际可用的资源。因此，如何合理分配工程能力，始终会是高管团队需要持续讨论的问题。
3. 新任工程高管要专注于路线图执行
每天早上醒来，你都应该问自己一个问题：
我今天所做的事情，是否有助于团队兑现已经作出的承诺？
工程领域有很多有趣的事情，例如参加行业会议、公开演讲、撰写文章、参与开源项目，以及打造技术影响力。
但这些事情最终都应该建立在一个基础之上：持续为内部或外部客户交付有价值的产品。
我曾在 2008 年加入海外某家互联网公司，担任 CTO。在此后的近一年半时间里，我没有进行任何公开演讲，也几乎没有对外写作。
因为在那个阶段，我必须把全部精力投入到公司和工程团队中：搭建合适的团队，调整组织结构，改善系统稳定性，并确保我们能够可靠地交付产品。
即使后来我们开展了一些看起来与产品交付没有直接关系的工作，背后也有清晰的业务目的。
例如，我们曾推出一个工程技术博客，希望借此建立公司的技术品牌，吸引优秀人才，最终帮助团队交付更加可靠的产品和基础设施。
事实证明，这项工作取得了很好的效果。许多后来加入公司的工程师，在参加面试之前，就已经通过博客了解了我们的核心文化和产品开发方式。
还有一点可能听起来有些奇怪：
你的大多数高管同事，甚至可能是所有高管同事，其实并不关心工程技术的具体细节。
这并不是坏事。
他们有各自负责的职能，也有各自需要处理的问题。这就像大多数员工并不关心公司的财务系统和薪资发放流程有多么复杂，他们只希望工资能够按时、准确地到账。
其他高管对工程部门的期待也类似。
他们关心的是：
- 系统能否稳定运行；
- 产品能否按计划交付；
- 风险能否被及时识别；
- 资源是否得到了合理使用；
- 工程问题会对业务产生什么影响。
至于底层技术究竟如何实现，并不是他们最需要理解的事情。
这也是为什么工程高管不能只依赖口头汇报，而要建立一套能够反映目标、进度、风险和质量的数据体系。通过 PingCode 将需求、开发、测试、发布和研发知识连接起来，高管不必陷入每个任务的执行细节，也能看清路线图承诺是否正在兑现、风险集中在哪里，以及哪些环节正在消耗团队的工程能力。
你当然可以与工程团队深入讨论技术，但不要让其他高管承担没有必要的认知负担。
公司之所以让你担任工程高管，正是因为你应该负责理解并处理这些复杂性。
4. 主动帮助 CEO 和其他高管减轻负担
你应该定期询问其他高管：
我能做些什么，帮助你减轻负担？
尤其要这样询问 CEO。
作为一名高级职能负责人，你很可能需要向一位从未做过你这份工作的人汇报。
CEO 或许非常了解商业、融资、产品和组织，却不一定真正理解工程管理。这意味着，你们之间天然存在一定的认知差异。
这和你在工程部门内部与经验丰富的技术人员合作完全不同。
你的核心职责之一，就是在公司的技术部门与业务部门之间搭建桥梁。
过去，你与工程师和工程管理者交流时，可能习惯使用大量缩写、术语和默认背景。但进入高管团队后，你必须把这些内容翻译成 CEO 和其他高管能够理解的语言。
你需要清楚地解释：
- 当前发生了什么；
- 为什么会发生；
- 这会对业务产生什么影响；
- 目前有哪些选择；
- 不同选择分别需要付出什么代价；
- 你建议公司采取什么行动。
既然你是工程部门与业务部门之间的桥梁，就应该对沟通是否顺畅承担主要责任。
如果沟通失败，不要首先责怪对方“不懂技术”。帮助对方理解，本来就是你的工作。
担任 CEO 是一件非常困难的事情。对于管理科技公司、但本人并非工程师的 CEO 来说，难度尤其高。
因此，你应该尽可能独立解决职责范围内的问题，不要把所有困难都交给 CEO 处理。
当然，也有一些关键问题必须及时向 CEO 提出，这一点会在下一条建议中谈到。
CEO 在公司其他领域一定也面临着大量挑战。你越能够稳定地管理工程部门，他们就越能把精力投入到那些只有 CEO 才能解决的问题上。
5. 高管需要在关键时刻明确表达立场
要想成为 CEO 和高管团队真正信赖的顾问，有时你必须坚持自己的判断。
你可能需要反对某个项目提出的不合理要求，指出一项决策带来的技术风险，挑战一种不健康的企业文化，或者明确告诉团队：某件事情不能继续这样做下去。
作为高级领导者，这不仅是你的权利，也是你的职责。
不过，你表达立场时的可信度，始终取决于两个基础：
第一，你是否能够持续交付产品和基础设施；
第二，你是否能够让组织保持健康、高效地运转。
这两件事决定了你在公司内部拥有多少“社会资本”。
例如，如果你公开批评人力资源部门的某项做法，但工程部门长期无法兑现路线图，其他人很可能会在心里想：
“你或许应该先解决产品和基础设施的交付问题。”
相反，如果你带领团队稳定、高效地执行，公司就会认真对待你的意见。你说的话会更有分量，也更容易获得支持。
任何人都可以发表评论、指出问题，但并不是每个人都能建立并领导一支高效的工程团队。
你的影响力，首先来自你创造的结果。
6. 高管要为团队建立有意义的叙事
日常工程工作在很多时候非常琐碎，甚至显得有些乏味。
团队成员每天可能都在处理缺陷、重构代码、迁移系统、优化性能、参加会议，以及回应源源不断的需求。
但人们并不只需要任务和工资。他们还希望理解，自己所做的工作究竟意味着什么。
你的工作之一，就是帮助团队找到这种更高层次的意义。
这不仅仅是在解释优先级，也不仅仅是在展示路线图。你需要建立一种能够鼓舞团队、支撑文化，并帮助人们理解自身价值的叙事。
管理学者彼得·德鲁克曾在《管理的实践》中表达过类似观点：
目标管理能够告诉管理者应该做什么，合理的工作安排能够帮助他完成工作，但真正决定人们是否愿意投入精力、付出额外努力的，是组织的精神。组织精神决定了人们是愿意竭尽全力，还是只满足于维持现状。
我们过去曾提出过一个关于“代码与工艺”的理念，这就是我所说的“故事”。
这个故事只能诞生在当时那家公司，也正因如此，它才具有力量。
如今，这个说法或许听起来已经十分常见，但在当时，它是工程组织转型的一颗种子，也是一个能够振奋团队的口号。
在这个故事下面，我们可以容纳许多更加具体的理念，例如：
- 重视持续交付；
- 鼓励慷慨与协作；
- 进行不追责的事故复盘；
- 建立公平、包容的工程文化；
- 对产品质量承担共同责任。
除了文化层面的故事，你还应该为团队建立一个技术层面的故事。
一家公司可能因为持续部署而闻名，也可能因为开发者体验、系统可靠性、工程效率或者开放协作而形成独特声誉。
你的团队最终希望因为什么而被人记住？
除了你希望建立的企业文化之外，从纯粹的技术角度来看，你们最独特、最值得骄傲的地方是什么？
你需要认真思考，并逐渐找到答案。
7. 广泛阅读管理和领导力经典著作
不要只阅读内容平台上的热门文章，也不要只关注社交媒体上流行的管理观点。
你还应该花时间阅读一些经典著作。最好能够暂时离开屏幕，完整地读完一本书，而不是只看摘要、摘录和二手解读。
以下是一些值得参考的作品：
- 彼得·德鲁克：《管理的实践》
- 彼得·德鲁克：《卓有成效的管理者》
- 彼得·德鲁克：《德鲁克精要》
- 安迪·格鲁夫：《高产出管理》
- 吉姆·柯林斯：《从优秀到卓越》
- 迈克尔·卡罗尔：《正念领导者》
我并不是说自己同意这些书中的所有观点。
这些作品有各自的时代背景，作者的视角和部分表达方式也存在明显局限。但每一本书都以不同的方式提出了一些具有挑战性的问题。
阅读经典著作的意义，不是寻找一套可以直接照搬的管理方法，而是借助不同思想，检验自己的判断，拓展自己的思考边界。
8. 高管要管理自己的情绪和组织影响力
作为工程团队的领导者，你需要保持开放和真诚。
但与此同时，你也必须意识到：你的情绪、语气和行为，会对整个团队产生巨大影响。
当你成为一个完整职能部门的负责人之后，这种影响远远超过你担任个人贡献者或中层管理者时的影响。
你表现出焦虑，团队可能会认为公司正在遭遇严重危机。
你在会议中流露出不耐烦，其他人可能会认为某个项目已经失去支持。
你随口表达的一点怀疑，可能会被团队理解为一项已经确定的决定。
你当然不需要假装一切都很好。
当你遇到困难、需要帮助时，应该及时而坦诚地告诉大家。但你也需要注意表达方式，不要让自己的压力毫无节制地扩散到整个团队。
多年来，我见过不少类似情况。
一些工程师在个人贡献者阶段以敢说真话著称。他们经常抱怨问题、指出缺陷，也因此被认为坦诚、可靠。
但是，当这些人进入领导岗位后，如果仍然保持同样的表达习惯，就可能不断向团队传递挫败感，让所有人长期处于消极状态。
在个人贡献者的位置上，抱怨有时只是一种个人态度。
但在高管的位置上，抱怨会被视为组织信号。
我从未觉得你是这样的人。不过，当你开始围绕自己组建领导团队时，这一点会变得非常重要。
你不仅需要管理自己的情绪，也需要谨慎选择那些能够在压力下保持稳定、建设性和责任感的领导者。
9. 新任高管要与董事会建立信任关系
我担任 CTO 的最初两年零九个月里，公司经历了两次 CEO 更迭、工程组织的全面重组，以及几乎所有核心系统的架构升级。
换句话说，我们就像是在飞机飞行过程中重建引擎，而驾驶舱还在不断发生变化。
在那段时期，我定期向董事会汇报工程工作的进展，并逐渐与董事会成员建立了良好的关系。
这些关系并不是刻意经营出来的，而是在持续沟通和共同解决问题的过程中自然形成的。
正因为如此，当两次董事会会议之间出现关键问题时，我能够更轻松地与董事会成员进行非正式交流，而不必等到下一次正式会议。
董事会成员通常是经验丰富的投资人、创业者或企业经营者。
在我职业生涯的早期，我通过主动提问、接受建议，以及合理利用他们的人脉资源，获得了很大帮助。
例如，一位董事会成员曾帮助我联系海外某家大型科技公司的工程负责人。那次交流对我非常有价值，对方以一种积极的方式挑战了我当时的许多想法。
在少数关键招聘中，为了说服几位优秀的工程人才加入公司，我也曾请董事会成员亲自给候选人打电话。
顺便一提，那几次电话的成功率是百分之百。
我们还曾邀请一位董事会成员在董事会会议结束后亲自完成一次代码部署。他后来在自己的博客中分享了这段经历。
这件事看起来只是一次有趣的互动，但它帮助董事会更直观地理解了我们的工程文化。
后来，当我接任 CEO 时，早期与董事会建立的信任关系，在许多方面都给了我极大帮助。
因此，不要只在正式汇报时才与董事会成员交流。
主动了解他们的经验，向他们请教问题，也让他们理解工程部门正在做什么、为什么这样做，以及你正在如何带领团队解决问题。
董事会不仅是监督者，也可以成为你非常重要的支持者和资源来源。
新任高管如何完成角色转型
第一次成为高管，最大的变化并不是职位名称，也不是会议数量增加，而是你开始对一个完整职能、一支领导团队，以及公司整体结果承担责任。
你不能再只关注工程团队内部的问题。
你需要理解产品、业务、组织、CEO 和董事会的需求；需要把复杂的技术问题翻译成公司能够理解的语言；需要稳定地交付结果，也需要在关键时刻明确表达立场。
你还需要意识到，自己的每一次发言、每一种情绪和每一个决定，都可能被整个团队放大。
优秀的工程高管，不只是最懂技术的人，也不只是最擅长管理工程师的人。
他们能够在工程与业务之间建立桥梁，持续兑现承诺，塑造组织文化，并帮助整个公司作出更好的决定。
这或许就是从工程领导者迈向公司高管，真正需要完成的角色转型。
文章包含AI辅助创作，作者：liu，如若转载，请注明出处：https://docs.pingcode.com/baike/5250500
