技术人的影响力和晋升：我这些年慢慢理解的几件事

影响力不是把事情做完就结束

我以前很容易把“做成一件事”和“让别人理解这件事的价值”混在一起。后来慢慢发现，在公司里，尤其是技术工作里，事情做完只是第一步。真正产生影响力，还需要让别人知道：你解决了什么问题，为什么这个问题重要，你的方案和结果到底带来了什么变化。

这里我觉得 SCQA 模型挺实用。它不是很复杂，但能帮你把表达从“我做了很多事”变成“我解决了一个值得解决的问题”。

1. S（Situation）情景：先从大家熟悉的事实或背景说起。
2. C（Complication）冲突：说明当前情况和预期之间有什么矛盾。
3. Q（Question）问题：把真正要解决的问题提出来。
4. A（Answer）回答：给出你的方案，以及它为什么有效。

比如可以这样讲：

S：我们的系统每天处理数百万次请求，用户对性能要求越来越高。
C：但现有架构在高峰期经常出现延迟，影响用户体验。
Q：怎么提升系统性能和稳定性？
A：我们设计了一套新的缓存架构，把核心链路延迟降低了 50%。

这种表达的好处是，它不会一上来就陷入技术细节，而是先帮听众建立问题感。对技术人来说，这一点很重要。很多时候不是你做得不够，而是别人没听懂你做的事情为什么值得被记住。

晋升答辩要证明什么

晋升不是简单证明“我很努力”，也不是只证明“我完成了很多任务”。更核心的是证明三件事：你已经在做下一级别的事情，你做出来了结果，而且这些结果是别人认可的。

我理解的晋升准备，大概有三个原则。

主动原则

不要等到答辩前才让别人知道你做了什么。平时就要主动同步进展、想法和意愿，也要主动听反馈。很多时候，晋升卡住不是能力完全不够，而是可见性不够，或者别人对你的判断还停留在旧版本。

成长原则

成长要能看出轨迹。比如从方案设计，到架构设计，再到系统优化；从只负责一个模块，到能负责一条链路；从执行别人拆好的任务，到能识别问题、拆解问题、推进解决。

这种变化如果没有被记录下来，答辩时就很难讲清楚。

价值原则

你做的事要和业务、团队、公司目标有关。技术当然重要，但晋升时不能只讲“我用了什么技术”，还要讲“这个技术解决了什么业务问题，降低了什么成本，提升了什么效率，减少了什么风险”。

答辩材料可以怎么组织

一个比较稳的结构是：

1. 自我介绍：团队、业务、当前级别、目标级别。
2. 当前职责：负责范围、关键职责、是否带团队或虚拟小组。
3. 重点项目：最多讲 2-3 个，宁可讲透，也不要堆项目数量。
4. 能力证明：围绕下一级能力要求，讲复杂度、持续时间、规模、不确定性和结果。
5. 发展规划：说明你接下来还能继续创造什么价值。

项目表达上，STAR 模型依然好用：

• S（Situation）：背景是什么。
• T（Task）：你负责什么，角色是什么。
• A（Action）：你做了哪些关键动作。
• R（Result）：最后带来了什么结果，最好有数据。

这里要注意，结果尽量不要只写百分比。比如“性能提升 50%”当然好，但最好同时说清楚基数：从多少提升到多少，影响了多少用户，节省了多少成本。只有比例，没有基数，可信度会弱很多。

答辩现场也要区分问题类型。别人问 What，是在确认事情和结果；问 How，是在看方法和步骤；问 Why，是在考察你的判断、原理理解和系统性思考。不会的地方就说不会，不要硬编。技术答辩里，诚实反而会增加可信度。

核心竞争力到底是什么

我以前会把核心竞争力理解成“技术很强”。后来觉得这个说法太窄了。技术强当然重要，但真正让一个技术人长期有价值的，可能是几个东西叠加起来：

• 理解问题的历史：知道一个技术方案为什么会变成现在这样，背后经历过哪些权衡。
• 灵活使用技术：不是为了用技术而用技术，而是能把技术当成解决问题的工具。
• 解决问题的能力：能快速定位问题，提出方案，推进落地，并对结果负责。
• 表达和沉淀能力：能把经验写下来、讲清楚，让团队复用。

公司为什么愿意给一个人更高的级别和薪酬？简单说，是因为他能解决别人解决不了、或者别人需要花很久才能解决的问题。他不只是完成职责内的任务，而是在更高复杂度上创造了价值。

所以体现核心竞争力，不只是写好代码，还包括：把问题文档化，把方案讲清楚，把实现做扎实，把结果复盘出来。代码质量也很关键，比如不冗余、可读、可扩展，别人接手时能看懂，后续变化时能继续演进。

行为上有几个很朴素的点：多沟通、主动分享、展示贡献。这里的“展示”不是邀功，而是让团队知道什么方法有效，什么坑可以避免，什么经验可以复用。

能力模型：技术、业务和管理

我会把技术人的能力粗略放在三个维度里看：技术、业务、管理。不同阶段权重不一样，但越往后走，越不能只看技术深度。

技术维度

技术能力不只是“会不会写代码”。它至少包含几种复杂度：

技术不是越新越好。真正重要的是，它是否给业务和团队带来价值，是否引入了可控的复杂度。

业务维度

业务能力是很多技术人容易忽略的。你至少要知道：有哪些业务、业务现状是什么、痛点和挑战在哪里、核心指标大概是什么、技术对业务有什么机会点。

技术人如果只懂“怎么实现”，很容易变成资源方。如果能理解“为什么要做、做到什么程度算好、对业务有什么影响”，就更容易参与决策。

管理维度

管理不一定等于带团队。很多高级技术人也需要做虚拟项目管理：评估人力、拆时间、跟进问题、预判风险、协调上下游。

这里面最容易被低估的是“关系处理”。技术上对，不代表推进上一定能成。很多事情最后卡住，不是方案不对，而是相关方没有被提前纳入，风险没有被同步，信任账户不够。

做事方法：前期、中期、后期

我自己比较喜欢把做事分成三个阶段。

前期：先确认是不是正确的事

前期不要急着写方案。先确认问题本身是不是值得解决，和业务目标有没有关系，相关方是不是真的关心。很多低效来自一开始方向就偏了，后面再努力也只是把错误的事做得更快。

中期：用结构化方法推进

中期要把事情拆清楚。比如用 3C 做方案对比，用 PDCA 推进执行，用 5W 明确问题，用 WBS 拆任务，用 buffer 处理不确定性。

这里不是为了套方法论，而是为了减少模糊。谁负责、什么时候完成、风险是什么、验收标准是什么，这些越早说清楚，后面越少扯皮。

后期：复盘和沉淀

事情结束后，不要只停留在“上线了”。要从结果、数据、技术、成长几个维度复盘：

• 结果有没有达到预期？
• 数据有没有支撑？
• 技术上有哪些沉淀？
• 自己和团队成长了什么？

汇报时可以用金字塔结构：先说总体结论，再讲分析和证据，最后给出关键事项和后续动作。不要一开始就钻细节，听众会很快失去方向感。

P7 能力模型的一些理解

P7 这个阶段，我理解重点已经不是“把任务做好”这么简单，而是要能在业务、技术和组织之间建立连接。

业务理解

要能讲清楚几个问题：业务有哪些，现状和痛点是什么，核心指标大概在什么水位，技术能给业务带来什么机会。这里要尽量用客户语言，而不是只用技术语言。

比如业务更关心的是进展、风险、质量、效率、稳定性。你可以讲架构，但最好最后能落到：进展是否更透明，风险是否提前暴露，Bug 率是否下降，研发效率是否提升。

差异化价值

技术团队也需要差异化。比如数据平台能不能帮助业务更快看到问题，系统架构能不能支持多种业务形态，技术方向是不是足够笃定，是否避免了频繁切换带来的浪费。

“技术赋能业务”这个词听起来有点空，但落到具体事情上就是：技术有没有让业务更快、更稳、更低成本地完成目标。

技术解决方案

一个好的技术解决方案，至少要回答：为什么选这个方案，业务和技术特性是什么，研发环境有什么约束，有哪些替代方案，为什么不选它们，结果怎么度量，长期怎么持续产生价值。

这也是我觉得 P7 以上和普通执行最大的区别：不是只给一个实现，而是能给出判断，并且愿意为判断负责。

References

• Staff Engineer: Leadership Beyond the Management Track — Guide to growing influence as a senior engineer
• An Elegant Puzzle: Systems of Engineering Management — Will Larson — Book on engineering leadership and organizational design
• The Manager’s Path — Camille Fournier — Guide to tech leadership from engineer to CTO