|
|
# 41 | 冷静下来想想，员工离职这事真能“防得住”吗？
|
|
|
|
|
|
本周主要和你分享几个关于个人成长的话题。前面我们讨论了在新时期运维如何做好转型，运维是不是要懂产品和运营这两个内容，都是为了我们能够成长为技术骨干，最大限度地发挥出自己岗位的价值。
|
|
|
|
|
|
今天我们就往后聊一聊，当你从技术岗位转换到管理岗后，应该如何适应新的角色，做好技术管理。技术管理这个话题很大，不是一下子就能说透彻的。所以，我就把处理员工离职问题做为一个切入点，从这个角度说起。
|
|
|
|
|
|
## 从员工离职说起
|
|
|
|
|
|
年末年初，对于任何一家公司或者一个团队来说，最令人头疼的事情就是员工离职问题，特别是骨干员工的离职，对团队带来的影响和损失，以及团队氛围和信心上的影响是非常大的。
|
|
|
|
|
|
其实从员工离职这件事情上，我们还是能够反推出一些在日常管理中的问题，甚至是我们作为技术管理者自身存在的问题。同时，我们还应该从这件事情上找出我们的改进措施，不断提升我们的技术管理和团队建设能力。
|
|
|
|
|
|
**Design For Failure的软件架构设计理念，同样也适用于技术管理工作**。
|
|
|
|
|
|
因为我在EGO会员组（极客邦旗下高级技术管理者社群）专门分享过类似观点，引发了一些讨论。所以今天借着这个问题，详细分享下我在这方面的一些经历和感受，同时我也会给出一些技术管理中的反模式，这些是需要我们引以为戒的。
|
|
|
|
|
|
## 关于员工离职的两个观点
|
|
|
|
|
|
我先给出对于离职的**第一个观点**：**对于离职这个事情，本质上就是员工个人发展和团队发展不匹配之间的矛盾**。
|
|
|
|
|
|
稍微解读一下就是，如果员工个人发展速度很快，而团队提供的空间或机会不足，员工就会调岗甚至离职，寻求更好的利于个人发展的机会；而如果公司和团队发展很快，员工跟不上组织发展的节奏，这种情况极有可能就会被团队淘汰。
|
|
|
|
|
|
反观其它的理由，主管因素、薪酬福利，或者因为世界太大想去看看等等，这些都只能算是表面上的直接因素，或者叫导火索因素。
|
|
|
|
|
|
比如，我们现在经常说的，员工离职最主要的因素之一是与主管不合。如果我们仔细想想，根本上还是因为主管在目标方向上与员工个人诉求达不成一致，或者管理方式上限制了员工个人发展，所以员工选择离开，或者团队主动淘汰，本质上的原因还是离不开发展这个诉求。
|
|
|
|
|
|
但是，有时候员工对于个人成长的不满意和不顺心，无法客观理性地表达，最终就都归因到主管身上；当然作为主管，有时候不考虑员工感受和自身因素，就简单粗暴地进行管理，也不是没有问题。所以看问题要全面，我相信更多的情况是因为双方性格和风格上对不上，并没有什么是非对错，所以一切看开最好。
|
|
|
|
|
|
接着彼此间发展诉求的矛盾这个问题，我再给出**第二个观点**：**对于员工离职，从管理者角度，我们应该理解为必然结果，坦然接受，而不是避而不谈**。
|
|
|
|
|
|
每个人在不同阶段，总会有不同的成长和发展诉求，所以总会有一部分员工在一家公司待到一定年限之后，会为了寻求更加适合自己的机会而离开，因为员工和公司之间的发展不可能始终保持匹配，所以从这个角度来讲，员工个体上的离职是一个正常现象，也是必然结果。
|
|
|
|
|
|
上面这个观点来自于领英CEO里德·霍夫曼写的《联盟》这本书，这里结合我自己的感受和理解谈一下我个人的看法。
|
|
|
|
|
|
如果能意识到是必然结果，那我们要做的就是 **Design For Failure**，**不要试图去完全避免和杜绝离职，而是要有措施能够有效规避离职带来的问题和风险**。也许**最大的问题在于，道理我们都懂，但是能做到的不多**。
|
|
|
|
|
|
所以，下面就来谈谈应该如何做好技术管理。
|
|
|
|
|
|
## 谈谈如何做好技术管理
|
|
|
|
|
|
**1\. 帮助员工做好个人中长期发展目标规划**
|
|
|
|
|
|
主管应该跟员工一起确认员工任期内的中长期成长和发展目标，让员工能够在任期内发挥最大的作用和价值，同时能够尽可能地让员工在任期内达成自己期望的成长目标。对管理者来说有一件很重要的事情，就是能够找到团队发展和员工个人发展相契合的价值点。
|
|
|
|
|
|
**这里很重要的一点，做技术管理者，一定要从关注事情、管理事情转换到关注人的层面。要关注人的成长发展，关注成长发展中的问题和疑惑，关怀人的工作体验和心理感受，这个才是管理的核心。一定不要忽略人这个核心要素，人的事情搞不定，其它任何事情都无从谈起**。
|
|
|
|
|
|
我们很多管理者当前是缺失帮助员工做中长期个人成长这件事情的，更多的是做眼前工作的任务指派，甚至是指令性下达。所以现在很多员工离职，都会提看不到发展目标，看不到空间等等。这里的关键还是上面说的管理工作缺失，大多是我们没有帮员工做，而不是真的没有空间了。
|
|
|
|
|
|
这个事情要放到平时做，从团队人数还不多的时候就开始。我的团队30多人，基本每个月都和团队的每一个人做一次一对一沟通。如果实在忙不过来，那就针对核心骨干和有潜力的员工。这个沟通要持续做，并持续调整。如果放到员工要离职了再做，再去承诺，就没有意义了。
|
|
|
|
|
|
**2\. 进行梯队建设**
|
|
|
|
|
|
各层管理者和HRBP，要有意识做好梯队建设，确保人才能够源源不断地输入。如有有员工离职能够有人顶上来，至少是有Backup，不至于因为一两个人离职团队就垮掉了。这块就涉及到招聘和“传帮带”机制的建立。
|
|
|
|
|
|
**团队成员不一定都是水平很高、能力很强的人，关键是要合适，能形成合力**。所以团队中既要有经验丰富和技能突出的明星员工，又要有发展诉求强烈的骨干员工，还得要有对各种事情充满激情和新鲜感的小鲜肉。每个梯队的特点和风格不一样，形成互补，发挥各自独特的价值，这样的团队才能够有生命力。
|
|
|
|
|
|
**3\. 提升管理意识**
|
|
|
|
|
|
我也是从技术转技术管理，说实话栽了很多跟头，吃了很多亏，才慢慢有所转变，这个过程比较漫长。所以，对于刚做技术管理者的员工，HR团队一定要辅助做好“转身”的培训和赋能，不然就得吃“一将无能，累死千军”的亏。
|
|
|
|
|
|
同时，在这个事情上，更高级主管层面也应该要有些耐心，甚至有些时候要容许一些管理上的失误，不至于一出问题就一竿子打死。因为管理这个事情很多时候是需要管理者个人从一件件事情，甚至是一个个跟头中，一点点去“悟”到的。
|
|
|
|
|
|
## 技术管理中引以为戒的一些反模式
|
|
|
|
|
|
上面讲了做技术管理应该重点做哪些事情，那下面再说说应该少做甚至不做哪些事。
|
|
|
|
|
|
**1\. 事必躬亲，不懂授权，不敢授权**
|
|
|
|
|
|
最常见的情况就是所有事情都会参与、过问甚至是干涉，更甚者，因为自己做更快，就懒得指导员工，直接亲自上手做。这样下去，久而久之，就相当于剥夺了员工成长的机会，剥夺了员工独立思考的机会。
|
|
|
|
|
|
我的建议是，对于非紧急的事情，还是让员工自己动手完成。你可以指导，可以给建议，但是不要代替员工执行和思考。
|
|
|
|
|
|
**2\. 总认为自己才是最正确的**
|
|
|
|
|
|
懂得授权和分配工作后，往往把自己的想法和经验强加于员工，因为总觉得自己的经验才是最好的，即使思路上和方式方法上仅有一点点不同，也要跟员工争个是非对错。长久下去，员工的主观能动性就没有了，不但容易失去与员工之间的信任，还极容易造成与员工之间的矛盾。
|
|
|
|
|
|
我的建议跟上条相似，可以更多地给员工授权，多从边界条件和目标结果上提问，让员工主动思考。如果员工的方案是可以达成目标的，就可以放手让员工去做，过程中关注进展和风险，多给辅导和建议。
|
|
|
|
|
|
**3\. 仅仅关注技术层面，忽略全局**
|
|
|
|
|
|
因为技术管理者大多是从技术岗位上成长起来的，有时看问题难免会片面。典型的一个问题就是只关注技术层面，不看全局。比如外部的需求澄清、进度要求、服务支持等，这些都是非技术层面的，恰恰可能也是一线员工所不擅长的，所以更需要技术管理者来关注。
|
|
|
|
|
|
我的建议，技术管理者一定要先关注全局，然后再看细节。对于管理者的要求，更多的是要“**做成事情**”，而不再是技术骨干阶段的“**做事情**”。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
最后，我们来总结一下。
|
|
|
|
|
|
对于离职想表达的两个观点：
|
|
|
|
|
|
* 员工离职反应了个人发展与团队发展之间的矛盾；
|
|
|
* 员工离职是个必然结果，坦然接受，做出应对，而不是谈之色变，或避而不谈。
|
|
|
|
|
|
对于技术管理，这其实是个很大的话题，今天我们提炼一个重点：
|
|
|
|
|
|
* 技术管理者，一定要重点关注人，而不仅仅是事情。这一点是做技术骨干和技术管理者之间的最大差别，也是转变思路的第一步。
|
|
|
|
|
|
在技术管理上，你还有什么疑问，欢迎留言与我沟通讨论。
|
|
|
|
|
|
这里推荐一下我们隔壁的专栏《**朱赟的技术管理课**》，我订购后阅读了很多文章，产生了很强的共鸣，同时也收获到一些硅谷技术公司的先进管理经验，很有帮助。
|
|
|
|
|
|
如果今天的内容对你有帮助，也欢迎你分享给身边的朋友，我们下期见！
|
|
|
|