关于工程师与影响力

关于工程师与影响力

原始链接: charity.wtf/2018/08/17/...

(基于昨天的推特长文及随后的讨论，twitter.com/mipsytipsy/...)

我们来谈谈影响力。作为一名工程师，你该如何获取影响力？它长什么样？根基是什么？如何运用或失去它？它与管理者拥有的权力和影响力有什么不同？[0]

当独立贡献者（IC，即非管理职位的工程师）极其渴望转做管理，认为这样才能获取更多信息 并影响决策时，这类问题经常被提及。很遗憾这很常见，但这是一个糟糕的信号。

遇到这种情况，公司需要自我反思。你的组织是否给资深工程师留出了领导和做决策的空间？是否有与管理层平行（至少到总监级别）的纯技术晋升路线？薪资一样吗？有职业发展阶梯吗？非管理人员会觉得你们的决策过程很神秘吗？别想当然，要去问问大家的真实感受。

如果以上都做得很好，那可能是员工个人的认知问题。也许他们不相信你；也许他们之前待的公司只有管理者才有实权；也许他们被"工程师也能有巨大影响力"这种套话骗过并伤透了心；也许他们就是因为种种原因不习惯拥有权力的感觉。

无论如何，如果一个人想当管理者只是为了延续糟糕的权力结构，那你绝对不能让他当管理者。[1]

那么，工程师的影响力到底是什么样的？你的能力是如何体现的？

我这里不谈性别、种族和阶层等复杂的交叉问题，我们只需承认：对某些人来说，行使权力确实比其他人面临更多结构性的困难，好吗？

创造的力量

"动手做"是工程师的超能力。只用大脑和一台电脑，我们就能创造事物！这太神奇了。我们不需要每天费尽口舌去说服、哄骗或强迫别人替我们做事，我们直接动手构建就可以了。

这听起来是常识，但非常重要。创造是所有权力的本源。除非我们同意去构建，否则什么都做不成（这也是个伦理问题）。

Facebook 有张海报写着"代码胜于雄辩"（CODE WINS ARGUMENTS）。这句话有很多槽点，但你有多少次看到技术争论最终是由那个愿意去动手干活的人解决的？或者有人靠动手做直接推翻了之前的结论？行动终结争论。行动证明理论。行动就是力量。（"行动"不仅仅是指"写代码"）。

此外，写软件是一项创造性活动，而在大规模协作下，它更是一项高强度的集体活动。作为创造者，如果我们充满动力、灵感和热情，就能做得更好（这和砍柴可不一样）。作为合作者，拥有高度的信任和团队凝聚力，我们才能做出更出色的成果。

工程能力与判断力、自主性与目标感、社会信任与合作行为：这就是优秀工程师的基石。每个人都有自己最擅长和最舒服的工作模式，我们可以将其大致分为几种原型。

（以下例子来源于我多年来合作过的极其优秀的资深工程师，以及我自己做工程师时喜欢发挥影响力的方式。）

影响力的原型

• 啃硬骨头的人 ：专门做那些极度困难、极度需要，且往往极其枯燥的工作。比如 SOC2 合规、备份与恢复、可怕的代码重构、各种鉴权集成。只要对业务有帮助，他们不在乎工作有多无聊。如果你是这种工程师，你会赢得深深的尊重与感激。
• 最后的调试救星 ：通常是资历最深或最初搭建系统的人。如果你乐于助人，并且乐意分享你的经验和背景知识，那将是一笔巨大的财富。（顺便说一句，人们往往会高估这种人的不可或缺性，请不要纵容这种想法。）
• 专家：与上一条类似。如果你是某个技术组件的深耕专家，你对任何涉及该组件的事情都拥有巨大的影响力。（你应该不断跟进技术变动以保持优势。）
• 高产输出机器 ：有些人能持续爆发出惊人的产出，有时甚至能同时推进多个项目。有些人工作时间长，有些人则是对如何实现影响最大化有敏锐的直觉（这有时也体现在初级/高级工程师的区别上）。没人想惹恼这些人，因为做任何事都需要他们的同意。他们的加入往往能让项目提速，或者把快要失败的项目拉回正轨。

并非所有的影响力都源于纯粹的技术实力或产出。还有很多创造性、协作性和人际交往方面的优势：

• 有些工程师极其好奇，总能比别人多想几步。有时你觉得他们在瞎鼓捣，想去批评他们；结果他们却把你从彻底的灾难中救了出来。久而久之你就会懂得珍惜他们的"瞎鼓捣"。
• 有些工程师通过社交来解决问题，在行业内交朋友、交换技巧、互相帮忙。别低估社交化调试 ，它往往是找到正确答案的最快路径。
• 有些人极其"偷懒"，却能用优雅的捷径和完美的"偷工减料"惊艳到你。
• 有些人是招聘磁铁，单凭有那么多人想再次和他们共事，发给他们的薪水就值了。
• 有些人擅长促成各方达成共识。
• 有些人是优秀的解说员、教育者和讲故事的人。
• 有些人是大家心里默默想成为的那种资深工程师。
• 有些人能描绘出极具启发性的未来蓝图，让所有人都愿意为之奋斗。
• 有些人把代码审查（Code Review）变成了一门教学艺术。
• 有些人能奇迹般地让身边的人变得更高效。有些人能创造无休止的向前动力。有些人非常擅长说"不"。

还有一些特殊的权力来源值得一提：

• 做过管理者的工程师：他们价值连城。他们能用初级工程师听得懂的语言解释业务目标，且极具信服力（这恰恰是管理者在初级工程师眼中往往缺乏的）。他们是非常棒的技术负责人，懂得如何把项目拆解，既能挑战成员的能力又不会把他们压垮，同时还能按时交付。
• 有些工程师是彻头彻尾的刺头 ，因为他们喜欢质疑并挑战每一个系统和层级。但这些锋利的石头也能打磨出伟大的团队。当然，这需要一位强大的管理者来引导他们的能量，促成建设性的对话和改进，避免他们惹恼整个团队。
• 别忘了值班（On-call）的工程师 。如果你们有健康的值班文化，你对生产环境的所有权会赋予你极其深厚的权力和道德威信------你可以据此提出要求、推动变革、决定优先级。值班不应该是一堆强加给无法拒绝之人的烂摊子，而应该是每个写代码的工程师肩负的荣誉和责任。（而且它不应该让人痛苦，也不应该频繁影响正常生活。）

......我可以说上一整天。工程是一个极其强大、充满力量的职位和技能组合。你绝对值得去剖析一下自己的影响力源于何处，并了解别人是如何看待你的优势的。

大多数权力的本质就是"被行使的影响力"

但光会敲代码是不够的。你可能有信誉，但拥有信誉不等于使用信誉。要把影响力转化为权力，你必须去运用它。而运用的方式就是沟通。

藏在你脑子里的想法对别人毫无影响，你必须把它表达出来。

方法有很多：写作、1对1沟通、小组讨论、公开招募盟友、说服手握实权的人、在公开场合广播等等。

因为工程是一项创造性活动，所以专制的权力实际上非常脆弱且具有破坏性。唯一可持续的权力是诸如影响力和启发力这类"软实力"，这就是为什么好的管理者会自如地运用软实力，而极不情愿地、极其克制地使用硬实力。如果你的领导经常拿权威压人，那绝对是个反模式。[2]

如果你不发声，你就没有资格坐在那里生闷气抱怨自己没有影响力。而发声就意味着在别人面前展现脆弱，甚至有时候会犯错。

这不是零和游戏

你们大多数人拥有的潜在权力比你们意识到的要大得多，只是你们没觉得自己强大，或者没有用"权力"的视角来看待自己的工作。

管理者可能有硬权力和权威，但关于技术交付和卓越性最核心的决策，理应由最贴近技术的工程师来做。这些权力属于实干家，很大程度上是因为他们要为这些决策的后果负责。

权力之所以容易向管理者倾斜，是因为他们掌握了更多信息。所以必须聘请那些明白这一点，并懂得有意识地将权力下放给其他人的管理者。

就像在健康的 BDSM 关系中顺从者其实拥有最终权力一样，在健康的团队里，工程师才是拥有最终权力的人。你拥有最终否决权：你可以拒绝创造。市场对你的技能需求量很大，你大可以去寻找更好的环境。你们中的许多人可能确实应该这么做。

当技术优先级和管理优先级发生冲突时谁说了算？理想状态下，双方应该共同努力，找到对业务和人都最好的解决方案。那些战斗力爆表（🔥on fire🔥）的团队，在这两方面总是保持着高度一致。

挑值得打的仗

最后一点思考。如果你懂得培养并明智地使用你的影响力，你能在"做什么"和"怎么做"上有很大的发言权。但是你不可能对每件事都有发言权。这行不通。

把它想象成 @mcfunley 著名的"创新代币"（innovation tokens），只不过这里衡量的是你的注意力和精力。 你越多地将影响力用于产生好结果，积累的影响力就越多......但它是一件精密工具，而不是背景噪音。想象一下有人给你按摩，如果他整个人直接趴在你背上，而不是用手肘或手掌精准按压穴位和痛点，那根本没用。目标过于宽泛会分散你的力量，限制你的潜在影响。

请明智地使用你的注意力代币。

一旦你拥有了影响力，别忘了为他人使用它。关注那些声音未被听到的人，帮他们放大声音。贡献你的时间，借出你的支持和信誉，最重要的是，把那些让你变得强大的技能传授给需要它们的人。

charity

附言：我非常感谢那些我有幸共事过的极其优秀的资深工程师们。深深爱着你们。<3

• [0] 我成功回答了其中一（1）个问题后就没力气了。以后再说。
• [1] 羞愧地坦白：这就是我成为管理者的原因。
• [2] 如果管理者不愿意赋予对结果负责的人明确的权限，这也是个糟糕的信号。我这里指的是相对健康的组织，而不是那种病态的组织：告诉员工（通常是女性）她们不需要晋升或明确的权限，只需使用"软实力"------尤其是当与她们对立的一方握有硬权力时。这纯粹是让你去送死。
• [3] 当我用"权力"一词来指代非组织明确授予的能力时，有些人似乎感到很惊讶。我无法理解这一点。把权力仅仅看作被授予的权威，我觉得太令人沮丧、太缺乏力量了。这也不符合我对这个世界的认知。个人的影响力是一种动态增减的东西，并且只存在于与他人的互动中。我见过很多软弱的管理者被个性强势的人推着走（当然，这也是很糟糕的）。