IT外企那点儿事(14): 好领导和好员工，坏领导和坏员工，鸡生蛋还是蛋生鸡？

领导和员工，似乎天然成为互相博弈的矛盾体，他们只要单独坐在一起，比如面试，或者是One on One，都时而擦出火药味，在表面的和谐谈话气氛下，心里充满的对对方的不满和不屑，而在工作外，我们常常听到这两者相互抱怨。

例如在面试时，一般会问及面试者对于原来的项目的详细情况。由于在沟通中，往往伴随着信息的噪音和失真，每个信息接收者，都会根据自己以往的经验队接收到的信息进行解读，形成一定结论，存入大脑，并成为此后处理来自相同的信息发送者的信息的基础。然而很遗憾的是，当前技术纷繁复杂，分支众多，每个程序员可能仅仅会在自己工作过的一点或者两点上比较深入，而碰到的面试官，虽说也是从事相关方面的，却未必在面试者擅长的点上了解的十分深入，从而造成了一定的沟通障碍。我们常常看到面试者大汗淋漓的描述自己做过的项目的难点，而面试官不得要领，于是两者心中的不满开始蔓延，面试者心里想：这么说怎么都理解不了，看来没有做过这方面的，真是对牛弹琴啊。而面试官却往往想：项目描述这么不清楚，要么是表达有问题，要么就是没有真正做过这个项目。经过一段时间的你来我往，面试者只好将问题抽象出来，来迎合面试官的知识体系，然而编程毕竟是一个细活，很多的难点都是在细节中攻克的，一旦抽象出来，很多难点也就难以体现了，终于面试官长出一口气：哦，就像那个A项目差不多是吧。(当然这个什么A项目自然是面试官熟悉的知识体系里面的)。而面试者也精疲力尽，点头称是，虽然心里总感觉自己做的项目和A项目多少有些不同，但总算是没有白费口舌。这个时候，两者的心里又发生了奇妙的变化，面试官想：原来是这个样啊，简历上吹得这么玄乎，也没多少技术含量嘛。而面试者想：哪有你理解的这么简单啊，做项目的过程中遇到各种各样的难题，加班加点才攻克的啊。

再如面试的时候，对于技术的提问，是应该提问公司使用的技术，还是应该提问面试者使用的技术，当然双方都有自己充分的理由，面试官一般会倾向于提问公司使用的技术，一方面是自己比较了解，容易知道面试者的深浅，一方面认为，对于有工作经验的面试者，公司是招来能干活的，而不像应届生一样学习和培养的。而面试者则往往认为：你使用的技术我没怎么用过，当然应该问我擅长的啊，这才能体现我的能力和解决问题的水平嘛，要不就是面试官技术有限，只会你的那一点。

基于上面所述，所以很多比较大的正规公司，都会倾向于面试一些中立的东西，比如基础知识，比如算法，有时候还会有笔试。而有了一定工作经验的人，往往又比较不乐意进行笔试，认为这些孔乙己式的基础知识题目，是刚毕业的才做的，自己离毕业这么长时间了，很多基础知识都忘了，而且关键工作了这么长时间，主要是项目经验和解决问题的能力，你问我茴香豆的茴字有几种写法干嘛。而面试官往往认为，基础知识是应该每次面试之前准备好的，是综合素质的体现，连笔试都不愿意做的人，工作态度很有问题，根本不能要。而谈到算法，往往面试官会将一个经典的算法稍加修改，然后抽象成一个类似有点游戏的题目，然而这有点像猜谜语，知道了谜底后，怎么看怎么觉得谜面显而易见，然而对于时间有限，外加紧张的面试者来说，往往难以看透背后可能本十分熟知的算法。这个时候，面试官会觉得面试者算法不精，面试者则认为：你千辛万苦编了个技巧题考我，还妄图我在几分钟内做完，换了你也不行。

至于谈薪水，面试官则往往认为：不要只想你要拿多少钱，想想你能给公司带来多少贡献。而且不应该只看薪水啊，发展机会也是很重要的。眼睛只盯着薪水的员工一定不是好员工，流动性太强，不稳定，这么年轻只认钱，肯定没有发展。而面试者却是这样想的：我本来就值这个钱嘛，原来薪水就这么多，不加个几千我干嘛跳槽啊。不想花钱还想找人才，没门儿。找不到牛人的Team一定没有前途。

有时候面试还会问到加班问题，面试官和面试者各有打算，面试官想：做IT哪个公司不加班啊，一提加班面有难色，一看就像是混日子的，年轻的时候应该苦一苦，多学点东西，技术才能进步啊，现在的年轻人和我们那时候不一样了，我们当时可没有怨言。再说其实是问一问态度，又不是一定每天都加班。还没来就挑三拣四的，我们是请能干的员工的，不是请大爷的，肯定不行。面试者却想：面试的时候就提加班，是不是一定会狂加班啊。天天这么累，身体越来越弱，没有时间找女朋友，悲剧啊。不会是血汗工厂吧，工作拼的是质量，不是时间啊，天天加班的Team真没法待啊。而且天天加班，哪有时间自我成长呢，时间长了就真成了苦力了。

以上面试中的种种矛盾，说白了就是立场问。公司自然认为，你面试者既然是来找工作的，当然应该站在公司立场上想问题，事先了解公司的背景，尽量把自己的长处和价值展现出来，并能够让公司很好的了解和接受，这都是面试者的责任，作为一个好的面试者，理当如此。当然面试者也有充足理由，你们公司是招人才的，我是做过很多工作的，也是很有能力的，挖掘出面试者身上的亮点和价值，是一个好公司责无旁贷的。然而很可惜，时间往往有限，即便是面谈几轮，从开始到结束，加起来也没有几个小时，很难要求双方都能够一下子精准的站到对方的立场上去，矛盾在所难免。很多工作经验比较长的同事都表达过类似的观点，找工作这东西，职业生涯初期是看技能，越往后越像谈恋爱， 就是要双方看对眼儿。

有的读者说，既然面试中是因为时间有限，那工作中，领导和员工的相处时间多了，就会不那么对立吧。当然情况会好很多，但是如果处理不好，工作中，双方还是会出现沟壑。

例如任务的分配问题。当新员工入职以后，领导这时候往往还不太敢于将核心模块交给新员工，一方面此员工对项目还不是十分熟悉，一方面对于员工的具体执行力还不能完全建立信任。毕竟，领导是这个项目的最终负责人，项目做不好，难逃责任的首先是领导。所以，一般情况下，先给新员工一些边脚的项目去做，以考验能力，并根据反馈决策此后的任务分配。然而此时的员工是意气风发，挽起袖子准备大干一番，然而边角料的活让他们感到沮丧，因而往往对待这些任务不十分尽心，觉得项目没有那么重要，能大概完成就行，这反而增加了领导的担心和忧虑，并试图通过进一步的非核心工作来增强对此员工的正向评价，如果员工不能及时调整，将继续增加双方的隔阂。一部分领导这个时候会选择做一定的调整，也即试图给予员工一定的挑战性的工作，然而既然让步来自于领导，则期望也会相对较高，如果对于此次的挑战性工作，员工能够达到甚至超出领导的期望，则双方的关系会得到一定的改善，然而如果不幸，员工并没有很好的完成此挑战性的工作(没有完成或者时间使用比较长)，即便是因为此类挑战性工作的概率问题(一般对于有一定难度的调研，prototyping, bug fix，即便交给有经验的员工，也是有一定失败概率的)，也会使得双方的信任急剧下滑。领导可能会想：刚来干活就挑三拣四的，简单的任务不愿干，难的任务要干好长时间，也干不好。总要简单的任务干好了，才能给你更有挑战的工作啊，要不然怎么放心交给你啊？而员工则认为：天天让我干这种没有技术含量的工作，我的技术都快浪费了，让我怎么踏踏实实干下去啊，如果让我干核心模块，我一定会全力以赴的。

再如对于技术选型，作为领导往往比较保守，因为项目需要在一定的时间，一定的资源的情况下达到一定的质量向上级交代，因为上级大多以黑盒的方式看待项目组的成果，所以领导希望技术方面要慢慢改进，而不是一步到位的求新，必须在有一定的把握的基础上，才放心使用某种技术。而作为技术导向型的程序员，往往乐于追求最新的技术，框架，设计模式，并期望尽快的用在项目上，所以对于领导的技术选型有时候会抱有鄙视的态度，会怠慢甚至拒绝使用当前的技术方案，却很少有员工会利用业余时间，真的自己开发一套来证明自己技术方案的优势，而多在技术讨论会上侃侃而谈。于是领导抱怨员工工作不认真，纸上谈兵，总要整个team的产品拿的出手，才是对大家都有好处的嘛。而员工抱怨领导不接受建议，技术落后，没有魄力，这种破东西不值得去做。

再如任务监督，由于对整个项目的进度和质量负责，领导总是会迫不及待的知道每一部分的状态，从而调整进度或者资源，而程序员们多是过于乐观自信并且不太乐于交流的，喜欢埋头自己干，因而时常领导总会走到身边问进度和困难，或者每天开会，或者要求写daily report，这有时候会让程序员不厌其烦，并认为这是对他的一种不信任，心想：任务既然交给了我，用人不疑，疑人不用嘛，到时候给你不久行了嘛，还整天问啊问的，每天还要花半个小时开会，半个小时写daily report，这是对技术人员的不尊重。而领导却想：又过去一天了，不知道这些模块都做的怎么样了，如果再不提前一段时间整合，可就真的来不及了，谁谁谁的daily report又没发给我，明天得问问。

再如绩效考核，在日常管理中，管理者多会选择采用鼓励为主的激励方式，当任何一个员工完成了分配的任务后，well done此类的邮件是常有的。但其实在管理者的心目中，此well done非彼well done，有的员工能力一般，所以分配一些相对简单的任务，因为其努力工作而顺利完成，有的员工能力较强，专啃硬骨头，战绩不错但非每战必胜。尽管这种well done式的管理平时人人有面子，大家很和谐，但是一到年底考核，需要加薪升职的时候，就必须区分个名次，决出个胜负了。当总是收到well done邮件的员工拿到绩效一般的评价的时候，往往会心里不服气，心想：你每次分配给我的任务我都很好的完成了，难道这还不够么？说我的能力一般，能力不就是在平时的任务完成中体现的么？我的任务简单？哪有那么简单啊，你不亲自做，不当家不知柴米油盐贵啊！就算是简单，也是你任务分配的问题啊，不信你给我硬骨头试试，照样给你啃下来。再说说我能力一般，你平时早说啊，早知道是个普通评价，用得着我每天加班加点的干啊。领导则心里想：能力和成绩大家都看在心里，自己当然应该有自知之明啊，平时well done是给你的鼓励啊，现在告诉你能力的差距也是对你有好处的啊，需要你继续努力啊。现在简单的活你都要加班加点，难的活你不得累死啊，只要你继续努力，以后会给你硬骨头啃的嘛。

当听说了很多这种的例子的时候，发现真的是婆说婆有理，公说公有理。到底是谁对呢？到底是先有一个好的公司或者好的领导，才配招来好的员工并为公司或者团队全力以赴呢(要一流的人才为你工作，当然要高薪水，良好的环境和完善的管理，君不见某某公司，为啥牛人都去他那儿了啊)？还是先有好的员工，肯全力以赴，才能使得公司和领导乐意提供好的薪资和机会呢(只要你技术好，工作努力，哪里没有机会啊，君不见某某先进工作者，那无论薪水还是职位都是快速增长啊)？到底是先因为公司没有良好的管理，薪资和机会，才使得员工不肯努力工作呢(就你这里，管理混乱，还这么点钱，还想让我加班加点玩命啊，我还不如晚上看看书，早点跳到更好的公司去呢)？还是先因为员工没有全身心的投入工作，才使得公司或者领导不肯提供良好的薪水和机会呢(你看你这工作能力和态度，到哪里能混得好啊，你还嫌钱少，就你能找到更高的工作吗，你总要能力上来了，才有升职加薪的机会啊)？这真是个鸡生蛋还是蛋生鸡的问题。

此类问题各行各业都有，但是在IT行业表现相对明显。因为无论是管理者，还是被管理者，大家都是程序员出身，而程序员大多有一个特点，就是完美主义倾向。想想我们在coding的时候，是不是总是试图花费蛮长时间设计一个自认为完美的架构，使用某某设计模式，在尚无需求的情况下，考虑大量的扩展性。当此架构使用一段时间后，随着需求的增加，已经被改的不那么完美了，尽管时间有限，进度很紧，却忍不住加班加点重构一番，重新达到另一个完美的架构，如此往复。

完美性倾向的一个表现就是，希望一步到位，达到期望，宁缺毋滥。这种态度对于代码来讲，是值得鼓励的。然而对于人与人之间的交流，则往往效果不佳。首先每个人有每个人的情况，每个人的理想状态，别人没有义务，也不可能很快的站到你的立场上，达到你的期望，你的理想状态不一定是别人的理想状态。所以不可能达到理想状态，而只能达到双方都满意的一个中间点，这就需要不断的交流，沟通，商量。其次，这个过程不可能一步到位，而是慢慢的建立信任，大家都向满意点进行努力，并最终达到。因为每个人都不是完美的，你的员工可能是一个没有职场经验的，可能技术不足，可能沟通能力有问题，你的领导也可能刚刚上任，没有太多的管理经验，不可能达到教科书上管理者所达到的公平公正，只要双方都有意愿妥协并合作，就可以了。最后，宁缺毋滥是不行的，不能一看不是我的菜，就彻底放弃，领导不能看的员工有能力或者态度问题，就打上标签，不给机会，试问如果员工都是雷锋，还要领导干嘛。当然员工也不能到一家公司，一遇到不满，就想跳槽，试问哪里不存在各种各样的问题呢，跳槽能解决一切吗。这个世界上，只要是人与人之间的事情，大多都可以商量，只要通过多次沟通，建立信任，总能够找到双方都满意的结合点，使得双方都受益。

对于工作中的例子可能不太好理解，我常常举身边的例子给做管理的朋友。每个人都有三两知己，要好的朋友的，朋友之间互相借个三五千块钱应该没有问题的。那我们假设一种场景，就是你和你的好友现在是不认识的，你的好友走在街上，你径直走到他面前，一步到位的表示：“你好，请你做我做好的朋友吧，借给我3000块钱”。你的朋友一定觉得你神经病：“你以为你是谁啊，上来就向我借钱。”，你接着会这样想：“连3000块钱都不肯借，还想做我的好朋友，没门。”这不正是领导和员工之间经常有的心里活动吗？员工：“我一定会成为最好的员工的，把核心项目，高薪，培训机会都给我吧，我不会让你失望的”，领导：“刚刚毕业，你以为你是谁啊，还没做出贡献就要这要那的。”员工：“一个既不肯出钱，又不肯培训员工的公司，绝对不值得你去工作。”当然这个例子也可以从另外一个方面开始，领导：“我们是一家不可多得的很有发展的公司，来我们团队工作吧，以后机会大大的，不过你要严守纪律，加班加点，忘我工作。”员工：“你们把自己当成什么啦，上来就要求加班加点，人家某某公司福利这么好，都没这么说。”领导：“一个都不想努力工作的员工还想有出息，没门。”如果真如这个例子，那么你和你的朋友可能永远不会成为知己，而领导和员工也不可能精诚合作。然而现实却告诉我们，你和你的朋友最后确实成为了知己，那领导和员工之间就不能进一步发展么？想想你和你的朋友是如何发展到今天的呢？你们可能最初在餐馆认识的，双方只是寒暄：“你好，你也住这个小区啊。”当在同一个餐馆碰到的次数多了，便到了一个餐桌上，聊聊各自的背景，起初还可能是AA制，后来熟了，我请你100，你请我100，我回老家给你带500元东西，你去旅游给我带500元东西，时常聚会，时常聊天，直到有一天，你需要3000元去应急，相信得到的答案应该是没问题。所以领导和员工之间的关系也需要经历这么一个过程，通过不断的沟通，建立信任，互相认同，互相商量，互相妥协，最终在一个双方都可以接受的点上，达成合作。

对于领导和员工之间的关系，在组织行为学中，有个绩效-工作满意反馈环：

 

左面称为良性循环，员工在有了好的绩效后，领导给予奖励，员工认为这些奖励是同他的努力匹配的，从而更加满意，更加努力，从而有了更好的业绩。

右面称为恶性循环，员工在有了不好的绩效后，领导给予惩罚，员工认为惩罚是不合适的，于是更加不满，更加心不在焉，从而有了更差的业绩。

所以，好的领导和好的员工，并不是鸡生蛋，也不是蛋生鸡，不能一步到位的完美合作，而是应该通过不断的沟通，双方都争取进入良性循环，互相督促，共同进步。要进入这个循环，可以是领导率先发起，也可以是员工率先发起，最后达到一种状态，即：员工深信，自己的每一份努力必将能够得到领导的认同，得到应有的回报，所以可以放心大胆的投入工作，不用担心自己的血汗打了水漂，而领导也深信，自己的每一份激励(加薪，升职，机会，培训等)，必将能够使得员工更加努力，做出应有的成绩，所以可以放心大胆的投入资源，不用担心肉包子打狗，一去不回。

这种良性循环的一个要点，就是信任。信任的建立是缓慢的，是需要从双方接触开始，通过不断的沟通，一步一步建立起来的。而信任的失去是比较容易的，在良性循环中任何一个节点数次破坏，就会马上进入恶性循环，比如员工几次没有很好的完成工作，或者员工认为奖励不怎么公平等。在恶性循环中，员工深信，领导已经对自己有看法，自己无论如何努力，都不可能有好的回报，索性不努力，还是跳槽吧。而领导也深信，对这个员工已经仁至义尽，无论自己如何给机会，都不会有任何效果。

更可怕的是，信任是领导和员工双方沟通的最后一条路，一旦失去信任，进入了恶性循环，便几乎不可挽回。因为双方彼此已经不会相信对方的话，那么再多的管理方法，沟通方法都没有用了。这就像两台机器网络通信，如果双方加密解密算法使用错误，双方都不能解析对方发过来的任何包，则包中的任何信息，无论是好是坏，在对方看来都是乱码，都是没有意义的了。我们也许会看到这样的情形，员工早有去意了，即便领导说：好好干，年底给你升职。员工也会毫不在意，心想：又要忽悠我加班加点啊，你的泡泡吹得不是一天两天了，哪次说了算了，别以为我还会相信你。或是领导已经将某员工排在所有员工的最后一名了，员工如果提出：如果能让我干那个核心项目，我一定会全力以赴的。领导也多会敷衍过去，心想：你给我捅的篓子还不多啊，还想干核心，现在的这点能够不出错就谢天谢地了。

所以，当良性循环中任何节点发生问题的时候，需要在信任丧失之前，积极沟通，争取早日修复，而且对于这个循环，不能一劳永逸，而是时时勤拂拭，莫使染尘埃。然而这却是非常困难的，因为你作为领导，天天坐在办公室里，如果高高在上，员工对你敬而远之，开会一片和谐，One on One形势永远大好，下面则暗流涌动，已经n多人不满，意欲跳槽，你却无从得知。所以，你要采取相对民主的领导风格。当然所谓的民主，并不是让领导者逃避责任，放羊式的管理，而是相对于专制型的领导风格来讲，在平时的项目管理中，就注意充分信任员工，让员工更多的了解项目的全貌和总体目标，而非仅仅其任务模块，多倾听员工的声音，采纳合理的意见。在工作外，能够多参加员工的活动，而不是天天板着脸，似乎唯有不苟言笑才能体现出威严和等级。要争取让员工不怕你，敢于在你面前说话，你才能在第一时间内了解到团队的细微变化，防微杜渐，使得良性循环得以保持。