标题: 工程经理入职前90天：你的团队评估正在杀死你
你手里握着新offer，总包从380K跳到了520K。你觉得自己赢了。但入职第三周你就会发现，前90天你做的每一个判断都在为18个月后的被动离职埋单。工程经理不是被代码质量干掉的，是被入职初期对团队的误判干掉的。
一句话总结
入职前90天的团队评估不是信息收集，而是一个权力结构测绘工程。你看到的产能瓶颈大概率是架构问题的症状而非根因，你听到的信任危机往往是前任留下的组织债务。正确的做法不是快速赢得信任，而是先搞清楚谁会因为你做出正确决策而损失最大。那个人就是你的第一个对手。
适合谁看
这篇文章写给拿到FAANG级别工程经理offer、正在倒数入职日的人。你已经过了"怎么拿offer"的阶段，你现在面对的问题是：怎么活过试用期，而且不是苟活，是建立真正的决策权。
如果你管的是8-15人的团队，有2-3个tech lead直接汇报给你，你的skip level是一个senior manager或director，这篇文章就是你的生存手册。如果你还在面EM岗位，这东西会让你在面试里聊出别人聊不出的深度——但那是副作用，不是目的。
入职第一天，你拿到的团队文档里藏了什么致命信息
入职第一天，HR会给你一份团队概览：headcount、tenure分布、上次perf cycle的rating。大多数人扫一眼就过了。他们会看谁待得久、谁刚升职，然后开始约1:1。这是错的。
你要做的第一件事不是认识人，是读组织债务。打开那个文档，找三个数字：过去18个月团队流失率、内部转组比例、以及tech lead和产品经理的入职时间差。
流失率本身没意义。你要看的是流失人员的级别分布。如果走的是senior居多，而且都在同一个季度离开，那不是市场行情问题——那是某个事件触发的。可能是reorg、可能是某个关键决策被推翻、可能是某个TL被架空。你需要在第一周找到那个事件，因为那个事件的余震还在影响留下来的人。他们会用"当时那个事之后，我们就..."来开头，你要听完整。
内部转组比例比流失更致命。流失可能因为钱，转组一定因为人。FAANG内部转组不需要换公司，股票不会断，所以一个人选择离开你的团队去隔壁组，只有一个原因：他宁愿跟另一个经理从头开始，也不愿再待一天。如果过去一年有两个人内部转走，你要问的不是"他们为什么走"，而是"留下来的人从他们的离开里学到了什么"。答案通常是：学到了不要公开反对某个人。
tech lead和产品经理的入职时间差是组织债务的计时器。如果TL比PM早入职两年，PM是三个月前才来的，那这个TL已经习惯了没有产品搭档的决策模式。他会说"我们一直这么做"，意思是"我不需要PM来告诉我优先级"。
如果反过来，PM比TL早来一年，那这个PM已经学会了自己做技术取舍。他会说"我跟之前的TL确认过"，意思是"你新来的TL最好别推翻我的判断"。这两种情况下，你都不是在管理一个团队，你是在调解两个已经形成独立决策习惯的人。
入职文档不会写这些。但数字会。
> 📖 延伸阅读：RivianAI产品经理岗位职责与面试要点2026
第一轮1:1，为什么你问"你觉得我们该做什么"是自掘坟墓
标准管理书告诉你第一轮1:1要问三个问题：你觉得什么做得好、什么做得不好、你觉得我们应该做什么。这套问题对于IC转EM的人有用，对于空降FAANG的工程经理是毒药。
因为这三个问题预设了一个前提：你已经有决策权了。你没有。你只是有headcount authority——你能决定谁做什么项目，但你不能决定团队判断什么是对的。那个权力需要你自己挣。
正确的第一轮1:1只有一个目的：搞清楚每个人认为谁是房间里最有权力的人。不是org chart上的汇报线，是实际决策时的参照系。
你要问的是："上次你们做了一个我不在场的技术决策，过程是什么样的？"
这个问题的回答会暴露三件事。第一，决策的实际发起人是谁。如果回答是"TL提了个方案，我们讨论了一下就定了"，那TL是实际权力中心。如果回答是"PM说业务需要这个，我们找TL确认了可行性"，那PM在驱动技术方向——这在大厂是危险的。第二，决策有没有被挑战过。
如果回答里没有"但是""不过""当时有人提出"，那这个团队没有健康的冲突文化。没有冲突的团队不是和谐的团队，是恐惧的团队。第三，决策被谁最终拍板的。如果回答是"我们跟director sync了一下"，那你的skip level在微观管理。如果是"我们就上线了"，那团队有自治权，但也可能有失控风险。
一个真实场景：我在一个debrief里看到新经理问"你们觉得我们的tech debt该怎么处理"。团队给了五个答案，他选了最合理的那个，三个月后那个方案被证明是错的。不是因为他判断力差，而是因为他问错了问题。他应该问的是"上次你们试图修tech debt，被什么挡住了"。
答案可能是"director说要先做feature"、可能是"隔壁组不配合API迁移"、可能是"我们自己的测试覆盖率太低，没人敢动老代码"。这三个答案对应的是完全不同的权力结构：向上管理问题、跨团队协作问题、团队能力问题。你不先搞清楚挡路的是谁，你做的任何决策都是在撞墙。
不是收集意见再做判断，而是先测绘出意见形成之前的权力地形。
前30天，你该看什么代码——不是PR，而是on-call记录
新经理看代码，通常看最近的PR、看架构文档、看tech spec。这是典型的IC思维残留。PR告诉你团队在写什么，不告诉你团队在怕什么。
要看on-call记录。过去6个月的incident timeline、postmortem、以及最关键的——谁在凌晨3点被叫起来处理过什么问题。
on-call记录是团队压力结构的X光片。如果一个服务的告警频率高但每次都是同一个人响应，那这个人不是最勤奋的，他是被当成了人肉盾牌——团队默认他兜底，所以其他人不优化监控。如果postmortem里的action item总是"增加监控""增加测试"，但三个月后同样的incident又出现，那这个团队不是在解决问题，是在表演解决问题。
根因可能是那个服务太老、文档丢失、原来的作者早就离职了，没人敢重构。这时候你推任何"提升工程质量"的倡议都是隔靴搔痒。
一个具体判断：找到过去半年最严重的那个incident，看它的postmortem是谁写的、谁review的、action item是谁跟进的。如果写的人和跟进的人不是同一个人，而且跟进的人在三个月内离职或转组了，那这个incident就是团队的未愈合伤口。
你在第一周就要约谈那个跟进的人——如果他还在的话——问他"如果再来一次同样的incident，你觉得我们能更快恢复吗"。他的回答如果是"能，只要XX不插手"，你就知道真正的瓶颈不是系统，是人。
不是看代码质量来衡量工程能力，而是看on-call记录来测绘组织的恐惧分布。代码写得烂可以重构，恐惧不消，重构也没人敢做。
另一个反直觉动作：查一下团队的alert threshold是谁调的。如果调阈值的人不是on-call轮值的人，而是TL或manager，那这个团队有严重的授权问题。调alert threshold本质上是"我信不过你对严重性的判断"，这是微观管理的工程表达。
> 📖 延伸阅读：Palantir PMreferral指南2026
第30-60天，你的第一次sprint planning该怎么毁掉
第30天左右你会有第一次真正意义上的sprint planning。大多数人会做两件事：尊重现有优先级、在结尾加一个小改进。这是最安全的做法，也是最致命的。
安全意味着你没有打破任何平衡。但你是空降经理，平衡本身就是你的敌人。团队在你来之前已经形成了某种均衡——某个TL说了算、某个PM永远让步、某个工程师总是拿到最无聊的活儿。这个均衡如果对业务有利，你前任不会走。你来，就是因为这个均衡已经坏了。
第一次sprint planning你要做一件事：公开挑战一个优先级决策，并且赢。
选哪个决策挑战？不是最大的那个，也不是最小的那个。选那个"所有人都觉得不太对但没人说"的。这种项目通常有一个特征：它的立项理由里有"因为某某VP说"或者"因为上个季度定的OKR"。它的实际价值没人说得清，但它的政治正确性让它活到了现在。
挑战的方式不是直接说"这个项目没价值"——那是找死。你要问："这个项目上线后，我们怎么判断它成功了？如果判断不出来，我们能不能先做两周的探针，验证假设再全量投入？"
这个问法有三个效果。第一，你把决策标准从"谁说的"变成了"怎么验证"，这是工程文化的正道，没人能公开反对。第二，你争取了两周时间，这两周里你可以观察谁最反对探针方案。那个人不是关心项目价值，是关心项目背后的承诺——他可能已经跟VP夸下海口了。第三，如果你赢了，团队会第一次意识到：新经理不是来维持现状的。
一个真实场景：一个新经理在第一次planning里挑战了一个做了6个月的内部工具项目。TL当场脸色变了，说"这个项目是director亲自定的"。新经理没退，说"那我去跟director聊，如果他能给我这个项目的成功指标，我们就继续"。director没给出来。
项目被砍了。那个TL在两个月后转组了。团队的其他人在那个TL走后开始主动提改进建议。不是新经理赢了权力斗争，而是他让团队看到：你们之前的沉默不是因为你们没想法，是因为你们怕那个人。
不是融入团队节奏，而是打破一个大家都想打破但不敢打破的东西。
第60-90天，你的skip level 1:1该怎么谈——不是汇报，是校准预期
第60天左右你会跟你的skip level（通常是senior manager或director）有一次正式1:1。大多数人准备了一堆进展汇报：我们做了X、修复了Y、招聘了Z。这是浪费。
你的skip level不关心你做了什么，他关心你有没有发现他需要被拯救的地方。他招你来，不是因为缺一个管sprint的人，而是因为他的管理半径太大，需要有人帮他盯住一个他没空盯的团队。他要的是一个能给他early warning的人，不是一个报喜不报忧的人。
这次1:1你要带三样东西：一个你确认的团队风险、一个你需要他出手才能解决的问题、一个你对团队reorg的建议。
团队风险不是"我们测试覆盖率低"，那是你该自己解决的。风险是指"我们的TL和隔壁组的TL在过去三个季度里没有达成过一次技术决策共识，接下来那个跨组项目大概率会翻车"。这个级别的风险你自己兜不住，需要他知道。而且你告诉他，说明你在看跨组的事，不是只看自己的一亩三分地——这是senior manager最想要的信号。
需要他出手的事，必须是单靠你搞不定的。比如"我们组有个L6工程师，表现连续两个cycle不合格，但他跟VP关系很近，我需要你知道这件事，而且我需要你在calibration会议前给我cover"。
这不是推卸责任，这是管理复杂度。你不提前对齐，到了perf cycle你提交一个低rating，VP一个电话打过来问怎么回事，你的skip level如果毫无准备，他会觉得你给他挖坑。
reorg建议要具体到人。不是"我觉得我们应该把A组和B组合并"，而是"把负责数据管道的两个工程师从平台组挪到业务组，他们现在70%的时间都在给业务组做ad hoc支持，但report给平台组，平台组的TL根本不了解他们的工作量"。这个建议有三个好处：第一，它证明你在看实际的协作模式而非org chart。
第二，它解决了一个真实的效率问题。第三，它给了你的skip level一个可以在他的peers面前展示的洞察——他可以说"我的新经理发现了一个组织问题"，这让他有面子。
不是汇报成绩，而是让你的skip level意识到：你是那个帮他看清他看不清的东西的人。
准备清单
- 拿到团队文档后，先画权力地图而非组织架构图。标注每个关键成员的入职时间、上次晋升时间、以及他们与skip level的汇报历史（之前有没有共事过）。
- 第一周结束前，读完过去6个月的on-call记录和postmortem。标出重复出现的incident类型、以及action item的实际完成率。这个数字通常低于40%，低的部分就是你前90天的技术抓手。
- 第一次1:1不要问"你觉得我们该做什么"，而是问"上次重大决策是怎么做出的"。记录每个人的回答里谁的名字出现最多，那个人就是实际决策中心。
- 在第30天左右的sprint planning里，公开挑战一个"没人敢碰"的优先级。用"怎么判断成功"作为切入，不要用"这个没价值"。
- 第45天前，完成与所有跨组stakeholder的1:1。重点问"你跟我的团队协作时，最让你难受的一点是什么"。跨组的抱怨比你团队内部的抱怨更真实。
- 第60天跟skip level的1:1，带三个东西：一个风险预警、一个需要他出手的障碍、一个具体的reorg建议。不要带进展汇报。
- 系统性拆解入职评估框架。PM面试手册里有完整的跨团队协作评估和权力结构测绘的实战复盘可以参考，那些框架对EM同样适用，尤其是如何在不动声色的情况下完成组织诊断。
常见错误
错误一：把团队的高绩效者当成盟友
一个典型的BAD场景：新经理发现某个L6工程师技术极强、code review又快又准，于是把他当成自己的技术顾问，什么事都先跟他商量。三个月后，团队其他成员开始绕过经理直接找这个L6，因为"反正经理也听他的"。这个L6不是你的盟友，他是前任留下的影子经理。你把他当盟友，等于把自己降级成了他的发言人。
GOOD版本：识别出高绩效者后，第一件事不是依赖他，而是问他"你觉得团队里谁被低估了"。如果他答不出来，说明他只看得到自己。如果他答出来了，你去找那个人，给那个人一个有可见度的项目。这既削弱了高绩效者的信息垄断，又激活了被低估的成员。
错误二：过早承诺"我不会大改"
新经理为了安抚团队，第一周就说"我不会做大改动，我想先学习"。这句话说出来，你已经失去了做任何改动的合法性。因为三个月后你发现了问题想改，团队会说你言而无信。不是不能说不改，而是要说"我会在前60天不做结构性变动，60天后我会基于我看到的做出判断"。60天是一个具体的、合理的时间窗口，它给你留了退路，也给团队设置了预期。
BAD： "大家放心，我不会来了一通乱改。"
GOOD： "前60天我的重点是理解现有流程，60天后我会跟所有人同步我的观察和调整方向。这段时间里如果有什么你们觉得必须马上改的，随时找我。"
错误三：把skip level当导师
新经理在第一次skip level 1:1里问"你觉得我该注意什么""你有没有什么建议给我"。这听起来很谦虚，实际上是暴露脆弱。你的skip level不是你的教练，他是你的内部客户。你要让他觉得你不需要他操心，而不是让他觉得你需要他指导。
BAD： "我很想听听你对我的期望，以及你觉得我前几个月该重点做什么。"
GOOD： "我已经识别出三个我需要解决的优先级：X、Y、Z。X我自己能搞定，Y需要你帮我跟某个VP对齐，Z我想听听你的判断——因为你对历史背景比我清楚。"
FAQ
Q：如果我发现团队里有个tech lead是实际权力中心，而且他在架空我，我该直接处理他还是先观察？
不要直接处理。架空你的TL通常有两种：一种是恶意的，他在你入职前就想拿这个岗位，没拿到，所以用信息垄断来证明你不行。另一种是无意的，他只是习惯了没有经理的状态，所有决策都从他这里过。不管是哪种，你直接对抗都会输——因为你对业务的了解还没他深。
正确的做法是建立独立的信息渠道：跟他的peers聊、跟PM聊、跟跨组stakeholder聊。当你掌握了他不知道的信息时，他的信息垄断就破了。这个过程通常需要4-6周。一个具体信号：当你在他不在场的会议里能准确回答业务问题时，时机就到了。
Q：前90天要不要换人？如果有个明显不合格的工程师，我该等到perf cycle还是马上动手？
等到perf cycle。不是因为你善良，是因为你需要那个perf cycle来建立你的判断信用。FAANG的PIP流程需要书面记录、需要明确期望、需要给改进期。你入职第一个月就启动PIP，HR会问你"你怎么在这么短时间内就确定他不合格"，你的任何回答都会显得草率。
正确的节奏是：第一个月记录具体问题——不是"他代码质量差"，而是"他在X项目里提交了3次代码，每次都需要别人重写50%以上"；第二个月给他一个明确的改进目标和时间线；第三个月review。如果他没改进，你在perf cycle提交低rating时，手里有三个月的具体数据，而不是三个星期的印象。
Q：我的skip level在我入职第30天就想让我接一个我判断会失败的项目，我该怎么拒绝而不显得不听话？
不是拒绝，是重新定义成功标准。你不能说"这个项目做不了"，因为你的skip level可能已经跟他的peers承诺过了。你要说"这个项目我想做，但我需要确认我们对成功的定义一致。如果成功的标准是X，那我们需要Y资源，目前我们没有。如果资源不变，那成功的标准需要调整为Z。
你觉得哪个方向更合理？"这个回应的核心是把"做不做"的问题变成"怎么做"的问题。你没有挑战他的判断，你只是让他面对一个他之前回避的取舍。如果他两个方向都不接受，那说明他要么没想清楚，要么在赌你能创造奇迹——不管是哪种，你都得到了一个重要的信息：这个人不理性。知道这个比接不接项目更重要。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。