公开表扬,私下批评?

标签: Yurii谈开发 一家之言 团队管理 领导力 | 发表时间:2014-12-11 13:43 | 作者:Yurii
分享到:
出处:http://www.luanxiang.org/blog

很多初上管理岗位的人都听过这样一条教诲:“公开表扬,私下批评”。而且,很多有管理经验的人也是这么做的。理由很简单:公开表扬能给人鼓励,催人继续,私下批评给人留了面子,减少副作用。但是,它真的是一条应当时刻遵守的行为规则吗?

不妨看两个例子:某人表现不好,主管与他谈话之后有了一点改进的苗头,应该鼓励,所以主管公开表扬,结果其它人明明做了更大贡献,却没有得到表扬;某人搞砸了工作,造成整个团队加班为他收尾,然而主管只是私下批评,让其它人觉得不公平,主管有意袒护。

很明显,在这两个例子里,“公开表扬,私下批评”并不是合适的做法,反而造成了新的矛盾。那么,问题究竟出在哪里呢?表扬和批评,到底应该在什么情况下公开进行,什么情况下私下进行呢?

要回答这些问题,首先要清楚,表扬和批评的目的是什么。“公开表扬,私下批评”的倡导者,明显是从被表扬和批评的对象出发的——表扬是为了给他鼓励,让他更有动力,批评是为了给他压力,也给他留面子。从这个角度来看,是没有问题的。但是我们不要忘记,管理者要面对的是整个团队,过分专注于个人,专注于个人的感受,就容易忽视对整个团队的影响。仔细观察就会发现,之前说的两个不适用的例子,真正的矛盾来自团队,来自团队其它人的感受和反应。

管理者对团队负担着什么职责呢?这个问题可以换种表述:团队为什么需要管理呢?我的答案是:管理的重要作用之一,是降低协作成本,提升协作效率,所以能让一群人做成没有管理时做不成的事情。从这个角度出发,无论是表扬还是批评,无论公开还是私下进行,只要造成了“不公平”的感觉,都会增加协作成本,降低协作效率。那么,表扬和批评要怎样做,才能降低协作成本,提升协作效率呢?

要回答这个问题,我们不妨问问:什么样的团队能做到协作成本低、协作效率高呢?按我的经验,这样的团队一般都具备共同的价值观,公认的行为方式。所以大部分情况下,大家都清楚什么是对的,什么是不对的;应该做什么,不应该做什么;什么行为是受认可的,什么行为是不受认可的;所以不需要每次发生分歧的时候都争个面红耳赤,或者找上级来评定输赢,而可以自行协作。

站在管理者的角度,无论表扬还是批评,甚至其它的一举一动,短期来看或者是项目的需要,长期来看则都是在对团队发出信号,告诉大家什么是对的,什么是错的。团队的共同价值观和行为方式,就在这种信号的河流中慢慢演化成形。所以,公开表扬微小的进步,或许对被表扬的人很有用,却可能在告诉其它人“小进步也要去邀功”;私下批评明显的过错,或许为被批评的人留了面子,却可能在告诉其它人“犯这种过错可以不用担责”;或者更糟糕的,其它人会觉得选择公开或私下的原因只是“和领导走得近”,在团队内产生拉帮结派、吹须拍马的恶果。

所以,如果管理者赞同“表扬和批评都是管理团队(而不是个人)的手段”,那么表扬和批评就无需遵守“公开表扬,私下批评”。我自己的经验是:如果只针对个人,也只影响个人,表扬和批评都应当私下进行——一对一的肯定,分量不见得比众人面前的表扬要轻,管理者反而更好把握分寸,一对一的批评,甚至可以比公开的批评还要直接和严重;如果还需要考虑其它人的感受,并向团队传递清晰的信号,公开表扬和批评都无可厚非——因为批评是对事不对人的,也是告诫大家:无论是谁,犯了错误都是要担责的。

相关 [Yurii谈开发 一家之言 团队管理 领导力 ] 推荐:

TokuMX使用小计

- - 乱象,印迹
最近因为工作的缘故,接触了 TokuMX,尝试下来感觉不错,值得介绍给大家. 事情的起因是要解决MongoDB的问题. 系统中需要保存程序输出的运行信息,这类信息比程序语言的log更高级,比明确的操作日志更低级,却是某些时候发现问题的关键证据,所以必须保存下来. 因为其格式不规范,又需要方便检索,综合下来文档型NoSQL的MongoDB是比较好的选择.

公开表扬,私下批评?

- - 乱象,印迹
很多初上管理岗位的人都听过这样一条教诲:“公开表扬,私下批评”. 而且,很多有管理经验的人也是这么做的. 理由很简单:公开表扬能给人鼓励,催人继续,私下批评给人留了面子,减少副作用. 但是,它真的是一条应当时刻遵守的行为规则吗. 不妨看两个例子:某人表现不好,主管与他谈话之后有了一点改进的苗头,应该鼓励,所以主管公开表扬,结果其它人明明做了更大贡献,却没有得到表扬;某人搞砸了工作,造成整个团队加班为他收尾,然而主管只是私下批评,让其它人觉得不公平,主管有意袒护.

“推倒重来”的讲究

- - 乱象,印迹
上个月,有个以前的同事问我:“你在的时候,为什么不把原来的系统都重做了,我们明明有实力啊”. 我说:“我们也做了很多事情嘛,系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理. 他说:“对,但我还是想知道,你为什么不把系统重做了呢. 于是我问:“我离职之后,后来似乎多投了不少人重做系统.

团队管理101招

- 狂之想 - C++博客-牵着老婆满街逛
转载自:http://www.iteer.net/modules/doc/article.php?storyid=1402. 无论你是新手还是资深管理人,对你而言,管理好团队都是重要且具激励性的挑战. 切记:每位成员都能为团队作出一些贡献. 谨慎地设定团队目标,且认真严肃地对待它们. 尽早决定何种形态的团队适合你的目标.

小团队管理与大团队管理

- -
如有好文章投稿,请点击 → 这里了解详情. 我们公司和大部分传统软件公司一样,随着业务的发展和新领域的开拓,公司的管理风格越来越像华为,这是不是最佳的演进路线,我觉得值得探讨,以下是我的思考,希望跟大家讨论. 前段时间跟一个创业的朋友聊天,说起他们最近在做的一个项目,这是一个教育行业的管理系统,业务非常复杂,牵涉到的决策人,需要对接的系统也非常多,最后问到他们做了多久完成这个项目,朋友告诉我2个多月,6个人,其中还括一个美工,一个项目经理;剩下的都是开发人员,没有测试,没有前端开发;朋友问我,如果这个项目给你们做,你们需要做多久;我想了想说,这个项目如果交给我们做,顺利的话,至少要半年.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

如何提高团队管理能力?

- - 人人都是产品经理
接手任何一个部门的最重要的事情,是明确或者重新调整组织架构. 架构的关键是:谁在什么位置,负责什么内容,一定要明确. 出了问题,大家都清楚谁应该出来承担责任. 领导不是决定怎么爬梯子的人: 他是决定把梯子搭在哪个墙上的人. 所以他必须明确的指出这个方向,向全员传达. 如果这个没有做好,再优秀的团队也不会拿出好的结果.

关于技术团队管理的胡言乱语

- - 博客园_知识库
  临近年底,接到《程序员》杂志的邀请,希望我能写一篇与团队管理有关的年终盘点文章,盘点2013年业界与团队管理相关的大事. 试想,揪出各个公司在2013年的各种“大事”,指点江山,激扬文字,那种众人皆醉我独醒的感觉是相当的妙不可言. 可细细一想,2013年可以归纳为团队管理大事的事件倒是不少,例如Yahoo!美女CEO宣布取消在家办公制度,最近又按照绩效评估结果排名开始裁员;最近知乎上好事者提出的“你问什么离开xx公司”系列,各种回答纷至沓来,为2013的团队管理大事记提供了不少素材.

关于UED团队管理的那点事

- - legene的用户体验设计
昨天晚上跟几个做设计leader的朋友聊天,对方谈起目前的工作情况和难处,我听了后觉得很有感触. 如果换做一年前的我在这里,也一定也会遇到同样的处境. “产品经理觉得交互设计师的出现增加了一个环节,效率降低了”;. “我们设计好的方案产品经理挑了一部分做,然后功劳就变成他们的了”;. “我们辛辛苦苦设计的方案产品经理总是不采用,等上线后发现体验不好大领导又责怪我们,说UED是怎么做的设计”;.