抱着学习的态度分析manager应不应该怼engineer？

首先叠一个buff, 我是一个有可能以后当小manager的小engineer，之前经常被manager怼，不知道以后如我开始带人了会不会怼别人。虽然在业界呆了很多年，但是自己各方面水平都不高，大家包涵哈。纯抱着学习态度讨论。
我来明确一下 “怼” 的定义，不是就一个技术问题辩论应该走A方案还是B方案，或者一个项目DDL临近了，一直催促。而是指，针对engineer个人进行批评，名义上是为了让engineer进步和成长。
这里我举一个在我身上发生的例子：
比如目前的项目比较乱，每天都一堆新的task下来，都差不多equally important和equally challenging。但是由于engineer的每天meeting和manager的日常meeting， 不一定重合的，所以很多情况下对各个任务的优先级会有不同的判断。比如，manager上周刚开了一个顶层的会，大老板急迫地想要task C在几月几号之前尽快完成，这里manager对于这个需求是敏感的。
但是传达到engineer这里，其实听起来，A，B，C项目都是同等重要，而且C需要和X组合作，虽然不算完全blocked，但短时间内做好就很challenging，但是鉴于A， B可以更快地完成，engineer自然而然地就会倾向于集中经历干A和B，而C可以等到下周X组处理好一些东西再办。结果，manager突然跑来向engineer要C的结果，发现engineer竟然在做A，B，而C没怎么做。于是对engineer做了批评教育，最后engineer日夜兼程去push X组，还真在DDL之前把C作出个60%（能用）。
后来，engineer以为自己替task C 解围, 应该得到一点夸奖吧，但结果事后被manager揪着这个事儿一顿猛批，大概就是为什么无法自己判断好优先级？既然X组不是100% 的blocker, 为什么不push他们？作为老员工有自己own/drive项目的觉悟吗？
大概就是这样几次之后，我的心情一度变得非常糟糕，也对自己的能力和未来产生了怀疑，搞得我后续每天要花很多精力来消化情绪（这说明我的抗压能力一般吧）。所以我在想，manager真的有必要在task C 作出来的情况下，这么给我一顿怼吗？客观来讲，我觉得对项目进展并没有帮助。但是，转念一想，我是不是格局小了？Manager批评engineer是不是有更深层次的考虑的？或者这是什么管理学的方法论？

假如以后我当了manager，是不是也要经常这样批评一下员工，这样比较有利于管理？比如说，每次都鼓励夸奖或者心平气和说事儿会让低下员工觉得自己好说话，以后就不听你的了，或者不敲打一下员工真的不知道自己的错误在哪里？
请地里已经当了manager的朋友分享一下，你们是在什么情况下“怼” 手下engineer的？是不是敲打员工是某种项目管理的方法论？（我之前举的例子，可能带有主观偏见和自己的借口，大家辩证地看哈，我也愿意接受大伙儿新的批评。）

我觉得很关键的是manager也是人，希望manager把所有工作都做好（一切scope清晰，一切priority清晰，出了问题护着组里的人，技术可能还是个大牛）是不切实际的，能做好的早就到下一级了。说实话对mgr要求这么高就跟父母一定要托举自己一样，都是不太自立的人容易有的想法。
你到时候会有自己的风格的，而且不实操不会明白。

现在搞笑的地方就是，为什么要有这么多层的传话筒？ skip，pm，sdm，tl，一层传一层，信息最后都传错了或者根本就是误导。
核心会议都掖着藏着，然后经理突然给你一个cold call，啥context没有就让你估计eod，这不扯淡吗？ 再加上每天无穷无尽的meeting，还想让sde出活？ 也不知道各大公司狂吹的GenAI在哪里，这群吃干饭怎么还没被替代？

这种manager有毒，赶紧跳槽吧，项目优先级本来就是manager应该讲清楚的，每一个任务不都应该有明确的deadline嘛

作为一个有身份的人，我遇到这种情况一般会摆烂跳槽。
作为DP，我曾经被TL指出在划水，之后就马上摆烂跳槽。后来发展到M+TL+PM三个人都在单独跟我开会的时候直接指出过划水。后来没等到他们走开人流程，我自己找到下家了。
现在算回到正常干活的节奏吧。
我觉得经理最好还是看人下菜碟，没卡的，或者家里有房贷有小孩的好拿捏一些。没有负担，有本事跳槽，且脾气刚的就难。

补充内容 (2025-06-17 03:50 +08:00):
我当时坐在办公室，打开代码的界面，然后就打印一些llm的论文自己读着玩。我们做的也是llm，他们也说不出什么。

匿名用户 发表于 2025-6-16 12:39
这种manager有毒，赶紧跳槽吧，项目优先级本来就是manager应该讲清楚的

谢谢回复。manager的确也是讲过，这个C很重要，要尽快做出来。虽然没有明确说C比A， B更重要，一定要在某月某月之前做出来。客观来讲，我觉得这事儿他有一半儿以上的责任，但是他说“老员工要有自己own/drive 项目的能力和觉悟”似乎也是对的。。。

这个manager以前是隔壁组的同事，私下见面闲聊也很融洽，后来被调来我现在的组管着一摊。他估计比我还年轻一点儿，能感觉他当上manager后压力也挺大的。

匿名用户 发表于 2025-6-16 12:43
作为一个有身份的人，我遇到这种情况一般会摆烂跳槽。
作为DP，我曾经被TL指出在划水，之后就马上摆烂跳槽 ...

有道理啊。谢谢分享。

我就在思考假如我们当了manager，能心平气和地把团队管理明白吗？
还是说要做成项目就是得变成一个“坏人”？

我manager是我隔壁组同事，以前走廊里见到会笑呵呵地聊几句。他也抱怨过，自从他开始带队，他"lost all the friends in this org" LOL

所以我就在思考，这是项目管理的一种方法论模版，还是单纯他管理水平不行也控制不住情绪，单纯就是冲我宣泄脾气。。。

匿名用户 发表于 2025-6-16 13:01
现在搞笑的地方就是，为什么要有这么多层的传话筒？ skip，pm，sdm，tl，一层传一层，信息最后都传错了或者 ...

你这个角度赞啊。的确是一种传话筒机制！中间的manager应该可以跟下面的engineer有“leadership”最终想要什么的解释权。你做的东西，他暂时用不到，他会说这不是大老板想要的；如果他让你干什么你有疑问，他会说这就是大老板想要的。

这时得多人精的engineer才能每次精准判断出大老板想要啥LOL 如何体现自己own/drive 这个项目。。。（认真地讲，已经是manager的朋友，你们对手下员工own/drive一个项目的定义到底是什么？不是辩论，不是辩论，纯学习交流，之前我说的manager是个印度人不是老中）

Manager就是份工作，你觉得什么办法最合适你早早赶完摸鱼就怎么干，别的都是扯淡。

建议拒绝内耗，不要轻易自我怀疑。
但看你分享的例子可以看出mgr不算特别成熟（抓着小问题不放甚至放大问题来pua人），不过事情本身也只是miss alignment而已。

- 第一个无解，要么mgr成长，或者这次只是个例事件，他的处事风格不太会改变。不想走的话就忍着，少犯错。
- 第二个问题好解决，以后有任何urgent task问清楚deadline，和主动share tradeoff和timeline。