技术领导力实战笔记2022_24_22提升影响力信念热情与行动缺一不可
你好，我是观测云CEO蒋硕淼。
在创业的这十多年里啊，我带领我的团队努力达成一个又一个目标。
团队呢规模也从原来的不足十人，发展到现在两百多人。
作为团队的管理者啊，想要带领团队取得成功，首先呢要以身作则。
我相信领导力并不是来自于你的角色和岗位，而是来自于你自身所具备的素质，以及对团队成员产生的影响力。
我曾经呢也在技术管理工作上懈怠过，比如引入一些技术管理的方法软件。
等等我。
当时呢是希望通过工具来代替人在管理中的角色，但是最终发现啊这些只不过是手段，如果不能够有效的去构造整体的领导力和影响力，那么工具的使用呢只会变成流程，无法引领工程师们整个团队也会进入麻木的状态。
想要在团队中构造整体的领导力和影响力，首先啊我们要清楚自己的使命是什么。
领导者必须要先有目标，而后才会有追随者。
比如说我一直认为啊我作为一个具备产品思维的工程师，我最希望呢就是做出世界级的软件产品，这就是我的创业目标，甚至是人生目标。
为什么有些人愿意追随你，去完成你的梦想，你的目标呢？影响力在这其中啊发挥着重要的作用。
如果你是一个对目标很执着，规划很清晰的领导，那么同样追随者呢也会被你影响，他们的路啊也会变得很清晰。
在这个过程中呢，我们首先要做的呢就是让团队的绝大多数成员相信这种相信啊是根据你自己对未来三到五年的判断而得来的。
并且呢能够给大家描绘出比较完整的蓝图。
这个蓝图必须有相对清晰的实现路径。
就像观测云这个产品在开发的早期啊，大家对方向还是很模糊的时候啊，我就坚定的带领着团队，整个团队走出了最初的混沌状态，靠的就是目标和信念。
回过头来看啊，如果没有给团队树立正确的目标，只是单纯靠物质奖励来笼络住团队，缺少使命感，往往是做不出好产品的。
同时，技术管理者啊要以身作则，进入到具体的细节当中。
这个具体的细节呢并不是说需要你自己去编写代码，而是要清楚每一个核心路径节点为什么这么选择。
因为团队里的每个人呢都有自己的背景认知，只有把握住核心路径，才能保证整个团队不走偏，才能让每一个成员了解自己的目标。
并且在他们困惑的时候呢，能够给予适当的指导。
每当我们公司遇到技术问题卡点的时候呢，我都会和技术工程师一起去研究技术文档或者代码。
这时候啊问题解决起来就快了很多了。
也许呢并不是我直接解决了这个问题。
但是技术管理者参与其中所产生的影响力是非常巨大的。
这种举动呢能够让工程师知道大家是在为同一个目标而努力。
他们并不是在孤军奋战，并且啊在这个过程当中呢，我们还会做一些trade off的选择，让大家在思想上统一起来。
在实际的工作过程当中啊，我也特别强调工程化。
所谓工程化呢就是我们要有自我意识，如何通过工程的手段去解决手头的问题。
比如说引入CICD啊，引入啊啊要不要coopernetiservice match啊等等。
当你具备了工程化思维的时候啊，这一切都变得简单了。
我们公司很多的技术文档都是在代码里的认可，发布时候啊啊自然CR渲染到文档系统，这样呢也养成了工程师必须要写文档的习惯。
同理，我们也强调对单元测试的覆盖，除了code解决的问题啊，避免使用UI操作，避免click ops这种工程化的思想。
某种意义上呢也是一种正确的目标，能够让每一个工程师的交付物更加标准，质量更高。
这种工程化呢不需要强迫，在潜移默化的影响下呢，认可这种方式的工程师，自然而然的会向我我们的目标靠拢。
而不认可的人呢也会自动的脱离这支队伍。
除了上面我们说的用自己的目标和信念影响团队外啊，我们还可以从专业能力入手，提升自身的影响力，保持对技术的好奇心。
俗话说文无第一，武无第二。
软件技术领域呢是一个变化非常快的行业，而这种变化呢是渐进的。
但是当你离开技术一线太久也就拎不起来了。
如果技术管理者呢都是从一线的技术工程师成长起来的。
但是有一部分人啊成长为了优秀的技术管理者，有一部分人呢只是成为了管理者，有可能还是个拖后腿的管理者。
因为技术管理者在带领团队的时候呢，是要下决定的，是要下判断的决定使用什么框架，什么工具，什么平台。
如果一个技术管理者不能够时刻保持对新技术的好奇心，充分了解各种技术、各种新技术及其思想。
那么在具体的技术决策上啊，他凭什么来判断？凭过去的管理者当然不行，因为软件行业本身是一个经验，价值很低的行业，你需要呃不断的去更新自己的知识库。
我举个例子，你就知道我为什么这么说了。
之前我遇到过一个技术人员，对于HTTP返回都是二零零，他也不知道具体原因。
事实上呢是因为早年运营商会劫持互联网公司的HTTP来偷流量。
而今天啊大部分的系统呢已经默认HTTPS了，根本不需要在画蛇添足的使用返回二零零。
用正确的IFC的code就可以了也有助于系统的去分析问题。
其实这根本不是一个技术问题啊，而是这个行业里面呢有太多的人在解决问题的时候呢，倾向于依赖经验，而不是根据事实去判断。
对于一个技术管理者来说啊，保持好奇心，关注新的技术，就是最好的修炼，避免受到经验的修断。
我自己的习惯是时常的呢去翻看github的tradings,发现一些新的项目。
注意啊，尽量去看标准的产品的文档和引用，多用google或者bein,而不是使用百度中文事件呢。
由于大量的内容农场问题啊，有很多错误的内容，这往往呢会使很多人误入歧途。
那对于一些有趣的项目啊，我还会去翻看相关的代码。
嗯，毫不谦虚的说啊，我对大部分开源的商业项目呢都有一定的研究，技术管理者呢要能够与时俱进。
这一点虽然很基础，但是非常重要。
当团队的小伙伴向你寻求技术方向的支持的时候呀，在你面前啊对新老技术做出正确的决策时啊，在你给团队分享新的技术趋势时呢，影响力也就一点一点的建立起来了。
另外持续更新自身对技术的理解，也能够给团队带来更好的氛围。
我认为一个有抱负的程序员啊是不喜欢在一个老记横秋的管理者。
手下工作的一个好的技术管理者呢，一定是不断的学习提升，而不是躺在自己的历史功劳簿上。
但是呢却无法在当下做出正确判断的人，想要做出正确的判断。
我们需要通过持续学习了解外部的变化趋势。
同时呢我们也要对内部的实际情况呢了如指掌，内外结合才有效。
这就要求技术管理者要参与到一线的产品技术讨论当中。
古代战争中啊优秀的将领往往都是一马当先胜先士卒的。
虽然在现代战中啊这种方式已经不适用了。
但是在一个技术产品的开发过程中，技术管理者拥有这一点特质，能够大大的提升自身的影响力。
很多时候呢，一个技术管理者通常呢也兼任了产品设计师或者系统架构师的角色，一将无能，累似三军。
同理啊，代码的bug不可怕，但产品设计上的bug或者系统架构上的bug往往难以修复，有时候会导致系统重构，甚至呢会使整个产品失败。
如何更好的避免这种情况呢？这就需要技术管理者积极的参与到一线产品技术讨论中。
因为信息传递啊是会失真的，每个人的认知理解也是不同的。
如果不能够参与到一线产品技术讨论中呢，就很有可能啊会出现互相不认账的情况。
我相信大部分的团队都遇到过，所以参与到一线技术讨论，把讨论的结果记录下来存档。
这样呢既保证了你和团队的认知是一致的。
同时呢既确保了你的认知是连续的。
很多时候啊，如果技术管理者不参与一线讨论，那么就会出现信息长期偏差的情况。
这就相当于是在放任错误的设计，最后啊会造成无法挽回的损失。
大量的技术债呢也就是这么来的技术管理者参与一线讨论，是真正的把这个技术团队的成败的责任给扛下来了。
同时啊也更容易去了解团队中每一个成员的真正能力，了解当前系统存在的风险，以便于更合理的去规划优先等级。
一从创建观测云产品。
开始呢我就参与了大部分的功能设计，整体架构设计，甚至是参与了一个IO模型的设计。
这种参与感呀一方面会让我们的软件更优秀。
另外一方面呢也会无形中激励团队的其他成员，让他们感受到CEO与他们在一起。
大家是一起努力一起投入的，而不是一种单纯的指挥家。
真正投入百分之百精力的人啊，并愿意承担责任的人呢就是最值得信任的人。
希望你在团队中可以成为这样的一个存在。
这里总结一下，一个优秀的技术管理者呢，可以从很多个方面提升自己的影响力，小到为团队解决bug,大到带领团队达成目标，赢得胜利。
但我今天谈的这三点啊。
树立目标和信念，持续学习，保持对技术的好奇心。
参与一线产品研发讨论是提升影响力最底层的三个要素。
没有目标，团队就如同一盘散沙，不持续学习呢就会变得平庸，不亲临一线就了解不到真实的情况，无法让团队真正信赖，你提升影响力也就无从谈起了。
这三点看起来很多人都能够做得到，但落实程度呢用心程度有多深呢。
你可以反观一下你自己，这里有一个思考题，如果你在参与一线讨论的时候，与团队内部的骨干意见相左，你会怎么处理呢？欢迎你把自己的处理方式分享到评论区，你们一起讨论，也欢迎你把这节课分享给有需要的人。