职场之锤
技术管理者生存指南- 我靠这3件事保住了技术敏感度
虎头锤 · Staff Engineer本文另有英文译文 · 阅读英文版 →
当我开始带团队以后，最怕听到一句话就是——
“你现在应该不怎么写代码了吧？”
有时候是下属问的，有时候是外部同事寒暄，也有时候是面试官试探。但不管是谁说，我心里都咯噔一下。因为我知道，一旦别人开始默认你“管人不写代码”，你的话在技术讨论里的分量，也会开始打折。
不是不能转型管理，而是管理之后，技术话语权需要靠新的方式维护。
不是硬写代码就够了，而是你要能——
听懂别人的方案背后用了什么假设；
看出一个提案里的盲区，不是从细节，而是从系统；
知道现在在流行什么，不被“公司惯性”包裹。
说白了，管理者的技术敏感度，已经不靠“卷代码量”来定义了，而是靠：你还能不能及时看见技术决策的变与不变。
我也不是天生敏锐。刚转管理那两年，我也有一段时间根本不知道大家在用什么新库、出了什么新安全事件，更别说和架构师并肩讨论了。
但我后来做了三件事，重新找回了“感知能力”。
第一件事，是用听而不是写，保持架构理解的肌肉感。
我之前有一个误区：觉得要“保持技术敏感度”，就要硬写代码，不然就不算“懂技术”。
但我后来发现，写代码很容易陷进细节——写着写着就开始纠结语法糖、lint规则、PR谁先过了。更大的技术决策反而看不到了。
我开始刻意换一个方式：每次技术评审我都参加，不是为了挑毛病，而是练习听出“这个方案为什么选这个方向”。
比如别人说要拆 service，我就问：
是为了解耦部署，还是为了异步通信？
是哪一块先出问题了？是卡吞吐，还是影响数据一致性？
我不插手细节，但我会在会后记笔记，把每次评审里出现的技术选择和权衡写下来。然后三个月后回顾一下，看哪个方向对了，哪个方向踩坑了。
这比我自己一个人闭门造车去写 side project，有效多了。
第二件事，是每季度订一次“外部趋势快照”。
我有个习惯：每季度都会花1-2天，做一次“外部技术趋势快照”，看看公司之外，行业里发生了什么。
我不会天天刷 Hacker News 或 Twitter，那样太耗精力。但我会关注几个关键渠道：
每季度更新一次订阅博客/播客/技术报告，比如 Thoughtworks Radar、InfoQ、The Pragmatic Engineer。
在 GitHub Trending 上观察新工具、DevOps 工具链、LangChain/Fine-tuning 等技术领域的活跃度。
有时候还会用 Notion 做一个“趋势备忘录”，里面按“方向-原理-落地案例”来分类。
这些信息，不是为了“赶热度”，而是给自己一个对比组。很多时候，我们觉得某个老系统还“挺稳定”，是因为我们太久没看过别人是怎么做的。
而保持技术敏感度，正是要避免这种“局部稳定的假象”。
第三件事，是自己做一个“快速理解新技术”的小工具。
我曾经试过写过一个脚本，把我收藏的技术博客和播客做了统一摘要，用 ChatGPT 把每篇文章压缩成“核心原理 + 应用场景 + 我该在什么时候用它”。
它不完美，有时候总结也会偏。但它帮我快速理解了很多陌生名词背后的动因，比如为什么最近都在谈 streaming data pipeline，不是因为 cool，而是因为它解决了延迟和扩展性之间的瓶颈。
更重要的是——这个小工具是为我服务的，不是展示用的 side project。
很多人做 side project 是为了 portfolio，为了加分。我觉得管理者不一定非得做给别人看，但可以做一些只为自己省时间、提认知的小工具。
它让你在每天琐碎的管理工作之间，还能有一条“技术感知”的暗流在流动。
我现在依然不写很多代码，但我能在关键场合说出关键问题，也能看出别人提案的盲点。有时候，不是靠我“懂”，而是靠我“能提问”。
因为我知道，管理者的技术敏感度，不是证明我还在写代码，而是让我还能看见技术的方向感。
它就像船长的雷达，不是拿来造船的，但没有它，你会不知道这艘船到底正开向哪里。
你有自己的“雷达系统”吗？