我所理解的技术领导力

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

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

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

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

  评估自己的能力“用乘法而不是加法”,可能初看起来不太容易理解,但也很好懂。人的能力通常是参差不齐的,有长处就必然有短处。要想成为好的技术人员,技术是不能“一俊遮百丑”的。以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就在《程序员的职业素养》中再三强调,团队要有凝聚力。要想打造全面的组织,有凝聚力的团队,温伯格列出了几种需要警惕的行为,包括“只抓大目标”(特别强调执行力的领导作风就是如此)、把人当成机器来看待(忽略人的情感和潜力)、事必躬亲(下属不应当仅仅是领导完成任务的手段)、奖励低效的组织(回到价值观的树立)等等。虽然我们日常工作中无法做到彻底戒除,但只有尽力避免这样的行为,才能真正营造全面的组织,形成有凝聚力的团队。

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

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

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

it知识库我所理解的技术领导力,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。