【职场经验】从Tech Lead到大厂ML Manager：写给在晋升瓶颈期挣扎的IC们 (Part II)
晋升
fishriver
大家好，今天是周日，在准备下周三和周四的 final onsite 面试之余，正好抽点时间继续来写 Part II。感谢大家在 Part I 里慷慨加的大米，你们的支持真的帮了我很大忙，让我有更多的权限去浏览地里的面经和求职资源。虽然还没有去浏览任何帖子，但有个这个可以看更多帖子的option，就很开心就不虚，踏实了，哈哈哈。
在上一篇里，我们聊了视角转换。今天我们来聊一个更实操，也是L5 (Senior) 升 L6 (Staff) 过程中最致命的问题：Scope到底是从哪里来的？
我经常在1:1里听到Senior IC抱怨：“老板，我想升L6，但我手里现在做的这些项目不够大，你能不能分给我一个更大的项目？”
每当听到这句话，我心里就会叹口气。因为这句话背后隐藏着一个L5最容易陷进去的思维误区——把Scope当成了“分蛋糕”。
1， 为什么“别人切好的蛋糕”，永远不够你升Staff？
在Manager眼里，团队现有的OKR和核心项目，就像是已经烤好的一块蛋糕。这块蛋糕是被切好、分派下去的。
如果你是在做“别人切好的蛋糕”，那意味着这个项目的蓝图（Roadmap）、预期收益，甚至是系统架构的高层设计，大概率已经被Tech Lead或者Manager定义过了。
你在其中的角色，无论执行得多完美、代码写得多漂亮，本质上依然是一个“高级执行者”。
而Staff Engineer的核心定义是什么？是Navigating Ambiguity（在极度模糊中找到方向），是Identify blind spots（发现团队的盲区），是0到1定义一个新方向。
如果你永远在等老板把大项目“喂”到你嘴边，你永远拿不到真正的Staff级别的Scope。真正的Scope，是自己“抢”来的，甚至无中生有“造”出来的。
2， 去哪里“抢”？去那些“三不管”的真空地带
很多IC觉得，想要大Scope，就得去卷最核心的模型。在电商搜索推荐团队，这通常意味着去卷主干的Ranking（排序）模型，大家都在绞尽脑汁地加Feature、换大模型结构，为了离线AUC提升个0.1%争破头。
但其实，真正的金矿往往在那些“没人愿意碰、或者大家都觉得很难搞”的真空地带。
给大家举个我自己团队里真实的例子。当年我们团队都在卷排序指标，但我手下一个很聪明的IC发现，无论我们离线模型怎么迭代，线上真实的收益总会打个折扣。他没有继续去调参，而是跑去查数据链路。
他发现，因为历史遗留问题，我们Search和RecSys两边底层的Feature Pipeline（特征流）是不一致的，这导致了严重的Online-Offline Skew（线上线下不一致）。这个问题大家都隐约知道，但没人管，因为它是跨部门的，极其繁琐，且不直接产出模型。但这，就是巨大的Scope。
3， 不要去要资源，要带着“证据”去谈判 (POC Strategy)
当你发现了一个真空地带，最忌讳的做法是：跑去跟老板说，“老板，我觉得这个方向很有搞头，你给我拨两个人，我们花三个月搞一下。”
在没有看到实际ROI之前，老板的回答一定是：“想法很好，但目前我们的优先级是把Q3的OKR做完，以后再说。”
正确的做法是“闷声作大死”（这里是褒义）。利用你20%的业余时间，或者周末，不要惊动大部队，自己偷偷搞一个极简的POC (Proof of Concept) 雏形。
还是上面那个特征不一致的例子。那个IC花了两个周末，写了一个小脚本，强行对齐了其中某几个核心Feature，然后拉了一个极小流量的A/B Test。结果显示，仅仅对齐这几个特征，线上转化率就获得了非常显著的提升。
4， 用业务语言Pitch，名正言顺成为这块封地的“王”
当他拿着这个初步的数据报表来找我的时候，你觉得作为Manager我会怎么做？
我立刻在接下来的Roadmap里加了一个最高优先级的项目：“统一全链路特征工程”。并且，我不仅让他全权负责，还主动去别的组帮他要 headcount，甚至把组里的两名中级工程师划给他调遣。
你看，这就是“抢”Scope的完整闭环：
洞察盲区 -> 偷偷搞出MVP -> 拿到初步数据证明ROI -> 拿着数据去“反向画饼”给老板 -> 拿到资源，成为这个新方向的Tech Lead。
总结与后续预告：
Scope不是老板发给你的，是你在业务的夹缝里，用敏锐的嗅觉闻出来的。别等别人切蛋糕，自己去找面粉，烤个新蛋糕出来。
今天这篇就先聊到这。如果大家觉得这篇讲的这些接地气的实操对你有启发，恳请大家继续多加点大米！
另外我想说，在极其核心且承载巨大业务压力的部门做Manager，我积累了很多在IC岗绝对接触不到的经验和教训。比如：什么时候该向你的上级（Director/VP）妥协，什么时候又绝对不能让步——尤其是当上面要求你交出团队的 Stack Ranking（强制排名），甚至逼你交出处于 Bottom（垫底）名单的员工名字时。如果你处理不好盲目顺从或保护组员太强硬push back，这会极其严重地 Backfire（反噬）到你自己身上。这是我亲身经历过的血的教训，以后有时间我会专门开一篇细聊。
在接下来的 Part III，我打算带大家走进“小黑屋”——Manager在打Perf的圆桌会议（Calibration）上，到底是怎么为手下争取名额的？什么样的IC具有不可替代的“提拔体质”？以及后续的 Part IV：VP级别 Promo Committee 的真实经历与震撼。
欢迎在评论区留言交流你们在工作中遇到的推项目的阻力。求大米，我们下周面完试见！
在上一篇里，我们聊了视角转换。今天我们来聊一个更实操，也是L5 (Senior) 升 L6 (Staff) 过程中最致命的问题：Scope到底是从哪里来的？
我经常在1:1里听到Senior IC抱怨：“老板，我想升L6，但我手里现在做的这些项目不够大，你能不能分给我一个更大的项目？”
每当听到这句话，我心里就会叹口气。因为这句话背后隐藏着一个L5最容易陷进去的思维误区——把Scope当成了“分蛋糕”。
1， 为什么“别人切好的蛋糕”，永远不够你升Staff？
在Manager眼里，团队现有的OKR和核心项目，就像是已经烤好的一块蛋糕。这块蛋糕是被切好、分派下去的。
如果你是在做“别人切好的蛋糕”，那意味着这个项目的蓝图（Roadmap）、预期收益，甚至是系统架构的高层设计，大概率已经被Tech Lead或者Manager定义过了。
你在其中的角色，无论执行得多完美、代码写得多漂亮，本质上依然是一个“高级执行者”。
而Staff Engineer的核心定义是什么？是Navigating Ambiguity（在极度模糊中找到方向），是Identify blind spots（发现团队的盲区），是0到1定义一个新方向。
如果你永远在等老板把大项目“喂”到你嘴边，你永远拿不到真正的Staff级别的Scope。真正的Scope，是自己“抢”来的，甚至无中生有“造”出来的。
2， 去哪里“抢”？去那些“三不管”的真空地带
很多IC觉得，想要大Scope，就得去卷最核心的模型。在电商搜索推荐团队，这通常意味着去卷主干的Ranking（排序）模型，大家都在绞尽脑汁地加Feature、换大模型结构，为了离线AUC提升个0.1%争破头。
但其实，真正的金矿往往在那些“没人愿意碰、或者大家都觉得很难搞”的真空地带。
给大家举个我自己团队里真实的例子。当年我们团队都在卷排序指标，但我手下一个很聪明的IC发现，无论我们离线模型怎么迭代，线上真实的收益总会打个折扣。他没有继续去调参，而是跑去查数据链路。
他发现，因为历史遗留问题，我们Search和RecSys两边底层的Feature Pipeline（特征流）是不一致的，这导致了严重的Online-Offline Skew（线上线下不一致）。这个问题大家都隐约知道，但没人管，因为它是跨部门的，极其繁琐，且不直接产出模型。但这，就是巨大的Scope。
3， 不要去要资源，要带着“证据”去谈判 (POC Strategy)
当你发现了一个真空地带，最忌讳的做法是：跑去跟老板说，“老板，我觉得这个方向很有搞头，你给我拨两个人，我们花三个月搞一下。”
在没有看到实际ROI之前，老板的回答一定是：“想法很好，但目前我们的优先级是把Q3的OKR做完，以后再说。”
正确的做法是“闷声作大死”（这里是褒义）。利用你20%的业余时间，或者周末，不要惊动大部队，自己偷偷搞一个极简的POC (Proof of Concept) 雏形。
还是上面那个特征不一致的例子。那个IC花了两个周末，写了一个小脚本，强行对齐了其中某几个核心Feature，然后拉了一个极小流量的A/B Test。结果显示，仅仅对齐这几个特征，线上转化率就获得了非常显著的提升。
4， 用业务语言Pitch，名正言顺成为这块封地的“王”
当他拿着这个初步的数据报表来找我的时候，你觉得作为Manager我会怎么做？
我立刻在接下来的Roadmap里加了一个最高优先级的项目：“统一全链路特征工程”。并且，我不仅让他全权负责，还主动去别的组帮他要 headcount，甚至把组里的两名中级工程师划给他调遣。
你看，这就是“抢”Scope的完整闭环：
洞察盲区 -> 偷偷搞出MVP -> 拿到初步数据证明ROI -> 拿着数据去“反向画饼”给老板 -> 拿到资源，成为这个新方向的Tech Lead。
总结与后续预告：
Scope不是老板发给你的，是你在业务的夹缝里，用敏锐的嗅觉闻出来的。别等别人切蛋糕，自己去找面粉，烤个新蛋糕出来。
今天这篇就先聊到这。如果大家觉得这篇讲的这些接地气的实操对你有启发，恳请大家继续多加点大米！
另外我想说，在极其核心且承载巨大业务压力的部门做Manager，我积累了很多在IC岗绝对接触不到的经验和教训。比如：什么时候该向你的上级（Director/VP）妥协，什么时候又绝对不能让步——尤其是当上面要求你交出团队的 Stack Ranking（强制排名），甚至逼你交出处于 Bottom（垫底）名单的员工名字时。如果你处理不好盲目顺从或保护组员太强硬push back，这会极其严重地 Backfire（反噬）到你自己身上。这是我亲身经历过的血的教训，以后有时间我会专门开一篇细聊。
在接下来的 Part III，我打算带大家走进“小黑屋”——Manager在打Perf的圆桌会议（Calibration）上，到底是怎么为手下争取名额的？什么样的IC具有不可替代的“提拔体质”？以及后续的 Part IV：VP级别 Promo Committee 的真实经历与震撼。
欢迎在评论区留言交流你们在工作中遇到的推项目的阻力。求大米，我们下周面完试见！
已获得 99 大米
+2
共36条回复
✨ 您正在体验新版论坛UI
