管理中第一可怕之事(3)
来源:互联网 发布:2016年四川统计局数据 编辑:程序博客网 时间:2024/06/10 08:52
假设说一个人是个项目经理或部门经理,并一下子扎到了一个执行力不好的环境中,那么这个人能干点什么或者说应该干点什么?
大多时候中层的人并不能左右高层的性格乃至种种选择,所以如果真有让人绝望的事情,又没有忍耐的的能力那就只能换个地方。
这很简单,并不值得多谈,我们主要要关注的是事情积极的一面,即如何扭转这种局面。
为了有所改善,第一关键的事情是要足够真诚。
工程师组成的团队中其实并不需要很多政治,大多时候,大多事情是可以谈,并谈出以逻辑和事实为根据的最佳答案的。
中层和工程师间的隔阂大多时候起于一些很简单的原因,如:
工程师更贴近现场,如果中层总是把自己的位置摆的很高,喜欢居高临下,那么工程师会觉的这个中层很白痴(当然大多时候不会直接说)。
中层接了高层的要求,回来也没啥办法,只能强制实施,但很可能这和事实违背,也和大家的意愿违背,进而累积矛盾。
比如:通过CMMI,导入量化管理这种事情。
中层并不能随心所欲的做事情这点很基本,但往往会混杂在事情中,进而被漠视掉。
当中层贯彻高层的要求时,其实他也只是一个执行者,并没有选择空间。
这时候中层需要做的事情是代表团队在决定出来前发出声音,而不单是做单方向的传声筒。
一旦决定出来后,作为中层可以跟大家讲自身的观点是赞同或反对,但行动上就只能是执行了。
如果上述这些都很坦诚的在团队中进行交流,大多数人是会理解中层并不能左右所有事情的走向的。
它既没这个权利,也没这个责任否则就就不是中层了。
误解往往产生在,工程师只看到中层,所以一旦缺乏交流,就会认为所有事情的责任都在中层身上。
因此,上述这类场景下,中层需要的是真诚,充分交流,并把自己切换为工程师的视角。
要尽量让大家明白,那些责任是属于中层的,那些中层也只是扮演一个执行者。
为了有所改善,第二关键的事情是要尽可能避免强势(尤其是在中层的权责范围内)。
要习惯用引导取代命令。
说了的话不干是底线,超出这条线的人是要想办法剔除的。
没到这条线的,牵涉到怎么去做的时候,则要尽可能引导。
在专门对权利进行研究的书籍中会对权利的类型进行进一步的划分:比如把权利分为授予型(granted)和挣得型(earned)权利。
挣得型(earned)权利也即是我们通常所说的影响力。
讨论具体项目事务的时候,只要有一线可能就不要让授予型权利发挥作用。
授予型权利是用来看护底线的,比如上面说的自己承诺的事情不做是一条底线,做事无法负起基本责任又是一条底线。
而这类底线其实并不多。
上述两点看着简单,但其实对改善局部的执行力帮助很大。
------------------------------------------------------------------------------------------------------------------------------------
理想流 + 软件 = 《完美软件开发:方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质,追求真理。
- 管理中第一可怕之事(3)
- 管理中第一可怕之事(3) .
- 管理中第一可怕之事(1)
- 管理中第一可怕之事(2)
- 管理中第一可怕之事(1) .
- 管理中第一可怕之事(2) .
- 实战c++中的vector系列--可怕的迭代器失效之二(删除vector中元素)
- 高效能管理之要事第一 时间管理表格3
- null的伟大与可怕 之 Optional操作 3
- Http之链接管理-第一课
- 高效能管理之要事第一 时间管理表格
- 高效能管理之要事第一 时间管理表格2
- 高效能管理之要事第一 时间管理表格4
- Linux之硬件管理(不断更新中)
- 现代操作系统之存储管理(中)
- 测鬼记(中)之奋斗——第一个项目
- 外包并不可怕 浅析IT外包风险管理方法
- 另类新婚闹洞房大全(可怕)
- ARM中的RO、RW和ZI DATA说明
- DES加密和解密算法
- C/C++经典面试50题(挑重点整理)2
- 我的上传,test.txt
- 备忘:DELPHI控件
- 管理中第一可怕之事(3)
- (转)android camera 小结
- 2012-7-30 总结
- 冰冻三尺 之“系统登录对话框”
- 转自cnodejs.org nodejs的mvc
- 2012.7.30计划并7.29总结
- 282.Love is full of trouble. 爱情充满烦恼
- /etc/rc.d/init.d和/etc/init.d 联系区别
- word5_1