如何理解技术领导力

Posted 2023-05-16 IT职场笔记

1）决策力：迅速拍板并为结果负责的能力

 

技术管理者看到的情况，经常不是“两好选其优”，而是“两害取其轻”，要在信息不完全明确的情况下，迅速决定用哪个方案，并为结果负责，同时为了激励士气还不能表露出任何痛苦。

要在这样的情况下迅速决策，而所有产生的问题和压力都要独立承担，而不能给下属，这就是一个管理者决策力的表现。

 

2）沟通力：倾听与准确反馈的能力

沟通是普通管理者最重要的工作，在对下属沟通时，根据员工的性格和成熟程度，准确告诉他的管理问题和对事情的目标、方法以及异常的处理情况。

初级员工需要手把手完整的指导如何去做，高级员工需要使命式沟通，如果沟通方式相反，反而会让初级员工不知所措，高级员工觉得无法成长，而起到反作用。 

在批评员工时更要准确，批评不是发泄自己的压力，对事不对人，有效的批评是帮助员工成长。

如《原则》中提到的“严厉的爱才是最可贵也是最难得的”。

沟通力，就是在合适的时间对合适的人用合适方法说合适的事情。

 

3）影响力：号召管理层和员工一致行动的能力

通过对于业界的影响力以及方案判断和决策不断的验证，建立管理层对于技术整体团队的信任。

这样在决策和预判过程当中，作为技术管理者可以有话语权，可以让公司以合适的技术节奏和技术路线来发展。

对于员工的影响力，是员工发自心底的一呼百应，通过准确的技术判断、正确的管理决策、合适的领导方法让员工信服决策者而不是因为职位的高低而去执行。

 

4）识人&授权：通过人员管理人员，通过别人完成使命的能力

超过百人的高级技术管理者一定不是亲自再做细节的工作，而是通过更多的合适的人员来完成任务。

首先，知人善用是高级管理者重要基本素养，人是否合适在一个岗位上是管理者最重要的判断。

其次，要充分的授权，管理者要和自己的直接下属建立信任，“疑人不用，用人不疑”。

 

什么是授权，我用个极端的例子，哪怕是下属去犯错，你也要眼睁睁的看别人犯错，而自己来承担所有的后果。除非你判断问题超过你的职权范围或者挽回范围，否则你不能直言相告。“看着下属犯错，自己却不能说” 这点是最难的。因为你说了，这些经验就永远是你自己的，下属不在错误中成长，管理者就是永远的瓶颈。

 

是否做到识人&授权，是管理者是否可以管理超过100人团队的门槛。

 

5）坦诚&开放：营造一种氛围，绝对的透明和坦诚，绝对的开放

 

技术管理者不一定是公司技术最强的人，这很好理解，在公司小的时候往往是技术最强的人，

随着技术团队的壮大，如果他还是各方面技术能力最强的人，那么他一定是这个公司的技术瓶颈，会被公司淘汰。

 

6）悟性&个人魅力：悟性与个人魅力是一个管理者的必备的软技能

所有的管理经验都是通过不同的管理实践和反馈中积累起来的。对于同样的一个人或事情，管理者从中参悟到什么，理解到什么程度，是一个管理者是否可以持续提高的关键。所以作为高级管理者，至少留给自己20%的时间在思考，而不是具体做事情，反思自己的决策、沟通、影响、开放当中的问题，是否可以有更好的方法来提高，这样才可以让自己持续在管理岗位上提高。

本文来自博客园，作者：IT随笔，转载请注明原文链接：https://www.cnblogs.com/binyue/p/17405672.html

我所理解的技术领导力

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

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

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

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

评估自己的能力“用乘法而不是加法”，可能初看起来不太容易理解，但也很好懂。人的能力通常是参差不齐的，有长处就必然有短处。要想成为好的技术人员，技术是不能“一俊遮百丑”的。以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的人。我向他说明情况，并说明我们已经修正了程序避免出现这种情况，他验证之后便解除了封锁。有了这段经历，不管是关于纯技术问题还是业务问题，我的思路都开阔了很多，也深刻明白了单纯靠技术是不能“一俊遮百丑”的。

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

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

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

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

https://blog.csdn.net/wave_1102/article/details/73607306