三年前，我晋升为工程经理。我曾是一名优秀的高级工程师，指导过初级开发者，领导过复杂的迁移项目。我以为管理会是我正在做工作的自然延伸。我几乎在所有事情上都错了。
第一周，我尝试审核团队提交的每一个拉取请求。到了第二周，我因为调试一个不再属于我负责的生产问题而错过了两个重要会议。第三周，我在一对一谈话中，我的一位下属告诉我团队感觉被微观管理了。我甚至没有意识到自己正在这样做。
从个人贡献者到管理者的转型是工程领导力中被讨论最多的主题，然而，我交谈过的每一位新管理者都会犯同样的错误。不是因为缺乏建议，而是因为知道该做什么和实际去做之间存在巨大的鸿沟，只有通过刻意练习才能弥合。这是我希望第一天就有人告诉我的事情——也是我现在指导每一位新管理者时提供的框架。
没人警告你的身份危机
作为一名个人贡献者，你的身份建立在技术能力上。你知道如何解决难题。你能在脑海中构建复杂系统。你交付功能。你的价值是具体且直接的——你可以指着生产环境中的代码说”这个是我构建的”。
作为管理者，这些都不再是你的工作。你的工作是让其他人有效地完成这些事情。你优化的产出是团队吞吐量，而不是个人吞吐量。而团队吞吐量难以衡量，改进起来令人尴尬地缓慢，并且在演示中无法指向任何具体成果。
这种身份转变确实令人迷失方向。最初的几个月，我感觉自己什么都没完成。我的日程表排满了会议。我没有写代码。我的待办事项列表充满了模糊的项目，比如”思考团队结构”和”跟进招聘流程”。每天结束时，我无法说出自己完成了什么。
这是我最终明白的道理：管理工作大多是不可见的，而这没关系。你帮助下属思考架构决策的那30分钟谈话不会出现在任何仪表板上。你发送的邮件解决了跨团队依赖问题，节省了两天的工作，但没有人会将这两天归功于你。你与表现不佳者进行的艰难对话需要数月才能显示出结果。你必须接受这一点。
前30天：倾听、学习，不要改变任何事
你的第一个月是用来观察的。我无法强调这一点的重要性。新管理者犯的最大错误就是带着”修复问题”的计划进入新环境。即使事情确实出了问题，你还没有足够的上下文来正确修复它们，而尝试这样做会在你建立任何信任之前就消耗掉团队的信任。
第1-2周：倾听之旅
与团队中的每个人安排一对一会议。不是你稍后会设置的那种定期一对一会议，而是一次特定的初次对话交流。我使用以下这些问题：
- 在这个团队中，哪些方面运作良好，我应该小心不要破坏？
- 目前什么是最让你感到受阻的事情？
- 你更喜欢如何接收反馈？
- 对你来说，完美的一周是什么样的？
- 有什么是你一直想改变但缺乏支持去做的吗？
做笔记。寻找模式。如果有三个人都独立提到部署过程很痛苦，那可能就是你需要解决的第一个实际问题。如果只有一个人有其他人没有的抱怨，这也是重要的背景信息——但这不是系统性问题。
还要与你的同行——那些你将共事的其他管理者交谈。与你的直属上司交谈。与你团队中的产品经理和设计师交谈。每个人对什么有效、什么无效都有不同的看法。你在第一个月的工作就是从这些零散的观点中拼凑出一幅完整的画面。
第2-4周：绘制系统图
我指的不是技术系统（尽管你也应该理解那个）。我指的是人的系统。弄清楚：
- 谁是非正式领导者？ 每个团队都有人不是技术负责人但大家都会向其寻求建议。识别出这些人。他们是你最重要的盟友。
- 信任关系在哪里？ 谁合作良好？谁存在摩擦？当你分配工作和发生冲突时，你需要这张关系图。
- 有哪些不成文的规则？ 也许团队总是在4小时内完成代码审查。也许有一个不成文的约定，就是没有人周五部署。这些规范是支撑性的——意外违反它们会损害你的可信度。
- 团队与其他团队的关系如何？ 依赖关系、共享服务、历史紧张关系。你将管理这些关系，而你不能管理你不理解的东西。
前60天：建立基础
到第30天，你应该对团队、工作以及组织背景有了不错的心理模型。现在你可以开始建立将支撑你未来一年的管理基础设施。
正确设置你的1:1会议
1:1会议是你管理工具箱中最重要的工具。把它们做好，其他一切都会变得更容易。做不好，你会花几个月时间 wondering 为什么你的团队似乎缺乏参与感。
频率：每周至少30分钟。我听说过有管理者主张每两周一次的1:1会议。根据我的经验，在新管理角色下，前六个月每两周一次的频率太低了。你需要通过频繁交流来建立关系。一旦信任建立起来，一些下属可能更喜欢每两周一次，这没问题——但开始时请保持每周一次。
最重要的1:1规则：这是他们的会议，不是你的。状态更新应该在站会或Slack中进行。1:1会议是为了指导、职业发展、反馈以及他们心中所想的一切。如果你在1:1时间里问”你在做什么工作？”，那你就浪费了这次会议。
我为每位汇报对象使用共享文档。他们拥有议程设置权。我也会添加项目，但他们的优先。典型的1:1文档看起来是这样的：
- 他们的项目（5-15分钟）：他们想要讨论的任何内容。障碍、问题、想法、挫折、职业思考等。
- 我的项目（5-10分钟）：对近期工作的反馈、影响他们的组织更新、我有的问题。
- 职业/成长（5-10分钟，不是每周都有）：长期发展目标、即将到来的机会、他们想要建立的技能。
当事情繁忙时，你可能会很想跳过1:1会议。不要这样做。取消1:1会议会发出一个明确的信息：”你现在不是优先考虑的对象。”即使这不是你的本意，但这就是他们听到的。如果你确实没有时间，应该重新安排而不是取消。
建立团队健康指标
你需要某种方式来了解团队随时间是变好了还是变差了。凭感觉并不可靠，特别是当你刚接手时。以下是我跟踪的指标：
交付指标（领先指标）：
- 周期时间：从首次提交到生产需要多长时间？跟踪中位数和90百分位数。P90指标可以告诉你最糟糕的情况，这些情况常常揭示了流程瓶颈。
- PR审查周转时间：PR等待审查的时间有多长？如果这个时间持续超过24小时，说明你的团队上下文切换过于频繁，或者没有足够的共享知识来审查彼此的工作。
- 部署频率：团队多长时间发布一次？每天部署的团队与每周部署的团队有着根本不同的风险特征。两者本身没有绝对的优劣之分，但频率的变化反映了信心或流程健康状况的变化。
人员指标（滞后但关键）：
- 1:1情绪：每次1:1后我都会做简单记录——对方是充满活力、中性还是沮丧？趋势比单个数据点更重要。连续三次沮丧的1:1就是一个信号。
- 自愿离职风险：谁有离职风险？这是一个基于1:1会议的判断，但你应该对每个人都有一个明确的答案，并每月更新。
- 团队调查结果：如果公司进行敬业度调查，请关注你团队的特定结果。如果没有，可以考虑使用类似Spotify的Squad Health Check模型，每季度进行一次匿名团队健康检查。
不要使用这些指标来评估个人。用它们来评估你的系统和流程。如果周期时间很长，问题不是”谁慢了？”——而是”什么阻碍了流程？”
学习利益相关者管理
这是管理中工程学校没人教的部分，而且可以说这是决定你成败的关键技能。你的利益相关者包括你的直属经理、团队的产品经理、同级经理以及高层领导。
我通过艰难经历学到的一些原则：
积极向上管理。如果你的经理不了解情况，他们就无法帮助你。发送每周总结—最多两段话—涵盖已发布的内容、有风险的事项以及你需要他们提供什么。我从未有经理抱怨信息过多，但有几个抱怨过被意外情况惊到。
在需要之前建立同级关系。与平台团队经理建立关系的时间点，不是在你需要他们优先处理你的请求时。一起喝杯咖啡，了解他们团队在做什么，提供帮助。当你最终需要帮忙时，对话氛围会完全不同。
在技术和商业语言之间进行转换。这是你作为前个人贡献者的超能力。你的产品经理说”我们需要改善页面加载时间”。你的团队说”API响应包含了40个不必要的数据库连接”。你的工作是连接这两者：”如果我们花两周时间重构用户档案查询，页面加载时间将减少60%，这直接影响到产品经理关心的转化指标。”无论是产品经理还是你的团队，都无法像你自然地做出这种连接。
前90天：开始推动变革
到第60天，你已经建立了关系、了解了背景、搭建了基础设施。现在你可以开始有意识地做出改变。但要有所选择。我看到新经理的一个常见模式是试图一次性解决所有问题。选择一两个高影响力的问题并专注于解决它们。
确定你的首次胜利
你的首次胜利应该是这样的：
- 团队已经识别出的问题（来自你的倾听之旅）
- 可以在2-4周内解决的问题
- 对团队日常体验有可见影响
- 不需要你尚未建立的政治资本
常见的首次胜利：修复不稳定的CI流水线、移除不必要的审批流程、为团队一直需要的工具争取预算、解决长期存在的跨团队依赖。这些虽然不 glamorous，但它们证明了你会倾听并采取行动——这正是你早期想要建立的形象。
进行艰难的对话
到第60-90天，你可能已经知道团队中谁表现不佳。也许从第一天起就很明显，也许是在观察团队工作时才清楚。无论哪种情况，你都需要解决这个问题。
新经理往往会推迟绩效对话，因为他们感到不适。我理解。告诉别人他们的工作未达标准感觉糟透了。但推迟对话更糟——对你、对他们，以及对团队的其他人都是如此。
团队已经知道谁表现不佳。他们在观察你会如何处理。如果你什么都不做，你传递的信息是标准由表现最差的人决定。表现优秀的人会注意到这一点，然后开始更新他们的简历。
当你确实要进行对话时，要具体直接。不要说”你的代码质量需要改进”，而要说”在最近三个PR中，我注意到错误处理存在重复问题——具体来说，在PR #1234中，数据库超时情况未得到处理，在PR #1289中，重试逻辑没有包含退避机制。我希望我们能制定一个计划来解决这些问题。”具体的观察、具体的例子、明确指出需要改变什么。
何时写代码（以及何时停止）
这是每个从个人贡献者转变为管理者的人都会纠结的问题。答案很微妙，并且会随着时间变化。
入职前30天：写一点代码。不是为了提高生产力，而是为了理解代码库、开发流程以及团队日常处理的痛点。负责新开发人员的入职流程。在本地设置项目。修复一个小bug。这会给你提供技术背景，让你成为更好的管理者。
入职30-90天：大幅减少你的编码量。你仍然可以审查PR（而且你应该至少偶尔审查，以保持技术连接），但你不应该成为任何交付物的关键路径。如果团队无法交付因为你没有完成你的部分，那就做错了。
入职90天后：你的编码应该完全是可选的。在黑客马拉松期间制作一些原型。修复一个一直困扰你的bug。编写一个小型内部工具。但这些是副项目，不是承诺。一旦编码任务与管理职责冲突，管理职责总是优先。永远如此。
你编码过多的危险信号：
- 你成为冲刺交付物的关键路径
- 你在审查PR而不是团队中的其他人
- 你跳过或匆忙进行1:1会议以便回去写代码
- 你的下属被阻塞，等待你的决策，因为你一直在埋头编码
- 你写代码是因为感觉有成就感，而不是因为这是你时间的最佳利用
最后一点是最致命的。管理工作是模糊的。代码是具体的。当你被管理的模糊性压得喘不过气时，打开IDE的诱惑很强烈。这是一种伪装成生产力的应对机制。认清它的本质。
常见的第一年错误
除了我已经提到过的，以下是我在新任工程管理者身上最常看到的错误：
试图成为每个人的朋友。 你可以友好待人，可以关心你的下属作为个体，但你不再是他们的同级了。你对他们的薪酬、职业发展，在最坏的情况下，甚至对他们的雇佣关系都有权力。假装这种动态关系不存在对谁都没有好处。保持热情、平易近人、有人情味——但要维持专业界限，这样才能给出诚实的反馈并做出艰难的决定。
为团队屏蔽一切。 新管理者常常把”保护团队”做得太过分。他们吸收每一条组织沟通，过滤掉任何令人压力的信息，呈现一个经过净化的现实视图。问题是，你的团队并不傻。他们能感觉到什么时候信息被隐瞒了，而填补信息真空的猜测通常比真相更糟。慷慨地分享背景信息。信任你的团队能够处理不确定性。为他们屏蔽干扰，而不是信息。
解决问题而不是指导。 当下属带着技术问题来找你时，你作为前独立贡献者的本能是去解决它。请克制。相反，提问：”你尝试了哪些方法？” “方法A和方法B之间有什么权衡？” “你需要知道什么才能自己做这个决定？” 你的目标是培养他们解决问题的能力，而不是成为团队的”神谕”。如果你解决每个问题，你就会成为瓶颈，你的团队也就停止成长了。
忽视组织架构。 你可能认为组织政治有失身份。事实并非如此。理解决策如何制定、谁影响谁、预算从何而来是你工作的一部分。你不必搞政治——你只需要保持信息灵通。了解组织背景的管理者能为团队争取到资源。而不了解的管理者则不明白为什么他们的请求总是被拒绝。
忽视自己的成长。 你花了多年时间作为工程师成长。你上课、读书、练习新技术。现在，将同样的自律应用到管理上。阅读卡米尔·福尼尔(Camille Fournier)的《管理者之路》(The Manager’s Path)。阅读威尔·拉森(Will Larson)的《优雅的难题》(An Elegant Puzzle)。加入一个管理者同行小组，与理解这些挑战的人讨论问题。管理是一项技能，和任何技能一样，它需要刻意练习才能进步。
构建你的管理系统
到90天结束时，你应该有一个包含以下内容的个人操作系统：
每周节奏： 周一回顾本周优先事项。周二至周四用于会议、一对一交流和深度工作。周五用于反思、撰写周报和规划下周。具体的时间表不如有一个并坚持执行来得重要。
一个信息系统：你从哪里记录一对一会议的笔记？如何跟踪行动项？如何记住你承诺下周要跟进某人？我结合使用共享的 Google 文档记录一对一会议笔记，个人 Notion 页面跟踪团队健康状况和行动项，以及日历提醒进行跟进。工具不重要，重要的是拥有一个系统。
反馈实践：在事件发生后48小时内给予反馈。公开给予积极反馈（如果对方不介意），建设性反馈则始终私下进行。建立一个反馈日志，记录你观察到的积极和建设性意见——在绩效评估季节你会感谢自己这么做的。
决策框架：不是每个决策都需要你的参与。明确将决策分为三类：(1) 团队自主决定并通知你，(2) 团队提出方案由你批准，(3) 你在团队意见下做出决定。让你的团队清楚这些分类。倾向于将决策推向第一类。
成功的样子
在你最初的90天结束时，你不会已经改变了团队。那不是目标。目标是为长期有效性建立基础。以下是良好的状态：
- 团队中的每个人都足够信任你，愿意告诉你何时出现问题
- 你定期进行一对一会议，并且这些会议感觉有价值（问问你的团队成员是否这么认为）
- 你充分了解团队的技术工作，能够形成有见地的观点，即使你不是在写代码
- 你的经理无需询问就知道发生了什么
- 你已经交付了团队关心的至少一项具体改进
- 你已经开始处理绩效问题，而不是忽视它们
- 你有一个个人系统，防止事情被遗漏
如果你在第90天时能勾选大部分这些项目，你就已经提前完成了计划。管理第一年是一场学习的马拉松，而前90天只是开始。你会犯错。你会有些周感觉自己完全力不从心。这是正常的。成功的管理者不是那些把一切都做对的人——而是那些保持自我意识、持续学习，在事情变得困难时不退缩到自己的 IDE 中的人。
从个人贡献者到管理者的转变，在很多方面，是在同一张办公桌开始新职业生涯。允许自己成为一名新手。你作为工程师建立的技能——系统性思维、调试复杂问题、快速学习——比你想象的更有可迁移性。你只需要现在将它们针对不同的问题。