多年来我一直用一个来自团队运动的比喻来描述我如何领导:Playing Captain。既是球员又戴袖标的那个人。不是坐在休息室里的主教练,也不是埋头磨分的纯个人贡献者——而是既划定底线,又和团队一起跑过去的人。

我清楚”我用体育比喻”是在博客文章里承认的一件略微尴尬的事。我认了。这是我找到的最准确的框架。

这实际上意味着什么

Playing Captain 是一种特定的领导姿态。它不是”我是个技术 lead,参加一些架构会议”。它不是”我是 VP of Engineering,偶尔写点代码保持感觉”。它更接近于:我在代码库里仍然是真实意义上在场的。我做架构决策不是从一份隔着距离的文档,而是从团队正在调试的同一个调用栈。我在结对、review、写非trivial的功能,在设计问题变成迁移遗憾之前就抓住它。

与此同时,我在做 lead 的工作:塑造 roadmap、清除阻碍、培养周围的工程师、跑跨团队对话。

目标——这部分听起来理想化但我见过它有效——是团队能自主执行,因为架构是干净的、被清晰传达的,而不是因为我在每个会议上审批决策。Playing Captain 是你避开两种失败模式的方式:一是不知道服务为什么慢的缺席型技术 lead,二是不让任何人独立做出决定的死抓型工程师。

在 12 人和 3 人团队里的不同样子

在 AFAQ 我是一个 12 人团队的 CTO。足够小,我在截止日期前在生产代码上写东西;足够大,有人需要我保护他们不被复杂度淹没、有 roadmap 需要我主导、有董事会更新需要我有观点。那个规模的 Playing Captain 意味着你在大多数房间里是最资深的技术声音,你利用这一点快速推进——你对数据库 schema 做出艰难决定,因为等共识比偶尔犯错再修复要慢。

在 Bytro 我是多团队现代化工作的 Lead Developer。不同质感。团队已经有资深工程师;我的工作不是成为最快的编码者,而是在并行推进的多个小队之间拥有架构愿景——否则他们会为同一个领域概念创建四个不兼容的抽象。我留在代码里是因为我需要知道哪些抽象是成立的、哪些即将崩塌。你没法从一份 Confluence 文档里感知到这件事。

在 auxmoney,信用评估平台有足够的复杂度——以及足够的速度——使得亲手参与不是对个人贡献的怀旧,而是我能给出有用技术指导的唯一方式。当你一直在跟踪团队正在跟踪的同一条请求路径时,你能嗅出在错误层面的 latency 问题。你没法从一块 Jira 看板嗅出来。

反方论点,最有利地呈现

“工程经理应该停止写代码”是真实的建议,来自真实的人,见过真实的伤害。我见过它描述的那个模式:被提拔的资深工程师,现在在每次设计 review 上都设置路障,因为他们还认为自己是房间里最好的程序员。拿走有趣的 ticket。让每次代码 review 都变成关于他们审美偏好的事,除了他们没人感觉拥有 codebase。

那不是 Playing Captain。那是把 Playing Captain 打得很差。

失败模式是真实的。解药不是停止写代码;解药是为团队服务而写代码。拿走那个人人都在躲避的可怕 ticket,因为爆炸半径大——不是因为有趣就拿走它。做架构层面的 review,不是风格层面的。结对是为了传递知识,不是为了看自己有多好用。

“停止写代码”的建议也是针对特定团队形态调整的——通常是大型组织,你的杠杆在于人员密度、流程和委托链。在 5 到 15 名工程师的团队里,尤其是在 startup 或现代化项目中,那是错误的形态。你不是在优化流程;你在优化架构连贯性和速度。技术可信度对 Playing Captain 来说不是一个加分项——那是整个基础。

Playing Captain 是错误选择的时候

我做 Playing Captain 足够长时间了,知道什么时候它是错的。

如果你在一个有 80 名工程师还在增长的组织里,Playing Captain 开始复利地产生负效应。团队需要你全时在跨职能的房间里;每一小时花在代码 review 上,就是没花在以更快速度复利的组织问题上的时间。你有能够持有架构愿景的人——也许他们需要你给更多方向设定,而不是更多结对编程时段。

如果你在用它来逃避你觉得不舒服的那部分领导工作,它也是错的。我抓到过自己拿着一个硬技术问题作为转移活动,当时有个我一直拖着的绩效对话。那不是 Playing Captain。那是用代码当安慰毯。Captain 仍然要做艰难的人际工作;代码不是借口。

它做对的那件事

Playing Captain 做对的是反馈循环。当你在 codebase 里时,你在团队告诉你之前就知道架构在漂移。你知道哪个工程师头脑里装着太多复杂度,因为你看过他们发出来的 PR。你知道一个服务边界是错的,因为你在这个抽象的两侧都待过。

纯管理型技术领导有 latency 问题。你通过会议、复盘、以及(正确地)不想把每件小事都带给你的人这些过滤渠道获取信息。当一件事以问题的形式浮出水面时,它已经是问题好几周了。

Playing Captain 压缩了那个 latency。来自代码的反馈快速到达你,因为你在读代码。你可以早期纠偏,这意味着你不需要大幅纠偏。

我在四家公司、三个不同技术栈、从 4 到 30 人的团队规模里实践过这个。这不是一个关于技术领导的普世理论。这是对我有效的理论,以及我最有用过的那种团队形态。袖标带来责任。靴子继续穿着。