新手TL请教：是别人太奇葩还是我不会带人

楼上给了很多好的建议，学到不少~不过也有点理解LZ。有的时候做mentor 真的很难。最近在做coop manager，coop 进公司4 个月了还要教table join (真的只是两个table 怎么join 起来)。 想当年自己学基础的SQL概念 / command 也是一个下午就学会了，不理解为什么coop 4 个月了还要人教这个，也是把我搞得有点抓狂。大概每个人都有自己的生活吧，不是每个人都愿意工作时间外再自己补强。

你们以为在北美小时候小学初中开始就喜欢倒腾电脑装机的是大多数吗？

看起来确实这几个人很有问题，自命不凡，听不进TL的建议，因为过于自负所以固执己见。

somehow谷歌内部自命不凡的人特别多，我遇到过一个小年轻，学历很好，自认为智商特别高，瞧不上其他组员，偶尔帮助一下身边人他都觉得自己放下了身段。总感觉这样的人很有可能会是你说的这些组员的其中一款。

同时，楼主的描述也让我想到了我曾经还是萌新时的某一个TL。听别人说他挺有耐心，所以一开始进这个组时我还挺高兴。结果，高兴过了头，第一次跟这个TL聊新项目时语调没控制好/语调太嗨，直接导致我问的所有问题都让这个TL觉得我一直在质问他、怀疑他的专业性。于是令他很恼火，于是有了先入为主的坏印象，之后的几次meet中，对我说话的语气就不大和善，也正好这个项目是我没接触过的领域，我上手慢，更令他看我不爽，对我不耐烦，即使online meet他给我讲一个东西而我还没找到屏幕上他在讲哪一块时，他都以为我是没认真听他讲话/不想听他讲。第一次工作就遇到这么打击积极性的事情，让我再也不敢问问题，即使问，也会刻意把语气变得怯生生很卑微，以防TL又开始不爽。现在回想，在那个TL眼里，我一开始是不是也是楼主描述的某个听不进建议又什么都不会的组员呢？

匿名用户 发表于 2022-8-20 11:47
看起来确实这几个人很有问题，自命不凡，听不进TL的建议，因为过于自负所以固执己见。

somehow谷歌内部 ...

我带过的几个mentor也刚来时候给我过非常没有礼貌的印象。帮ta从来不说谢谢之类的。
但是多交流之后就消除了误会。
communication真的太重要了。

让C带A, B, D。大饼，高帽子给C画上/戴上。

你确保你自己的delivery progress和处理好和C的关系，别在A,B,D上浪费时间。

微信用户_de75404 发表于 2022-8-20 04:49
能兼容烂人本来就是manager和TL的能力体现吧 人人都是self-driven big scope卷王还要TL干嘛 直接投票直接民 ...

“你越是能carry或者manage out烂人 说明你越牛逼”

能manage out烂人是牛逼的，我同意。
但能carray，这算是个啥道理呀，正是因为是烂人没法carry了吧

怎么说呢，你如果把带人的工作，跟你平时优化某个计算机系统的工作对比一下，你就知道为啥你不会带人了

组员A：某个EC2 instance一直latency极差，本来一个小时该跑完，日常fail一半，成功的时候也得跑10个小时。你的解决方法：不停的retry，设置越来越严格的SLA，指望哪天这个instance跟奇迹一样突然变的高效，结果越跑越慢。这不废话吗，不停的retry， 哪天cpu都给你搞崩了。
point：你知道不知道起码要dive deep一下，时间都浪费在哪了？这个task适合不适合这个instance？是不是拿本来该拿gpu跑的用cpu跑了？有没有别的task在占用资源？管理好你自己的预期，对症下药，找到这个机器擅长的task。

组员B：你是个老c++程序员，你打算用python写个某个latency要求极高的real time job（打个比方啊，没有黑的意思），结果发现python下面每个函数都不effcient，写的都不对，一堆库design的在你看来很有病，比如GIL这种，连真正的multi threading都不支持。于是你疑惑，怎么这么popular的语言，有的地方design的还没一个初学c++的人写的effcient？
于是你的结论：哎python这语言太菜了，design这语言的人连我的水平一半都不如，写的程序慢的要死，memory也用的贼多，跟python开发者交流了半天人家也不怎么理解你。
point：c++和python设计的底层思路，着重点就不同。你和这个B也是一样。所以就是你对标准放宽一点，甭管人代码小的细节和design的思路，as long as不出大的问题，程序不会直接崩了就行，记得你只提建议和要求，别管python具体怎么实现。或者就是你努力理解python的思路，理解了以后想办法把这机器上装的python卸了，装上c++。

组员C：我都懒得吐槽了，只能推荐你多换位思考一下，想想如果C知道了你的想法他会怎么想，再想想如果你换个想法呢？你也许会说，那可以让C不知道啊？我只能说，就你这个性格，基本上你的态度就差写个大字报贴墙上了。。

组员D：某个老系统你们一直用的内部自己的build系统，突然某一天有个外面的公司/外组推荐你们切换成他们的tool，老板还挺感兴趣的。但是结果外面的新tool bug很多，结果你还得额外花时间修。外面的新tool还一副都是你不支持的态度导致这东西不好使。
point：这种情况本来就不太好处理。无论如何，先relax一下你的态度。你首先得明白，新东西大概率会出问题，不出问题是不正常的。实在是出问题了，本着公心，这东西到底有没有potential？哪些问题是小问题，哪些问题是大问题？最重要的是，外面的人维护不好tool，小问题都出错，那你就不能把这个tool（D的思路）拿过来，你自己来弄？这不就最后credit都是你的。。再或者说，这东西就完全不靠谱，一开始就不该switch的，那你着急啥，尽量别去管这个tool设计的事儿，躲远点，等这个tool烦到的人够多，那么自然最后大家的共识是switch back。。

dudongtai2002 发表于 2022-08-20 14:13:23
怎么说呢，你如果把带人的工作，跟你平时优化某个计算机系统的工作对比一下，你就知道为啥你不会带人了

组员A：某个EC2 instance一直latency极差，本来一个小时该跑完，日常fail一半

感谢感谢！感觉一下子清晰了好多！🙏太形象了哈哈哈
组员A：确实这台机器上其他task占用的resource太多了，manager和我给他的perf expectation是80%在这个项目上，但是没用cgroup，另一个task时不时oom一下

组员B：应该少扣细节，尤其code quality这些，说实话项目能按时launch，代码不至于差到难以维护就好；我原来走的就是强行想让python变成c++，最后搞出了个cython🐶 B的code和design大方向都有问题，这时候显然没法一起抓，有时候我自己抓多了都觉得constructive feedback过多，小问题多鼓励，重点抓design就好

组员C：感谢拍醒，我原来报着不让他发现的心思…想想就我这性格+他的阅历怎么可能没有察觉，心底里明明知道自己这心态不对，得从根本上调整一下

组员D：emmm这位确实是没啥救，组里所有人都看得出来他在瞎说，我之前一直以为他还有救，结果入坑出不来…现在只想像你说的一样，离他越远越好，全都帮他cover了他的事情也没关系，但是问题是老板还让他在这个事情里混着，因为给他找不到他能做的其他活🤷‍♂️ 不过终于有点盼头了，这个项目之后就把他转到别人那里了

总结一下学到的：
1. 心胸要宽广，从内因调整自己（C，B）
2. 分清主次抓重点（B）
3. 对low performer，不管是客观原因（A的bandwidth）还是个人原因（D），及时认清之后不要犹豫

匿名用户 发表于 2022-08-19 23:36:37
楼主提到c哥soft skill强，试着让c和一个你觉得difficult的人合作？没准人家有奇招可以学习一下

有道理，我让C去催过A一回，2周以内催成功了，改天讨教一下他是怎么做的

denistek 发表于 2022-08-20 04:26:52
楼主确实不会带人，没有leadership，情商有待提高。带手下就如养孩子一样，要一天到晚逮着他们做对的地方很劲夸，不要在烂人烂事上过多浪费自己的精力和情感。关键是要营造一个组里轻松快乐，大家共同进步

感谢建议！其实道理都懂，就是感觉很难😭这样是不是只能多实践多提高？

> 多夸奖，营造轻松的氛围
我试过B做出来一点事情就夸他（楼主情商低情绪挂脸，特意text夸他lol），但是还是觉得好生硬，自己憋了十分钟修修改改text message，夸完之后感觉过于艰难，接下来就好久缩在comfort zone里没法夸他…回想一下我夸C和其他人，包括主动在1:1的时候跟manager夸E做的特别好，都没什么压力；所以low performer也要夸吗？

> share credit把蛋糕做大
嗯嗯我主贴也提到了，觉得这才是正确的mindset。现在有concern主要因为我们同级别，组里大家包括C的yoe比我长好几倍，但是5升6 mentor 5也是必经之路，我也确实是design和build early cross team relationship的人，请问层主经历这一步的时候是怎么做到既保持credit又开心相处的？

> 让手下senior manage烂人
可以的，像楼上说的一样，C soft skill强，但是是半新人没有带人机会，可以给C来带，可能比我带的好