yexiaochai

原创不易,求分享、求一键三连

其实不算是投诉啦,更多是建议。

第一次离职,团队是被解散的,组内有个老油子不停给我灌输全部是Leader无能造成的,并且怂恿我离职的时候写封邮件,年少轻狂,离职的时候真的写了一封部门邮件......

工作几年成熟后,才发现团队解散其实是多方面因素造成的,Leader只占一小部分,不应该对他过于苛责。

在工作场景中,有小概率离职员工会跨级给Leader发邮件暴露一些问题,我上周刚好就遇见了...

一个离职同学给老板发了一封邮件,老板随后转给我了,大概内容是:

老板好,我是运维部XXX,主动离职,今天是我的lastday,感激这一年间,公司让我有机会用自己的领域能力在本职工作上为公司的愿景做出一点点的贡献。在职期间感受到了很多积极行为,比如量化的OKR、年终的吐槽节目、全公司层面的微创新,产品研究结论权威发布,甚至要求公司会议必须视频在线等。

站在交付价值,让事情变得更好的目的上;站在自己狭隘的认知和职位上,做出如下可能并不公正也不客观的回应和离职反馈。

公司、团队有太多太多好的优点和优秀的品质,但我感受到了一个缺点,团队“领导者”的缺失,导致了IT从一个本来应该用IT能力来支撑业务的决策者,变了一个执行不到位的执行者,具体包括:

  1. 立场的偏离,员工目标与公司目标对立,负能量重;
  2. 领域能力的不足,并不能站在一个专业技术角度去理解问题;
  3. 管理能力的缺失,并不是端到端的考虑,人,职能,工作流,协同方式之间闭环逻辑,更多只关注到了“做”这个具体的事情;
  4. 缺少投入,空头支票,无效的承诺,或是根本就关心,事情口头、上面上答应,但却并没有能力去做到;
  5. 缺少信任,没人愿意去表达;
  6. 小小的傲慢;

leader角色的缺失,可能导致了我现在的感受:这个不是一个团队,而是“聚集在一起的人”,表示出来形式可能就是:

  1. 形式主义,数据不好看就关注怎么让数据好看;
  2. 公司说每人应该要去听产品会,那我们就签到走人;
  3. 很多应该怼事情的讨论会,开成了表彰会;
  4. 做事做一半,技术重构本来能解决未来2,3年it成本和快速高质量交付问题,结果做了一半,导致事情更复杂,对上没结果;
  5. 缺少领域能力,看事情可能只看开始不看全局,比如人力外包,只考虑了外包人员如何登录,至于外包质量如何控制,效率如何管理,安全如何保障,公司其他部门如何协同,就不用去考虑拉,最后结果大概率是IT投了人,系统不用或是没什么卵用;
  6. 不考虑成本,更不会关注有价值的结果,只管做,加班加点做,至于ROI是不是真的高,是不是真的有用,好像没人太关心;

这样的问题可能在任何公司都有,但公司依然是个好公司,比较大的问题可能是看不到希望(可能有些小小的傲慢)。看不到为此在用心,用力,把事情引导向好的方向。

站在一个运维的职位上,想到的一些狭隘的建议:

  1. 把IT从执行变成决策参与者,让IT用领域能力去支撑公司业务。阿里云的人特别希望能有一次机会来北京给您当面汇报下,作为阿里云,他们是如何用云的能力去推动业务发展以及他们从数据维度如何看到行业的;
  2. 适当的放弃一些无效或是错误的量化指标,从定量到定性,减少一些无效的浪费和可能导致错误的引导;

事实上,该同学的出发点是好的,真的就是想提一些意见,暴露一些问题,但他的归因跟我第一份工作一样,做的很糟糕,认真读下来感觉彼此认知差异巨大,于是便给他写了一个回复:

同学你好,很高兴你对团队表达的问题,面对你所提问题我觉得还是有必要作下回答。

首先我个人认为你所描述确实是开发部某个期间的状态,公司其他部门或多或少都有这些现象。

但我当然不认为这是领导力的缺失,或者Leader的缺失,事实上其根本原因是开发部暂时的真空期,缺失一条主线,乃至是行业困境下公司战略调整导致的主驱动力暂时还不足以带动整个车队,而我们公司只是大环境下的一员,虽然不好,但并不很差。

增长放缓导致了内卷,最终导致了矛盾扩大,这个应该是根因。而什么导致了增长放缓,这个与疫情、互联网寒冬、公司严肃的战略选择,再到进一步的HC紧缩、费用收拢、团队合并等等都不无关系。

所以,开发部状态差只是多种原因交迫的暂时结果,其中的领导力占比真不大

增长放缓是结果,团队力求创新是当前的策略,不断的同步战略信息是表现,这也是你为什么看到了《公司微创新》、《产品研究结论权威发布》、《创作吧》等等战略信息透传的节目在不断发生的原因。

但学习是反人性的,团队提供的是信息传导工具,OKR提供的是上升通道工具,而这并不能保证每个人一定能进步,事实上我认为公司能有20%乃至30%的人脱颖而出就很不错了。

当然,具体到实施层面,我们依旧想要更多人参与,所以会要求Leader强制上线,但类似“签到走人”的情况是不可避免,甚至是正常情况。

另一个方面开发部一直是有CaseStudy复盘机制,用来以“怼”求进,所以团队是自省的,公司层面的复盘也在推进,但机制推行都是系统性工程,很难一蹴而就,里面存在认知博弈时机权衡,过于激进的推进很可能机制沦为噪音,最后反而造成更大的浪费。

最后说回Leader的缺失这个话题,每个Leader处理问题的选择是不一样的:

  1. 有些Leader确实喜欢处理事情层面的问题;
  2. 有些Leader会尝试用机制去解决问题;
  3. 有些Leader更希望由资源层面解决问题;

具体表现就是一些Leader喜欢跟员工打成一片,一些Leader张口规则闭口制度,一些Leader喜欢盘资源盘钱。

比如你描述的技术重构本来能解决未来2,3年it成本和快速高质量交付问题,结果做了一半,导致事情更复杂,对上没结果

这个就是一个ROI问题了,我也知道全局系统年久失修难以维护了,但是他的背景是行业寒冬、团队合并、预算紧缩、技术栈不同这些困难叠加的情况,如果依旧要推行重构,那就是花1000w要买什么东西的问题,理智的人不会把资源放到重构上。

所以,这依旧是个资源问题或者说资源投入问题,不是团队不想把资源往这里投入,而是确实暂时没有那么多资源。

再比如说外包,那真的是迫不得已并且不得不为啊,其中苦楚不足为外人道也,但这些都是过度状态而已。

然后,感谢你的建议,技术变成决策参与者,这也是我们想要努力的方向,但阿里云的人我见了很多次了,你可以认为他们更多是从事“商务活动”,毕竟大环境不好,商务活动只会更频繁,并且公司的主方向是腾讯云;

最后,没有指标就没有方向,无效的指标和错误的指标,也是一步步试出来的,这个场景要拉到公司角度,那么多部门,都要不停的试数据,调模型,才能最终走向科学。

​后来跟该同学还有一些其他方面的讨论,但都感觉聊得有些空,不在一个频道,就不再贴出来,但其中他一个观点倒是引起了我的思考:

技术部门为何从一个决策者沦为了执行者?

为此首先问了自己几个问题:

  • 什么是决策者

决策者是告诉团队接下来做什么的人,并且这个预测是正确的。

  • 第二个问题,技术部门应该是决策者吗?

技术部门当然不应该是决策者,至少暂时不是,将来某个时间段可能是,但长期来说,在我们的业务场景下不会是。

  • 第三个问题:不是决策者有问题吗?

财务是决策者吗、人力是决策者吗、法务是决策者吗、品牌是决策者吗、***事务部是决策者吗?

并不是谁都应该是决策者,在合适的角色做好正确的事情,就已经是一件很酷的事了,一个决策需要很多核心支持者。

所以技术部门在多数时候其实不适合做决策者,技术驱动的公司一般是阿里云、神策、声网,这种纯技术服务驱动的公司。甚至外包公司都不是技术驱动的,他们可能是商务驱动的,我们对自己的社会角色分工要有一定理解。

最后,作为Leader大概率都会收到这种离职“告白”,其中有好有坏,有建议也有投诉,大家不要把他当一回事,也不要把他不当一回事,对于很多暂时不能解决问题的要提前向上预警,要有本质的认识和系统的解决方案,有认知、有方案,如果你只是认为是暂时性,过度性的困境,那么面对突发投诉问题就不会慌了。

好了,今天的分享就到这,喜欢的同学可以四连支持:

想要更多交流可以加我微信: 

分类:

技术点:

相关文章: