受不了了!是leader都管得这么细么???

简介: 据说,每一个设计师背后,都有无数个指点江山的神。

作为员工,你是否有过这样的感受:

leader对自己很不放心,很多细节都盯得太紧,感觉老板不信任自己

leader把架构都设计,数据库,流程,接口都设计好了,自己只是做实现,感觉很没有成就感

leader都不怎么管,压力好大,很多事情不知道怎么做

画外音:员工想,什么时候能当上leader呀,还是指挥别人好。

作为leader,你是否有过这样的感受:

明明很简单,怎么教都不会,还不如自己来

帮下属都安排好了,执行总是出问题

想给下属一些空间,每次交付都搞砸

画外音:leader想,带队伍太累了,还是做好自己的事情轻松,把我撤回去得了。

以上种种情况,都是“授权”的问题,对于新晋管理者,关于授权,这四点一定要注意。

一、思路的转变

很多leader,都是从团队专家提拔而来,ta们在自己熟悉和擅长的领域得心应手。

升级为leader之后,仍然保有原来做事的方式与思路,沉浸在细节里,继续做自己擅长的事情能够“让自己感觉良好”。

这个时候,leader应该将自己的目标,团队的目标,分解转化为下属的目标,完成由“亲自动手”到“指导教练”的转变。

二、口令的转变

回顾一下,作为团队一线专家时,是怎么沟通项目或架构设计的:

  1. 这个地方,做了xx设计,以实现高可用;
  2. 这个地方,做了xx方案,以实现高并发;
  3. 这个地方,先xx,再oo,以保证一致性;
  4. 有几个同学在做后端接口,有几个同学在做页面,哪一天联调,哪一天能交付;

5…

作为一线员工,更多说的是做什么(what),怎么做(how),作为leader的时候,就不能总这么和员工下达口令了。

leader,应该更多的说明:

  1. 为什么要做(why);
  2. 目标是什么(goal);
  3. 交付的时间是什么(when);
  4. 好的交付标准是什么(criteria);

然后,给员工以授权,给员工以挑战,充分发挥员工的主观能动性,并在ta遇到风险和困境时,站出来指导他和支持ta。

画外音:有时候不是leader管得细,是口令下达不对。

三、根据员工的类型做授权管理

作为leader,和员工说清楚原委,目标,标准,交付时间之后,要做的就是授权员工,然后拿到结果。

有些leader又反馈了,“我充分授权了呀,但到交付日期时,员工搞砸了,我还得背锅”。

所谓的授权管理,不是简单的放任员工去做而不管,而是要针对不同的员工类型,做不同的管理动作。

在授权管理这一块,员工通常根据能力和意愿会分为四类:

员工能力强意愿低,此时的管理动作是:和员工沟通,找到动力,并做潜在的内在外在激励动作,比如:达成目标时嘉奖

员工能力弱意愿高,此时的管理动作是:安排高阶能力强的员工对其进行指导

员工能力强意愿强,此时的管理动作是:未来应该让员工承担更多责任,并让ta更多的参与到决策中来

员工能力弱意愿弱,此时的管理动作是:辞退

四、授权不授责

权责这一块,很多人的观点并不能达成一致。

有些人认为,应该“权责合一”,既然交给你的事情,你就得想办法做好,做不好就是你的问题。

个人旗帜鲜明的认为,在授权下属这一件事情上,授权不授责,是一个有担当的leader必须具备的品质。

画外音:我分享自己认为正确的观点,欢迎探讨。

leader的工作,确实是把团队的目标,自己的目标转化和分解为下属的目标,授权leader放手去干。但出了问题,没有拿到结果,不也是因为leader自己:

没有及时check和review

没有给与协助,提供资源与解决方案

看错了人

么?

不要让下属背负太大压力,和下属建立良好的信任管理,疑人不用用人不疑,“授权不授责”都是最基础的。

犯了一次错,要勇于替下属承担责任,找到问题所在,帮助下属成长提升。不迁怒。

“不迁怒”的同时,也必须让下属“不贰过”,出过一次错,指出了问题所在,但同一个坑不能踩两次,下属不涨经验,则很有可能是态度出了问题,此时则需要严肃处理。

总结

新晋的管理者,想想自己身上有“管的太细,被下属嫌弃”的状况么,此时可能你需要:

  • 思路的转变:从亲自动手,到教练思维
  • 口令的转变:从传达what和how,转变为传达why/goal/when/criteria
  • 根据员工类型做不同的管理动作:

(1)能力强,意愿低:激励

(2)能力弱,意愿高:指导

(3)能力强,意愿强:赋予更多职责,让其参与决策

(4)能力弱,意愿低:淘汰

  • 有担当,授权不授责,不迁怒,不贰过

场景一

刚毕业那会,有个leader帮我做code review,读到一行时:

他给我下指令:dd

我说,啥?

他又重复了一遍,dd

我当时心底就团起了一股无名业火,别只让我删除一行,告诉我为什么。

场景二

每次路过设计团队,都能听到,雪白的Mac后面,不断的有人在指挥:

粗一点粗一点

深一点深一点

快一点快一点

...

我在想,被“指点”的设计师是什么感受?

据说,每一个设计师背后,都有无数个指点江山的神。

不迁怒,不贰过,共勉。

image.png

架构师之路-分享思路

目录
相关文章
|
4月前
|
消息中间件 缓存 算法
美团面试官让我聊聊kafka的副本同步机制,我忍不住哭了
美团面试官让我聊聊kafka的副本同步机制,我忍不住哭了
|
7月前
|
消息中间件 算法 容灾
7年工作经验面试被问:谈谈你对Kafka副本Leader选举原理的理解?
一位7年工作经验的小伙伴,面试被问到这样一道题,说:”谈谈你对Kafka副本Leader选举原理的理解“。当时,他想,这Kafka用的不就是Zookeeper 的选举吗?难道Kafka又自己搞了一套。没错,这回Kafka自己造了一个轮子。 那么今天,我给大家来聊一聊我对Kafka副本Leader选举原理的理解。
63 1
|
12月前
|
算法 Java 数据处理
不是我吓唬你,写不出这种代码,那就等着被leader开除吧
这种代码,对于我们自己练习编程或者解决一个算法题,当然没有问题。但是如果是在一个工程中,尤其是几十上百人维护了几年的工程中,还使用这种写法,倾泻自己天马行空的才华,保证leader不打死你哦。 所以,对于代码的整洁性,可读性,自古以来就有很多大神做出过总结,比如这本《clean code》,中文名叫做《代码整洁之道》,今天,我们就来看看吧。
|
消息中间件 存储 Kafka
关于MQ的几件小事(四)如何保证消息不丢失
介绍如何保证消息队列消息不丢失
关于MQ的几件小事(四)如何保证消息不丢失
|
消息中间件 分布式计算 监控
RabbitMQ 线上事故!慌的一批,脑袋一片空白
1.什么是kafka Kafka是分布式发布-订阅消息系统,它最初是由LinkedIn公司开发的,之后成为Apache项目的一部分,Kafka是一个分布式,可划分的,冗余备份的持久性的日志服务,它主要用于处理流式数据。 2.为什么要使用 kafka,为什么要使用消息队列 缓冲和削峰: 上游数据时有突发流量,下游可能扛不住,或者下游没有足够多的机器来保证冗余,kafka在中间可以起到一个缓冲的作用,把消息暂存在kafka中,下游服务就可以按照自己的节奏进行慢慢处理。 解耦和扩展性: 项目开始的时候,并不能确定具体需求。消息队列可以作为一个接口层,解耦重要的业务流程。只需要遵守约定,针对数据
165 0
RabbitMQ 线上事故!慌的一批,脑袋一片空白
|
NoSQL Java 程序员
面试官:Redis集群有哪些方式,Leader选举又是什么原理呢?
本文介绍Redis集群的方式和Leader选举的原理。
141 0
面试官:Redis集群有哪些方式,Leader选举又是什么原理呢?
|
Kubernetes Perl 容器
一个“看不见摸不着”的 Leader
记录了一次线上 volume provisioner 选举(LeaderElection)失败的问题,对问题进行了模拟场景复现
757 0
一个“看不见摸不着”的 Leader
|
算法
分布式系统的“脑裂”到底是个什么玩意?
分布式系统的“脑裂”到底是个什么玩意?
1696 0
分布式系统的“脑裂”到底是个什么玩意?
|
SQL 关系型数据库 MySQL
《叶问》38期,MGR整个集群挂掉后,如何才能自动选主,不用手动干预
《叶问》38期,MGR整个集群挂掉后,如何才能自动选主,不用手动干预
325 0
|
机器学习/深度学习 弹性计算 运维
为什么这个92年的小哥从实习生到P8级技术Leader只用了6年
那个92年生的少年,如何从实习生成长为阿里P8级技术Leader.......
4334 0
为什么这个92年的小哥从实习生到P8级技术Leader只用了6年