从许多管理类书籍中看到过关于“猴子”的比喻,无意中从再别康桥的微信中看到他晒出的一份书单,大部分我也读过了,只有《别让猴子跳回背上》这本没有认真看过。本来想看该书的英文版,可惜没有搜到,只能看中文版了。
在我以前的理解看来,猴子就是管理者扔给你的任务和项目,把猴子扔给你的上级或下属,相当于GTD中的委派,但读完此书后,发现这种理解并不完全正确。这本书说是写给管理者的,对于技术类人员不太适用,但遇到一些杂事时,也可以应用里面谈到的技巧,把猴子甩到上级或下属的背上,每每看到这里,总有一种罪恶感。原来工作事务,完全转变为一场猴子战争。
书中的“猴子”指的是双方谈话结束后的下一个步骤。猴子不是问题、项目、计划或机会;猴子只是解决问题、开展项目的下一个行动步骤(与GTD中的Next Action完全一致)。
有些下属关于把猴子扔到你背上,当你从下属身上接下责任,会发生两件事。第一,你让员工来监督你,你成为了项目的瓶颈。第二,你让他们不必做自己份内的工作。请记住,帮你的部属做事不是你职责所在。
书中提到了一个安肯自由量表,谈到了下属可运用的五个任务层级:
(5)独立行动,例行性报告(最高层级)
(4)行动,但须立即请示(意味着报告频率超过例行性报告)
(3)建议,等待裁示再行动
(2)请示要做什么
(1)等待指示(最低层级)
当下属处于(1)和(2)的任务层级时,实际上他已经成功地把猴子扔给了老板。如果老板全被下属的时间所占据,说明他处于一种逆向管理状态,这时员工游手好闲,而老板忙得焦头烂额、团团乱转。最糟糕的外行管理者是整天接受下属的猴子,被下属的时间占据;第二糟糕的业余管理者,是多产的猴子分配者,这种管理员每天会丢出去一千只猴子,连他自己也搞不清楚要干什么。
管理者的贡献来自于他们的判断力与影响力,而非他们所投入的个人时间与埋头苦干。如果一个人既有管理角色,又有技术角色,该怎么办?
书中最后指出了减少猴子在身的六条规则:
规则1:喂养它们,或射杀它们:千万不要让它们活活饿死。
像是GTD中的第二步“明确意义”,到底需不需要做这件事?如果对用户、对自己、对将来都没有用,就杀死它。
规则2:只要你找到需要喂养的猴子,你的部属就得找出时间喂食它们,但千万不要过量。
不要每天往下属身上扔一堆猴子。
规则3:按照喂食进度表上的时间和地点喂养猴子是部属的责任,主管不必再沿途追逐即将饿死的猴子,胡乱地喂食。
高层管理者不应该未通知直接下属,直接对更底层的下属发号施令(明显的例外是,攸关生死的情况),这项原则一旦遭到破坏,便会导致所谓的越级监督,混淆了任务的优先次序,让接到指示的下属费力不讨好。
规则4:如果有冲突发生,预定喂食猴子的时间可在任何一方的提议下,做出变更,但不被视为延误,事情毫无进展不能作为重新安排喂食时间的借口。
约定的时间可以协商变更,没有进展也要报告。为了汇报,总要弄出点进展来的。
规则5:无论何时,应尽可能面对面地喂食猴子,否则便使用电话,绝对不要用信件。备忘录、电子邮件、传真和报告可以使用于喂食过程,但不能替代面对面的对话。
你不该说:“寄给我一份会议记录。”你应该说:“把记录拿来给我看。”
下属真正想说的话根本不会出现在那份文字记录里,它暗藏在字里行间。
至于面对面的对话也会出现一个问题:如果对话结束,下一个具体的步骤显然属于你时,你要如何往下进展?
带着你的部属一起进行。通常这是一种很好的管理做法,这么做,猴子将不会乱窜。
规则6:超过好几页的备忘录,电子邮件、传真和报告应该在一页的摘要中写清楚,以便展开立即的对话。
长篇大论的报告一定要附上一份简短的摘要,以说明里面的内容。
本文转自申龙斌的程序人生博客园博文,原文链接:http://www.cnblogs.com/speeding/p/4472204.html,如需转载请自行联系原作者
http://www.cnblogs.com/speeding/