“技术领导”和“技术管理”
文/余晟
关于技术领导力已经有很多的讨论,我自己也写过好几篇文章。这次我避免“大而全”地讨论技术领导力,只简单谈谈技术领导力的几个主要侧面,供大家在自己的工作中参考。
首先要明确的是,我们谈的是“技术领导”而不是“技术管理”。
“领导”和“管理”是不同的,两者的区别虽然已经有很多的讨论,仍然有很多人不清楚,所以有必要再次强调。“管理”通常描述的是为着某个特定目的来进行周密的组织安排,而“领导”的目的更加抽象,手段也更加多样。如果你去看过工厂的生产线就会深刻体会到,把工作拆分到岗位,给每个岗位定下操作规程,再把人落实到岗位,这就是“管理”。与此相反,带领一群人用创造性的方案高质量地解决问题,并且让团队和个人得到成长,这就是“领导”。
对于技术团队来说,“管理”当然必不可少,但“领导”显然更加重要。因为技术团队要面对的往往是全新的问题,必须靠全员开动脑筋,探索寻找更新的解决方案才可以完成任务,“组织”只是在这之后的完成任务的具体安排而已。对优秀的技术团队来说,虽然它解决的不是重复的问题,但工作效率一定是越来越高的,不可能也不应该原地踏步,做到这一点离不开个人和团队的成长。
在一些技术公司存在着对“执行力超强”风格的膜拜,这无可厚非。但在大部分技术人员的内心里,这种风格更能多是“技术管理”,而无关“技术领导”,大家不认为这样的“领导者”有真正的“领导力”。所以身为技术领导者,一定要把握好“管理”的份量,留出更多的精力给“领导”。
明确了“领导”和“管理”的区别就会知道,“领导”比“管理”难度更大,因为管理很多时候是在解决重复的问题,是有章可循的,而领导经常要面对新问题、新形势,而且没有严格的规章可以遵循。不幸的是,在各种“领导”里,技术领导的难度是高于平均水平的,因为它的对象是技术人员,技术人员都是知识工作者。
“知识工作者”这个定义是德鲁克提出来的,按照德鲁克的说法,知识工作者与从事简单重复劳动的工人不同,他们需要解决全新的问题,需要具备较强的学习知识和创新知识的能力,这是一种以足够知识为基础,以严密思维为辅导因素,以灵感为触发条件的能力。所以知识工作者的劳动兼具知识性、创造性、灵活性等等多种特性。对知识工作者来说,通常只能管理目标,而不能管理过程,所以不要指望严格的操作规程来约束他们。传统的管理虽然也要求目标,但相当强调整齐划一的过程,以过程来保证结果的达成,这种做法与知识工作者所要求的灵活性和创造力是冲突的。
程序员(技术人员)就是明显的例子,没有多少程序员喜欢工厂式的工作环境,他们要求有舒适的办公空间,良好的硬件设备,工作时间还得尽量自由——上班时间上上网、聊聊天都得容许,而且大部分程序员都承认“一天能有 4 小时专心写程序就很了不起了”。这些要求看起来“好不正经”,但如果做不到就难以写出好的程序,至少能写出好程序的程序员不会选择这样的工作。所以,尽管从传统的角度来看技术人员确实“难以伺候”,但这是技术管理者不得不接受的事实。这时候应该怎么办?在我看来,技术管理者要做的、能做的就是找到靠谱的、有足够追求和内驱力知识工作者,提供良好的工作环境,然后耐心地等着美好的事情发生,决不能揠苗助长——虽然很多时候我们无可避免地有揠苗助长的冲动。
那么,技术领导者是不是必须对技术人员放任自流了呢?答案当然也不是。
任何工作成果的严格产出,都离不开约束。我相信大家都见过这样的场景:一个团队里,大家技术都不错,但彼此看不顺眼,或者彼此工作方式相差迥异,结果团队的战斗力相当低,什么也做不出来。具体而言,这可以说是“管理”的问题,没有能落实工作计划;但考虑到上面说的知识工作者的工作特性,主要的问题还是技术领导没有能把整个团队给凝聚起来,只是一盘散沙。
个人对于技术有不同的习惯和看法,这很正常。但是如果大家在一个团队内工作,这个团队就必须有共同的工作习惯、方式、价值观,它们无所谓对错,但不可或缺,也不容模糊。做技术的人往往都有“分出对错、辨明高下”的天性,所以小到代码规范,大到架构设计,常常都要陷入旷日长久的争执当中。这样的情况对于技术团队来说是有害的。所以身为技术领导,必须有能力、有动力去及时解决这些问题,保证团队从代码规范到架构设计等等问题都有明确决策,帮助大家树立共识并督促执行,同时化解个体的反感——这份工作很不好做,但不得不做。
既不能像管理工人那样严格规定,又不能放任自流,其中的分寸究竟在哪里呢?这个问题确实很微妙,但也不难回答,主要需要把握两个方面。
第一个方面是规定的程度,应当给被领导者留出适度的空间,过分细致让人没有自由发挥的空间当然是不行的,过分放松完全依赖被管理者的自觉性和自协调性也是不现实的,所以技术领导者最好从“目标管理”的角度思考,为了达成团队的目标,为了让被领导者完成自己的目标,应当给予多少自由空间。最简单的是设身处地地思考,为了完成目标,你作为领导者希望施加怎样的约束,作为被领导者又需要有哪些自由,把两者有机结合起来,就能找到分寸的所在。
第二个方面是团队协同,也就是如何让彼此不同而且乐意“较真”的技术人员形成共识。技术领导者,尤其是技术出身的技术领导者,虽然明白“目标管理”的重要性,但通常对于工作习惯和工作方法有自己的认定,并且希望推广这种认定成为团队的共识,但是很多时候,领导者自己认定的工作习惯和工作方法,未必是团队里其他人真心认同、乐意接受的,如果只是勉强服从,长期来看团队是难以有凝聚力的,技术领导者也是不合格的。更好的做法是,通过与团队的交流,逐步选择并确定共识,并像滚雪球一样,不断推动这种共识落地、前进、赢得更多人的认可,慢慢依照这些共识凝聚团队,淘汰不认同的成员。要做到这一点,技术领导者必须高超的沟通技巧来达成共识,有宽广的胸怀接受与自己不一样的共识,还必须有精准的眼光判断这种共识对于团队的利益。
技术领导确实不好做,但这就是现实,甚至管理大师德鲁克都说过,知识工作者的管理和领导很难有定论,这个将是 21 世纪大家要面对的难题,何况技术人员还是知识工作者里相当有创意、相当依赖灵感和自由的一群人。但是,考虑到技术已经在我们的生活中扮演了那么重要的因素,考虑到技术人员大多是那么的单纯可爱,对技术领导者们来说,提高自己的技术领导力,既是义不容辞的责任,也是让人迷恋的诱惑。
本文文字及图片出自 微信公众号
你也许感兴趣的:
- 技术领导必须更懂技术吗?
- 【译论】杰出程序员的秘诀
- 【外评】我是程序员,我很笨
- 【译文】别再装得像你很有名
- 【译文】使用你的药水和卷轴
- 【译论】各种拖延症的建议对你有帮助吗?
- 【译文】为什么手写更有利于记忆和学习?
- 【译论】如今,是否有充分的理由在新项目中使用 C++ 而非 Rust ?
- 【译文】角斗士风格面试
- 王垠:我为什么不再研究编程语言(PL)
你对本文的反应是: