An image to describe post 再谈“上不得台面”的技术领导经验

2019年,首尔

之前写了《 总结几点“上不得台面”的技术领导经验》,反响似乎不错,甚至有许多朋友说“早点看到就好了”。看起来,身处同样的行业,就有同样的困惑和烦恼。

今天,我再补充几点“上不得台面”的经验,希望能帮助大家少走弯路。

第一,不畏惧招聘技术比自己好的人。

技术行业有句流行的口头禅:Talk is cheap, show me the code,意思是“有本事别吵吵,放出代码才算真英雄”。这句话其实不仅是口头禅,更被许多人引为座右铭。确实,技术不骗人,无论水平高低、方案好坏,如果单纯靠说很难的出个公认的结论,那么就写代码,比拼硬功夫,然后可以高下立见。这很客观,也很现实。

但它也有不好的结果,就是部分技术领导心里有压力,凡事以代码优先,所以很怕手下的人技术比自己好,争论起来让自己丢了面子。

在这方面,反而是不懂技术的领导更占优势,因为他反正不懂技术,认定“少废话,我就是要这样”就好了,手下的技术人员哪怕有抱怨也不怎么会争论。

倘若领导懂技术,手下的技术人员如果不认同,很可能会摆出各种数据、逻辑、资料来分析,说明他的观点,一定要从技术上与你争个高下。此时若是手下技术比较好,领导多半会觉得难堪、丢面子。所以有不少团队里,领导者就是团队的天花板,一个“更能打”的都没有。

技术领导者有这样的心理不奇怪,但这种心理并不健康。要知道,“技术领导”仍然是“领导”,仍然需要调动资源、作出决策、承担责任,如果过分担心手下技术太好,提出不同意见会让自己丢面子,不好安排工作,那么这样的“领导”其实是不称职的。

我们也可以换个角度来看。技术工作是脑力劳动,是需要调动创造力的。如果手下技术都比自己弱,那么他们充其量只能成为肢体的替代,而绝对不能成为头脑的扩充。我的一个外国同事说,“这样的领导只需要laborer而已”,这个词我印象很深。

如果真的出现这样的领导,那么不管项目再大、团队再多,需要的脑力和创造力都只能唯一来自领导者本人,既增加了领导者的负担,也增加了工作的风险。这样的局面,是任何公司都不希望看到的。

所以,招聘和驾驭比自己技术更强的人,是技术领导者必须闯过的难关,技术上、心理上都是如此。注意,我说的不只有招聘,还有“驾驭”。刘邦可以放心招韩信到自己阵营任用,但是刘备招个曹操当手下多半会是悲剧,而这样的悲剧并不罕见。

第二,不要羞于谈钱,而应当善于谈钱。

技术人员的普遍特点是喜欢与机器打交道,不善表达,羞于谈判。若是涉及到钱的问题,就更是难以开口。但是,这并不意味着他们不看重钱。如果认为他们不开口谈钱就是不在乎,那就大错特错了。

以前曾介绍一个技术不错的朋友去大公司,技术面试都通过了,HR了解了他的期望薪水之后问:“你为什么期望这么多的薪水呢?” 瞬间他面红耳赤、夺门而出。这反应把大家都吓了一跳,完全不知所措。

事后了解才知道,原来他觉得HR问这个问题是认为他要价太高,故意为难自己。其实,HR只是单纯希望了解一下原因,再考虑如何定薪酬包,不管你答刚生了小孩,或是刚买了房子,甚至哪怕是“希望对得起自己之前的努力”,都不是问题。

所以技术人员必须能谈钱,会谈钱,虽然这很难。

对这个问题,我们当然可以采取“分布式”解法,期望所有技术人员都能认清这一点,或者有强制培训,告诉大家如何谈金钱相关的话题,但这多半是痴人说梦。

或者,我们也可以使用“集中式”解法,就是让技术领导学会和掌握如何谈钱相关的话题,无论对上还是对下。相对来说,这种解法的成本会更低一些。

技术领导懂得如何谈钱的好处很多。对下,引导员工说出自己的真实感受和想法,把握他们在经济上的期望,有必要的时候做一些调整;对上,努力为自己的团队和员工争取利益,尤其让避免让不擅长谈钱的员工直接面对专业的HR。对上对下,都可以很好保证团队的稳定性,也让公司的福利能够更有效果。

我还见过这样的例子。技术领导在江湖上有名声,所以入职时公司给了很好的待遇。而且,因为技术领导的名声,也确实吸引了不少人前来投奔。但是,技术领导在平时工作中却忽略了为手下人争取利益。结果团队技术骨干不久就纷纷离职,或者被其它公司挖走。这实在是非常可惜的事情。

要避免出现这种情况其实不难,只是需要技术领导能够有勇气、有办法、有能力去谈与钱有关的问题。

第三,“系统-流程思维”并非唯一,学会从利益格局和价值链条的角度看待工作。

技术人员最喜欢谈的就是“流程”、“规范”、“系统”、“设计”,大家追求的是以简约、规范为美。面对乱糟糟的局面,直接动手当然是最快的,但仔细思考、拿出详细设计再全面推动落实,这种系统化的办法,往往能从根本上解决问题,也是技术人员的价值所在。

也正因为如此,技术人员往往有非常浓重的“系统-流程思维”的惯性。这样有好处,也有坏处。因为在系统和流程世界里的游戏规则是逻辑,而公司总是在商业世界里的,商业世界的规则是利益。如果逻辑和利益不一致,很可能就会产生问题。

有朋友在公司担任技术领导,负责公司经营业务的全面流程化设计和推动。之前,经过充分的了解,大家已经搞清楚了公司的业务流程,并且拿出了设计方案。

所以在这位朋友看来,最难的部分已经解决,剩下就是开发系统,然后按部就班推动各个部门配合落实即可。尽管困难重重,他也确实推动了两三个部门接入系统,看起来系统的全面上线应当只是时间问题。

不料他迅速就碰到了大钉子,甚至差点把自己陷进去,而且根本搞不清楚自己为何会跌得如此之惨。真正的原因,在几个月之后他才明白。

原来在系统设计图里看起来毫无差别的部门和团队,在公司利益格局里分量截然不同。有两个团队一贯作风粗野,对于系统化的事情不甚关心,所以之前谈落实计划时也没有提出多少反对意见。

但是因为市场形势变化,这两个团队偏生是目前公司创收的主力团队。他们本来就不习惯系统化、流程化管理,只是虚以委蛇,现在更是“挟洋自重”,制造出各种或明或暗的阻力。

一方面是暗流涌动、波光诡谲,另一方面,技术团队仿佛“不知有汉,无论魏晋”,还在按照原来的节奏推动。直到有一天,阻力变得足够大,量变产生了质变,结局就非常可惜了。

身为技术领导者,尤其是中高阶的技术领导者,务必学会从系统和流程的世界里适当跳出来,放下单纯的逻辑,把利益格局和价值链条看清楚。

第四,要学会用“别人听得懂的语言”沟通。

技术行业有自己的文化,这个行业的人也有一些自己的语言。比如常见的各种术语、缩写,还有一些“不足为外人道也”的说法,比如表达某种感情时说select finger from hand where id = 2,懂的人当然明白其中妙趣,不懂的人会以为在看天书。

但是我们也需要知道,这种沟通方式仅限于行业内,甚至一些专门的说法仅限于特定的公司、部门、团队。外人一旦遇到这种说法,多半就会选择彻底放弃——确实有些人不会放弃,但我们无法苛责选择放弃的大多数人,想想有多少程序员一看到命令行界面立刻放弃就知道,这其实是普遍心理。

按照流行的“领域驱动设计”方法论,要能够进行领域驱动设计,关键前提是要构建通用语言(Ubiquitous Language)。如果语言都不统一,所有沟通和协作都无从谈起。可是,非专业人员往往又对技术术语望而却步,该怎么办?

我的经验是,技术领导者需要多走一步,学会用“别人听得懂的语言”来沟通。工作多年之后我才发现,有几种沟通方式是最通用的。

一种是按先后顺序,比如“第一要做什么,第二要做什么……”,无论对方懂不懂术语,都可以知道工作的先后顺序。还有一种是按层级,比如“最上面是什么,然后下面是什么,再往下是什么……”,这样可以很直观理解各项工作的依赖和外延,讲清楚轻重缓急。如果能像我在《 文不如表,表不如图》中说的那样,以示意图来表示,沟通就更加方便了。

此外,能想出精当的比喻也是对沟通相当有用。

我之前供职的公司曾经与国外某大服务商对接业务,对方很大牌,规定只能由负责对接的业务人员去洽谈。但其中又涉及一个技术细节,就是“要求数据以XML格式提供”。业务同事一看XML这种缩写就打退堂鼓了,认为自己完全理解不了。

结果,我随手做了一个XML通过XSLT(这例子如今看也确实太老了)转HTML的例子,一边演示一边告诉她:“如果我们要的报表是一把伞,XML就是伞骨,只是没蒙上伞布而已。” 几分钟后她就明白了,然后再没有任何担心,可以很自信去代表公司谈这些细节。

这还只是具体工作中使用“别人听得懂的语言”,如果有能力再深一层就会发现,在商业中有一种“人人都听得懂的语言”,那就是财务的语言——做这个事情要花多少钱,能收获什么。无论什么问题,什么场合,对方什么身份,基本都可以基于这种语言来沟通。

我曾经很排斥这种语言,认为技术应当尊重自己的规律。后来才发现“排斥”是因为不懂,一门心思想着把技术做好,却给不出关于预算和收益的任何分析,其实说法很苍白。相反,如果懂得了财务的语言,倒是能更好地尊重技术规律。

最简单的,一味说“我们应当加大投入,消除技术债”,说服力远远不如“我们技术团队目前的成本是多少钱,明年应当把预算上调多少,经过计算,投入这些资源消除技术债,未来几年可以从招聘、运营、维护等方面节省多少钱……”

我曾在某本书里看到一句话,印象很深:“抽象,就是把不同事物深挖到一个程度,然后可以找到共性,把对一个事物的理解嫁接到另一个事物上”。所以从这个角度来说,能够用“别人听得懂的语言”来沟通,也意味着对自己的工作有了足够深的抽象。身为技术领导,应当重视这种能力。

《反脆弱》中有个观点:只有脆弱的人才会每时每刻努力证明自己是正确的,反脆弱的人则会时常思考自己还有哪些地方做错了,哪些地方可以改进。对此我是深以为然的,以上写的这些经验,有许多就源于自己的血泪教训——不敢直接谈钱导致该拿的没拿到,没搞清利益格局结果辛苦一场反而踩雷…… 今天把这些写出来,只要能启发哪怕一位同行,也是很大的安慰了。

延伸阅读

总结几点“上不得台面”的技术领导经验

文不如表,表不如图

我所理解的技术领导力

An image to describe post 再谈“上不得台面”的技术领导经验

如果您认为本文有意思,欢迎长按识别上面的二维码订阅。

“余晟以为”虽是个人号,但只用心做原创,不虚张声势,不故弄玄虚,不带节奏,力求定期更新,只为和你一同探索世界,分享致中平和的观点。