我所理解的技术领导力

　　一晃六年，《技术领导之路》要再版重印了。回想刚刚开始翻译这本书时，我还忙碌在程序开发的一线，对领导技术团队并没有太多经验；如今，也能差强人意地带领技术团队支撑年销售额数亿的业务。一路走来跌跌撞撞，所幸没有中途倒下。思考其中的原因，除去运气，除去身边同事朋友的支持，翻译《技术领导之路》也是不容忽视的因素。

　　很多人都知道，“职场童年”非常重要，一个人最初工作的几年，在什么样的环境里，得到过什么样的锻炼，很可能决定了他整个职业生涯的走向。同样的道理，“领导力童年”也很重要，一个人对领导力的最初接触和认知，也会深深影响他对于“领导”和“领导力”的观点，甚至领导作风。所以，在我还忙于一线开发的时候，通过翻译《技术领导之路》，“生吞活剥”了一整套关于领导力的学说，基本“塑造”了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向，因此也对很多问题有了自己的判断——前段时间和另一位掌管公司技术的朋友聊天，说起那种“执行力超至上”的领导风格，我们都认为，尽管或许能出结果，但不是好的领导风格。

　　怎样成为好的技术领导？《技术领导之路》的作者温伯格给出了一系列的答案。以技术人员的身份，我觉得最受用的几点是：通过写日记来加深自我认识，评估自己的能力应该用乘法而不是加法，从哪里寻找改进所需要的时间。

　　在生活中，我们大多会有一些自己的习惯和坚持，却习焉不察，没有去想过它们是否有道理。然而，如果需要不断改进自己，就必然需要不断观察和审视关于自己的一切，包括习焉不察的坚持。对此，温伯格给出的建议是，每天抽一点时间来写日记，不需要抒情，不需要感慨，忠实记录自己就好。开始我对此也有些怀疑，觉得写日记不过是小朋友过家家。但真正坚持之后才发现收获很大。因为静下心来写日记让我发现，在生活里，自己真正在乎什么，而不在乎什么。有一些东西我很在乎，但成长经历不同的人并不在乎，所以其他人并不是有意冒犯。还有一些东西我不在乎，却是某个人群特别在意的，考虑到其他人的感受，以后还是多加小心为好。

　　评估自己的能力“用乘法而不是加法”，可能初看起来不太容易理解，但也很好懂。人的能力通常是参差不齐的，有长处就必然有短处。要想成为好的技术人员，技术是不能“一俊遮百丑”的。以1分为满分，如果你的技术有0.8分，表达能力只有0.1分，总分可能不是(0.8+0.1)/2=0.5分，而是0.8*0.1=0.08分。如果给你时间把自己的技能提升0.1分，用来提高技术水平，总分可以到0.09，而用来提高表达能力，则可以达到0.16。哪种选择对个人更有利，其实是一目了然的。不幸的是，大家通常在潜意识里更愿意遮挡自己的短处，更习惯于训练提高自己的长处。程序员更是如此，面对非技术问题，他们往往更希望从技术方面解决。仅仅是因为他们更“喜欢”从这方面入手，而没有考虑这样做是否真的有效率。想要成为优秀的技术人员，一定需要能克服情感的抵触，注重补齐短板。

　　我在抓虾网（早年一个很流行的在线RSS阅读网站）工作时曾有过深刻的体验。有一次我们的抓取调度出了问题，抓取新浪博客过于频繁，被新浪封锁了服务器的IP。当时大家想出的办法就是找一大堆代理服务器，通过代理来抓取。从技术人员的角度出发，这种思路是自然而然的。我当时觉得还有更好的解法。于是我尝试给新浪打电话说明情况，一下午的时间打了超过二十个电话，终于找到了决定封锁IP的人。我向他说明情况，并说明我们已经修正了程序避免出现这种情况，他验证之后便解除了封锁。有了这段经历，不管是关于纯技术问题还是业务问题，我的思路都开阔了很多，也深刻明白了单纯靠技术是不能“一俊遮百丑”的。

　　关于改变自己所需要的时间，温伯格的一句话让我印象很深，“如果你想做某件事情却一直找不到时间，那多半是你其实不想做”。想要改变，尤其是自我改变，通常不会像上级布置的任务那样，有明确的压力和期限，所以改变也停留在“想”而已。网络上经常可以看到类似的问题：道理我都懂，但就是行动不起来。所以很多人在纠结，希望有什么办法提高行动力。但是在我看来，要解决这个问题，第一步是承认自己其实不想实践这些道理。

　　如果确认自己想去做这件事情，由苦于找不到时间，温伯格给了三个建议：第一，对已经分配的任务，不要反复纠结；第二，对实现过程中的细节，不要反复纠结；第三，不要让自己的生活被层出不穷的危机所支配。比如对于“缺乏行动力”的问题，如果你真的希望提升行动力，应该首先制定计划，制定好计划之后应该按时推行，在这个过程中可以容忍错误和异常，但不要轻易纠结计划本身。在实现过程中，不要过分纠结细节，比如学英语，捧着一本书刚看了个开头，又觉得要先学语法呢，还是先背单词，还想知道是这本书更好一点，还是那本书更好一点。更重要的是，要想有时间做自己的事情，应当把一切保持在“井然有序”的状态，哪怕平时需要花更多的时间来维护，这样才不会被各种意外所支配。我曾经见到很多程序员，每天忙于改正线上的各种问题甚至乐在其中，却从来不想想怎么让程序保持在“自主稳定运行”的状态，还一个劲的抱怨“工作辛苦，生活忙碌”。也正是因为如此，我才大力提倡程序员要“横向发展”，要操心程序运行的整套环境，才能真正把自己解放出来

　　当然，既然名为《技术领导之路》，温伯格讲得最多的还是“如何成为技术领导”。温伯格反复强调的根本观点是，人不应当被作为机器对待，尤其因为技术工作强调思考和创新，所以技术工作者更不应当被视为机器，而应当被视为种子——蕴含内在力量，会不断发展成熟的种子。所谓领导力，就是创造一个环境，让所有的人都可以发挥出比单干时更大的价值，并不断成长。以此为基础，领导力的培养和发挥，需要注意激励、组织、创新三个方面。

　　关于领导的激励，已经有很多的论述。不幸，通常的激励似乎是从行为主义心理学的角度出发的，认为简单机械的“奖励/惩罚”就可以对员工起到引导和归束的作用。但这种理论其实是行不通的。赫兹博格的“激励-保健因子”理论指出，员工在不同的阶段所看重的方面是不同的，简单说员工刚开始更看重的是个人生活、工作环境、薪金福利等“基本因子”，满足之后则寻求学习与发展、工作乐趣、成就与肯定等“激励因子”，而简单的“奖励/惩罚”在这些方面并不能奏效。更重要的是，因为技术工作的核心之一便是创新，简单的“奖励/惩罚”并不能催生创新。按照我的经验，激励的作用更多是树立正确的价值观，这种价值观既符合公司的利益，又兼顾个人的成长，而且还要能落实到真实的工作中来。

　　在很多公司，有一些程序员是众望所归的“明星”：程序出了什么问题，找他们可以第一个响应，而且他们可以非常投入地解决问题，哪怕加班加点也无所谓。可是如果仔细思考，这样的程序员有不少就是麻烦的制造者，因为他们写不出高质量的程序，只能以“高度的责任心”在线上除错。而且，这样的程序员往往因为态度好、加班多，受到大量的关注和鼓励。还有一些程序员，他们或许沉默寡言，或许不爱加班，但他们总能提交高质量的程序，上线之后就不需要自己再操心。不幸的是，这样的程序员往往不会获得关注，颁发奖励的时候也论不上他们。

　　身为技术人员，很多人都知道两种做法的优劣，但因为外界（领导）没有明确的褒贬，很多人并不敢坚持自己的选择。所以，如果希望成为好的技术领导，一定要注重激励的方面。在日常工作中，技术领导应当持续表扬和鼓励能提供高质量程序的行为（哪怕日常不怎么说话），而不是提交质量一般但努力除错的行为。有这种持续的激励，才有可能塑造正确的价值观，给有潜力但还在摇摆、困惑的成员发出清晰的信号，从而打造高质量、迅速成长的团队。

　　技术领导需要注意的第二个方面是组织。前段时间我和一位MBA朋友聊天，他说很多领导对于招人的定义就是：因为我忙不过来，所以我需要一个人帮我做这个。他评价说：“其实，这类领导需要的不是员工，而是劳工”。用我的话说，这种组织不叫团队，只能叫团伙。

　　既然领导力的表现是创造让所有人都能成长，都能发挥更大价值的环境，当然不能把所有人当成可以互相替换的棋子。按照温伯格的意见，好的组织应当是“全面的（Organic，也可以翻译为“有机的”）”，也就是可以互相取长补短，形成一股合力。假设一支团队里没有产品经理，虽然客户对产品的要求并不是太高，程序员也有一定的产品意识，交付的软件堪称能用。但技术领导应当看到，关于产品的工作其实消耗了开发人员大量的时间，而且开发人员本身并不“愿意”从事产品方面的工作。所以应当考虑补充产品人员，并让产品和开发协调工作，形成1+1>2的结果，提升整个团队的效率。同样的道理，如果团队里多数开发人员都比较沉闷，在继续招聘开发人员的时候，就应当优先考虑开朗外向的性格。

　　组织的全面，还提现在一个方面，即它是自组织的，各级的情况和任务可以在对应的级别自动自发地完成。或者用温伯格的话说：“（在全面的组织）中每个人都能解决问题，做出决策，执行这些决策。而领导不需要对各种问题亲自出面，亲自做决策，亲自执行”。这种观点也可以在其它相关书籍中得到验证，比如Uncle Bob就在《程序员的职业素养》中再三强调，团队要有凝聚力。要想打造全面的组织，有凝聚力的团队，温伯格列出了几种需要警惕的行为，包括“只抓大目标”（特别强调执行力的领导作风就是如此）、把人当成机器来看待（忽略人的情感和潜力）、事必躬亲（下属不应当仅仅是领导完成任务的手段）、奖励低效的组织（回到价值观的树立）等等。虽然我们日常工作中无法做到彻底戒除，但只有尽力避免这样的行为，才能真正营造全面的组织，形成有凝聚力的团队。

　　技术领导需要关心的第三个方面是创新。许多技术领导本身对技术非常有兴趣，所以他们自己在创新方面是没有问题的。但是身为领导，仅仅自己创新是不够的。既然相信人不是机器，既然相信软件开发是需要创造力的工作，那么就应当鼓励每个人的创新，为团队营造勇于创新的气氛。

　　在很多公司，技术领导往往掌握着框架和类库的生杀大权。我听到不少程序员说，自己在网络上看到了很多新的、好的框架和类库，但领导就是不同意。很多时候，这是因为领导没有用过，对此不熟悉，不愿意冒风险，毕竟领导要对公司业务负责。有时候我也确实发现，因为经验等方面的限制，一些程序员提出的创新想法并不实际。但是好的技术领导从来也不应该因循守旧。按照温伯格的说法，即便你用某种方式成功过，也不意味着没有更好的办法来解决同样的问题。所以，身为技术领导，应当鼓励所有人的创新，对于不够完善的创新建议，不能简单拒绝，需要代之以鼓励和引导。甚至在某个问题上，即便自己有过成功经验，心里已经确定了方案，也需要虚心听取其他人的不同建议，更要勇于采纳更好的方案。要知道，这样做并不意味着贬低自己的技术威信，反而确立了积极创新，并且能采纳合理创新建议的工作方式。只有一个人能创新的团队，永远不会强过一支人人都能创新的团队。

　　很多人读过《技术领导之路》之后跟我说：“我觉得这本书写得很好，我也承认作者说的很有道理。但是，这和中国的现实不搭配。我努力去激励了、去组织了、去创新了，却好像对牛弹琴，我领导的人似乎无动于衷。还不如安心当个包工头省心省力”。是的，我承认现实中确实有这样那样的困境，但我也认为这不是安心放弃成为优秀的技术领导的理由，因为有个重点书里没有写到，那就是想要打造好的技术团队，必须对招进来的人有足够高的要求。实际上，在《极客与团队》之类讲述技术团队管理的书籍里都强调了这一点：如果期望打造有战斗力的团队，必须保证大家形成一致的工作习惯和价值观；对这种工作习惯和价值观持续产生负面影响的“害群之马”，是应当坚决予以淘汰和替换的。