Meta高级经理详述数据科学家晋升路径 软技能权重超技术能力

Meta's Indian-origin senior manager shares insights on upward management. — 课代表立正

课代表立正

员工应将一对一会议由项目汇报转变为主动的向上管理,并在缺乏数据支撑时凭借业务直觉勇敢表达观点,以沟通和协作将技术转化为实际的产品影响力。

AI-assisted summary of Meta's Indian-origin senior manager shares insights on upward management. — original source. Check the original for full context.

Source published:

Detailed notes

## Background 该内容由 YouTube 频道“课代表立正”于 2026 年 3 月 2 日发布。视频简介指出,这是一期与 Meta 数据科学高级经理 Mujtaba 的深度对话,旨在为 IC、数据科学及产品分析人员提供一套可落地的“经理使用说明书”,帮助大家将 1:1 会议从单纯的“项目汇报”转化为主动的“向上管理”。

## TL;DR 本期内容探讨了职场中如何通过高效的向上管理与经理建立深度信任。Mujtaba 指出,优秀的 IC 应主导 1:1 会议的主动权,主动将沟通模式从被动的“推”转化为透明的“拉”,并在做足功课后及时向经理同步项目风险。同时,高级技术人才的瓶颈往往不在技术复杂度,而在于产品直觉、跨团队协作等软技能,数据科学家应敢于在缺乏数据时基于业务理解表达观点,通过追问业务背后的决策动机来反推需求,从而摆脱“数据工具人”的底层定位并推动职业晋升。

## Atmosphere & style 整场对谈氛围真诚、自然且充满干货,两位发言人的互动既有职场前辈的倾囊相授,又有同侪间的心领神会。YZ 大方分享了自己早期因恐惧而推迟谈晋升的真实心路历程,Mujtaba 则以丰富的管理经验进行现场角色扮演和案例复盘,将原本严肃的职场生存法则解构得生动易懂。尽管是嘉宾的播客初体验,但在主持人积极的反馈与鼓励下,流露出一种虽略带初次录制的微妙抽离感、却极具启发性和实操价值的温和力量。

## Key takeaways - [00:00](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=0s) 1对1会议(1:1)的本质是下属开展“向上管理”的最佳机会,应由员工主动引导和主导,极力避免将其变成机械列清单的项目进度“站会”。 - [00:00](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=0s) 高效的1对1应使用持续记录的文档将事务性的FYI(仅供知悉)内容异步化,将有限的会议时间聚焦在需要经理输入、决策或解阻的实际讨论上。 - [06:10](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=370s) 及时向经理暴露项目风险和进行升级处理(escalation)具有极高价值,能让经理在外部沟通时保持谨慎,避免因信息不对称导致项目翻车。 - [06:10](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=370s) 员工不应因“羞耻感”而不敢向经理求助。现实中大多数人常犯的错误是求助不够,且培养、把下属推向更资深的位置完美符合经理个人的最大利益。 - [14:47](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=887s) 经理通过“推模式(Push)”与“拉模式(Pull)”来判断IC的成熟度。成熟的IC会采用拉模式,主动掌控沟通并在需要时把经理拉进来,从而建立深厚信任。 - [19:43](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1183s) 顶尖IC具备极强的自我认知,其职业发展的关注点不再是死磕弱项,而是如何双倍放大强项,并通过专属的“职业对话”主动主导自己的职业路径。 - [24:04](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1444s) 开启晋升对话需要带着“脆弱与透明度”,提前主动向经理了解标准与差距,通过日常对齐杜绝在绩效评审(Performance Review)时收到意外的坏消息。 - [24:04](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1444s) 当面临绩效评分不公等职场现实时,优秀的经理会迅速将谈话焦点从“工作量(Execution)”转移到实际达成的“产出影响力(Impact)”上。 - [32:14](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1934s) 技术岗位的高阶晋升瓶颈往往不是技术复杂度,而是软技能、产品直觉、沟通与跨团队协作能力,因为在Meta等大厂中“影响力就是货币”。 - [37:43](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2263s) 即便在没有完美因果数据支撑的新领域,数据科学家也必须习惯于结合历史经验和直觉勇敢表达定性观点,否则无法阻止团队盲目拍板推进决策。 - [40:25](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2425s) IC应在自身努力尝试后仍被卡住时带着现状找经理求助。经理应当承担“保护伞”的责任,将IC隔离在Director或VP级别的权力博弈之外。 - [40:25](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2425s) 经理的核心价值之一是提供宏观战略背景信息(context),帮助IC将具体的成果与公司高层最关心的战略优先级相连接,从而让成果落地并产生价值。 - [47:18](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2838s) 摆脱“SQL Monkey(数据工具人)”的关键在于主动追问需求的背景以及该数据将被用来做什么决策,若数据不改变任何决策,则可作为反推优先级的工具。 - [47:18](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2838s) 明确数据背后的决策性质有助于把握所需的“精度水平”(如粗略估算还是带置信区间的精确数据),从而让资深IC和经理准确判断应投入多少精力。

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=0s) 向上管理与一对一(1对1)的真正核心

在一对一(1对1)会议中,许多员工往往存在思维误区,认为这只是经理管理下属的单向过程。然而,1对1恰恰是下属“向上管理”经理的最佳机会。在实际工作中,关系的本质通常需要由员工主动去引导和管理。在会议形式上,应极力避免将其变成机械列清单的“站会(stand-up)”或单纯的项目进度更新。如果1对1流于形式,只是一味向经理汇报“自己正在做什么”,对双方而言都是极其低效的。

真正高效的1对1应该是一场充满互动、有来有回的深度探讨。员工需要对会议的议程(agenda)拥有明确的掌控权,带着清晰的问题、主题和期望走入会议。强大的IC(独立贡献者)恰恰体现在能够主导1对1的节奏,从中获取自己需要的输入与反馈。

- **1对1文档管理**:建议使用一个持续记录的文档(如按周记录、按月跟踪),将不需要展开讨论的事务性内容记录在内。 - **会议结构拆解**: * **FYI(仅供知悉)**:战术性的同步更新或路线图/工作流的常规提醒,只需让经理知情,无需在会议中口头展开、浪费时间。 * **实际讨论**:需要经理提供意见、采取行动或提供核心信息的事项,这是会议最该聚焦的硬核部分。

---

[06:10](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=370s) 项目风险、羞耻感与经理的底层利益

在项目管理中,向上管理的第一组核心更新往往围绕着“项目风险”与“升级处理(escalation)”。许多员工在接受“不要做项目更新”的建议时容易过度矫正,导致什么都不说,直到项目彻底面临延期或失败才被迫开口。这种迟疑往往源于内心的“羞耻感”——人们习惯性地将职场关系类比为学校里“老师会因为没做作业而惩罚我、给我打低分”的师生关系,误以为标出风险就等于向经理承认自己无能、无法处理事情。

事实上,告知经理项目风险本身就具有极高的价值。经理往往身处IC无法参与的高层会议和评审中,随时可能被问及项目状态。如果下属能与经理保持信息同步,经理在对外沟通时就能表达一定程度的谨慎,而不是盲目乐观地打包票,从而避免将下属推向更容易失败且压力更大的境地。优秀的下属应该在做足功课、尝试自己解阻之后,大方地将超出控制范围的风险升级给经理。

- **不求助的代价**:Mujtaba 分享了自己早期转型到 ecosystems 团队担任高级 IC 时的教训。当时他为了证明自己的独立性与自主性,在面对跨功能(XFN)合作伙伴的阻碍时选择硬撑、没有及时升级,最终导致模型开发和项目整体延期,错过了领导层的评审。 - **求助的“那条线”**:Mujtaba 的前经理曾给予过他一生受用的建议——大多数人常犯的错误不是求助太多,而是“求助不够”。员工大可以提出足够多的问题,如果真的超过了当前级别的独立性边界,经理自然会明确指出,但现实中几乎没人会真正触碰那条红线。 - **经理与下属的利益绑定**:经理的绩效并不看他解雇了多少人,而是看他帮助多少人实现了职业晋升、打造了怎样的人才储备。培养下属、把下属推向更资深的位置,完美符合经理个人的最大利益。

---

[14:47](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=887s) 推动型与拉动型管理模型

在挑选优秀 IC 并考虑晋升时,经理极为看重 IC 在“自主性”与“向上管理”之间取得的平衡。基于此,Mujtaba 提出了经典的“推模式(Push)”与“拉模式(Pull)”模型。

- **拉模式(Pull)**:IC 能够主动掌控沟通、对项目全盘负责,在需要经理介入时主动把经理“拉”进来,让经理知晓何时该出手、何时一切尽在掌握。这种高度透明的沟通能建立深厚的信任,让经理放心授权其独立负责整个领域。 - **推模式(Push)**:经理由于收不到持续的进展更新,对项目处于一头雾水的状态,被迫像催债一样去“推”着 IC 要更新、跟进里程碑。这种模式通常只适用于刚入职或较为初级的 IC。如果一个资深 IC 长期让经理处于推模式中,这就是一个令人担心的危险信号。

优秀的 IC 不仅能打消经理的顾虑,更能高效管理所有干系人(stakeholders)和跨功能协作者的预期。要想克服沟通不足的通病,关键在于“把注意力放在项目负责上”,将自己与个人得失的担忧分离开来。

---

[19:43](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1183s) 强 IC 的核心:清晰的自我认知

除了沟通模式,顶尖 IC 的另一个分水岭在于拥有极强的“自我认知”,清晰地洞察自己的优势与弱点。随着资历的加深,职业发展的关注点不再是死磕、弥补无伤大雅的弱项,而是如何“双倍放大自己的强项”,并将自己放在能最大化发挥优势的岗位上。

很多时候,IC 的弱点在经理和旁观者眼里一目了然,但其自身却深陷当局者迷的境地,这导致经理很难在不伤感情的情况下把话说破。对此,有效的管理手段是在日常1对1之外,单独开辟专属的“职业对话(Career Conversation)”,坚决切断战术细节的干扰。在探讨绩效评估前,让员工主动反思进展、对标当前的层级标准。当员工对自己的职业路径拥有主动性时,职业对话就会由他们主导,经理的角色则转变为如何调配项目与机会,来实现技能与兴趣的完美匹配。

---

[24:04](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1444s) 谈晋升的恐惧与直面坏消息的职场现实

在职场中,“谈晋升”往往是让员工充满恐惧的起点。YZ 坦言自己在 Meta 时曾因为害怕经理觉得自己“不配”、甚至质疑自己为什么要提出这种要求,从而在脑海中脑补了各种负面场景,导致谈晋升的时间整整晚了半年。

面对不同动机的员工(一类目标明确只看晋升,另一类更关注生活平衡或技能本身),优秀的经理应当一视同仁地为其规划路径。而作为 IC,自己才是个人职业生涯最大的代言人。Mujtaba 传授了一个带着“脆弱与透明度”开启晋升对话的绝佳话术:直接告诉经理“我觉得自己离晋升可能还有一年以上,但我希望现在就了解我的差距在哪里,以便针对性努力,并在后续对话中评估我是否有进步”。

- **透明度杜绝意外**:如果员工在绩效评审(Performance Review)时对自己的评分或反馈感到震惊和意外,这通常意味着经理在日常管理中存在严重失职。坏消息不应该在评审当天才第一次被揭晓。 - **应对“不公平”的现场模拟**: * **员工(YZ 饰)情绪化申诉**:“这不公平!我工作非常努力、经常加班,提交的代码行数最多,做了那么多分析,为什么最后拿了个差评?” * **经理(Mujtaba 应对)**:首先认可并肯定其付出的时间和代码量,随后迅速将焦点从“工作量(Execution)”转移到“产出影响力(Impact)”上。直接指出其差距在于承担了太多执行性、运营性的小事,挤占了更有影响力的工作时间,并提出接下来的下半年一起重新制定路线图,聚焦能助力晋升的产品类型。

---

[32:14](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1934s) 技术复杂度与影响力的货币

对于数据科学家(Data Scientist)等技术岗位,人们常常误以为高阶人才的定义就是解决极其复杂的技术难题。然而在 Meta 等大厂的实际评估中,所有被录用的人都已经具备了扎实的技术胜任力。真正卡住员工晋升、阻碍其获得更大 Scope 的,往往是软技能、产品直觉、沟通与协作能力。

即便面临技术复杂度不够的门槛,通常也是因为所在领域的 Scope 限制,可以通过更换团队或项目来解决。最成功的高阶技术人才,是那些能够用正确的沟通和协作将“技术”与“影响力(Impact)”连接起来的人。如果空有高深技术却无法说服别人这为何重要,技术就只会停留在个人手里,无法改变任何事情。

- **影响力的建立**:在 Meta,“影响力就是货币”。数据科学家不写生产代码,其价值在于通过说服别人做出正确决策来产出影响力。建立长期影响力和个人品牌就像经营自媒体(Influencer)一样,需要依靠长期的诚实和成功记录来让团队主动寻求你的输入。 - **Marketplace 的数据文化启示**:YZ 曾请教过 Marketplace 组织的早期总监 Ashish 和 Nav 优秀的秘诀。答案是早期 Ashish 总是坚持自己的观点,且时间证明他绝大多数时候都是对的,从而一步步在组织中确立了极高的声誉。 - **敢于表达观点的打破**:在没有数据支撑时,PM 或领导并不会因此停止做决定。如果数据科学家因为自卑、觉得屋里的人都比自己资深而选择保持沉默,“即便你没有提供正确的数据,人们也会继续拍板推进”。因此,数据科学家必须习惯于基于现有信息勇敢表达观点,去引导团队走向正确的方向。

[37:43](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2263s) 数据是用户的声音,即便没有数据也要敢于判断

数据在某种程度上就是用户的声音,数据科学家有责任代表产品用户把他们的关注点和心声说出来。如果不这样做,团队在做决策时就可能由于缺乏用户的声音而导致伤害用户体验的后果。对此,讲者分享了自己在 Facebook 期间上过的一堂“最有价值的课”:在一场由时任 Instagram VP 的 Roberto 主持的高级数据科学家圈子(circle)会议上,Roberto 提问在场的人,在没有因果证据(causal evidence)的情况下,有多少人愿意表达观点。当时只有大约一半的人举手;随后他又问有多少人在“完全没有数据”时愿意表达观点,结果全场只有 Roberto 一个人举手。

Roberto 随即指出,没有数据并不会阻止产品经理(PM)或领导层表达观点和做出决策。因此,数据科学家也不应该被此束缚。在实际的业务管理中,面对新领域而缺乏数据时,决策往往演变成定性判断,需要依赖已有的直觉、历史经验以及对业务的理解来提出建议。如果凡事都要等待完美的因果数据,公司的决策速度就会变得极慢。因此,“强 IC 应该有好的心智模型”和正确的直觉,即使在没有数据的情况下,也应当能够经常做出正确的业务判断,这是科技公司产品分析的核心所在。

---

[40:25](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2425s) 如何向经理求助,打破权力博弈与连接战略背景

当探讨到“如何向经理求助、何时求助以及能求助什么”这一职场核心问题时,讲者明确指出,IC 应该在自己已经努力尝试过、但仍然被卡住(stuck)的时候带着当前的情况去找经理,并清晰说明已经发生了什么。经理能够帮忙处理协作模式上的困难,或在资深层级上进行升级处理(escalation)。讲者强调,自己绝对不期望直属的 IC 去和 Director 或 VP 级别的领导进行激烈的权力争论和推拉,经理应当承担起“保护伞”的责任,把 IC 保护在权力博弈之外。

除了帮助解阻(unblock),经理更重要的核心价值在于“提供更多的背景信息(context)”。由于经理参加了更多更高级别的会议,更了解领导层、利益相关者(干系人)的关注点以及公司的宏观战略优先级。IC 没有这些背景信息完全不是其个人的失败,而是层级分工使然。经理可以帮助 IC 将手头的具体分析连接到更大的公司战略上,从而让工作更具落地和产生影响力的机会。讲者认为,影响力就像资本,要获得影响力,数据科学家的成果就必须谈论跨职能团队(XFN)和高层所关心的问题,否则即便分析做得再完美、再正确,若受众不关注,也无法产生实际价值。

- 经理对初级 IC 通常会审阅更粗的成果草稿,而现在团队规模变大后,讲者更倾向于审阅最初的提纲/计划(确保方向正确)以及最终成稿后的框架迭代(framing)。 - 面对非常资深的受众时,成果通常需要经过多层级 skip、甚至几轮的共同打磨,以将叙事清理干净并连接到领导层最关心的战略优先级上。 - 当协作难度超出直接经理的处理能力时,升级机制可以随着管理链向上扩展至 skip 乃至更资深的 VP 级别,以便在更高层级获取审评会议的上下文背景。

---

[47:18](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2838s) 摆脱“SQL Monkey”:通过关键追问反推业务需求与确定精度

为了从经理或合作方那里提取出更多有效信息,数据科学家在面对随机或具体的零散数据需求时,应当主动追问两个核心问题。第一,“这个问题出现的背景是什么,你们当时在看什么、讨论什么时提出的?”。第二,也是最重要的问题,“我们会用这份数据做什么决策,它的目的是什么?”。很多时候,需求方由于不了解数据,往往会索要不合适的数据指标;如果数据科学家能够弄清楚背后的决策动机,就能主动提供更好、更全面的数据解决方案。

同时,通过询问“要做什么决策”,也可以作为优先级的检验和反推(push back)工具。如果对方的答案是“没有决策”,数据科学家就可以理直气壮地反问这是否比当前的其他工作更优先,若数据不会改变任何决策,则可能根本不需要做。这一思考过程是将一个“SQL monkey(数据工具人)”与一个真正能够影响决策的“数据科学家”区分开来的关键。此外,明确了决策的性质,就能把握好所需的“精度水平”(是需要一个大概的规模预估,如 1%、10% 还是 70%,还是需要带清晰置信区间的精确数据以规避高风险错误),从而让资深的 IC 和经理能够准确判断应该在项目中投入多少精力。

---

[50:06](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=3006s) 播客对谈的复盘与真诚的力量

在对话的尾声,两位发言人就本次对谈的感受和内容进行了总结与互相反馈。虽然对转做经理等老生常谈的话题进行了克制的探讨,但他们一致认为今天针对“如何使用经理”、“如何与经理沟通建立连接”等话题的探讨已经足够深入,覆盖了非常丰富的行动项和职场心态,直属下属们完全可以“明天就开始用”。

对于第一次录制播客,讲者坦言“第一次肯定有点别扭”,觉得自己有时候说得太多、显得有些絮叨,并且有一种虽然是在面对面沟通,却仿佛在对不在场的更广泛观众说话的奇妙抽离感。对此,主持人给予了高度的肯定和鼓励,认为讲者的表现“很自然、很真诚”,没有多说也没有少说,体验完全不别扭。这段对话由于其蕴含的高价值和真诚的流露,非常适合发给所有直属下属看以帮助他们更成功。两人最后愉快地约定,两周之后再一起录制一期更有趣的播客。

## Notable quotes > [00:00](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=0s) 一对一不是经理“管理你”的会议,而是你“向上管理”的最佳机会。 — Mujtaba

> [06:10](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=370s) 大多数人常犯的错误不是求助太多,而是“求助不够”。 — Mujtaba

> [06:10](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=370s) 经理的绩效并不看他解雇了多少人,而是看他帮助多少人实现了职业晋升、打造了怎样的人才储备。 — Mujtaba

> [24:04](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1444s) 我觉得自己离晋升可能还有一年以上,但我希望现在就了解我的差距在哪里,以便针对性努力,并在后续对话中评估我是否有进步 — Mujtaba

> [24:04](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1444s) 这不公平!我工作非常努力、经常加班,提交的代码行数最多,做了那么多分析,为什么最后拿了个差评? — YZ

> [32:14](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1934s) 影响力就是货币 — Mujtaba

> [32:14](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=1934s) 即便你没有提供正确的数据,人们也会继续拍板推进 — Mujtaba

> [37:43](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2263s) 没有数据并不会阻止产品经理(PM)或领导层表达观点和做出决策。因此,数据科学家也不应该被此束缚。 — Roberto

> [40:25](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2425s) 影响力就像资本,要获得影响力,数据科学家的成果就必须谈论跨职能团队(XFN)和高层所关心的问题,否则即便分析做得再完美、再正确,若受众不关注,也无法产生实际价值。 — Mujtaba

> [47:18](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2838s) 这个问题出现的背景是什么,你们当时在看什么、讨论什么时提出的? — Mujtaba

> [47:18](https://www.youtube.com/watch?v=c7M6B2GR5-k&t=2838s) 我们会用这份数据做什么决策,它的目的是什么? — Mujtaba

## Mentioned Meta, Mujtaba, 课代表立正, YZ, Ashish, Nav, Marketplace, Facebook, Instagram, Roberto

[Source](https://www.youtube.com/watch?v=c7M6B2GR5-k)

中文简报

Meta高级经理详述数据科学家晋升路径:软技能权重超技术能力 员工应将一对一会议由项目汇报转变为主动的向上管理,并在缺乏数据支撑时凭借业务直觉勇敢表达观点,以沟通和协作将技术转化为实际的产品影响力。 本期内容探讨了职场中如何通过高效的向上管理与经理建立深度信任。Mujtaba指出,优秀的IC应主导1:1会议的主动权,主动将沟通模式从被动的“推”转化为透明的“拉”,并在做足功课后及时向经理同步项目风险。同时,高级技术人才的瓶颈往往不在技术复杂度,而在于产品直觉、跨团队协作等软技能。数据科学家应敢于在缺乏数据时基于业务理解表达观点,通过追问业务背后的决策动机来反推需求,从而摆脱“数据工具人”的定位并推动职业晋升。 1对1会议(1:1)的本质是下属开展“向上管理”的最佳机会,应由员工主动引导和主导,极力避免将其变成机械列清单的项目进度“站会”。 (0:00) 高效的1对1应使用持续记录的文档将事务性的FYI(仅供知悉)内容异步化,将有限的会议时间聚焦在需要经理输入、决策或解阻的实际讨论上。 (0:00) 及时向经理暴露项目风险和进行升级处理(escalation)具有极高价值,能让经理在外部沟通时保持谨慎,避免因信息不对称导致项目翻车。 (6:10) 员工不应因“羞耻感”而不敢向经理求助。现实中大多数人常犯的错误是求助不够,且培养、把下属推向更资深的位置完美符合经理个人的最大利益。 (6:10) 经理通过“推模式(Push)”与“拉模式(Pull)”来判断IC的成熟度。成熟的IC会采用拉模式,主动掌控沟通并在需要时把经理拉进来,从而建立深厚信任。 (14:47)

Reading summary

Meta 资深经理 Mujtaba 与主持人 YZ 阐明,高效的“向上管理”并非被动汇报工作,而是独立贡献者(IC)主动掌控沟通节奏、借力经理打破协作壁垒,并将技术能力转化为业务决策影响力的过程。 重塑1对1:从机械汇报转向拉动型管理 (0:00) 在一对一(1对1)会议中,常见误区是将其降级为单纯同步项目进度的“站会”。Mujtaba 强调,强 IC 应当拥有会议议程的主导权,将其转化为双向互动的深度探讨。在操作上,建议维护长期跟进的文档,将事务性进展归为仅供知悉(FYI),把有限的会议时间集中留给需要经理提供建议或采取行动的核心事项。 在协作关系上,资深员工需要建立“拉模式(Pull)”而非“推模式(Push)”。在推模式下,经理因缺乏透明度而被迫像催债般主动追讨进度,这在资深 IC 身上属于危险信号;而在拉模式下,IC 对项目全盘负责,仅在关键阻碍节点主动拉入经理支持。这种主动透明的沟通能够建立稳固信任,为 IC 争取到更大维度的独立授权空间。 破除求助羞耻:借力经理排障与对齐战略 (6:10) 许多员工受学生时代“做错事被惩罚”的心态影响,因羞耻感而不愿暴露风险,误以为求助等于承认无能。Mujtaba 结合自身在 ecosystems 团队硬撑导致跨职能项目延期的教训指出,职场中绝大多数人常犯的错误是“求助太少”。及时预警能让身处高层评审的经理提前管理外部预期;且经理的核心绩效依托于下属的晋升与团队梯队建设,为下属扫除障碍完全符合经理自身的利益。 向经理求助的关键在于先做足尝试,并在超出控制时果断升级。经理的首要职责是当下属的保护伞,阻隔与 Director 或 VP 级别的高层权力博弈,而非放任 IC 卷入政治推拉。此外,经理身处更高级别的会议体系,能提供关键的宏观背景(Context),协助 IC 将手头的具体分析对齐到公司的战略优先级,从而让成果获得更高的业务落地几率。 主导职业对话:聚焦优势放大与对齐差距 (19:43) 随着员工资历加深,职业发展的关键不再是死磕微小缺点,而是“双倍放大自身强项”。针对当局者迷的短板盲区,团队应在日常 1对1 之外剥离出专属的“职业对话”,由员工对照职级标准主动反思,推动经理调配匹配其优势与兴趣的业务机会。 对于谈晋升的顾虑与拖延,Mujtaba 建议采用“透明且示弱”的话术主动破冰,例如直接告知经理“自知目前距晋升可能还有一年以上,但希望提前明确差距以便针对性努力”,以此杜绝绩效考评出现意外差评。当遭遇付出巨大但评级不佳的落差时,经理会将考评焦点从单纯的代码行数与工时等“执行量”引导回“产出影响力(Impact)”,协助员工削减低价值琐事,重塑高回报的路线图。 摆脱数据工具人:以决策为导向构建影响力 (32:14) 在科技大厂中,纯技术能力仅是底线要求,“影响力才是硬通货”。高阶技术人才的核心竞争力在于通过协作说服他人做出正确决策。Mujtaba 援引 Instagram 前 VP Roberto 在资深会议上的测试指出:业务决策很少停滞等待完美的因果证据;数据专家必须作为用户代言人,在缺乏完备数据时依靠业务直觉与心智模型勇敢做出定性判断,否则团队仍会在毫无数据输入的情况下依据常理推进。 若想摆脱“SQL Monkey(数据工具人)”的被动处境,IC 在面对零散数据需求时须主动追问两个核心问题:“提出该需求的讨论背景是什么?”以及“这份数据将被用来做什么决策?”。若数据无法改变任何既定决策,IC 即可据此反推工作优先级;同时,明确决策性质有助于确定所需的数据精度,避免为粗颗粒度的预估浪费过多精力。 本场对谈的核心论点表明,向上管理并非职场逢迎,而是 IC 与经理之间的战略协同。通过将经理视为信息杠杆与排障资源,下属能够摆脱机械执行的束缚,以业务决策和组织战略为牵引,实现个人与团队的共同增值。

Source quotes

[0:00] Mujtaba: 一对一不是经理“管理你”的会议,而是你“向上管理”的最佳机会。 [6:10] Mujtaba: 大多数人常犯的错误不是求助太多,而是“求助不够”。 [6:10] Mujtaba: 经理的绩效并不看他解雇了多少人,而是看他帮助多少人实现了职业晋升、打造了怎样的人才储备。 [24:04] Mujtaba: 我觉得自己离晋升可能还有一年以上,但我希望现在就了解我的差距在哪里,以便针对性努力,并在后续对话中评估我是否有进步 [24:04] YZ: 这不公平!我工作非常努力、经常加班,提交的代码行数最多,做了那么多分析,为什么最后拿了个差评? [32:14] Mujtaba: 影响力就是货币 [32:14] Mujtaba: 即便你没有提供正确的数据,人们也会继续拍板推进 [37:43] Roberto: 没有数据并不会阻止产品经理(PM)或领导层表达观点和做出决策。因此,数据科学家也不应该被此束缚。 [40:25] Mujtaba: 影响力就像资本,要获得影响力,数据科学家的成果就必须谈论跨职能团队(XFN)和高层所关心的问题,否则即便分析做得再完美、再正确,若受众不关注,也无法产生实际价值。 [47:18] Mujtaba: 这个问题出现的背景是什么,你们当时在看什么、讨论什么时提出的? [47:18] Mujtaba: 我们会用这份数据做什么决策,它的目的是什么?

Original transcript

[0:00] 一对一 [0:00] 是你向上管理经理的最佳机会 [0:03] 人们都觉得经理在管理我。不,很多时候 [0:06] 关系其实是 [0:07] 你在向上管理 [0:09] 没有数据就提出观点 [0:10] 这会阻止 PM 吗 [0:12] 或领导表达观点吗 [0:14] 不会,他们还是会做决定 [0:16] 所以到底是什么阻止了你 [0:17] 拉模式是你把经理拉进来 [0:19] 推模式是指 [0:21] 我需要去催他们更新 [0:22] 但是 [0:23] 如果我长期还得这么做 [0:25] 而且看不到转向拉模式 [0:27] 那对我来说是个令人担心的信号 [0:31] 嗨,Mujtaba [0:32] 欢迎来到频道 [0:33] 嘿 yuzheng,很高兴在这里 [0:34] 不熟悉的观众说明一下,Mujtaba 是高级经理 [0:37] 在 Meta 负责数据科学 [0:39] 你在 Meta 工作了七年。 [0:42] 你最开始不是数据科学家,你是SDE [0:47] 大学是学这方面的,但后来加入了 Meta。 [0:50] Meta 是你第一份工作吗? [0:52] 是的 [0:52] Meta 是我毕业后的第一份工作 [0:54] 我最初学的是工程,并不是正式的 [0:58] 数学或统计背景 [1:00] 大学里只上过一门统计课 [1:02] 不过是的 [1:03] 我做过几次软件工程实习 [1:07] 然后以数据科学家身份加入 [1:08] 作为应届毕业生 [1:09] 然后慢慢一路成长 [1:11] 过去七年一直是高级经理 [1:13] 很好,也许并不需要很深的理解 [1:16] 数学或统计,或者你用工程来补足 [1:19] 我觉得工程在一定程度上能做到 [1:21] 但我觉得更大的 [1:24] 角色层面,工程帮助很大的是 [1:26] 就是解决问题 [1:29] 这也是你在工程生涯中 [1:30] 会涉及到的很多内容 [1:32] 我认为数据科学,尤其是 [1:34] Meta 的数据科学,核心在于找出问题的根因 [1:37] 识别问题 [1:38] 能够把 [1:39] 清晰的方案整理出来 [1:41] 并施加影响力 [1:42] 去影响 [1:43] 团队其他人往正确方向推进 [1:46] 所以我觉得很多时候这与 [1:48] 你是否学统计 [1:49] 是否学科学、数学或工程无关 [1:52] 关键在于 [1:53] 你能把问题拆解到本质的能力 [1:56] 太赞了。因为现在你可以 [2:00] 用 AI 很快学会数学或统计概念 [2:02] 但解决问题的能力才是定义 [2:05] 优秀数据科学家的关键 [2:08] 完全赞同 [2:09] 我想问你大概三个问题 [2:12] 你先挑一个最喜欢的,我们就顺着聊 [2:16] 这三个问题是 [2:18] 第一,如何和你的经理做一对一 [2:21] 第二个问题是从经理的角度 [2:26] 挑选晋升人选时,好的 IC 是什么样 [2:30] 你更倾向于选什么样的人 [2:33] 第三个是我怎样获得帮助 [2:35] 什么时候寻求帮助 [2:37] 什么样的帮助 [2:38] 作为 IC 能从经理那里得到 [2:40] 我觉得很多人不是经理 [2:42] 但需要和经理互动,怎样最好地使用经理 [2:48] 这就是我问题的主题 [2:51] 在回答前先把问题放到背景里 [2:54] 你之前管理过多少人 [2:57] 我最开始管理的时候 [3:00] 管理的是一个大约四人的小团队 [3:03] 我想过去最多的时候 [3:07] 我曾作为生态系统的临时负责人 [3:10] 所以我负责支持大概 14 到 15 人的团队 [3:14] 我很快会转岗、换团队 [3:17] 新团队一开始有 10 个人,同时还有 [3:20] 我下面还有分层的经理 [3:22] 所以我有一些经验 [3:24] 接触过不同层级的管理 [3:27] 也包括大小不同的团队 [3:29] 这也要求我作为经理承担不同角色 [3:32] 从这些问题来看 [3:33] 我其实很喜欢你刚才的顺序 [3:35] 因为我觉得它们天然衔接 [3:38] 所以 我就按这个顺序开始。你的第一个问题 [3:41] 你一般如何利用和经理的一对一 [3:44] 我个人觉得大家最终会学到一件事 [3:48] 他们也应该学会 [3:49] 随着时间推移,你的一对一是否 [3:51] 和经理的一对一是你该主导的 [3:54] 尤其是刚开始的时候 [3:56] 当你刚加入公司或在入职期 [3:58] 你会希望去一对一时 [3:59] 经理会告诉你 [4:01] 你需要知道的一切 [4:03] 但经过足够时间、你熟悉了一对一之后 [4:06] 这其实是你应该主导的 [4:08] 你应该对此有掌控权 [4:10] 你应该设定议程 [4:11] 你应该带着清晰的 [4:12] 问题、主题或想覆盖的事项 [4:15] 但对我来说 [4:16] 这可能也会在你后面的问题里出现 [4:18] 强的 IC 是那种 [4:20] 对一对一议程有明确掌控的人 [4:22] 也清楚想从中获得什么 [4:24] 但我会把 [4:25] 如何使用一对一拆成几个 [4:27] 清晰的类别 [4:29] 这些主题连经理也该采纳 [4:32] 因为我和我经理的一对一也是这么做的 [4:35] 第一,我会涵盖 FYI [4:38] 更多是战术性更新 [4:41] 有些事情经理应该知道 [4:42] 比如在你的路线图上 [4:46] 或在你的工作流里 [4:46] 你只是提醒它们在进行中 [4:49] 让经理知情 [4:50] 我通常把它们写在记录里 [4:54] 我和经理一般有个一对一文档 [4:57] 这样能按月跟踪所有事情 [4:59] 按周持续记录 [5:01] 但我通常不讨论它们 [5:02] 就只是让你知道这事在发生 [5:05] 不需要展开讨论 [5:07] 因为我真正想用那段时间 [5:09] 来进行实际讨论 [5:11] 我需要你意见的事 [5:12] 我需要你行动的事 [5:14] 或者我需要你提供的信息 [5:17] 我不想花太多时间只是做更新 [5:19] 像是在做 stand-up [5:21] 如果一对一更像 stand-up [5:24] 你只是列出你在做的事情给经理听 [5:26] 这对你们双方都不高效 [5:29] 应该更多是讨论 [5:32] 你不希望它像 stand-up [5:35] 不是只是向经理列清单 [5:37] 你正在做的事 [5:37] 你更希望它 [5:39] 像一次讨论 [5:40] 能得到输入并来回交流 [5:43] 很棒。我记得 [5:44] 从很多成功人士那里听过这个建议 [5:47] 他们有成功的职业生涯 [5:49] 一个常见错误是 [5:51] 把一对一变成项目更新 [5:55] 但我觉得 [5:57] 我记得建议是不要把它当项目更新 [6:00] 但如果我不这么做 [6:02] 大家就会觉得哦 [6:03] 那我是不是只聊个人生活 [6:06] 是的,我觉得 [6:09] 这就会牵扯到其他事情 [6:10] 我提到的类别 [6:12] 第一就是 FYI,你需要如实列出 [6:15] 作为同步更新 [6:17] 让经理 [6:18] 知情。时间真正的用途在于 [6:21] 你需要升级处理的事情 [6:23] 一对一 [6:24] 是你向上管理经理的最佳机会 [6:27] 从概念上讲 [6:28] 有些人不太会想到,会觉得 [6:30] 我的经理在管理我。不是,很多时候 [6:33] 关系其实是 [6:34] 你在向上管理 [6:36] 你告诉经理你需要他们行动的事情 [6:39] 或者他们需要知道的事 [6:40] 所以在 FYI 之后的第一组更新 [6:44] 对我来说就是项目风险 [6:46] 你需要向经理升级处理的事 [6:49] 就像你刚才说的 [6:50] 有时人们把 [6:52] 一对一当成项目更新 [6:56] 但我这样反馈时,有些人会过度纠正 [6:59] 然后什么都不告诉我 [7:00] 等太晚了才说 [7:02] 项目已经快要 [7:04] 出现风险或落后 [7:06] 你的能力组合关键在于让我知道 [7:08] 当项目到需要我介入的程度 [7:11] 是否存在 XFN 协作困难 [7:13] 正在进行的分析是否有风险 [7:17] 数据或 XFN 是否有阻碍 [7:21] 比如了解项目风险的背景 [7:25] 或时间线风险之类的 [7:27] 才是最该讨论的 [7:28] 不是更新里的每一件事 [7:30] 所以在一对一里需要重点强调 [7:34] 我想我们在第三个问题也会谈到 [7:37] 不过寻求帮助可能会有羞耻感 [7:41] 或者把风险提出来 [7:43] 有些人觉得如果我标出项目风险 [7:48] 就说明我不够能干 [7:50] 我处理不了事情 [7:54] 在我经验里有些人会犯的错误,也是我 [7:57] 一直尝试去辅导的 [7:58] 我对团队很多人的一点就是 [8:00] 你可以告诉我哪些项目有风险 [8:03] 哪些分析或工作可能存在风险 [8:06] 同时说明不需要我去做什么 [8:09] 你让我知道这些信息本身就有价值 [8:12] 或者让你的经理知道 [8:15] 因为有一点 [8:17] IC 或直接下属可能 [8:19] 不知道的是 [8:20] 你的经理可能在很多会议和评审里 [8:23] 而你不在那些场合 [8:25] 他们可能会被问到项目状态 [8:28] 所以你 [8:29] 和经理在这些事情上保持一致很重要 [8:32] 如果工作有风险 [8:33] 告诉经理并不坏 [8:36] 没有什么羞耻感 [8:38] 经理会觉得我不行 [8:39] 不会的,你可以告诉我 [8:40] 我能掌控 [8:42] 但这次协作有困难 [8:44] 或者数据访问有困难 [8:47] 不过我觉得我能自己解阻 [8:49] 但只要我知道这个风险水平 [8:51] 我就能确保 [8:52] 当我和其他 XFN 或领导沟通时 [8:57] 我能表达一定程度的谨慎 [9:00] 或者说明这个情况的风险 [9:02] 这样就不会让我说出那种话 [9:04] 其实我谈过了,项目完全没问题 [9:07] 周五就能好 [9:08] 因为那会把你置于 [9:10] 更 [9:10] 容易失败且压力更大的位置 [9:13] 因为别人会说 [9:14] 你经理说都没问题 [9:16] 对我来说,这更多是为了 [9:18] 确保你和经理对事情达成一致 [9:21] 而不是 [9:22] 我让经理知道我需要帮助 [9:24] 因为很多时候,即便是我的 IC [9:27] 也会告诉我哪些项目有风险 [9:29] 他们会说明不需要我做什么 [9:31] 或者当他们来找我 [9:34] 对我来说,区别在于 [9:35] 你做得不好,以及 [9:37] 当你告诉我有风险时我就需要介入 [9:40] 你还没尝试自己解阻 [9:43] 你只是来找我,希望我第一个 [9:45] 帮你解决 [9:45] 这件事;相比之下你来找我 [9:47] 会告诉我你已经尝试过哪些解阻方法 [9:50] 然后我再介入,因为现在 [9:52] 已经超出你能控制的范围 [9:54] 这很正常 [9:55] 你本来就应该依靠经理帮你解阻 [9:57] 这是我的职责之一 [10:01] 先把功课做足,自己搞不定时 [10:04] 再向经理求助 [10:07] 但这个类比让我想到一点 [10:10] 我觉得你在说我们应该客观 [10:15] 要诚实,当然 [10:18] 要把事情做好 [10:20] 你需要理解不仅是好的部分 [10:23] 还有不好的和有风险的部分 [10:25] 但这源自一种信任关系 [10:28] 很多人处在“我不信任经理”的状态 [10:34] 可能从学校开始就觉得 [10:37] 我的老师会 [10:39] 因为不做作业而惩罚我 [10:41] 给我打分 [10:42] 或评估我 [10:44] 所以他们把这种 [10:45] 心态带到工作中,觉得经理是来 [10:49] 评估我的工作 [10:50] 做错了就会解雇我 [10:52] 我理解这种羞耻感从何而来 [10:54] 老实说 [10:55] 我过去也有同样的恐惧 [10:57] 但我觉得区别在于 [10:59] 你的经理虽然你可能觉得 [11:00] 他们是来评估你的 [11:02] 他们也会为你发声 [11:04] 因为涉及绩效评审 [11:06] 以及这些讨论 [11:08] 在那些会议里,经理会是那个 [11:10] 为你代言的人 [11:11] 尽力为你争取 [11:13] 你可能觉得我不能信任经理 [11:15] 我不知道能不能信任他们告诉我 [11:17] 但你也要问问自己 [11:19] 你有没有给他们机会去看到 [11:22] 你是否能信任他们 [11:23] 我早期有过这种经历 [11:26] 换团队加入 ecosystems 时 [11:28] 我还是一个很新的高级 IC [11:31] 在我脑子里我笃定 [11:33] 我需要很自主 [11:35] 因为我是高级 [11:36] 大家有期待 [11:37] 我能独立解决问题 [11:38] 我能独自搞定 [11:40] 于是我在做一个项目,它 [11:42] 到了一个 [11:43] 让我和一些方面有很多困难的阶段 [11:45] 一些 XFN 合作伙伴 [11:46] 但我没有升级处理,也没告诉经理 [11:49] 我以为告诉他们就像你说的那样 [11:52] 哦,这就是那种羞耻感 [11:53] 这意味着我不够自主 [11:54] 就是我没有 [11:56] 足够独立 [11:56] 需要他们帮我解决这些 [11:58] XFN 困难 [12:00] 因此 [12:00] 我不得不推迟项目截止日期 [12:03] 我得跟经理说 [12:04] 我们赶不上 [12:05] 这个 无法及时赶上领导层评审 [12:08] 模型上有困难 [12:10] 我也有困难 [12:11] 和合作伙伴那边 [12:13] 这对我是一次学习,因为在那之后 [12:15] 我经理来找我告诉我 [12:17] 他说 [12:18] 你只要告诉我 [12:19] 让我知道 [12:20] 有问题时可以告诉我 [12:21] 你可以向我求助 [12:23] 他说 [12:23] 我告诉你 [12:24] 大多数人常犯的错误 [12:26] 我也对很多直接下属说过 [12:28] 他们觉得自己求助太多 [12:31] 但更多时候是求助不够 [12:34] 他给我的建议是:我告诉你 [12:37] 你可以问我尽可能多的问题 [12:39] 或需要多少帮助就开口 [12:40] 如果我觉得 [12:41] 你已经求助过多 [12:43] 超过了一条线 [12:44] 超出我对你这个级别的期待 [12:47] 我会告诉你 [12:49] 现实是我从没接近这条线 [12:50] 大多数人也不会接近,因为 [12:52] 我们说服自己 [12:55] 觉得高级就该很强、很独立 [12:59] 但现实很少如此 [13:02] 我越资深,见过越多经理 [13:05] 我发现大家都会求助 [13:07] 每个人都会向经理或他人求助 [13:10] 所以我们以为必须非常 [13:12] 独立强大 [13:13] 但这通常只是意味着我们没有去求助 [13:15] 没有求到该有的帮助 [13:17] 也没有像别人那样求助 [13:20] 是的,就我作为经理的经验 [13:24] 能帮上忙其实感觉很好 [13:27] 因为我们离实际工作很远 [13:29] 我总是对团队这么说 [13:31] 我经常会想我是不是 [13:34] 为你的生活增值 [13:35] 我在做什么、如何提供帮助 [13:37] 然后他们带着问题来找我 [13:39] 我就会觉得 [13:39] 哦对,我还能帮上忙 [13:41] 还能创造价值 [13:42] 这让经理很安心 [13:43] 从某种意义上,我们想要 [13:45] 把团队培养起来 [13:47] 到一个程度 [13:48] 让我们自己“被自动化”掉 [13:50] 你们都很强 [13:51] 很独立,不需要我 [13:53] 但当他们问问题时也很让人安心 [13:56] 你会觉得 [13:56] 我还能帮上忙 [13:58] 对对 [13:59] 我觉得另一个点是 [14:01] 经理的绩效不是看我解雇了多少人 [14:05] 而是我帮助多少人晋升 [14:08] 完全同意!绩效管理是工作的一部分 [14:11] 也是你必须做的 [14:13] 但我会说 [14:14] 这是工作中最糟糕的部分 [14:15] 而且这也不是我们 [14:17] 最看重的 [14:18] 衡量你晋升或能力的 [14:20] 关键。真正重要的是 [14:22] 你能不能建立人才储备 [14:24] 打造团队 [14:25] 让他们更资深、获得晋升 [14:29] 提升他们的强项 [14:30] 这样你也能更好地规模化 [14:32] 所以在任何时候 [14:33] 培养你符合你经理的最大利益 [14:36] 在你的职业生涯里 [14:37] 而且除了 [14:38] 他们可能关心你 [14:40] 关心你的职业成长之外 [14:41] 这也符合他们的利益 [14:43] 去培养你在职业上成长 [14:45] 很好,我觉得这自然让我们过渡到第二个问题 [14:47] 但你一开始不是数据科学家 [14:49] 你在meta工作了七年 [14:53] 你更有可能帮助其晋升 [14:55] 好问题 [14:56] 我觉得这些也和我脑中的 [14:59] 思路很一致 [15:01] 我认为哪些技能能让一个人 [15:03] 得到晋升、达到高级水平 [15:06] 我们到底看重什么 [15:08] 不同层级不一样,但对我来说 [15:12] 最重要的一点是 [15:14] 能在两者间取得平衡的人 [15:16] 就是我刚才说的 [15:17] 既自主又能向上管理 [15:21] 我知道哪些 IC 可以信任 [15:25] 当 我知道我需要介入时他们会来找我 [15:28] 如果我能放心让他们独自做 [15:30] 并知道项目没有风险 [15:32] 因为在到那一步之前 [15:34] 他们会告诉我 [15:35] 会把我拉进来 [15:35] 他们能正确地向上管理我 [15:37] 这就是一种“可以”的程度 [15:39] 这是我可以信任的强 IC [15:40] 我也可以 [15:42] 让他负责一个范围或领域 [15:44] 因为我信任他的沟通程度 [15:46] 和我之间的沟通 [15:47] 让我能知道进展 [15:49] 知道问题 [15:50] 也知道何时需要介入 [15:53] 我觉得那些我不太信任的 IC [15:56] 就是那些我需要更多去拉的 [15:58] 所以我经常讲推/拉模型 [16:01] 给一些 IC 听 [16:02] 所以拉模式就是你把经理拉进来 [16:05] 你告诉他们:你需要在这里介入 [16:07] 你需要做点事 [16:08] 我相信他们会拉我进来 [16:10] 当我需要介入时 [16:11] 否则我就让他们自己处理 [16:13] 我们每周会有 check-in [16:14] 会有各种沟通,但之后 [16:16] 我能放心让他们自己做 [16:18] 推模式是指 [16:19] 我需要去催他们更新 [16:21] 我需要去跟进 [16:22] 因为我不知道进展 [16:24] 对我来说这更像 [16:25] 是对更初级的 IC 才做的事 [16:27] 这没问题 [16:28] 因为他们还在学习成长 [16:29] 或者新入职的人 [16:31] 但 [16:32] 如果我很长时间还得这样做 [16:34] 而且看不到转向拉模式 [16:36] 那对我来说是个令人担心的信号 [16:38] 于是我就会说 [16:39] 我需要你更有主人翁意识 [16:41] 就是要掌控议程 [16:42] 掌控沟通并负责 [16:44] 向上管理我,这样我 [16:47] 才会信任你能独立负责 [16:50] 让我再深入一层 [16:53] 那什么会触发你去推 [16:56] 会觉得必须进入推模式 [17:00] 有什么信号 [17:01] 所以对我来说很多时候是 [17:04] 我们在推进一个项目 [17:06] 我们在准备一次评审 [17:08] 但我感觉没有持续收到更新 [17:10] 我感觉自己并不了解 [17:12] 项目的当前状态 [17:14] 我感觉没有收到更新 [17:16] 关于我应该知道的里程碑或情况 [17:19] 在工作进展方面 [17:22] 强 IC 是能 [17:24] 把这些拆解开来 [17:25] 并定期向各方干系人沟通 [17:28] 不仅是对经理 [17:29] 也要对团队其他人 [17:30] 这样大家就不会觉得 [17:32] 对发生的事一头雾水 [17:34] 对我来说这就是 [17:36] 非常强的 IC,当他们能管理好 [17:39] 所有干系人的期望 [17:40] 所有协作者的期望 [17:43] 而在某些情况下 [17:44] 你的经理也属于这个定义 [17:46] 作为干系人和协作者 [17:48] 我开始担心 [17:49] 当我开始进入强推模式时 [17:51] 就是我在说 [17:52] 我们在推进,离截止日期越来越近 [17:54] 也快到一个节点 [17:55] 但我觉得不知道发生了什么 [17:56] 那时我就会更用力去催 [17:58] 因为我觉得他们还没把我拉进去 [18:00] 我不觉得你只能在需要帮助时 [18:02] 才把经理拉进来 [18:03] 你也应该把他们拉进来 [18:05] 让他们知道一切都好 [18:07] 不用担心 [18:08] 比如如果我 [18:09] 更早被拉进来 [18:10] 看到更早的草稿版本 [18:12] 发现一切没问题 [18:13] 那我就可以继续退一步 [18:15] 不需要介入 [18:16] 也不需要做什么 [18:18] 我只需要了解当前状态 [18:21] 我想说的是 [18:22] 可以抽象一下 [18:25] 第一,大多数人会犯的错误是 [18:28] 沟通不足 [18:29] 对,非常 [18:30] 很少有人会犯过度沟通的错误 [18:32] 我们应该更倾向于去 [18:34] 多沟通一些 [18:36] 这是第一点 [18:38] 第二点是我们到底在做什么 [18:40] 我们是要确保项目成功 [18:44] 重点在项目 [18:45] 不是个人表现 [18:47] 当人们沟通不足时 [18:50] 往往是担心 [18:51] 别人会如何评价我说了这些 [18:54] 或做了那些。但如果你 [18:57] 换个角度 [18:59] 让项目或事情 [19:01] 被做好 [19:03] 那你就会有一种自然的 [19:05] 比如理解 [19:07] 什么时候该沟通,以及该沟通什么样的 [19:10] 信息到什么程度 [19:13] 完全同意,我觉得这是很好的 [19:15] 一种表述方式 [19:17] 如果你能把自己和个人担忧分开 [19:20] 比如 [19:21] 我不想显得不好 [19:23] 我不想看起来不够独立 [19:25] 我不能在这个情境里自主 [19:27] 而把注意力放在项目负责上 [19:30] 比如 [19:32] 我是否确保 [19:33] 项目会成功,或项目是否有风险 [19:36] 那你可能更愿意 [19:38] 推动事情并采用更好的沟通方式 [19:43] 还有一点我想强调 [19:44] 关于 [19:45] 强 IC,我认为 [19:48] 强绩效 [19:49] 我遇到的更强的 IC [19:52] 我觉得都有很强的自我认知 [19:54] 知道自己的优势和弱点 [19:57] 我觉得这也 [19:59] 可能和资深程度相关 [20:02] 越资深 [20:04] 越不亲自上手 [20:07] 在职业发展或职业路径上 [20:08] 我需要介入得越少 [20:10] 这并不是说 [20:11] 我不会和高级 IC 聊职业 [20:14] 但我觉得我的高级 IC 更加 [20:17] 对自己的职业路径有主动性 [20:19] 比如 [20:20] 他们很清楚自己的优势 [20:22] 也知道自己的弱点 [20:24] 并把这些告诉我 [20:26] 所以我的角色和关注点是 [20:28] 如何把他们放在最合适的位置 [20:31] 发挥他们的优势 [20:33] 我觉得在较弱的 [20:36] 不是更初级的 IC,而是能力较弱的 IC [20:39] 他们没有很好的 [20:41] 对他们优势在哪里的自我认知 [20:42] 对弱点在哪里的认知 [20:44] 他们仍在 [20:45] 有点 硬撑自己没意识到的事情 [20:47] 那些并不是他们的强项 [20:49] 在大多数情况下弱点对你明显吗 [20:52] 比如他们不 [20:53] 了解自己的弱点 [20:55] 但对你和其他人来说明显吗 [20:58] 是的,我觉得大多数时候 [20:59] 如果给足时间 [21:01] 去校准和评估一个人 [21:03] 我觉得这 [21:04] 对我来说很明显 [21:05] 我觉得 [21:07] 差距和问题在于 [21:08] 他们自己不觉得明显 [21:10] 因为那就会有一种 [21:13] 我需要的优势和能力 [21:15] 每个技能在某个层级都要达到的标准 [21:17] 在某个层级时 [21:19] 但除此之外 [21:20] 当你真正考虑更高层级的成长 [21:23] 时 [21:24] 关注点其实在于 [21:26] 如何最大化发挥自己的优势 [21:27] 我如何把自己 [21:28] 放在能最大化发挥优势的位置 [21:31] 发挥我的优势 [21:32] 因为过了某个阶段就不再是 [21:34] 提升弱项,而更多是 [21:38] 加倍投入在强项上 [21:40] 对,显然 [21:42] 如果每个人都能把我们的工作做得像你一样好 [21:44] 或者你知道每个人都会变得不可替代 [21:46] 所以你需要放大你的优势 [21:48] 但我想深入聊一下 [21:51] 你觉得为什么会这样 [21:54] 我也有同样的体验 [21:57] 一个人的弱点 [21:58] 对其他人和经理来说很明显 [22:02] 但他们自己不明显 [22:03] 但这很难 [22:05] 让经理直接指出来 [22:07] 又不伤感情 [22:10] 你越不能明显地识别 [22:13] 显然就越难 [22:14] 作为经理,我越难成为 [22:16] 那个把话说破的人 [22:18] 但我觉得很多时候这确实与 [22:20] 自我反思 [22:21] 我做的一件事有关 [22:22] 回到一对一的问题 [22:25] 就是把 [22:26] 每周一对一和职业对话分开 [22:28] 我觉得 [22:29] 很难进行深入的职业对话 [22:32] 当我们太专注于战术细节 [22:34] 在很多职业对话中 [22:37] 我通常会先开场聊 [22:39] 在谈绩效评估之前 [22:41] 我会让你回顾 [22:43] 事情进展如何 [22:44] 你觉得哪些进展得好 [22:46] 你觉得哪些进展不好 [22:47] 你的目标是什么 [22:49] 职业路径目标 [22:50] 你觉得自己在朝这些目标推进得怎样 [22:53] 我觉得当人们 [22:54] 不去问自己这些问题 [22:55] 或不去认真思考这些事情 [22:57] 他们就不会完全了解 [23:00] 自己的优势或弱点 [23:01] 即便如此 [23:03] 如果他们仍然不了解 [23:03] 很可能只是校准不准 [23:06] 比如他们对 [23:07] 标准线在哪里有错误认知 [23:09] 针对某些技能和能力 [23:11] 然后 [23:11] 作为经理,我的工作就是把这些说清楚 [23:14] 有时这完全合理 [23:16] 有时候这是我作为经理的问题 [23:17] 如果 [23:19] 对你的期望 [23:20] 没有把标准线讲清楚 [23:23] 这时我会开始投入 [23:25] 我必须投入更多精力 [23:26] 确保你理解清楚 [23:28] 但以我的经验 [23:30] 更强的 IC 是非常有自我认知的 [23:33] 知道自己哪里低于标准 [23:35] 或离下一级有哪些差距 [23:37] 或者他们的优势在哪里 [23:39] 因此 [23:40] 职业对话更多由他们主导 [23:42] 和一对一一样也更多由他们主导 [23:44] 他们对这些有很清晰的认识 [23:48] 这些是我的强项,这些是我的弱项 [23:50] 我想在这些方面提升 [23:51] 但我觉得在能让我 [23:55] 最大化发挥这些技能的角色里我会更出色 [23:57] 然后我们就聚焦在项目和机会 [24:00] 与他们的技能和兴趣相匹配的 [24:02] 我想深入聊一下“掌控自己的职业” [24:05] 和职业对话这部分,因为我职业生涯中犯过一个错误 [24:10] 在 Meta,我觉得 [24:12] 我谈晋升 [24:14] 晚了半年 [24:16] 当我开始和经理谈晋升之后 [24:19] 我们就有了计划,也有了 [24:22] 持续的检查 [24:23] 差距在哪里,以及如何 [24:26] 给我更多项目来补差距或提高可见度 [24:31] 这是一个非常重要的起点 [24:35] 和经理谈晋升 [24:37] 但我为什么晚了半年 [24:40] 我害怕 [24:41] 我害怕经理怎么看我 [24:43] 比如我可能不配晋升 [24:46] 然后经理会说为什么 [24:49] YZ 要求晋升,当他还 [24:51] 那些都不是真的。我的经理并不这么想,但 [24:56] 人们会有这种想象,对吧 [24:58] 我觉得这回到一个点 [25:00] 就是你之前说的 [25:01] 要和经理建立信任 [25:04] 作为经理 [25:04] 我需要评估和弄清楚的一件事 [25:06] 早期是这样的 [25:08] 人们的动机是什么 [25:09] 比如我团队不同 IC 的动机 [25:11] 有些人动机非常明确 [25:14] 就是晋升,比如他们 [25:16] 每次晋升后都会说好 [25:18] 我怎么到下一级 [25:19] 关注点是什么,差距是什么 [25:21] 也有一些人 [25:22] 其实很少谈晋升 [25:24] 他们只谈 [25:26] 生活、工作生活平衡 [25:28] 技能、优势这些 [25:30] 作为经理,我仍然有责任确保 [25:33] 我把两类人都安排好 [25:34] 在通往晋升的良好路径上 [25:36] 比如 [25:37] 不是有人更常问我就意味着 [25:39] 作为经理我就不该 [25:41] 付出同样的努力 [25:42] 给不常问的人 [25:44] 但现实是到头来 [25:47] 作为 IC,你是自己最大的代言人 [25:49] 所以 [25:50] 我也会这样做 [25:52] 在理想情况下 [25:53] 我的经理会付出同样的努力 [25:55] 去考虑我的晋升 [25:56] 确保我在接近时知道 [25:58] 或者我的机会是什么 [25:59] 我仍然想要进行这样的对话 [26:01] 并会主动推动这个对话 [26:03] 这样我就知道我离目标还有多远 [26:06] 我通常这样开启这些对话 [26:10] 带着脆弱和非常清晰的状态 [26:12] 比如我会告诉经理 [26:15] 我觉得自己还没那么接近晋升 [26:17] 对我来说,我觉得还要一年以上 [26:19] 但这对我有帮助 [26:21] 去了解我的差距在哪里 [26:23] 也听听你觉得我的差距是什么 [26:25] 所以即使还要一年以上 [26:27] 我也可以专注于这些方面 [26:29] 这样当我们有职业对话时 [26:31] 你可以告诉我是否在变好 [26:33] 我是否在进步 [26:35] 我不是让你一年内提拔我 [26:37] 我只是希望你告诉我 [26:38] 我需要努力的点是什么 [26:40] 并告诉我你是否看到改进或成长 [26:43] 并由此出发 [26:43] 这种透明度和信任建设 [26:46] 我觉得很有帮助 [26:47] 现实是,有时候说实话 [26:49] 你可能会觉得 [26:51] 我觉得离晋升还有一年以上 [26:52] 或者很远 [26:54] 但其实不是 [26:55] 我遇到过,我对 [26:57] 某个时候的一个经理说 [26:59] 我觉得离晋升还有点距离 [27:01] 所以我不确定,我在考虑 [27:03] 换团队或其他选择之类的 [27:06] 我其实不觉得你离得那么远 [27:08] 而这只是 [27:08] 因为我真的不知道标准线在哪里 [27:10] 在那个时候 [27:11] 所以我觉得 更透明一些 [27:13] 而成为自己职业的主人和代言人 [27:17] 有助于确保没有 [27:20] 不清晰 [27:21] 没有 [27:22] 沟通误差 [27:23] 也不会错过任何 [27:25] 对期望的清晰度 [27:26] 因为在理想情况下 [27:28] 好的经理应当把这些都沟通好 [27:30] 不管你问不问 [27:32] 但你不应把这完全交给经理 [27:34] 你完全可以主动去推并要求 [27:36] 清晰 [27:37] 是的,我觉得需要清晰,不应有意外 [27:42] 正确的期望 [27:44] 是的,这里大概有两种失败场景 [27:48] 我认为 [27:49] 当你进入绩效评审时 [27:51] 如果你感到意外 [27:53] 被反馈或评分吓到 [27:55] 要么 [27:56] 显然只有两种失败方式 [27:58] 要么你没有很好地 [28:00] 理解 [28:02] 你的位置和你的期望 [28:05] 但更大的问题是 [28:07] 你的经理没有做好 [28:09] 向你沟通这些 [28:10] 因为即使你不自知 [28:12] 而你觉得一切很顺利 [28:13] 你的经理也应该早就给你这些 [28:15] 反馈贯穿整个过程 [28:17] 你的 [28:17] 职业绩效评审不应是第一次 [28:19] 你收到任何 [28:20] 关于弱点或差距的关键反馈 [28:23] 如何 [28:24] 你会怎么把坏消息说出来 [28:27] 以建设性的方式给下属 [28:29] 我认为最重要的是 [28:30] 要直白、坦诚 [28:33] 艰难对话确实很难 [28:36] 无论是绩效管理还是 [28:39] 给某人 [28:40] 更低的评级,甚至 [28:43] 给人一个好评级 [28:44] 但低于他们预期 [28:45] 或者没拿到晋升 [28:47] 他们期望的 [28:48] 传达这个消息的人很难 [28:52] 但我觉得这也是岗位责任 [28:55] 我会尽量 [28:55] 要理解我们都是成年人 [28:57] 不拐弯抹角 [28:59] 我会很直接地说这是 [29:02] 发生了什么 [29:03] 我会很清楚地说明 [29:06] 差距是什么 [29:07] 讨论过的差距、我认为差距在哪 [29:10] 然后在深入到 [29:13] 具体细节前 [29:14] 我会问他们的感受 [29:15] 比如这很令人失望 [29:17] 这很难过 [29:17] 我知道你希望的是别的结果 [29:20] 我们可以聊聊这个 [29:21] 你的感受是什么 [29:23] 你失望的点是什么 [29:24] 你怎么看 [29:24] 我本可以在整个半年来做得更好 [29:26] 这样 [29:27] 就不会有这种失望 [29:29] 作为经理有时你会担心 [29:31] 我是不是把预期抬得太高了 [29:33] 我是不是让他们以为晋升 [29:34] 百分之百会发生 [29:36] 给了他们一种错误的 [29:38] 确定感,觉得一定会发生 [29:40] 所以也很重要 [29:42] 作为经理反思 [29:44] 我还能做得更好的是 [29:46] 在这件事上对你而言 [29:47] 介意我演一个困难场景吗?可以 [29:50] 我们来演一个困难场景 [29:52] 你问我晋升 [29:53] 我的情绪是这不公平 [29:55] 我工作很努力,我加班了 [29:58] 我提交了最多的代码行数 [30:01] 而我做了那些分析 [30:03] 结果却拿了个差评 [30:06] 这不公平 [30:07] 你说得很对 [30:08] 你确实投入了很多时间 [30:10] 也写了最多的代码行数 [30:13] 我觉得这点是 [30:14] 我们认可,也讨论过 [30:16] 在你的绩效评定中 [30:18] 但我觉得我们需要 [30:19] 真正关注的是 [30:21] 要思考的是 [30:22] 不是代码行数或工作时长 [30:25] 而是产出的影响力 [30:27] 所以我觉得 [30:28] 尤其是在下半年 [30:30] 这是我们应该一起努力的 [30:32] 确保你的路线图设置得合理 [30:34] 这样你就不必 [30:36] 花那么多 [30:37] 额外时间 [30:37] 也不用花那么多时间写那么多代码 [30:41] 而是能把精力聚焦 [30:42] 在最有影响力的项目上 [30:44] 我觉得你晋升案例的差距 [30:47] 不是 [30:48] 工作量,而是工作影响力 [30:50] 我觉得你现在承担了很多这些 [30:53] 更多执行性、运营性的事情 [30:55] 小事情 [30:56] 把时间从更有影响力的工作上挤走 [30:58] 本来你可以做的 [30:59] 所以这是个合作 [31:01] 我希望接下来 [31:02] 我们可以 [31:02] 一起制定路线图 [31:04] 真正聚焦 [31:06] 在能 [31:08] 更有利于晋升的产品类型上 [31:11] 是的,这显然很难 [31:14] 这是很难的对话 [31:16] 有时候说到底 [31:18] 不管你作为经理说什么 [31:19] 人们都会失望 [31:21] 而且这取决于公司 [31:23] 不同公司会不一样 [31:25] 但我觉得 [31:26] 还有一点很重要 [31:28] 其实并不是 [31:29] 并不只是由你的经理决定 [31:30] 你是否能晋升 [31:31] 经理的角色是 [31:33] 在绩效对话中为你发声、推动 [31:34] 但具体怎么做取决于公司流程 [31:36] 不一定完全是 [31:38] 他们个人的 [31:39] 是或否能决定 [31:41] 这件事是否发生 [31:43] 我觉得好的经理会跟你沟通 [31:45] 告诉你反馈是什么 [31:47] 差距在哪里 [31:49] 但是 [31:50] 这需要时间 [31:51] 不是人马上就能消化 [31:54] 是的,我觉得 [31:55] 不知道有多少人有现实的预期 [31:58] 但我感觉 [32:00] 大家在变得更成熟 [32:02] 也更能接受现实预期 [32:05] 比如事情并不完全在我们控制中 [32:07] 行业、公司 [32:09] 股市、经济等都会影响 [32:12] 某种路径 [32:14] 最后一个问题关于什么是一个好的IC [32:17] 或许也是为观众问。 [32:19] 有些观众可能会想,尤其是数据科学家 [32:22] 你谈沟通 [32:23] 你谈项目管理,你谈 [32:26] 自主、不意外、向上管理 [32:30] 但你没有谈技术复杂度 [32:34] 很多人 [32:35] 想到 [32:35] 什么是高阶数据科学家 [32:38] 他们会想象 [32:40] 是某个领域专家 [32:42] 能做复杂、技术复杂的事情 [32:46] 对,你能展开说说吗 [32:48] 这是常见问题,也很合理 [32:51] 我对技术专长的看法是 [32:54] 我看到这种情况经常出现的方式是 [32:56] 这里有一个 [32:57] 基础胜任力水平 [32:59] 当谈到技术能力 [33:00] 或技术复杂度 [33:01] 或成功所需的能力 [33:03] 在很多地方都是如此 [33:05] 现实是 [33:06] 我认为 很多被这些公司录用的人 [33:08] 和我们一起工作的人 [33:11] 都具备这种技术胜任力 [33:14] 真正成为 [33:16] 成长和影响力的主要阻碍 [33:18] 往往不是技术专长 [33:21] 而是软技能 [33:23] 产品直觉 [33:26] 沟通能力 [33:27] 协作能力 [33:29] 这些才是关键 [33:31] 我见过更多情况是 [33:33] 这些阻碍了一个人 [33:35] 获得更大影响力 [33:37] 阻碍了一个人能够 [33:40] 在更大规模或更大范围上工作 [33:43] 这些更会卡住晋升 [33:46] 而不是技术复杂度门槛 [33:48] 即便是技术复杂度门槛 [33:51] 也不是能力不够 [33:53] 而是 [33:54] 所在领域的 scope 不够 [33:56] 不足以产生那样的复杂度 [33:58] 通常这意味着 [33:59] 你需要换个团队 [34:01] 或换个项目 [34:02] 它有合适的复杂度 [34:05] 是的,我和一些非常聪明的 [34:08] Meta 数据科学家共事过 [34:10] 我相信你也是 [34:12] 也和一些非常强的 [34:13] 技术人才共事过 [34:15] 但即便在我见过最技术的人里 [34:18] 最成功的那些 [34:20] 也同时能把技术 [34:22] 和正确的沟通能力连接起来 [34:24] 正确的优先级能力 [34:25] 和正确的协作能力 [34:27] 才能把它转化为影响力 [34:28] 我见过很强的技术人 [34:31] 把领域钻得很深 [34:32] 但如果他们不能说服别人 [34:35] 为什么这很重要 [34:37] 或为什么这有意义 [34:38] 或无法与他人协作 [34:41] 就不会真正改变很多事情 [34:43] 它只会停留在他们那里 [34:45] 是的,作为数据科学家我们影响他人 [34:48] 我们不写生产代码 [34:50] 公司雇我们是为了产出影响力,如果 [34:54] 我们解决了一个很难但没有影响的问题 [34:57] 那其实是在浪费很多资源 [35:00] 我们在 Meta 这么说 [35:01] 我的意思是,我确定其他地方也会这么说 [35:03] 我们的货币是影响力 [35:05] 你的能力在于说服别人 [35:07] 做出正确决策 [35:09] 如何提升这种影响力 [35:12] 这是个好问题 [35:13] 有很多东西会逐渐融入其中 [35:15] 长期的诚实 [35:16] 我觉得类似于 [35:18] 建立你的品牌,就像 [35:20] 像一个 influencer 在构建个人品牌 [35:23] 在 LinkedIn、YouTube [35:23] 以及其他地方 [35:24] 公司内部也是一样 [35:27] 你必须与他人建立信任 [35:29] 他们必须相信你的技术能力 [35:32] 你的胜任力 [35:33] 还要相信你的直觉 [35:36] 他们才会想听你更多意见 [35:38] 会来找你要输入 [35:39] 在其他事情上 [35:40] 当你有成功影响力的记录 [35:43] 以及能够 [35:45] 识别 [35:45] 机会或做出正确建议 [35:46] 的历史 [35:48] 就会有一个反馈回路 [35:49] 人们会更多来找你 [35:52] 通常当我刚加入时 [35:54] 我会尽量找到 [35:56] 容易实现的目标,快速见效,建立关系和联系 [35:58] 我认为讨论不够充分的重要观点 [36:00] 因为我觉得那是基础 [36:02] 才能影响任何人 [36:04] 这真是 [36:05] Marketplace是如何建立起如此强大的数据文化的 [36:08] 正确的直觉 [36:10] 因为我早期会问 [36:12] 像 marketplaces 组织 [36:13] 科学家有很大影响力 [36:16] 人们听数据 [36:18] 我问过早期的 director Ashish 和 Nav [36:21] 独特的 [36:24] 答案是早期 [36:26] Ashish 就坚持自己的观点 [36:29] 而且他很多时候是对的 [36:31] 所以一开始大家可能不听他 [36:33] 时间久了他建立了声誉和影响力 [36:36] 还有一点,也许是 [36:38] 每个人都只是 [36:39] 在大公司里你会逐渐意识到 [36:42] 就是 [36:43] 即便你没有提供 [36:46] 好的数据或正确的数据 [36:48] 人们也会做决定 [36:49] 比如 人们会做决定并继续推进 [36:51] 公司也会 [36:52] 推动事情前进 [36:54] 所以你很重要也必须 [36:57] 去引导他们 [36:58] 做出正确的决定 [36:59] 并朝正确方向推进 [37:00] 因为如果你不做,他们也会继续推进 [37:03] 我过去经常收到这种反馈 [37:05] 我一直不太擅长表达自己的观点 [37:09] 每次我进入一个新房间或群体时 [37:11] 我通常会告诉自己 [37:13] 这里每个人都比我资深 [37:15] 这里每个人都比我更有背景 [37:17] 这里每个人都有更多人生经验 [37:19] 那我的输入和观点为什么重要 [37:23] 我的经理和 skip 一直推动我 [37:25] 表达自己的观点 [37:26] 或者说你显然有观点 [37:28] 但你应该多分享 [37:30] 让自己习惯于 [37:32] 正是这种情况 [37:32] 基于现有信息去行动和表达 [37:34] 作为数据科学家 [37:36] 我们往往确实拥有 [37:37] 比一般 [37:38] XFN 或协作方更多的信息。PM [37:41] 如果从这个角度看 [37:43] 那么你会发现 [37:47] 数据在某种程度上是用户的声音 [37:51] 所以在某种程度上这是你的责任 [37:54] 代表产品用户 [37:57] 把他们的关注点说出来 [37:59] 把他们的数据说出来 [38:01] 他们喜欢做什么 [38:02] 不喜欢做什么、希望更多什么 [38:04] 所以如果你不做 [38:06] 不给用户发声 [38:08] 那我们也可能会做决定 [38:10] 而这些决定可能对产品不好 [38:11] 也伤害用户体验 [38:13] 这让我想起 [38:15] 我在 Facebook 的一堂最有价值的课 [38:18] 高级数据科学家圈子 [38:20] 由 Roberto 主持 [38:22] 他现在是 Instagram 的 VP,非常聪明 [38:26] 他问我们 [38:26] 没有因果证据 [38:28] 你们中有多少人 [38:28] 来参加这个 circle 的人 [38:30] 愿意表达自己的观点 [38:32] 但其他所有职能部门可能都会 [38:34] 我觉得有一半人举了手 [38:37] 然后他问 [38:38] 有多少人愿意在没有数据时表达观点 [38:41] 我想只有他举了手 [38:44] 他说 [38:47] 这会阻止 PM [38:48] 或领导表达观点吗 [38:50] 不会,他们还是会做决定 [38:52] 那是什么阻止了你 [38:53] 是的,你会走到一个阶段,坦白说 [38:56] 当你是经理时 [38:57] 很多时候如果你是某个领域的负责人 [38:59] 你就是在做这件事 [39:00] 就是 [39:02] 如果是新领域没有数据 [39:04] 你会基于已有的直觉 [39:07] 以及历史 [39:09] 数据和你理解的一切 [39:10] 来做一个 [39:12] 建议 [39:14] 我觉得 [39:15] 重要的是要确保 [39:16] 有防护措施 [39:17] 避免我们 [39:18] 基于错误信息就 100% 投入 [39:22] 先尝试自己解决问题 [39:24] 反正大家也会 [39:25] 在没有数据时做 [39:25] 建议和决策 [39:26] 所以没有什么阻止你去做 [39:30] 但也要相信这并不是零数据 [39:34] 你有过大量数据点的经验 [39:36] 你已经内化了 [39:37] 这些影响你的直觉 [39:39] 是的,决策是定性判断 [39:42] 它不是 A 比 B 大就选 A [39:44] 对对 [39:45] 即便因果数据是很强的证据 [39:46] 但它只是证据的一部分,不是全部 [39:49] 如果我们每次都等 [39:53] 因果数据来做决策 [39:54] 那我们就根本不会快起来 [39:56] 这样我们会很慢 [39:57] 我觉得判断力很重要 [40:00] 直觉很重要 [40:03] 这可能就是 [40:04] 大多数科技公司产品分析的核心 [40:06] 很好,我可以总结为 [40:08] 强 IC 应该有好的心智模型 [40:10] 应该有正确的直觉 [40:13] 即便没有数据也能经常判断正确 [40:16] 1486 00:40:07,600 --> 00:40:08,566 [40:18] 即使没有数据,他们也应该能够经常做出正确判断 [40:20] 所以这是数据科学家需要内化的 [40:21] 在个人身上的 [40:25] 我们进入第三个问题 [40:27] 那就是如何向经理求助 [40:29] 何时求助,以及能求助什么 [40:34] 对我来说,我想我们之前讨论过这个 [40:37] 我认为有很多领域 [40:38] 让人们听你的 [40:41] 你应该在尝试过 [40:43] 你谈论的是不同的维度 [40:46] 在你努力过之后 [40:47] 仍被卡住时向经理求助 [40:50] 然后带着当前情况去找经理 [40:53] 说明发生了什么 [40:54] 经理可以在很多方面帮忙 [40:57] 比如这是协作模式的问题 [41:00] 比如你在和某些人合作 [41:02] 遇到困难 [41:03] 然后你需要 [41:05] 在经理层面升级处理 [41:06] 甚至到你经理的经理层面 [41:09] 所以你需要让经理介入 [41:10] 当涉及到资深层级时 [41:12] 就需要和经理一起处理 [41:14] 因为那已经超出你的范围 [41:16] 我不会期望我的 IC 去 [41:19] 和 director 或 VP 争论 [41:20] 他们不应该这样做 [41:21] 那应该由我来承担 [41:23] 我应该把他们保护在那种 [41:26] 权力博弈的推拉之外 [41:28] 因为这会让对话和反对变得困难 [41:30] 但我需要知道 [41:31] 他们已经尝试过什么 [41:33] 已经沟通过什么 [41:36] 已经做过哪些尝试 [41:39] 经理还能帮助 [41:41] 提供更多背景信息 [41:42] 这些在沟通中很常见 [41:44] 也回到好的“一对一” [41:45] 首要任务和最关心的问题 [41:49] 你做的一部分 [41:51] 或经理帮助的一部分就是提供背景 [41:54] 这会在沟通中体现出来 [41:57] 而且 [41:58] 回到一对一的概念 [42:00] 你做的一部分 [42:02] 或经理帮忙的一部分就是背景信息 [42:05] 你的经理比你参与更多会议 [42:07] 更了解领导层和干系人的背景 [42:11] 公司最关注的问题 [42:13] 你可能没有这些背景 [42:16] 所以经理可以帮助把你的工作 [42:18] 和你的分析连接到更大的战略 [42:21] 你应该利用经理拥有的这些背景 [42:25] 你没有这些背景并不是你的问题 [42:28] 你没有这些背景 [42:30] 并不代表你失败 [42:31] 因为经理参加的会议你没参加 [42:34] 所以没有人期望你拥有这些 [42:36] 但你应该能够 [42:38] 和经理沟通获取这些信息 [42:40] 所以经理能帮的不只是 [42:44] 帮你解阻 [42:46] 也包括连接正确的信息 [42:48] 和背景 [42:49] 让你的工作更有影响力 [42:51] 对我来说,这也是你应该 [42:54] 你的经理应该主动告诉你的 [42:56] 但这也是 [42:57] 你应该去推动经理的 [42:59] 如果你在做一个项目 [43:01] 却不完全明白为什么做 [43:03] 或者你对 [43:04] 问题本身、动机有疑问 [43:07] 你就应该推动经理解释 [43:09] 经理也应该帮助你 [43:11] 并提供这些 [43:13] 是的,就像你提到的 [43:14] 影响力就是资本 [43:16] 要获得影响力 [43:18] 进行几次迭代 [43:20] 你得谈对方关心的内容 [43:22] 更多是他们同级别的人和跨职能团队(XFN) [43:24] 即便你说得都对 [43:27] 对他们也没意义 [43:29] 是的,我有时会对团队说 [43:31] 因为我觉得在 ecosystems [43:34] 我们很多工作就是关于 [43:37] 在整个 app 层面的影响力 [43:38] 整体 [43:41] 影响 [43:41] 是你做了很好的分析 [43:45] 并且大家很关心那个问题 [43:48] 有时很难产生影响 [43:50] 你可以做很棒的分析,但如果 [43:53] 干系人 [43:53] 和受众当前不关注那个问题 [43:55] 那就 [43:56] 很难说服别人这个问题重要 [44:00] 你的建议和方案重要 [44:01] 所以有时候关键在于把合适的 [44:04] 能力匹配到大家关心的问题 [44:07] 这就是经理能帮很多的地方 [44:11] 经理应该帮你找到合适的范围 [44:13] 合适的机会 [44:15] 合适的问题 [44:16] 来与你连接 [44:18] 而你自己 [44:20] 未必能获取所有这些信息 [44:22] 所以我为团队做的很多事 [44:25] 尤其是对更资深的 IC [44:28] 就是帮助他们 [44:31] 头脑风暴并与之连接 [44:34] 这些都是好问题,你能再给几个 [44:36] 以及建立路线图 [44:38] 然后当他们在 [44:40] 撰写和沟通成果时 [44:41] 确保他们能把 [44:43] 发现连接到公司和 app 的其他事情 [44:45] 这些是战略优先级 [44:48] 这样更有机会落地产生影响 [44:52] 你多久会审阅他们的 [44:54] 写作沟通并给反馈 [44:56] 这取决于 IC 和资深程度 [44:59] 对更初级的 IC 我可能会 [45:03] 问什么问题 [45:05] 我会看更粗的草稿并给反馈 [45:07] 我通常会尝试 [45:09] 对团队来说,尤其现在更大了 [45:12] 我喜欢审 [45:13] 最初的提纲和计划 [45:15] 这样他们开始时方向正确 [45:17] 然后我会在结尾审阅 [45:19] 当它成稿后 [45:20] 把它整理好 [45:21] 并帮助他们在 framing 上迭代 [45:25] 所以取决于 [45:27] 受众是谁,比如这是要发给 [45:29] 我应该在这上面花多少时间 [45:32] 那我可能只审一次 [45:34] 如果是面向很资深的受众 [45:36] 那就不只是我 [45:38] 通常还有 [45:39] 我的多层级 skip 都会审 [45:41] 会有几轮迭代 [45:43] 我们会 [45:44] 一起打磨 framing [45:46] 并清理表达 [45:47] 并试图把它连接到 [45:49] 对领导层重要的叙事 [45:51] 但我会说 [45:53] 大概 2 到 3 次 [45:55] 是的,所以作为经理 [45:57] 涉及权力动态时升级 [46:01] 先尝试自我解阻,失败后 [46:03] 再向经理要信息 [46:06] 联系人并建立连接 [46:08] 与合适的 [46:09] 人员、信息、联系人 [46:11] 这些不只适用于 [46:14] 你的直接经理 [46:15] 这会随着层级扩展 [46:17] 当你想到管理链时 [46:19] 有些事情 [46:20] 连你的经理也解不了 [46:22] 你就得找 skip [46:24] 比如我举 Meta 的例子 [46:27] 我在 Facebook app 上工作 [46:28] 如果我与其他 org 或 app 有问题 [46:31] 到了某个阶段 [46:33] 连我经理也帮不了 [46:34] 我就得找 skip [46:36] 我得找更资深的 VP 级别 [46:37] 你会依赖他们 [46:39] 所以同样的情况会扩展 [46:41] 要理解什么时候事情 [46:43] 升级到某种难度或协作难度 [46:46] 你需要进一步向上升级 [46:49] 以及什么时候需要的背景 [46:52] 在更高层级获取 [46:55] 比如我有时需要知道 [46:56] 领导评审或领导会议发生了什么 [46:59] 甚至我经理也不在其中 [47:01] 那我就去找我的 VP [47:03] 于是我会联系 VP [47:05] 嘿,我需要这个 request 的一些背景 [47:08] 我想知道当时 [47:10] 在哪里讨论的 [47:11] 你们当时看了什么 [47:13] 还讨论了哪些额外内容 [47:15] 我需要更多背景 [47:16] 谢谢。我觉得这很好地回答了我的问题 [47:18] 类似的问题吗 [47:19] 那一类的问题 [47:21] 如何从你的Manager那里提取更多信息 [47:24] 应该问什么问题 [47:25] 我通常会先问 [47:27] 这个问题出现的背景是什么 [47:29] 因为很多数据科学家应该知道 [47:32] 他们经常被问一些 [47:34] 随机或很具体的问题,比如 [47:38] 我们想要这个功能的数据 [47:39] 或者我们想要这些用户的数据 [47:41] 我就会说,好 [47:43] 能否给我更多背景 [47:45] 发生了什么 [47:46] 你们当时在看什么 [47:47] 或讨论什么时提出的 [47:50] 我觉得最重要的问题是 [47:53] 我们会用这份数据做什么决策 [47:56] 这份数据的目的是什么 [47:58] 你想做的决策是什么 [48:00] 因为通常会发生的情况是 [48:04] 其实有更好的数据可以提供 [48:06] 来帮助做这个决策 [48:09] 但因为他们不了解数据 [48:11] 所以会去要某些数据 [48:12] 但如果你知道问题 [48:13] 你其实可以提供更好的数据或更多数据 [48:16] 所以我一直会 [48:18] 尽量弄清楚讨论的背景 [48:20] 这些讨论是在什么情境下发生的 [48:22] 你们当时在看什么 [48:23] 在看已有的数据吗 [48:25] 在看已有的趋势吗 [48:27] 我可以看看吗 [48:28] 第二是你们要做的决策是什么 [48:32] 我觉得有时问 [48:34] 你们要做什么决策 [48:35] 也有帮助,因为如果答案是没有决策 [48:39] 你就可以反问:这是优先级吗 [48:42] 拿到这些数据能帮到什么吗 [48:44] 这会改变我们的想法吗 [48:45] 这会改变决策吗 [48:46] 如果不会,这比我其他工作优先吗 [48:49] 我正在做的 [48:50] 对我来说这常常是 [48:52] 一个优先级与反推的检验 [48:54] 因为我觉得每个数据科学家都经历过 [48:56] 被大量 [48:58] 数据需求 [48:58] 轰炸 [48:59] 而大家总想要更多数据 [49:03] 一个简单的反推方式是问 [49:05] 这些数据能帮助我们做什么 [49:07] 重要吗 [49:08] 如果这些数据不会改变任何决策 [49:10] 那我们真的需要吗 [49:12] 是的 我觉得这是关键问题 [49:14] 区分一个 SQL monkey [49:16] 和一个能影响决策的数据科学家 [49:21] 这也有助于理解 [49:23] 我们需要多高的精度 [49:26] 你需要的精度水平是什么 [49:29] 为了你要做的决策 [49:30] 你是要一个大概估计 [49:32] 还是需要知道是 1% 还是 10% [49:34] 或 70% 的机会或规模 [49:38] 还是需要非常具体 [49:40] 需要很清晰的置信区间 [49:42] 因为要避免 [49:43] 高风险的错误 [49:45] 这能让我知道 [49:47] 我该投入多少时间 [49:50] 我觉得尤其是 [49:51] 你越资深,无论是 IC 还是经理 [49:52] 你就越擅长 [49:54] 把握这种度 [49:57] 能够判断 [49:58] 提出问题 [49:59] 你觉得他们在乎IC(个人贡献者)吗 [50:01] 并问对问题来判断 [50:04] 应该投入多少精力 [50:06] 很好 [50:06] 很难说出什么新东西 [50:09] 我觉得我们已经谈到了心态和行动项 [50:13] 他们可以带走明天就开始用 [50:16] 所以你觉得我还应该问你什么 [50:19] 反正我也告诉所有我的直属下属 [50:20] 关于转做经理 [50:21] 之类的吗 [50:22] 比如是什么感觉,什么容易什么难 [50:25] 还是说太私密了 [50:26] 我觉得大家关心这个 [50:28] 但这个问题已经被问烂了 [50:32] 太多次了 [50:33] 大家每次都问这个 [50:35] 也许是替观众问 [50:38] 可以,完全合理 [50:40] 我觉得因为焦点一直在这里 [50:42] 如何使用经理 [50:43] 以及怎么和经理沟通 [50:45] 如何建立连接 [50:46] 我觉得我们已经回答了 [50:47] 我觉得不止三个问题 [50:49] 因为我们很深入地聊了 [50:51] 各种话题和追问 [50:51] 所以我们覆盖了不少内容 [50:53] 很好,谢谢你 [50:55] 你觉得这次对话怎么样 [50:58] 第一次肯定有点别扭 [51:00] 就像 我觉得我有时说太多,会絮叨 [51:04] 但很不错,就像我 [51:09] 有意思的是我在直接跟你说 [51:11] 但感觉像在对观众说 [51:14] 尽管他们不在 [51:15] 你会有这种感觉 [51:16] 你在对更大的 [51:18] 更广泛的听众说话 [51:19] 对,我会把这种视角带给我对话的嘉宾 [51:22] 我不知道 [51:26] 我试图使用的锚点是 [51:27] 关于这个的最后一个问题,什么是好的IC [51:31] 如果你把这个视频发给我们的直属下属 [51:34] 会不会让他们更成功 [51:36] 如果是,那就可以 [51:38] 我们已经从对话中获得足够价值 [51:41] 剩下的就是算法之类 [51:44] 很多不可控的事情 [51:48] 比如什么是好的IC [51:49] 你之前是SDE [51:50] 所以我很乐意发给所有直属下属 [51:53] 是的,我不觉得你说太多或太少 [51:57] 我觉得刚刚好,而且对我来说一点也不别扭 [52:00] 很自然、很真诚 [52:02] 你应该多做播客 [52:04] 你应该多做播客 [52:06] 两周后我会再和你做一期 [52:08] 会很有趣,太好了