管理中第一可怕之事（3）
假设说一个人是个项目经理或部门经理，并一下子扎到了一个执行力不好的环境中，那么这个人能干点什么或者说应该干点什么？
大多时候中层的人并不能左右高层的性格乃至种种选择，所以如果真有让人绝望的事情，又没有忍耐的的能力那就只能换个地方。
这很简单，并不值得多谈，我们主要要关注的是事情积极的一面，即如何扭转这种局面。
为了有所改善，第一关键的事情是要足够真诚。
工程师组成的团队中其实并不需要很多政治，大多时候，大多事情是可以谈，并谈出以逻辑和事实为根据的最佳答案的。
中层和工程师间的隔阂大多时候起于一些很简单的原因，如：
工程师更贴近现场，如果中层总是把自己的位置摆的很高，喜欢居高临下，那么工程师会觉的这个中层很白痴（当然大多时候不会直接说）。
中层接了高层的要求，回来也没啥办法，只能强制实施，但很可能这和事实违背，也和大家的意愿违背，进而累积矛盾。
比如：通过CMMI，导入量化管理这种事情。
中层并不能随心所欲的做事情这点很基本，但往往会混杂在事情中，进而被漠视掉。
当中层贯彻高层的要求时，其实他也只是一个执行者，并没有选择空间。
这时候中层需要做的事情是代表团队在决定出来前发出声音，而不单是做单方向的传声筒。
一旦决定出来后，作为中层可以跟大家讲自身的观点是赞同或反对，但行动上就只能是执行了。
如果上述这些都很坦诚的在团队中进行交流，大多数人是会理解中层并不能左右所有事情的走向的。
它既没这个权利，也没这个责任否则就就不是中层了。
误解往往产生在，工程师只看到中层，所以一旦缺乏交流，就会认为所有事情的责任都在中层身上。
因此，上述这类场景下，中层需要的是真诚，充分交流，并把自己切换为工程师的视角。
要尽量让大家明白，那些责任是属于中层的，那些中层也只是扮演一个执行者。
为了有所改善，第二关键的事情是要尽可能避免强势（尤其是在中层的权责范围内）。
要习惯用引导取代命令。
说了的话不干是底线，超出这条线的人是要想办法剔除的。
没到这条线的，牵涉到怎么去做的时候，则要尽可能引导。
在专门对权利进行研究的书籍中会对权利的类型进行进一步的划分：比如把权利分为授予型（granted)和挣得型(earned)权利。
挣得型(earned)权利也即是我们通常所说的影响力。
讨论具体项目事务的时候，只要有一线可能就不要让授予型权利发挥作用。
授予型权利是用来看护底线的，比如上面说的自己承诺的事情不做是一条底线，做事无法负起基本责任又是一条底线。
而这类底线其实并不多。
上述两点看着简单，但其实对改善局部的执行力帮助很大。
------------------------------------------------------------------------------------------------------------------------------------
理想流 + 软件 = 《完美软件开发：方法与逻辑》
理想流 + 人生 = ??
理想流 + 管理 = ??
理想流 = 以概念和逻辑推演本质，追求真理。