04 | 如何帮助团队成员成长

大家留言都好用心，感动之余，也让我学习了很多。感谢大家！

从我自身出发讲讲我遇到的管理坑： 1.盲目自大，任何事情亲力亲为，造成结果是：项目推进缓慢，问题百出，团队成员懒散、懈怠，自己累得半死 2.不会正向鼓励，老看到别人错误，不会帮助团队成员找出错误原因，导致大家都很怨恨我，团度气氛很坏。一味通过换人解决问题，只会使问题更糟 3.团队成员有负面情绪不会引导，导致造成更大的严重后果 4.对团队成员不坦诚，只说好的，不说坏的事情，导致团队成员有点功劳都沾沾自喜 5.不会关心团队同事，不能取得他们信任，他们为什么会舍得付出？ 6.一直错误认为物质奖励能激励同事，但是物质只是短暂的，有可能带来负激励，所以物质激励是把双刃剑，用不好会变成负能量堪称：赔了夫人又折兵 啊 7.过份依赖KPI，导致所有成员养成大公司病（缺乏创新和内驱力）其实对于初创团队更应该看中员工自身纵向水平提升（自己跟自己比），还有就是团队协同能力（帮助更多同事能力） 当然这些都是从业多年所犯的错误，希望大家引以为戒，不要再踩一遍坑。

从业10年，工程师-技术经理-工程师的路线，现在更多的体会到管理和coding工作的不同、管理者和下属心态的不同。做工程师的时候，得到最大的帮助：1. 领导的认可；2. 从领导上学到的分析问题的视角和方法。因此自己作为管理者时，也非常注意这两点。自己做管理者时，迅速克服掉安姐那种“万事自己上”的心态的方法是：更多的把自己和手下看作合伙，看到自己其他的长处和价值，经常问自己团队为什么需要我这个不coding的人。因为coding其他人也会，因此需要自己在指方向、搭架构、思考问题方式上多提供价值。开始也会有焦虑，毕竟放弃自己专长、靠团队生存，有些担心。但看到自己能够在其他方面提供价值，也很高兴。当然，身处知识结构更新换代极快的行业，危机感还是很强，技术也没有放下，这是我又能在爱airbnb中国做回工程师的原因。现在也多了一份换位思考。

“如果你是一个管理者，你做过哪些举措帮助自己的团队成员成长呢，而你又得到过哪些上级的帮助呢？” 去年，我也是一线工程师，每天在实现需求中度过。后来公司规模扩大了，人员增多了，也许是因为在本职工作以外沟通还可以，所以就被推上了半管理岗位，今年的话基本上管理工作占了大头，但是还是在写代码。 我能深切的体会到大部分的工程师们对自我成长这块还是十分关心的。除了金钱以外，大家更关心的是干的开不开心，个人有没有成长。如果大家在一起工作，能通过工作得到个人的成长，大家的神态表情都会变成那种亢奋的状态，会有一种满足感。 所以今年下半年以来，我把团队成员的成长作为了工作中一个非常重要的部分，开始推进团队的每周分享。这几年我更多的是一个组织者的身份，去组织协调分享会，找到大家真正需要和感兴趣的知识和技能点。最开始的时候可能形式感比较强，更多的是为了分享而分享，和实际的工作交集不够多，现在更多的是从工作出发去寻找分享点，这样大家对分享的内容都有一些基本的认识，也容易产生共鸣。 总之我觉得分享有一个基本原则，要让讲的人得到锻炼，要让听的人获得收获。两者具备是最好的结果。 后续的话会推进 Code Review(CR) 。这也是安姐在公号中强调的一点。作为一线工程师，CR 应该是能够最直接快速提高工程师能力的一种手段，期望能够有好的结果反馈，也希望安姐后续可以深入讲讲。 除了这些，最主要的还是需要经常和团队成员沟通，听听他们内心的真正想法，了解他们的刚需。 最后，最近看到有句话挺好，分享在这里： Before you are a leader, success is all about growing yourself. When you become a leader, success is all about growing others. (在你成为领导者之前，成功的全部都是自我成长。 当你当了领导者，成功的全部就变成帮助他人成长。)

在下一个级别稳定半年以上才可以提升。 我曾大力培训员工技能，员工能力提升就要求更高的薪水，被公司拒绝然后离职。

一对一的沟通，让下属吐露心声，想成长的方向等，一起制定季度OKR，并定期的review。 在作出成绩时，一起带大家吃饭喝酒，酒过三巡会聊的比较开，充分认识真实的大家。

晋升是个后验机制，你必须在下一级别上稳定表现了半年到一年。 这一点深表赞同。所以聪明人需要的是机会。

下属是扶不起的阿斗，怎么办

原来是这个道理。不是觉得你可以达到下一个级别的标准就提升你，而是你已经达到下一个级别的标准，并在这个水准上稳定地保持了一段时间，才会被提升。

有些时候必须要忍住自己去介入去管的冲动，只是要做好观察，私下里辅助好下属就好。有时候又必须跟进去跟的很细致，每个环节都不能有差池。到底用哪种，得看Case，也得不断揣摩才行：）