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