经理人的产出 = 他直辖部门的产出 + 他间接影响所及部门的产出
Manager翻译成经理人其实颇贴切，职责就是将经手的事务理顺。其中“经”的意思是必须亲手接触业务，了解任务从何而来，怎样解决；“理”的意思是需要将复杂的问题厘清分解，抓住实质，让大家，乃至各部门各司其职，高效且井然有序的解决。这里为什么要用“理”而不是“解”，“办”之类的，正是说明它在过程中的应该起到的作用。
初级经理人大多是业绩出色的一线员工，比起同僚们要强。也许是惯性所致，很多人的工作习惯是将团队人员配备成让自己，或者是自己类似的岗位能够发挥最大生产效率的模式。让组里的其他人作为辅助，撑住四周，让自己冲在前面攻城拔寨。也有些会相对平等的分配机会，但是懒于帮助他们进步，采取自由放羊形式，这样管而不理的模式和没有经理也没多大差别，都是坐在排长位子上干单兵的活，浪费了。
就部门本身来看，在人数不多的情况下，可能总产出还差别不大，但一旦还想晋升，作为更大部门的领导者，这种毫无杠杆的做法就要吃大亏。你再强，也强不过10个人，也强不过一个10人团队每人提升10%的效率。人数越多，单兵的作用就越有限。（话说回来，对于有价值的业务，如果你真的能抵得上10个人的效率，说明你要么天资极其聪慧，要么做事的方法相对于凡人是降维打击，那作为一个个人贡献者拿个5倍于市价的薪水也是相当不错的选择）
过程初期所付出的能量将会收到十倍的回报，而过程末期所付出的能量会收到十倍的负回报。
深有体会。哪怕是一周工作量的feature也是如此。在软件开发行业里，过程初期所付出的能量包括:
- 产品和技术方案评审 - 确保产研对需求理解一致
- 撰写Test Case和Release Plan - 确保到发布时有可靠且明确的验证和实施步骤
- 和需求方充分沟通，不仅考虑产研，还考虑外部依赖 - 确保除产品之外的资源及时到位
- 评估项目所需的Story point，确定优先级 - 决定发布的范围，既不过多增加风险，也不过少浪费资源
这些事显然很有意义，作为Manager，如果不安排好这些事情的预期产出和负责人，并带领执行，是不能指望大家自行考虑这么多的。并不是说大家不想把事做好，而是大家不明白自己的职责在哪里，所以只会按旧流程去做自己熟悉的内容。懒政的结果就是
- 没做评审 - 到验收的时候发现采取的技术方案不正确，无法满足功能/性能/安全性/灵活性等要求
- 没写Test Case和Release Plan - 验收发布全凭感觉，盲人摸象，边上线边修bug，整个团队等个别工程师修到半夜
- 没考虑外部依赖 - 没事先让客户准备素材，用户名单，以及了解一些特殊需求，导致做出来了没法用，又要等一周
- 没评估Story point和优先级 - 大家随意进行开发，到最后一天发现Must-have发不出来
说实在的，这里面没哪一个是我没碰到过的，不管是哪一项发生，补锅的过程都确需花费若干倍时间，而且特别无谓。比如出bug了不仅要修，还要向客户解释发生的原因，还得修复数据，还让客户觉得我们不靠谱，总之很不值。
写下这一切的时候觉得不遵守原则简直蠢透了，但在紧凑的日常事务中做到滴水不漏的坚持完成每一项也不是那么容易。这是一个惰性和习惯的竞争。都知道团队有这种习惯是好事，但养成习惯的过程确实很痛苦。一旦一次没做，离理想中的团队就又远了一分。如果经理人在想的是：已经执行了几个星期了，大家应该知道要执行了，需要评审会来找我的，我就不说了吧，那请趁早把这种想法掐死在萌芽状态。如果连经理人想着弃疗，那整个团队是不会养成好习惯的。
- 第一原则：要有指标，它能引导我们的管理，但不要反应过度特别是量和质的指标通常需要配对使用。过度反应会导致我们对另一方面指标的失控。
- 第二原则：是评估产出，而不是产出之前的生产活动。
- 第三原则: 衡量具体且可计算的事情
这里的指标，是衡量团队各位Output的指标。
之所以我的业界里会出现衡量代码行数或者BUG数这种看似不可思议的事，大概是对这两个原则采取了简单化的拿来主义所致。要知道，设定了指标，负责人就会按负责的指标为导向工作。因为管理者会衡量，执行者也会，而且由于身处需要完成指标的第一线，要比管理者更擅长规避风险。
要求低事故率？那就尽量少上新功能，拖延上线甚至拒绝客户
要求低BUG率？多做多错，那干脆少写或者不写
要求客户满意度？那就专注于“性价比”最高的项目，而不是按整体规划来看最有价值的项目
想起当年作为外包平台中的项目管理者，远程管理若干项目，接包方是多家企业且素质参差不齐，不得不采取很多僵化的指标(例如Checkstyle或者PMD，甚至某些Performance Improvement)来衡量交付质量，接包方为完成指标而采取的某些做法也让我印象深刻。大量的时间花在这类无聊的事情上，让我到现在都对外包模式心存芥蒂。当然，在同一个团队内，大家的利益是一致的，但仍然需要管理者正确评估每一项任务的重要程度和真正价值，不管是对项目，团队还是个人。分配时间给最有价值的任务，给完成最多价值的团队成员最高的指标评价，这就是好的优先级管理，好的OKR管理，以及Build有战斗力的团队的踏实一步。