管理中第一可怕之事（3）

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

大多时候中层的人并不能左右高层的性格乃至种种选择，所以如果真有让人绝望的事情，又没有忍耐的的能力那就只能换个地方。

这很简单，并不值得多谈，我们主要要关注的是事情积极的一面，即如何扭转这种局面。

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

工程师组成的团队中其实并不需要很多政治，大多时候，大多事情是可以谈，并谈出以逻辑和事实为根据的最佳答案的。

中层和工程师间的隔阂大多时候起于一些很简单的原因，如：

工程师更贴近现场，如果中层总是把自己的位置摆的很高，喜欢居高临下，那么工程师会觉的这个中层很白痴（当然大多时候不会直接说）。

中层接了高层的要求，回来也没啥办法，只能强制实施，但很可能这和事实违背，也和大家的意愿违背，进而累积矛盾。

比如：通过CMMI，导入量化管理这种事情。

中层并不能随心所欲的做事情这点很基本，但往往会混杂在事情中，进而被漠视掉。

当中层贯彻高层的要求时，其实他也只是一个执行者，并没有选择空间。

这时候中层需要做的事情是代表团队在决定出来前发出声音，而不单是做单方向的传声筒。

一旦决定出来后，作为中层可以跟大家讲自身的观点是赞同或反对，但行动上就只能是执行了。

如果上述这些都很坦诚的在团队中进行交流，大多数人是会理解中层并不能左右所有事情的走向的。

它既没这个权利，也没这个责任否则就就不是中层了。

误解往往产生在，工程师只看到中层，所以一旦缺乏交流，就会认为所有事情的责任都在中层身上。

因此，上述这类场景下，中层需要的是真诚，充分交流，并把自己切换为工程师的视角。

要尽量让大家明白，那些责任是属于中层的，那些中层也只是扮演一个执行者。

为了有所改善，第二关键的事情是要尽可能避免强势（尤其是在中层的权责范围内）。

要习惯用引导取代命令。

说了的话不干是底线，超出这条线的人是要想办法剔除的。

没到这条线的，牵涉到怎么去做的时候，则要尽可能引导。

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

挣得型(earned)权利也即是我们通常所说的影响力。

讨论具体项目事务的时候，只要有一线可能就不要让授予型权利发挥作用。

授予型权利是用来看护底线的，比如上面说的自己承诺的事情不做是一条底线，做事无法负起基本责任又是一条底线。

而这类底线其实并不多。

上述两点看着简单，但其实对改善局部的执行力帮助很大。

------------------------------------------------------------------------------------------------------------------------------------

理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。