技术团队中层如何改善团队执行力

第一关键的事情是要足够真诚
服务器君一共花费了264.885 ms进行了7次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

假设说一个人是个项目经理或部门经理,并一下子扎到了一个执行力不好的环境中,那么这个人能干点什么或者说应该干点什么? 

大多时候中层的人并不能左右高层的性格乃至种种选择,所以如果真有让人绝望的事情,又没有忍耐的的能力那就只能换个地方。 这很简单,并不值得多谈,我们主要要关注的是事情积极的一面,即如何扭转这种局面。  

为了有所改善,第一关键的事情是要足够真诚。 

工程师组成的团队中其实并不需要很多政治,大多时候,大多事情是可以谈,并谈出以逻辑和事实为根据的最佳答案的。中层和工程师间的隔阂大多时候起于一些很简单的原因,如:

  • 工程师更贴近现场,如果中层总是把自己的位置摆的很高,喜欢居高临下,那么工程师会觉的这个中层很白痴(当然大多时候不会直接说)。
  • 中层接了高层的要求,回来也没啥办法,只能强制实施,但很可能这和事实违背,也和大家的意愿违背,进而累积矛盾。比如:通过CMMI,导入量化管理这种事情。  
  • 中层并不能随心所欲的做事情这点很基本,但往往会混杂在事情中,进而被漠视掉。
  • 当中层贯彻高层的要求时,其实他也只是一个执行者,并没有选择空间。这时候中层需要做的事情是代表团队在决定出来前发出声音,而不单是做单方向的传声筒。一旦决定出来后,作为中层可以跟大家讲自身的观点是赞同或反对,但行动上就只能是执行了。 

如果上述这些都很坦诚的在团队中进行交流,大多数人是会理解中层并不能左右所有事情的走向的。他既没这个权利,也没这个责任否则就就不是中层了。 

误解往往产生在,工程师只看到中层,所以一旦缺乏交流,就会认为所有事情的责任都在中层身上。因此,上述这类场景下,中层需要的是真诚,充分交流,并把自己切换为工程师的视角。要尽量让大家明白,那些责任是属于中层的,那些中层也只是扮演一个执行者。  

为了有所改善,第二关键的事情是要尽可能避免强势(尤其是在中层的权责范围内)。要习惯用引导取代命令。

说了的话不干是底线,超出这条线的人是要想办法剔除的。没到这条线的,牵涉到怎么去做的时候,则要尽可能引导。

在专门对权利进行研究的书籍中会对权利的类型进行进一步的划分:比如把权利分为授予型(granted)和挣得型(earned)权利。

  • 挣得型(earned)权利也即是我们通常所说的影响力。讨论具体项目事务的时候,只要有一线可能就不要让授予型权利发挥作用。 
  • 授予型权利是用来看护底线的,比如上面说的自己承诺的事情不做是一条底线,做事无法负起基本责任又是一条底线。

而这类底线其实并不多。 上述两点看着简单,但其实对改善局部的执行力帮助很大。

本文地址:http://www.nowamagic.net/librarys/veda/detail/2143,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/2143

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《深入理解计算机系统(原书第2版)》 布莱恩特(Randal E.Bryant) (作者), 奥哈拉伦(David R.O'Hallaron) (作者), 龚奕利 (译者), 雷迎春 (译者)

《深入理解计算机系统》从程序员的视角详细阐述计算机系统的本质概念,并展示这些概念如何实实在在地影响应用程序的正确性、性能和实用性。全书共12章,主要内容包括信息的表示和处理、程序的机器级表示、处理器体系结构、优化程序性能、存储器层次结构、链接、异常控制流、虚拟存储器、系统级I/O、网络编程、并发编程等。书中提供子大量的例子和练习题,并给出部分答案,有助于读者加深对正文所述概念和知识的理解。

更多计算机宝库...