每一个公司，特别是小型公司，都会欢迎“英雄”式的员工。这些“英雄”式的员工，一个人可以挽救公司的销售年报，一个人可以解决客户challenge多日的产品问题，一个人可以做出客户强烈要求而迟迟不下订单的产品功能——“英雄”式的人物不用说是老板的眼中红人了，很多时候简直可以说是公司的救命稻草。

　　那么“英雄”式的员工对公司是不是有百利而无一弊呢？

　　我认识一个小软件公司亚太区的技术总监，是一个在亚洲的欧洲人，聪明绝顶，不是CTO胜似CTO，他对公司产品的精通程度，以及对软件技术的掌握和钻研远远超出了常人的水平。他能够利用产品的开放接口，通过预留给客户的二次开发功能，做出比产品出厂功能还要棒的新功能；很多员工说，他做的二次开发的功能比公司研发人员做出来的一次开发后的产品还要棒，还要吸引客户。整个亚太区很多国家解决不了的技术问题都会找到他，他也往往不会让同事们失望，工作没日没夜的，一般都能够利用各种产品技巧和软件技巧解决问题；他自己通过二次开发写出来的一些功能甚至传播到了世界各地的同事们中间，很多其他区域和国家的同事都用他写出来的东西来赢得客户的青睐。

　　这样的员工真的是从上到下，从老板到员工每一个人都会喜欢的角色，整个公司都非常器重、甚至是依赖这个技术总监。

　　这样能干的一个人，你能想到他对公司有什么潜在的危险影响么？

　　直到有一天我和这个公司的一个工程师聊天，他给我讲了这样一个故事。

　　有一次这个工程师和几个人的技术团队一起去一个重要客户那里做一个项目，在项目过程中，客户对一个产品功能非常不满，并且给他们看了其竞争对手的实现方法。这个工程师和其他团队成员都非常触动，因为平时并不是有很多机会接触到竞争对手产品的，看了才知道原来在这方面自己已经被远远的甩在后边了。

　　回来之后，整个团队都认为应该让公司总部的产品决策者知道这个情况，在相关方面必须做出改进，吸取竞争对手的长处，了解客户的喜好倾向，夺回市场。在和公司总部以及相关领导层沟通的时候，和所有公司的天性一样，产品经理在竞争对手的产品和自己的产品之间首先捍卫自己的产品优势，相对轻视客户一线现场的反馈情况——当然这个实验室和一线的协调问题是另一个话题了；在这个工程师积极上下沟通的时候，亚太区技术总监站了出来，他的立场是公司不应该改变这个产品现状，应该保持产品的灵活性，能用二次开发实现的就不用实验室去改原产品，至于客户的需求，他可以自己通过二次开发做出一个和竞争对手产品非常相似的功能。

　　事情后续的进展就很平淡了，技术总监日夜兼程，用他独一无二的、公司内基本没有第二个人掌握的软件技巧，做出了客户的需求；总部的产品经理当然也就没有再去理会这个产品改进的建议和讨论。

　　在此后，这个工程师在其他客户处还遇到过很多次对同样功能的相似需求，这些需求都是可以通过竞争对手产品的内置功能轻易实现的，但是他们却不能完全照搬他们的技术总监给之前的客户开发出来的东西，所以他们还是得在现场付出很大的人力来通过二次开发实现。

　　我询问这个工程师，当时那个技术总监为什么反对把该功能做到产品中去而坚持保持产品原有发展思路，将该客户需求通过他的英雄式的二次开发来实现呢？

　　这个工程师没有告诉我一个明确的答案，也许产品原有的开发思路有它的合理性，也许技术总监非常enjoy这种通过一个个人英雄主义的方式解决问题的状态，而他表态以后，很多他下边的工程技术人员也不好再继续反驳了。但是事实是，他和他的团队成员从此一直为了和竞争对手在该功能上对抗，打得很累很艰难。

　　而且，似乎公司里并没有人意识到这一点，他们总是觉得客户有需求？我们的英雄能解决么？如果需求很紧急，赶快去找我们的英雄！却没有人再次把从根本上解决问题的建议提上日程。

　　故事总是这样，听故事的人听的明明白白，但是故事里的人就不那么明白了。从这个故事我们能总结出一些什么理性的结论呢？

　　首先，别让问题被你的“英雄”所掩盖！

　　很多时候“英雄”就像一个救火队员，没有他们扑不灭的火，但是与此同时，既然火没有着起来，我们也就忘记了去查为什么会着火——既然每次都能把狼赶走，也就忘记了补牢。

　　但是每个人都知道，牢不补，迟早羊会被狼叼走。

　　在上边的例子中，我们可以设想如果这个公司没有这么一个“英雄式”的人物，没有人有能力在现场能够通过二次开发做出和竞争对手类似的功能，要签下订单必须产品经理去充分理解亚洲市场，必须去改变产品，那么是不是这个问题在一个阵痛过后就一劳永逸的解决了。

　　这一点上另一个我们需要注意的是，“英雄”们，你们要理解不是每个人都是英雄，当你们可以去完成一个貌似不可能完成的任务的时候，千万别忘了想一想，这是一个公司，一个团队，这里并不是每个人都是英雄，每个人将来都可能再次面对同样貌似不可能完成的任务，到时候他们怎么办？在英雄们以个人英雄主义的壮举去解决了问题的时候英雄自己也别忘了赶走羊后补好牢。

　　其次，英雄往往是用一种“非流程化”、“非常规化”的方式解决问题，这种情况下我们往往就会忘记了去建设一个正规的流程。

　　一个公司的健康运营，说到底应该依靠一个健康的流程和责任划分，而不能仅仅依靠英雄的非常规的解决问题方式。大多数把目光盯在“目标”和“结果”上的经理们，特别是一些注重业务结果而非公司运营的经理们，他们往往在解决了问题之后忽视了一个正规的流程建设。因为往往虽然问题解决了，但是我们并没有去想一想“问题是不是应该这么被解决？”，“这种解决方式是不是在将来有可复制性？”

　　再次，很多时候我们有了一个够用的“诸葛亮”，就忘记了把更多的“臭皮匠”培养发展成“诸葛亮”。

　　我曾经询问这个故事中的工程师，公司有没有尝试把你们每个人都打造成一个技术总监那样的人物，答案是否定的，公司甚至没有做过类似的尝试。为什么呢？一个原因是，每个人都公认英雄是“英雄”，而“英雄”显然不是每个人都可以当的，领导层不会这样去讲，但是人们的潜意识里是承认这个定理的，所以根本没有往这个方向去尝试；而这个时候如果英雄本身没有意识到这个问题，比如如果这个技术总监本身没有意识到最急迫的事情是让自己的技巧和技能最大限度的传播给别人，那么作为一个公司的整体水平就会越来越往一个“平原上的珠穆朗玛峰”的形状去发展了。事实上，英雄很多时候处于日夜兼程的救火状态，甚至出于自我意识的保护，他们也确实没有这样做过。

　　最后，最实际的一个问题。如果英雄们离开了公司，我们怎么办？问题没有从根本上解决，解决问题的正确流程没有被建设起来，“平原上的珠穆朗玛峰”倒了我们就剩下高度为零的平原了，怎么办？

　　所以，经理们，在你们庆幸你们拥有一些英雄员工的时候，也应该考虑一下这些问题。