事关激励：如何带领（并成为）骄傲的猫
October 5th, 2011
（商业读书会第十二期： Google’s CFO on growth, capital structure, and leadership | McKinsey Quarterly ）
这期的读书题目，我早已经读过了，有 微博 可为证。这事让我感到挺欣慰的：如果我读的东西越来越多，那么老师出的题目就越来越可能是我已经读过的。（广告：我的新浪微博都是从 TRSS 同步的，如果想讨论的话请用Twitter。）
在这个访谈里这位CFO讲了一些我们早就知道并且一直在做的事例如频繁的项目体检和反馈，以及一些我们早就知道不过没有做的事例如只有十亿人会用的产品才是值得做的产品。不过对我最有感触的，就是我在微博中引用的那句话，关于业务部门的观点——或者往大了说，如何激励知识工作者做正确的事。
简单地说，Google的业务部门设置就是没有业务部门设置——ThoughtWorks除了 Studios 这个产品团队以外也是如此。没有部门设置的直接效果就是没有部门墙和经典的“跨部门协作”。（我有个客户曾经很感叹地说：“真羡慕你们要做什么事就大家一起努力把事做成。”）更深层的意味在于：没有部门设置，就不给任何人考虑局部优化的视角，所有人都需要考虑“我做什么事是对全局最有价值的”。
一旦公司有了不同的业务部门，部门经理就会倾向于占据其中的资源。只有当所有人互相信任地站在公司而非部门的角度来做计划，才可能说出“对面那个团队比我们更需要这些资源”这样的话。
Dan Pink说 ，知识工作者的激励有三个关键词：Autonomy，Mastery，Purpose。刻意地不设置业务部门，实际上是在强化对“Purpose”的认知。德鲁克说，企业的价值都在企业之外，企业内部只有成本。道理很对，但我跟客户讲起来，他们只当我在讲笑话，因为强大的业务部门的存在已经让工作的目的不再是做对客户或者这个世界最有价值的事、而是做部门领导最希望看到的事。
Dan Pink讲的三个关键词其实组合起来就非常简单。就像我前阵子跟一个猎头MM说的，管理这群骄傲的猫其实很简单：你只要让他们知道他们所做的事有什么重要意义，不断用反馈给他们信心和帮他们改进，他们就会自己搞定所有事——当然如果这件事本身确实没有重要意义那么他们就不应该在做它。显然猎头MM也当我在讲笑话，不巧这个笑话跟Pink的调调还挺暗合的。
我经常跟人讲，在ThoughtWorks工作最大的好处是我可以绝对信赖这些人，他们叫我干什么我就会去干哪怕是叫我把手上的项目立即搞死我也不会犹豫，这让我的工作轻松很多。米高和郑晔最近一直在关注 如何得到值得信赖的同事 和 如何让他们变得真正值得信赖 ，而我想说的是：有了这样的同事之后，你需要做的就是让他们明白目标，帮助他们提升自己，他们会自己把事情搞定。
至于传统意义上的“激励”（通常是钱和可以用钱买到的各种东西），它该来的时候自然会来的，根本不用操心。
面向进展的管理
August 20th, 2011
（商业读书会第十期的题目： The Power of Small Wins | HBR ）
简单地说，内在的工作状态可以显著影响工作表现，对于知识工作者尤其如此。不那么广为人知的是，影响内在工作状态（也就是员工的心理状态）的最重要的因素，不是很多管理者以为的激励方式尤其是物质激励——这个话题可以单独再开一篇——而是（1）在有意义的工作上（2）取得进展。这个基于大量研究得出的结论实在是管理者的一大福音。
（图片来源：美军欧洲军事指挥部博客 ）
员工需要在有意义的工作上取得进展。这个简单的叙述背后有一些重要的意味。首先，它意味着员工与管理者与老板不必是对立的，因为在有意义的工作上取得进展是所有人都期望的事。其次，它意味着——再一次地——阳光是最好的消毒剂，因为只有信息透明才能让员工明白琐碎的日常工作蕴含的意义，没有只让干部知晓的数据 是简单而有效的鼓励方式。最后但绝非最不重要，它意味着管理者必须——就像德鲁克早已预言过的——做出一些改变。
文章里给出了一份很好的检查列表：作为一个领导者或者管理者，你是否在催化和滋养一支团队，而非抑制和毒害它。说起来真的很简单：你只要让团队了解目标，给他们搞定资源和约束，尊重和信任他们的专业能力，必要时给他们支持，和他们一起回顾进展和教训，他们就会自己把事情搞定。然而问题是，为什么那么多的领导者仍然使用一些有害的管理方式，尽管已经有充分的证据表明这些管理方式会直接损害知识工作者的绩效：
- 过大的目标以至于挑战超出团队的能力。
- 缺乏目标以至于团队看不到工作的意义。
- 缺乏管理和支持以至于团队受困于各种障碍。
- 微观管理以至于团队毫无自主性。
更有趣的是，这些看似彼此矛盾的表述经常同时出现在同一个团队。
我这样评价 一位从事软件研发管理的朋友 ：“我认识的研发领导中最走进现场、最理解客户疾苦、最善于打造团队的之一。”HBR这篇文章讲的是打造团队，为了有效地催化和滋养团队，领导者就必须了解客户、了解现场。了解客户，才真正明白自己的产品如何帮助同样水深火热（而不是传说中青面獠牙）的使用者；了解现场，才真正知道什么时候应该伸手什么时候应该放手。所以，还是向大野耐一致敬：管理的学问不是关于管理，而是关于在现场感受炮火。
作为反例，拒绝走进现场的领导者永远都弄不清应该管（或者不管）到什么程度。当你看见需求分析师和项目经理开了一个又一个的会来讨论“需求文档应该细化到什么程度”，你就知道自己正在看见一组远离现场的领导者，并且可以想象他们所领导的团队正在因为不知道工作的意义和微观管理而缺乏动力。最糟糕的是，人是可以培养的，而且不止一个可能的方向：如果你认为程序员不会考虑架构设计，如果你认为程序员不会考虑工作的意义，他们就真的不会考虑。然后你就得到一支缺乏动力因此低效的团队。
把人当机器的管理者是在人为降低员工绩效。老板们应该记住这个推论。
从成功中学习
June 30th, 2011
（商业读书会第六期的题目：Why Leaders Don’t Learn from Success | HBR April 2011）
首先，关于为什么成功不能成为成功之母，这篇文章总结的几个因素：
- 错误的根源归因 。在获得好成绩时，人们会倾向于把成功归因于自己的能力、智慧、管理有方、决策英明⋯⋯而不是外在的、偶发的、非受控的因素。这种错误的归因会使人们产生盲目自信，并且错过从经验中学习的机会。
- 过分自信偏差 。盲目的自信会促使人们做出风险更大的决策，并且倾向于不对现状做改变，从而错过改进的机会。
- 不再追问“为什么”。就连丰田也只强调针对有问题的事情追问 五个为什么 。人们倾向于只是庆祝成功，而不是冷静解剖“我们为什么成功”——就像解剖“我们为什么失败”一样。这也让人们错过从经验中学习的机会。
其次，关于如何有效地从成功中学习，这篇文章总结的几个实践：
- 庆祝成功，然后检查。承认有些成功就是因为运气这没有什么不好意思的，卡卡西说“运气也是实力的一部分”。需要明白成功是为什么成功，否则没有办法学习。
- 进行系统的项目回顾。成功的项目也有做得不够好（或者叫“可以做得更好”）的方面。为了下次把这些事做得更好而回顾，这不会影响对这次成功的庆祝。
- 使用正确的时间线。今天的成功很可能归因于很久之前的某个决策，甚至早于现在做事的所有人进入这件事之前。意识到这一点才能提早为将来的成功做准备。
- 重复不是学习。可以采用对待失败的工具同样对待成功：根因分析。找出真正的驱动力才是学习，而不是简单重复上次做过的所有事。
- 缺陷引入。（这个词是黄亮总结的。）在成功的项目上尝试各种变量，尝试把它推向边界，从而找出成功的原因。但是我个人有点担心：这会不会成为一个漂亮的借口，对一个本来非常漂亮的项目施加越来越大的压力，直至它变成一个普通的项目呢？
（总体来说，我认为 完美主义事儿逼处女座 具备从成功中学习的潜质⋯⋯只有变得更强是唯一追求，成功不成功的算什么老子就是不满意啊不满意啊～）
再次，这篇文章再一次体现了最近的一种趋势：认知科学与其他学科的交叉研究很容易热门。前一阵读的《 非理性繁荣 》就大量使用认知科学的研究来解释经济泡沫，这一篇又谈到了认知偏差，还有 这本书 也是。老师前两年在办公室讲过好几次认知偏差，这个套路还真是百搭啊。
最后，尽管有很多组织从失败中学习并最终成功，也有很多组织沉湎于成功而一朝沦落，但从中真的能推出“领导者们无法从成功中学习”吗？会不会这也是一种认知偏差呢？
创新的张力
June 18th, 2011
（商业读书会第五期的题目：The CEO’s Role In Business Model Reinvention | HBR January–February 2011。我又延伸了一篇：Stop the Innovation Wars | HBR July–August 2010。）
这两篇文章都是关于“现在”与“将来”的平衡：绝大多数取得成功的企业都拥有一个运转良好的效能引擎（performance engine），它是稳定的收入来源，它确保当前的成熟业务持续正常运行。但效能引擎的问题在于：它从本质上不是面向剧变的。而现代企业越来越多地需要面对剧变，例如新技术的发明，例如全球化带来的超低价格，例如互联网企业得到了所有潜在用户之后的增长瓶颈。效能引擎在面对剧变时，表现出的是温水煮青蛙的痛苦和无力。
作者的观点是：在最大化利用今天的同时，为了应对剧变的明天，企业必须有意识地打破昨天的习惯。另一方面，昨天的习惯往往是效能引擎在今天运转良好的重要原因。在三者之间做好平衡，就是CEO需要扮演的角色。
以InfoSys的咨询业务为例，作者提到了商业模型创新中需要注意的三个方面：策略制定，责任明晰，组织设计。在这三个方面，创新工作需要体现与效能引擎的极大不同。如何应对这种差异带来的张力，是第二篇文章的主题，也是我更关心的主题，因为它的视角出发点是创新领导者而非CEO。
从创新领导者的角度，同一位作者用Westlaw的例子阐述了业务创新的一个根本原则：创新不能脱离效能引擎进行。游离于运行良好的效能引擎之外去“一心搞创新”，实际上就是在浪费企业过去积累的经验和资产。创新领导者的挑战就在于促成创新团队与效能引擎之间的协作关系。这需要创新领导者做好三件事：
- 划分任务。哪些事是效能引擎善于达成的？哪些事是必须在创新团队中实现的？如果一件任务需要超出现有人员的能力、或者要求不同的协作方式，它很可能应该在创新团队中实现。
- 组建团队。创新团队需要尽量借助于效能引擎，但又不能全无变化。通过引入空降兵、设立不同的团队结构和考核标准，创新团队必定要在某些方面差异于效能引擎。“如果来自效能引擎的员工全都对在创新团队中工作感到舒服，那只能说明这是又一个具体而微的效能引擎。”诚哉斯言。
- 管理两者之间的张力。通过前两个环节建立创新团队的独特性，随之而来的问题是如何保持协作和企业文化的连贯性。两个团队互相尊重吗？他们在面对资源争用时是在积极地协作解决问题吗？跨团队的成员对创新行动有足够的重视吗？创新团队与效能引擎之间的冲突很容易被升级为企业文化的断裂，保持平衡是一件微妙并且需要持续努力的事。
在做好现在的同时关注未来，在积极创新的同时给予效能引擎充分的尊重，这是谈到业务创新时战略和执行层面的两个基本原则。InfoSys和Westlaw遵循这些基本原则成功地实现了业务创新。在固有文化中就不去极端强调可预测、可控制的企业，业务创新时的张力可能相对较小；但在保持创新团队的独特性同时保持企业文化的连贯性，这对于创新领导者而言始终都是一个挑战。
Leadership Over Management
March 5th, 2010
灰色区域是普通员工，蓝色区域是被尊敬的员工，绿色区域是优秀的管理者，红色区域是危险的。
所以，得不到管理职位没什么好着急的，领导力更要紧。
