Brett： 非常感谢你加入我们。
Marcel： 谢谢。很高兴能来到这里，也很感谢收到邀请。
1. 新管理者死亡螺旋
Bretttt： 关于我们的对话，我想可以从一个话题切入，那就是工程经理的培养，特别是你如何看待帮助 IC 工程师成长成为优秀的管理者和领导者。更具体一点的问题是，当公司首次考虑将独立贡献工程师培养为工程经理时，你认为大多数人最容易在哪些方面犯错或走偏？
Marcel： 我认为这通常是一个非常艰难的转变。之所以困难重重，是因为在大多数情况下，组织是在某种压力和紧张程度下进行这种调整的，尤其是在规模较小的组织里，往往缺乏相应的支持体系。我常见的问题是这样的：一个在高绩效团队中担任工程师的成员，会因为团队扩张过快、需要更多支持，而被要求成为该团队的管理者。
于是，他们周五还是团队里的高效贡献者，周一就要开始管理四五个人的团队，而且周围几乎没有结构或支持作为依托。这种转变往往非常坎坷，人们发现自己要去做一份从未接受过培训、也未必具备相应技能的新工作，团队进度开始有点落后，这时候问题就出现了。
这就是我所说的“新管理者死亡螺旋”——团队开始落后。而那位曾是团队中最高效员工之一的经理，为了帮助团队扫清障碍，亲自介入。他们以为通过写代码就能帮团队走出困境。但此时，你又回到了之前的状态：团队没有全职经理，而那个人因为既要当经理又要做个人贡献者，精力被拉得极其分散，结果哪方面都做不好。
嗯，我认为这对工程团队来说尤其明显，因为在典型的产品设计或产品设计与工程团队中，大部分人员配置都在工程侧。因此，通常产品设计和工程团队会有一个职能负责人，但团队中的大多数人都需要向工程部门汇报。
所以你会看到这样一种情况：大多数初次担任管理者的人在转向其他职能时，最初可能只需要支持一到三个人。但对于工程经理来说，他们第一次转型时，通常要接手一个五、六、甚至八人的团队，而要支持这样多元化的团队所需的各种技巧——
团队里会有资深员工、初级员工、长期任职的老员工、也有刚加入团队的新人。而这些技巧最好通过经验来习得。而且，新任经理往往缺乏可以效仿的榜样，无法以最高效的方式获得这些经验。
我认为在利用经验方面非常关键的一点是：我想借助他人的经验，这样就不必亲自犯同样的错误。而作为导师，我希望人们能借鉴我过去犯过的错误，从而避免重蹈覆辙。这恰恰是管理者成长过程中最强大的加速器——向其他人、其他管理者学习。
嗯，但如果没有这样的架构，你就是在让每个人都要亲自犯一遍所有的错误。到那时，作为管理者，你会感到非常孤立——因为如果你没有同侪群体、一群可以依靠的人或导师，那你就很可能要面对一连串颇具挑战性的错误。
嗯，我觉得这其实是在给人们制造不必要的困难。
2. 识别潜在的工程经理
Brett： 假设我们有一个五到七人的工程师团队，其规模在逻辑上已经需要一位管理者了（我们稍后可以再讨论“极度扁平化组织”这一话题，以及这类做法在某些情况下是否总是行不通）。如果团队中没有人具备工程管理经验或管理经验，你会如何判断团队中是否有人能够成长为一名真正出色的工程经理？
Marcel: 这个问题问得很好，因为其中既涉及对人才的评估，也关乎对动机的理解。而且这些动机往往是潜在、不明显的。比如，是什么在驱动一个人？直接去问、通过一系列问题来探寻，会非常有帮助。无论是对被问的人，还是对进行评估的人而言，都是如此。我时常提醒大家的一点是，领导力有多种形式。一个人可以作为工程经理发挥领导作用，也可以作为团队中的技术负责人展现领导力。但要弄清楚究竟是什么真正激励着一个人、让他充满干劲——虽然这听起来有些过于简化，像是一刀切的论断，因为每个人都是独一无二的——但如果你能判断出某人真正热衷于解决“人的问题”而非“技术问题”，那么他很可能就是工程管理岗位的合适人选。因为工程管理是通用管理的一个分支，其核心最终归结为如何与人互动、如何激励他人。 同样，这一点非常重要，因为团队中的人处于不同的职业阶段。他们在团队中扮演的角色各不相同，比如是否是团队中资历较深的成员，是否已经在同事间建立起了信任，甚至可能已经是一个非正式的领导者。
接下来，只需要让他们看到这一点被认可和反映出来，他们就能更自在地步入那个角色。因为无论是谁完成这一转变，都会面临一定程度的“冒名顶替综合征”。但你要让这个人从即将开展的工作中获得能量。
如果一个从解决棘手的技术问题中获得最大动力，你应当引导他朝那个方向发展，并支持他去做这件事。但如果一个从解决人员问题或帮助一群人实现他们单独无法完成的目标中获得最大动力，那么他就具备了从事管理工作的部分动机。同时也要提醒大家，从 IC 转为管理者不一定意味着晋升。这两者是不同且并行的职业轨道。重要的是，当人们正在或考虑进行这种转变时，要认识到——我认为工程管理是一门以服务为导向的职业。你必须真正建立起这样的思维模式：你的存在是为了为团队中的人提供服务，你是为他们工作的。
他们并不为你工作。因此，那些已经展现出部分相关行为特质的人，是担任管理角色的理想人选。话虽如此，你仍需与他们进行一次非常坦诚、开放的对话，讨论可能面临的挑战，以及他们需要放弃的一些东西。嗯，你知道，很多初次担任管理者的人常跟我提起的一点，就是失去了对自己日程安排的控制。
作为 IC 工程师，你通常一天只开几场会，还能留出整块时间专心写代码，享受自己真正热爱的工作。但成为管理者后，你的工作节奏会更多地被各种打断驱动，别人会不断往你日历上塞进各种事项。会议就像是这个领域里的硬通货。
你会花大量时间充当信息中间人：收集信息、传递信息、做决策，而这些都发生在会议中。你的日程不再由代码拉取请求或功能工单列表驱动，而是被日历接管。所以，人们需要清楚地了解从 IC 转向 EM 时，伴随而来的究竟是怎样的角色转变。
3. 评估领导潜力的提问
Brett: 如果你正与一位有八年团队经验的 IC 工程师共进午餐，你想通过自己的分析和深入提问来判断这个人是否具备卓越潜力，你会问他们哪些类型的问题？
Marcel： 那么，如果一个人已经具备了那样的经验水平，此时他们很可能已经与团队中的暑期实习生或刚入职的应届毕业生有过一定程度的互动。这通常是一个很好的切入点，可以询问那段经历如何，他们喜欢其中的什么，不喜欢什么，以及下次再带人时会做出哪些改变。我在此想要评估的，是这位工程师在帮助新人融入或提升他人方面，对自身角色有多少反思。如果一个能够相当深入地反思自己的贡献和在过程中的作用，那么我认为他可能已经在潜意识中流露出了一些信号，表明他愿意再次承担这类工作，并希望成为其中的一部分。
也许在规模较大的公司里，如果有人主要关注的是挫败感，却不愿为自己的不同做法承担责任，或者没有从中吸取教训，又或者没有从过程中获得成就感，那么你可以尝试从其他方面进行探询和了解，但这通常不是最初就能判断出他们是否想成为管理者的信号。
Brett： 你认为一个水平普通的工程师能成为世界顶尖那 1%的工程经理吗？
Marcel： 这个问题挺有意思的。因为如果你去问那些世界顶尖 1%的工程经理，他们当初作为工程师时水平如何，几乎所有人都会说：“哦，我算是个还不错的工程师，但算不上顶尖。” 你每次都会听到类似的回答，对吧？其中一部分是出于谦虚。但我认为，很大程度上，恰恰是因为你本身就是顶尖的人才。
顶尖的1%工程经理能够吸引并留住极其优秀的工程师。因此，他们共事的工程师群体本身就已经非常出色，而他们也会以此为标准来要求自己。嗯，这个回答可能有点冗长，本来可以更简洁一些。我想说的是，我确实认为你需要成为一名非常优秀的工程师，但同时你也要非常擅长读懂人心，并具备高情商，才能真正有效地履行工程经理的职责，并在未来进一步成长为领导者。所以，我认为，尤其是在早期转型阶段，如果你能利用好自己作为高绩效工程师时已经具备的技能，那将大有裨益。
这就是为什么我认为，在已有一定技术领域专长的公司里进行这种转型会非常有帮助——这样你可以将学习能力用在提升工程管理技能上，而不是像学习技术栈等你已经掌握的技能上。
嗯，一旦他们做到了这一点，就可以进行角色转换，他们所学的管理技能是具有可迁移性的，能够带到新的公司或组织中去。
4. 权力分散与技术决策
Brett： 彼得·泰尔曾提出过一个颇为知名的观点，我认为基思·拉博伊斯至今仍深信不疑，那就是：把你最优秀的工程师提拔为团队的工程经理。听了你的大致介绍，我猜你对此框架持有异议，并且认为它会导致不良后果。
但我很好奇，也许你可以先站在反方立场，阐述一下这个观点可能存在的合理性，或者解释一下它为何有一定道理，然后再回过头来谈谈你之前分享的看法——为什么这可能会是一个陷阱，或者你过去在实践中看到这种思路引发了哪些问题。
Marcel： 是的，我认为这种思维方式比典型的风险投资领域更为普遍。我猜这源于其中蕴含的务实精神以及即刻见效的特性——能够为团队其他成员守住高技术标准，并有效绕过团队可能正在做的技术决策。
从而尽快找到正确的答案，并为团队指明方向。我认为这确实有其价值。不过，我其实觉得，很多这类工作并不一定需要以工程经理的身份来完成。这也是为什么我认为工程经理应该专注于支持整个团队，为团队提供一定程度的自主权，同时营造一种氛围，让团队中的每个人都能以某种方式成为领导者，参与技术决策，并为团队指明方向。
我认为这其中的部分原因可能在于人们考虑的时间框架。如果你身处初创公司，通常有一定的资金支撑期，最多也就12个月。你没有时间做长线决策，也没有时间反复评审决策。你需要尽快做出正确的技术决策，并让团队保持前进。
在我看来，这正是人们会把决策权交给最优秀工程师的原因。而如果决策权集中在工程经理层面，那么让最优秀的工程师担任经理也就顺理成章了。不过，我对此的反驳是：我并不认为决策权必须集中在工程经理层面。
我认为那样会形成瓶颈。你应该做的是，让这个人搭建好框架、流程和环境，让团队成员能够在离问题最近的地方做出决策。这样一来，各个层级的工程师都能参与决策。当然，这并不意味着他们的决策不需要经过评审。
嗯，但团队中那些并非工程经理、却表现卓越的工程负责人，同样可以通过规范文档来进行代码审查和技术评审。而且，如果他们不需要处理那些他们眼中——这里我用了带引号的——“额外负担”或“人员管理税”的话，他们很可能会更投入、更满意地在这个岗位上工作。
嗯，你知道，我认为我们这个行业没有足够重视的一点是：有多少高绩效的工程师转向工程管理岗位，干了一段时间后离开，并且再也没有回去。如果这像是某个服务的故障率，我们肯定会做一次事后复盘，并对如此高的故障率感到担忧。
嗯，但在这种情况下，我们通常只会说，啊，工程管理不适合他们。而不会进一步深究：为什么这个人本来很高效？是他们自己选择做管理，还是被要求做的？然后他们决定不再继续了。我认为，部分原因在于我们并没有明确设定这份工作的职责预期，或者这份工作中有一些不愉快的部分，我们只把注意力集中在那上面，而不是把责任分散到整个团队中。
嗯，所以我的一个总体目标是，希望我们这个行业能够更好地支持那些正在经历这种转型的人，提高他们转型成功的比例，并让他们愿意坚持下去，因为行业需要优秀的工程经理。
5. 转型成功的比例
Brett： 根据你至少接触到的样本，你觉得现在的成功率是多少？
Marcel： 我认为低于 50%。而且我觉得这个比例可能会因公司和公司所处的阶段而有所不同，但总的来说，根据我的经验，成功率低于 50%。
Brett: 我觉得你刚才已经开始触及这个问题了，但你会如何描述根本原因？有多大程度上是因为某人其实并不能从你提到的那些事情中获得能量，却还是选择了这个角色？相比之下，又有多少是因为技能和能力方面的原因——也许他们从理智上觉得自己会从培养人才、为一个更大团队的结果负责中获得能量，而不是亲手打造产品本身？
不过，我觉得可能还有几个你注意到的其他原因。我认为一部分是意愿问题，另一部分是能力问题。当然肯定还有其他因素，但我很好奇你是怎么看的。
Marcel: 这个问题问得好。我觉得，每一次失败或转型的情况都不太一样。有一类人，他们进入管理岗位的动因本身就是错的。而这可能并不全是他们自己的问题，也可能是他们所处的组织结构使然——为了获得加薪，或者得到公司的认可和重视，他们必须走上管理轨道。
我认为，这本身就是一个问题。相反，我们所说的并行发展轨道，应当让员工在每条轨道的每个阶段都能获得相应的回报。但归根结底，管理是一项艰巨的工作，充满挑战。如果你出于错误的原因进入这个岗位，又缺乏内在动力，那么工作的难度会促使你重新审视、调整方向，甚至可能选择放弃
或者半途而废。而我们初次担任管理者时，往往会欠缺某些技能。要成为一名高效的管理者，存在技能短板是常有的事。我认为，无论你所在组织的入门级管理者层级是什么，它很可能都是跨度最大的层级——因为它既要支持第一次担任管理角色、可能只带三四个人的人，也要照顾到那些已经从事管理工作两年左右的人。
你让他们去支持10个人。这两类组织的性质截然不同。但那些接手这类职位、可能存在技能欠缺的人，正是希望组织能提供一定程度的支持、学习和成长机会。这并不一定意味着——比如我就职于一家六万人的公司，他们有专门的学习发展计划，这是我学习管理的唯一途径。
在我提到支持以及完成这一转型时，实际上就是指拥有一位导师或管理者。他可以告诉你：接下来你将第一次面对艰难的绩效谈话，以下是应对的方法。仅仅是与一位有过类似经历的人进行这样的交流，就能让你在第一次实际操作时的效率提升至少十倍。
我的意思是，这其实是一场很有挑战的对话。稍微准备一下，会让你在进入对话时更从容一些。如果你发现人们正处在那种“边缘状态”——他们开始在不适应中感到些许自如，并且能从中学习，那就说明他们具备了成长型思维，这对所有参与者来说都是一个成长的机会。
但你会发现，如果缺乏恰当的支持体系，同样的情况可能会让人每周都陷入高压状态。而这样一来，就容易让人主动选择退出，不再愿意去学习或在经验边界上尝试突破。
这更像是一种长期处于高度紧张的状态，而人类并不适合那样生活。
6. 工程经理的职责定义
Brett： 你提到过、但我们并未完全界定清楚的一点是，优秀工程经理的职位描述究竟是什么？
Marcel: 嗯，这大概是大家讨论得比较多的问题之一，总体而言。
在我看来，一位卓越的管理者，基于问题的本质，必须在多个维度上都表现出色。你首先会想到，这个能显著提升团队的工作效率。这背后涉及的因素非常之多。同时，他们还要确保团队拥有所需的一切资源，从而能够稳定地向组织其他部门交付高质量的工作成果。
因为这样做，其实是在为自己的团队铺路。优秀的经理人也是出色的招聘者，他们擅长留住人才，擅长处理跨部门协作，能与产品、设计等对应方良好配合，真正提升整个团队的水平。同时，他们能为团队提供非常清晰的工作方向。我提到这其中涉及很多因素，而初次尝试这些的人往往容易出错。在我看来，大多数初任工程经理最容易卡壳的地方，是在为团队成员设定并维持恰当的期望值上。我特意用了“恰当的”这个词，因为优秀的管理是因情境而异的管理。正如我之前所说，团队里可能有资深员工、新人、正经历个人困难的人、目前缺乏投入感的人，或者正在学习新技术栈的人。每一种情况所需要的期望值、支持与鼓励方式都各不相同。
嗯，我认为这正是卓越的管理者所擅长的——他们知道如何有效地应对这些情境差异。他们不会用同一把锤子去解决面前的每一个问题，而是会先观察情况，真正加以评估，再审视自己工具箱里的工具，或者寻找新的工具，以此来激励和支持每一位下属。
这一点有时会被忽略：当你管理一个团队时，你既要管理人以及随之而来的人际动态，也要管理团队中的每个个体，真正去了解他们、与他们合作、支持他们，并在个人层面激励他们。我刚才说了很多关于优秀管理者需要具备的能力，但他们之所以优秀，部分原因就在于他们能够在某个阶段做到所有这些事情。
7. 期望设定与事实反馈
Brett： 我觉得你强调期望设定如此困难这一点很有意思。我认为，当人们在 2023 年谈论优秀管理时，往往会想到支持团队、帮助团队提升效率以及培养人才。但我感觉，其中有一部分常常被忽略。
那就是你还要对团队的结果或产出负责。嗯，我猜当你谈到期望设定时，这大概就是你想要表达的意思之一。也许当你想到新任管理者，想到两个极端时，有些人会偏向强势掌控。
我们必须完成这件事，并真正进入那样的世界。可能还有一些人像是支持系统，为他人提供帮助，诸如此类。但你需要两者兼备：既要有明确设定方向的能力（也就是设定预期），也要有培养人才的支持理念。那么，或许你可以再多谈谈预期设定，它对你来说意味着什么，以及你会如何帮助新任管理者培养这项能力。
Marcel： 预期设定非常关键，而且我认为每个团队的成员都强烈希望知道：对我的期望是什么？我怎样才能最好地发挥作用？每家企业都面临某种挑战——它们要成长、扩张、求生存，而团队中的每个人每天醒来，都希望为成功做出贡献。
他们希望成为其中的一部分，并且都意识到，共同努力才是实现目标最有效的方式。但为了达成这些成果，我们需要明确对自己的期望是什么。我认为重要的是——我个人的看法是，一位高效的管理者会设定一个很高的预期标准。
他们会对这一标准非常明确，然后支持团队成员达成目标，了解他们的需求并帮助他们达到那个水平。但这是一个共同的目标，因为我们已经设定了标准，而且标准清晰明确。现在关键在于，如何帮助团队成员达到那个水平？
因此，第一部分是设定预期，第二部分则是帮助员工达成这些预期。我还认为，对于新任管理者来说，这似乎是一项需要不同能力的任务。你需要对那些不久前可能还是你平级同事的人非常明确地表达：我需要你做什么，或者对你有什么期望。然后，你还必须根据这些预期客观地评估员工的表现。我认为这对新任管理者来说是一种截然不同的体验。我会试着鼓励他们不要把这看作是对团队成员的评判，而是要充当事实的陈述者，像一面镜子一样照出员工的表现，让他们看清自己的执行情况，并了解自己的绩效如何影响团队中的其他人，以及团队中的其他人是如何看待他们的表现的。
真正优秀的经理能够以让员工感到自然的方式提供反馈，而不是让他们去问同事：“嘿，我表现如何？” 我们当然希望建立鼓励反馈和直接反馈的文化，但人们往往会感到不自在。出于多种原因，他们更愿意从经理那里获得反馈。
因此，我总是鼓励新经理积极承担这一责任，尽可能向员工提供基于事实的证据，说明他们的表现与预期相比如何，同时也要明确传达下一阶段的期望。我会尽量以更积极——甚至是最积极的角度来阐述这一点：比如，当你为某人撰写晋升材料时，晋升所需的工作其实都是对方完成的，你只是像记者一样记录下这些成就。工作是他们做的，荣誉自然也该属于他们。
人们很喜欢这种说法，也愿意投身其中。我还会强调，无论是在设定期望还是进行绩效管理时，你所扮演的角色其实是相同的：向对方提供事实，让他们能够观察自身行为，并据此做出调整。
Brett： 您认为，新任工程经理应如何判断自己为团队设定的期望是否合理？
Marcel： 这里的一个好方法是，他们可以利用周围的其他管理者以及自己的上级。不过，观察团队在期望设定后的反应也非常重要。如果团队完全不知所措，作为管理者你是能察觉到的，进而可以问问自己：这是否符合你的预期？
这是否合理？你认为这是一个激进但合理的目标吗？我们能实现吗？答案本身是“是”或“否”其实并不重要，因为你真正在做的是为后续的深入对话打开空间，去进一步挖掘和理解——当我说“我们将在某个时间范围内交付某个功能”时，具体意味着什么。
你对此有什么想法？你的第一反应是什么？感觉如何？为什么这与你之前提供的估算不一致？也就是说，我说的与你之前给出的内容之间有什么差异？有时候人们会给出非常好的回答，比如：“哦，我的估算没有把开发周期、测试版阶段或实际测试时间考虑进去。”
这正是我们可以进行调整的机会——好，那我们就把这些因素纳入考虑，在估算时更全面地涵盖所有相关环节。同时，这也是一个很好的契机去追问：为什么当初我们没有把这些因素考虑进去？你为什么选择了这个更激进的时间表？
因为这可能会透露很多信息。也许团队正处在一个充满恐惧的环境中，大家觉得必须给出很短的预估时间，才能尽快完成工作、让项目获批。但实际上，这需要更充分地讨论所有涉及的环节。
但我认为非常关键的一点是，尽管管理者可以与自己的上级或同级沟通期望，但更重要的是直接与团队就这一点进行坦诚对话——因为设定期望不会只发生一次，你希望每次都能让彼此更加协调一致。
8. 健康的张力与目标设定
Brett： 在设定期望时，你认为多大程度的挑战是健康的？我猜，其中的一些微妙之处在于，你希望适度地推动团队，想要刚好处于那个临界点。同时，我也觉得很多关于 OKR 的思考——比如完成 60%或 70%就算达标——会带来不少问题，因为那可能会让人非常沮丧。
另一方面，如果你总是轻松达成目标，就可能滋生一种“压低预期”文化的，无法充分激发团队潜力，也难以对大家提出更高要求。设定标准的高低，感觉至关重要，但这一点似乎又有些被忽视了。
Marcel： 完全同意。
Brett： 目标设定这件事，往往做得非常模糊，但它可能恰恰是最重要的——关键就在于标准定在哪里。
Marcel： 说得太对了。
Brett： 作为团队的管理者。对此你有什么想法吗？
Marcel： 有的。我认为在谈论目标和期望时，正如我之前所说，管理者的部分职责就是设定明确的期望，然后支持团队去实现它。设定期望是工作的一半。而且我认为，在团队应该有多大程度的“拉伸”这一点上，需要一种健康的张力——我特意用这个词。
团队应该感到自己正在突破极限、完成某项重大成就，因为这正是最理想的境界。这种状态几乎就是心流状态所需要的：恰好能完成任务，同时感到自己得到了锻炼，并在过程中有所学习。
你需要避免的是设定期望时——显然过高或过低都不可取，但哪怕只是稍微偏高——导致项目延误，团队在最后阶段感觉像在“死亡行军”。即便最终项目上线，大家也不会有任何成就感。
这更像是一种情况：我们错过了截止日期，但还是发布了产品。而日期，你知道的，有些是随意的，有些是实在的，但日期是组织表达优先级的方式。所以，我确实认为，作为一个职能部门，纳入日期是很重要的。但在设定这些目标时，如果你80%到90%的情况下都能达成目标，依我看，那可能目标设得太保守了。
很可能是因为你设定得不够有挑战性。其中一部分原因在于，如果你设定的目标相当有挑战性，并且达成了其中的 70%，那么剩下的 30%你很可能也仍在推进中，并非毫无进展。我有时看到 OKR 或目标设定出问题的地方在于目标过多，比如一个半年周期内有八九个优先事项或顶层 OKR，到了那个地步，团队成员就会开始问：等待，这些目标我都要参与吗？
其中有些目标同等重要，但在业务层面，实际上所有目标都很重要。可能有两三个尤为关键。针对这几个，你需要再次明确设定期望，做到清晰透明。你要强调一点：虽然我们可能只完成了 OKR 中的 70%，但这三个必须全部达成，因为它们关乎企业的生死存亡。
我们必须确保完成这些目标。我认为，这种清晰的认知是每个人都欢迎的，因为它能帮助大家做出恰当的取舍和微观决策。这也是为什么要让团队对目标达成共识——你不希望决策过程成为瓶颈。
你希望每个人都能掌握足够的信息，在自己的层级和职责范围内做出正确决策，而无需层层请示、到处问问题。你已经赋予他们决策的权力，也提供了正确的背景信息、OKR 或其他规划与优先级框架，帮助他们做出合理的权衡。
因此，事情的推进速度变得更快。
9. 赋能与自主感
Brett: 您能否回想一下过去几年中，您自己管理或由您下属的工程经理负责的某个团队，并给我们讲一个故事，说明在一个季度或一年内，好的目标设定和情境设定是怎样的？或者任何能将其具象化的方式。
Marcel: 好的。我想，嗯，最近有一个例子可以说明。那是我在 Slack 支持 Slack Connect 团队的时候，这可以说是一个从零到一的项目。首先介绍一下 Slack Connect：Slack 是一款许多人在工作中用于沟通的产品。而 Slack Connect 则允许你跨组织进行沟通。
它打破了组织边界。在参与那个团队的工作过程中，我逐渐意识到一点：在此之前，我主要支持核心产品体验，其主要用户是每天与产品交互七八个小时的最终用户。但当进入跨越组织边界的领域时，我真正体会到的一点是，管理员或所有者的角色变得极其重要，因为他们希望确保信息得到保护，确保公司免于承担任何形式的法律责任。
在那个层面上有许多管控措施。在我们推出这款产品的过程中，我认为最初我们过分关注核心产品的最终用户体验。我们希望把它做得非常出色，因此在邀请流程、响应流程以及这些流程如何实际落地方面投入了大量精力。
在早期与首批 alpha 和 beta 测试客户合作时，我们面对的是主动选择加入的组织。因此，我们在管理工具以及提升管理员体验方面投入的精力较少。直到产品正式上线后，我们才意识到这一块投入明显不足。
因此在制定下一季度的目标时，我们重点关注如何改进这一体验。目标设定不再是围绕项目本身，而是围绕正确的指标，比如审批通过率和管理员参与度。随后，我们赋予团队自主权，让他们去研究应该采取哪些有效措施，开展调研，与管理员沟通，找出痛点所在，并在此基础上交付成果。
但并非领导层在告诉团队具体该如何执行，而是领导层明确哪些事项至关重要、如何衡量成效，至于具体达成路径，则由团队自行决定。我认为团队非常欣赏这种方式。各类组织在开展员工敬业度调查时，总会听到这样的反馈：员工敬业度的关键要素之一，就是自主感，以及能够真正产生影响、做出有分量的决策的能力。
如果你通过设定目标与预期成果，并提供相应支持来赋能团队，同时让他们自主决策，这远比直接列出具体项目更能激发团队活力。部分原因在于，这种阶梯式指令往往效率较低——你很难在季度初就准确判断哪些项目是正确的，并且能贯穿整个季度、半年或任何周期，这样的可能性微乎其微。
如果你依赖高管层的反馈周期，从最初的理论或假设到真正拿出可行的解决方案，往往需要很长时间。但如果你能将决策和反馈闭环下放到团队层面，同时确保大家对齐最终目标，你就能更快地达成结果。
团队离问题更近，也能更快地进行迭代。当然，这种情况下，团队可能会产生一些焦虑。如果你不完全清楚团队在做什么，你也会因此感到不安。所以这并不意味着完全放手不管，仍然会有与领导层的定期同步等机制。
但我认为，不同文化之间存在着差异：一种文化下，团队感到自己有自主权去完成这类工作；另一种文化下，团队觉得自己只是接单员，按指令行事——“这个功能就要这样来构建”。而这种差异，最终会体现在产品构建的方式、员工的投入度，以及最终的结果上。
10. 处理平级转型的尴尬
Brett： 我想稍微展开聊聊你提到的几点。其中有趣的一点是，当你成为新任管理者、新任工程经理时，有些人可能会面临需要管理原本关系很好的朋友。对此，你有什么建议或指导，帮助大家妥善处理这种情况，避免陷入困境？
Marcel： 对于这种情况，我通常建议大家要意识到这种尴尬确实存在，而且双方都心知肚明。这并非只是潜意识里的感觉，而是实实在在的问题。和大多数人际关系一样，最好的方式就是开诚布公地谈一谈，把这个问题先摆在明面上。
一开始，我也会鼓励大家不要把它必然视为障碍。当你开始管理一支不熟悉的新团队时，首要任务之一就是投入大量时间建立关系。而如果你已经拥有这些关系，虽然互动方式可能需要调整，但至少你是在已有一定关系基础的情况下起步的。
我认为明确这一点很重要：作为你的经理，我会戴上经理的“帽子”，并以这个身份向你提供这类反馈。同时要认识到，刚开始这种感受会有些不同。根据我的经验，对于刚走上管理岗位的人来说，这种感受是最为不同的。
那位成为经理的人。我认为他们在这方面遇到问题的情况相对较少。部分原因是，如果这一过程处理得当，团队早已感受到相关信号。团队成员会支持他，认可他作为实际上的领导者，而之前他们可能只是约他一起喝杯咖啡，请教一些问题。
如今，他们是在绩效评估中收到反馈。场合变了，利害关系也截然不同，但沟通的本质是一样的。当然，如果涉及绩效问题或其他情况，挑战就会出现，感觉也会大不相同。不过，新任经理应该认识到，他们并非孤军奋战。
大多数组织都设有人力资源部门。你自己也有上级经理。身边也有人可以依靠，帮助你完成第一次处理 X 类或 Y 类棘手对话的过程。
Brett： 你提到了那种“把隐含的东西变得明确”的想法。当你从某人的好友过渡到管理者的角色时，能否进一步谈谈你认为那场对话应该是什么样的？
Marcel： 这几乎是在某种程度上设定道路规则、交战规则。而且，虽然我认为这在处理“从平级同事变为管理者”的关系时最为明显，但我也认为，这对于那些作为团队新成员、接管一个已有团队的经理来说同样非常重要，因为团队中存在着一些不同的、但非常强烈的动态关系。
在这最初的几次一对一会面中，我都鼓励大家准备一份书面材料。这份材料要从下属的角度出发，写明他们希望如何接收反馈？哪些事情会触发他们的情绪？他们想做什么？他们的职业目标是什么？他们觉得自己在哪些方面需要被推动？
因为我觉得，这涉及你之前稍微提到过的一个问题：管理就像在支持与推动之间摇摆。而你真正想要的是两者的结合。我认为，在近期的管理理念中，管理被更多地描述为应该偏向支持一方，而不是推动一方。
但如果你在员工敬业度调查或日常交谈中再次询问大家，他们最想从经理那里得到什么？答案是他们没有得到的是能帮助自己提升工作能力的直接反馈。我之所以能一字不差地这么说，是因为在我所审阅的每一份关于经理的绩效评估中，都能看到这句话。
他们团队中的每个人都希望如此。但我觉得这多少是人之常情——有些人即使渴望得到直接反馈，也不愿主动对他人提出。不过，如果你在这种合作关系伊始便与对方坐下来沟通，询问他们希望获得怎样的反馈、以何种方式接收，他们一定会告诉你：他们想要建设性的、直接的反馈。
而一旦他们明确写下这一点，你就很难不去照做——毕竟是他们主动要求的。你是个有礼貌的人，更何况这是你的职责所在，你理应提供这样的反馈。此时，你的困惑便会从“我该不该这样做”转变为“我该如何去做”。而正是在这个节点上，你才能真正与对方展开对话，去了解：对你而言，我用怎样的方式提供反馈才是最有效的？
这在实际操作中只是初步的尝试，有些时候你需要立即给出反馈。有时，以书面形式提供反馈是最佳选择，这样对方就有机会阅读、理解和消化。但我认为，一旦你确立了这类基本规则——无论对方是与你平级的朋友，还是你刚认识、即将向你汇报的人——这都有助于为这段关系的走向奠定基础。
所以我鼓励大家真正重视这一点，并在关系建立之初花些时间来明确这些规则，因为这将成为他们未来可以借助的杠杆。
11. 直接反馈的艺术
Brett： 你刚才简单提到了这一点，但我想问，为什么你认为大多数情况下，直属下属最渴望的往往是获得更多反馈？我觉得这一点尤其耐人寻味，因为如果你不是 CEO，你在组织中的某个层级上通常也要向其他人汇报。
那么你正处于接收反馈的一方。我猜这里存在一种奇怪的二元性：比如工程经理向他们的工程总监要东西时，最想要的是更多反馈；而与此同时，如果你和他们的下属聊，他们也希望得到更多反馈。这就形成了一种微妙的关系，因为大多数人既是管理者，也是管理体验的消费者。
即便在一个只有两层管理架构的小型组织中，情况也是如此。那么，你认为这背后是什么原因呢？
Marcel： 我对此有一个看法，嗯，这可能有点尖锐。我的观点是，大多数管理者在觉得自己已经给出了一些反馈时，往往是他们为此做过准备、可能那天洗澡时还在思考的事情。他们写下一些内容，然后在一次一对一会议中传达出来。而接收反馈的人并不觉得自己收到了反馈，或者觉得这些反馈没有建设性、不具备可操作性。我认为，你可以说这是双方在自说自话，也可以说这是把话说得太委婉了。但我觉得，实际情况是我们永远没有自己以为的那么直白。作为管理者，说出“我给你一些直接的反馈”几乎是一件痛苦的事。我想这样说：我想让你知道，我接下来要说的这句话就是反馈，这样当你结束这次一对一会议后，你可以问自己：我收到反馈了吗？而你就能指向这句话，对吧？
这听起来有些刻板，甚至有点刻意。但我认为，关键的一点在于，我们必须非常明确地告知对方：我即将提出一些反馈，或者我对你有一些反馈。这样先把定位说清楚。而人们之所以不这么做，或者说这种情况之所以没有发生，一个主要原因在于——
因为一听到“我对你有一些反馈”这句话，有些人立刻就会产生防备心理。作为管理者，你会注意到这一点。于是你试着把反馈夹杂在其他话语中，结果反馈被稀释了，听起来就不像反馈了。所以，这种做法其实是出于想让大家感到舒适，但实际效果却截然不同。
它让人感到不满足。所以我认为，一旦双方建立起了信任关系，或者已经这样做过一两次，事情就会变得顺畅得多。但要迈出第一步，所需的启动能量是非常大的。
12. 绩效管理与离职处理
Brett： 我认为有一点可能被略微低估了，那就是优秀的管理者非常擅长让不合适的人离开团队。我个人的粗略看法是，大多数管理者在这方面做得还不够，而新晋管理者尤其难以应对。嗯，我好奇，我觉得很多公司在评估管理者时，并不怎么讨论如何妥善地让员工离职。
他们会根据管理者在让员工离开团队方面的能力来评价他们吗？我认为大家更多谈论的是培养人才、指明方向之类的事情。但这个问题很少被提及，对吧。所以，如果一个管理者今年还没有让任何人离开，那要么他们是天才招聘官——但几乎没人能做到这一点，
要么就是团队中有一部分人并没有被合理地劝退。这显然不是一个愉快的话题，但我发现，关于如何请人离开，或者如何判断某人应该离开团队，相关的指导并不多。因此我特别感兴趣的是，因为我们主要是在讨论新晋管理者的背景下谈这个问题。
您如何支持新管理者培养这种能力？这不幸将成为他们职业生涯中至关重要的一部分——如果他们希望成为优秀的管理者的话。
Marcel： 我先说几句扎心的大实话，然后再具体回答问题。之所以说扎心，是因为这是我职业生涯早期有人对我说的，当时让我冒塞顿开。每次我向别人重复这句话时，我都会感谢这个人：如果今天能用一个新员工替换掉你团队里的这个人，你会这么做吗？这与“你是否准备解雇这个人”是完全不同的问题。但当你引导人们从这个角度思考时，答案往往是肯定的——我愿意换人。我愿意找一个能通过面试流程的人，来取代这个已经在岗几个月甚至更久的人。一旦你确认了这一点，下一个问题是：作为管理者，我提醒大家，你们往往最后一个才知道——但如果你都这么想了，你觉得团队里其他每天和这个人密切合作的成员会怎么想？这两个问题通常足以让人们重新审视现状。
他们可能还没准备好解雇某人——解雇是个棘手的词，但他们确实还没做好让某人离开的准备。而他们在思考绩效管理时，我觉得关键在于如何让人们接受这是工作中合理的一部分，并在此过程中不断进步。大多数组织会采取某种形式的校准，比如每六个月一次。而你描述的情况，正是我在每一次非最高级别人员参与的校准中观察到的现象。对于首席工程师这类人，一进入会议室，大家就会立刻展开健康而激烈的辩论，因为人们对他们的标准非常高。但在我参与的其他所有校准中，有时我会在心里想——这个比喻可能暴露了我的年龄——我会想：这是《沃比根湖》吗？还是说所有这些人都高于平均水平？怎么可能每个人都达到了预期，而我们整个组织只完成了 70%的 OKR，或者某些项目根本没有交付？
这难道是我们的预期吗？当然不是。那么问题出在哪里呢？我们需要帮助人们理解，作为管理者，你既是资本配置者，也是人才评估者。人才评估并非始于招聘、终于招聘，而是一项持续不断的工作。绩效管理也是一项常规事务。
这并不是一个肮脏的术语，也不是一个负面的概念。你不应该将其视为贬义词，因为如果操作得当——我认为部分问题在于，人们往往直接跳到解雇这一步，而没有思考紧接在解雇之前的步骤，也就是绩效管理——或者更确切地说，绩效管理本应在解雇流程的上游就介入。如果操作得当的话。
其中一部分情况会得到改善，相关人员会成为对组织有积极贡献的人。他们会重新聚焦，更清楚地理解对自己的期望，并获得更好的支持体系。在绩效管理过程中，还会发现一些有助于这部分人取得成功的问题。
对于那些经历过这些却未能成功的人，我想我们所有人心里都隐约明白，只是大家不敢明说——那个人其实过得并不好。如果你已经接受过辅导计划或绩效改进计划，并且知道自己表现不佳，你心里其实很清楚。所有人都心知肚明，到了那个地步，再拖下去也没有意义。
我观察到，有些新任管理者会说“再给他45天试试看”，某种程度上，这不过是让这个人再多承受45天的痛苦。而我认为，当你认识到有一种体面且人性化的方式让员工离开、帮助他们告别公司时，你就会觉得这样做远比让他们再熬45天、持续处于被审视的状态、感觉自己的工作和未来岌岌可危、知道自己表现不佳要合理得多。当一个表现不佳，已经尽力尝试却仍无起色时，有时候他们需要的其实是去另一家公司的另一个岗位。我见过很多人在这样做了之后反而发展得很好。部分原因是他们找到了更适合自己的环境。也许是因为他们生活中有些问题需要先处理好。但我想，当事情行不通时，就必须做出改变。
而且这不仅仅是为了身为管理者的你自己，因为我认为回避那些棘手的对话多少有些自私。你这样做既是为了对方，因为清晰即善意；也是为了团队中的其他成员。作为管理者，你对整个团队负有责任。
确保团队得到良好的展现，并且为团队中的每个人坚守质量底线。所以，尽管这是一个彼此负责的团队，但真正执行问责机制的还是管理者。我之所以提醒管理者这一点，是源于我自己的亲身经历。
我遇到过这样的情况：团队成员会跟我说，某某人表现不佳，不可靠，指望不上。这时我的第一反应总是：好，我先去了解更多信息。我会找那个人聊聊，看他觉得自己表现如何，同时也会去问问团队里的其他人。
在我去询问团队其他成员时，从未有人跟我说“没有啊，这个人干得很好”。实际情况总是：那个人已经苦苦挣扎好几个月了。于是我开始追问：我怎么到现在才直接听到这些？为什么我之前完全没注意到？
后来我意识到，这个问题不该去问别人，而是该问自己——因为我本该更贴近情况，本该理解问题发生的根源。等到团队里有人向你反映绩效问题时，他们对那个人已经不再抱有期待了。
他们一直在默默计时，因为你本该在他们提出之前就发现问题。因此在我看来，这意味着：是时候采取行动了。这并不代表第二天就要让人走，但你必须立即积极处理这个绩效问题。
13. 管理者的辅导与以身作则
Brett： 假设你是一位工程总监，手下有五名向你汇报、并由你负责的工程经理。
那么，这位总监应该做些什么，来帮助直接下属培养这种能力，或者说让他们非常擅长处理人员离职问题？
Marcel： 我认为，第一步是评估人才并进行绩效管理实践。实际上，工程总监在这方面具有独特的优势，因为虽然我提到过校准流程通常是在副总裁级别进行，但总监完全可以与自己的直接下属进行非正式的校准。
定期进行。事实上，他们应该这样做。我希望我团队中的总监们能在中期校准中做到这一点。他们把经理们聚在一起，这时风险相对较低。这并不是要录入 Workday 等正式系统的评级，而是一次正在进行的对话。我认为在那一刻，总监们能够真正设定标准，以及处理问题的预期方式。当发现绩效问题时，总监们可以与那位经理以及其他经理一起参与，以身作则，明确指出：我们将如何支持这个人——这对我来说是关键部分——以及我们将在什么时间线上得出一个明确的解决方案。
Brett： 是的，预先承诺契约。
Marcel： 没错，正是如此。尤其是当你设定一个时间表时，因为日期是组织表达优先级的方式。这才能真正让人集中注意力。好比说，好了，在接下来你选定的 30、45、60 或 90 天里，事情只会朝两个方向中的一个发展。现在大家都大概明白了，我们将会……而到了这个节点，工程总监和经理再次以身作则，对所有人做出示范，就显得尤为重要了。
这是尽最大努力时的做法，因为我们会尽全力帮助改善局面。从财务角度看，这符合组织的最大利益。如果情况确实能够好转，我们也希望促成这样的转变，因为填补职位空缺需要很长时间。所有这些都说明，我们已经在这个人身上投入了很多，但如果到了某个节点，我们确定已经尽了最大努力，而局面仍未改善，那么这就是体面退出的方式。
提前向团队成员展示并说明相关流程，让他们清楚了解有哪些工具可用、以及问题升级的路径是什么。尤其是对于团队中新上任的管理者来说，“绩效管理”和“辞退员工”这些词往往让人感到害怕——如果他们之前没有相关经验，其实并不真正理解这些意味着什么。
是不是意味着我得和这个人面对面地告诉他们被解雇了？具体到底是什么流程？该怎么操作？提前解释清楚这些情况，反而能让每个人都更安心一些。大家也会明白，这绝不是一时冲动的决定——不是某天早上起床心情不好，就决定要开除谁。
而是有一套成熟的流程和可预期的步骤，最终引导我们走到那一步，并且当我们真正做出决定时，能够确信这是正确的选择。
14. 拖延绩效管理的陷阱
Brett: 在你的职业生涯中，关于妥善解雇员工或营造良好处理氛围方面，还有哪些值得提醒大家的陷阱或常见错误？
Marcel: 我认为在这方面，我看到人们最容易出问题的地方——无论是新任还是资深管理者都会犯——就是他们拖得太久才开始启动流程。再次强调，这是一个流程，你不能草率做决定。它需要时间。通常情况下，组织在处理此事时会有一个预期的时间表。
我认为，问题在于管理者不愿进行最初的艰难对话，也不愿将那次对话记录下来，因为那样会显得太过真实。但正因为他们没有这么做，他们一直处于沮丧之中，团队也倍感挫败，最终到达一个临界点，觉得不得不让这个人离开。于是他们去找人力资源部门，说必须解雇这个人，因为他已经挣扎了很长时间。人力资源部门问：“你们有留下任何记录吗？”管理者回答：“没有，但请相信我，这种情况已经持续很久了。”人力资源部门就会说：“好的，那流程是这样的，我们接下来要这样做。”
现在管理者往往会大吃一惊，竟然要等上30天甚至45天才能采取行动。他们感到挫败，因为他们知道团队正用质疑的眼神看着他们：你怎么能让这件事拖这么久？而这种情况之所以发生，正是因为他们没有尽早着手处理。再说一次，我认为绩效管理是管理工作的一部分，管理者应当能够坦然面对并积极处理它——因为越早启动这个过程，成功扭转局面的可能性就越大。
但如果你等待太久，事情就会变得棘手。
15. 管理者的常规提问清单
Brett: 稍微换一个方向来说，如果我在一周、一个月或一个季度的时间里观察你管理团队的方式，你会反复提出哪些问题？你倾向于通过哪些问题来引导团队成员、帮助他们或帮他们摆脱困境？显然，我们花了很多时间讨论建议和观点，而我认为帮助他人最重要的方式之一，就是向他们提出优质的问题。
所以，我很好奇，你通常会用到哪些问题？
Marcel: 有几个问题我确实觉得自己经常重复。嗯，我有点好奇，我的团队成员是否觉得我说得太多了。不过，我经常问他们：这里最大的好处是什么，最大的风险又是什么？以此来了解，我们是否权衡过各种因素，以及可能的结果有哪些。我想，我最常问的问题可能是——因为我在执行和交付评审上花了很多时间——那就是：这里可能会出什么问题？
这件事是什么？你最担心的是哪件事，而我又最应该担心哪件事？而且，我把这两个问题放在一起问，是因为这意味着答案应该有两个不同方向。第二个答案对我来说往往最具启发性。通常，他们最担心的那件事，是自己能够掌控的。
他们认为我最应该感到紧张的事情，是他们不指望自己能解决、而是期待我去解决的问题。有些事情或许他们自己也能处理，但这并不是他们的预期。所以通过这样提问，我能让自己更清楚地意识到这些问题。我还在尝试更频繁地去问另一个问题——当然，这也在不断调整中，毕竟我们都在成长。以前我常常在一对一交流时问“周末过得怎么样？”、“最近怎么样？”、“你好吗？”；现在我开始问大家：“这周工作中最让你开心的是什么？”或者“上周工作中最棒的部分是什么？”——希望这个问题不会让人觉得太重复。
我正试着把它变成一种常规做法，这样既能让大家顺势庆祝一下自己取得的成就，也让我能了解到这些事；同时，它也能自然地引出“最具挑战性的部分是什么”这个问题，而且大家会愿意坦诚地说出来。嗯，这让我知道该从何处着手。
Brett： 这个收尾很棒。非常感谢，这次交流非常精彩。
Marcel： 谢谢你，Brett。我真的很感激。