很多人慕企业之名而来，却常常因为直接领导而离职，为什么呢？

紧盯10%的错误

我在“说你玻璃心的就想免费耍流氓”一文的开始，讲了F的故事，F的领导的做法，完美演示了一个技术领导如何通过紧盯小错误来“完美挫伤”程序员，让其再也提不起干劲与活力。

摘录一部分：

有位朋友F，第一次找我聊天是两个月前，他说部门换了经理，新经理特别强势，对他横挑鼻子竖挑眼，总是碾压他，他想到上班就很痛苦，上班时间也不能专心工作，老担心经理突然挑他的不是。

他还说，每次技术讨论或项目启动会议，别人说什么都没关系，哪怕与项目无关的话题、与正讨论的技术主题无关的话题都没关系，经理都面带笑容地倾听，就算别人说的技术见解明显是不对的，经理也会包容，顶多转换话题。而他就不同，只要他一说话，经理要么说“这个不用说了，我都知道，还有没有别的？”，他压住受打击的情绪，挖空脑袋说点儿“别的”，经理往往在他话一出口就不耐烦地打断他——“别说了，毫无意义，这种情况根本不会发生”……

他还说，每次发周报，或者过项目状态，经理不是说你这个词儿写错了、那个问题还没解决，就是说任务某某实现方法不好为什么不用另外一种更好的，或者说周四发出去的那封信思路和措辞都不对，上面的领导和别的团队的人看了会有想法……总是指出缺点和批评他，对他列出来的1、2、3、4、5、6那么多工作成果看得不看。而别的同事呢，经理都不对他们这样。

总之，F觉得领导看不上他，对他有意见，有意针对他，想收拾他，让他知道厉害。他觉得很委屈，自己上班提前下班晚，领导一句屁话都当命令去执行，工作一丝不苟，搞下来反倒没那些迟到早退偷奸耍滑的同事受待见。他说他想不通，最近压力很大，想到要上班面对经理就别扭、发怵、恶心，问我怎么办。

F郁闷到不能正常工作，仅仅是因为领导对他“横挑鼻子竖挑眼”。在我看来，这里面有很大一部分原因，是这个技术经理犯了一个严重的错误：

从来不夸奖下属，但下属只要有一点闪失，就会被放大，并进行检视与责备。

看看F的情感诉求，我们很容易就能明白，假如经理在批评之前，能够针对F表现良好的部分给予鼓励与认同，就能有效提升F的干劲和活力。

然而大多数上司都像F的领导那般，将下属90%的正确行为视作“理所当然”而直接忽视，只着眼于那仅占10%的错误行为，管理变成了指责与批评，最后搞得下属一个个蔫吧的像霜打的茄子，没有建设性也没有战斗力。

关于这一点，汉堡原理可以参考：

指责与否定下属

作为一个从一线开发岗位晋升而来的经理，常常是因为技术能力突出才被提拔的，然而当他被提拔为经理后，他出色的技术能力很多时候会成为他转变为一个好的管理角色的障碍——因为他很容易以自己的技术能力为参考点来要求别人、指责别人。

“不对！不是这样！”
“错了，应该这样！”
“算啦，你别弄啦，让A来做！”
“这么明显的Bug你都没发现？！”
……

这是技术经理们经常说的话，是不是常常听到这样的话？

一边指责对方不成熟，一边否定对方，这就是我们的技术经理作为指导者的角色常犯的错误。

不是说下属犯错不能批评，而是要尽量优先考虑不挫伤他人、不剥夺他人机会与勇气的方式。对方之所以做不到，是因为现阶段的能力不足，但是能力不足只是一时的，将来还是有提高的可能性，而一旦你挫伤了对方的勇气，向想挑战困难的下属泼了冷水，往往会让对方感受到自己的无能并心生自卑，最终导致其失去克服困难的动力,甩手不干，不再成长。

顺带说一句，有些技术经理会通过指责别人会彰显出自己的优秀，从中感受优越感，甚至会以为只有彰显了自己技术上的优秀才能体现出自己作为领导的称职性。这是一个误区，我在“程序员，这12个问题让经理比你痛苦多了”一文中有提到这一点，温伯格的《成为技术领导者》一书里也有详细介绍。

经理们可能会感到委屈：“打也不行骂也不行到底怎么才行？”

其实并不是说我们不能批评或指责下属的错误，而是要对自己的指导方式是否能有效提升别人克服困难的勇气、增强别人提升自己的动力做考量。因为只有团队成员都成长了、独挡一面了，整个团队的战斗力才会提升。要知道，只有经理技术能力最强的团队是失败的团队！

要避免本节开始的那种职责与否定方式，其实也不难，只要在你脱口而出之前问自己一句话——“对方透过这种体验能学到什么？”——就行了。

害怕别人失败影响自己，不愿放手

人只能透过失败来学习，借由失败的经验，守护自己“想要改变”的决心。

然而作为一个软件开发团队的管理者，却往往是害怕失败和错误的，总因为担心一犯错就产生质量低劣的软件、延期而不愿意给某些下属独立解决问题的机会。

一部分技术能力强的经理，往往不懂得放手，忍不住伸出手来亲力亲为，结果只会导致下属产生依赖性，不能独当一面；另一部分不信任下属的技术经理，则采取能者多劳的策略，拼命把重要的、关键的、难度高的任务都压到某一个核心开发人员身上，一方面导致其他人没机会成长，另一方面这位优秀的开发者很快就会难以承受这么大的压力而选择退却或离职。

这样看来，“每个人都只干自己熟悉的事儿”这种司空见惯的分配任务的行为其实是不科学的。我们不能因为一个程序员不熟悉某个任务所需的技术而剥夺他接触新领域的机会，也不能因为害怕某个程序员做不好而越俎代庖替他解决问题。

每个人都有自己的课题，必须自己来完成，也唯有自己完成才能获得成长。作为上司，应该放手，让下属有独立解决问题的机会，培养他克服困难的勇气，这样他才能做得到，才能成长。。而你所要做的，就是支持，以及容许一点点错误的代价。

请谨记：不是因为做得到而放手，而是因为放手才做得到。

不聚焦如何解决问题

程序员可能对下面的场景很熟悉哦：

3月15号要上线新版本，结果14号下午5点测试阿美曝出王二一个Bug：App上的轮播海报，播到第三张时，一点击海报应用就崩溃。

经理焦大听了阿美的反馈，快步来到王二工位，满脸不快地喊道：“为什么老是到上线前出问题？到底怎么回事儿？”（果断拉仇恨啊）

……

王二听了焦大的话，第一反应就是：我靠，用得着这样办我丢人吗！然后，心里肯定不快，接下来的交流肯定是各自带着气儿的。比如，王二可能忍了焦大的气，转身去找阿美：“阿美为什么你们老是到上线前才测出这种Bug！”而阿美呢，可能又很委屈，反唇相讥：“为什么你们送测前都不自测一下呢？我们测试的时间就不是时间啊！”

Ok，到这里结束吧。我们来分析焦大的王二说的话，如果你仔细回味你所在的工作环境和生活环境，就会发现这其实是我们多数人遇到问题的习惯性反应：先指责错误追问原因，然后再去解决问题。

这种方式往往会滋生嫌隙和怨恨，不利于解决问题。我们应当直接将焦点放在如何有效解决问题上。比如阿美报了那个Bug，焦大可以省略指出问题与探究原因的步骤，直接问王二：“咱们该怎么查这个Bug？”接着给出建议：“你看咱们从App本地的Activity调用和服务器的轮播海报配置两方面来查，怎么样？”这样就可以将兴师问罪的行为转变成解决问题的行动，同时也能让王二更有勇气和责任感投入到问题的解决上。

一味指责对方的错误、打破砂锅问到底，对解决问题没什么实际帮助，反倒会伤害下属，挫伤其补救与解决问题的勇气，更不利于其从错误中汲取经验自我成长。聚焦于如何有效地解决问题，一边给建议，一边唤起犯错人补救的积极性和勇气，会更好一些。

作为开始的结束

好啦，到这里我们列举了经理们经常会犯的四宗罪：

• 总盯着下属10%的不足，忽略90%的成绩，把管理变成粗暴的指责与批评
• 用批评与否定来指导下属，不考虑这样做是否能帮助下属成长
• 不懂如何放手与授权，分不清课题到底属于谁，剥夺下属自我成长的机会
• 遇到问题先指责对方，之后才去解决，挫伤下属解决错误的勇气，降低下属借由错误成长的可能性

正是因为领导们常常犯这四宗罪，导致员工当下很难愉快地成长，将来也看不到成长的机会，担心自己越来越不值钱越来越没竞争力，最终才悻悻而去。如果一线经理们能够创造一个帮助员工成长的环境，相信很多人会反过来——因为领导而留下。

现在，请你想一个问题吧：

1. 作为经理，你犯了几宗？
2. 作为一线员工，你的经理，又在使用哪种方式扼杀你成长的可能性？

相关阅读：

• 程序员，这12个问题让经理比你痛苦多了
• 说你玻璃心的就想免费耍流氓
• 成为技术领导者