技术总监要不要自己下沉写代码

我主张“有节制地下场”，但不要做救火式的常态化代打。具体做法是：明确你在哪些场景亲自写代码、写到什么深度、写完怎么把能力和 ownership 还给团队。这样既不脱离一线，又不会把团队养废。下面把我自己踩过的坑和能落地的做法说细点。

技术总监要不要自己下沉写代码：哪些该上，哪些别上

• 该上（高杠杆场景）：

  • 架构方向不清、关键技术路线选型摇摆时。你下场快速做一版 Spike/PoC，用最小可行代码把“可行性、性能上限、复杂度边界”跑出来，时间控制在1-2天，目的是定锚，而不是把功能全揽了。
  • 影响面极大的“第一块砖”。比如核心域模型、核心中间件接入骨架、性能基准测试脚手架。这些你写得足够干净，后续同事照这个标准推进，能少走弯路。
  • 紧急线上事故的“last mile”。当止血优先于培养时，你可以亲自 patch，但要同步制定“事故复盘 + 责任归还 + 改进项排期”，把长期治理交回团队。

• 别上（低杠杆或副作用大的场景）：

  • 纯搬砖型、可替代的业务开发。你写再快，也是一次性效率；还透支团队成长。
  • 需要业务方背锅的需求变更/优先级问题。你冲进去写，等于替对方消化不合理性，反过来会加剧不良协作模式。
  • 任何你写了会破坏角色边界的任务。比如你跳过负责人，直接 push 初级同学，短期快，长期信任成本巨大。

一句话原则：你写的每一行代码都要产生“标准、范式或决定”，而不是替代劳动力。

我怎么把“写代码”和“管人管事”兼容：节奏与边界

• 设定“冲刺额度”和“下场清单”：

  • 每个迭代只给自己预留10-20%可支配编码时间。这个区间不是绝对值，但要让团队知道你不会全天写代码。
  • 公开白名单：PoC、核心骨架、性能剖析、事故止血。黑名单：常规需求、UI 拼接、报表、对接改字段。

• 将“下场”产品化：

  • 写 PoC 时同时产出1页技术备忘（目标、边界、已证伪路线、性能数）。把“为什么这样做”固化，避免只留下一堆聪明但难懂的代码。
  • 写骨架时顺手拉起模板仓库/代码规范/CheckList。比如为新服务提供 starter 模板+集成测试示例，让后续同学复制即可。
  • 做性能剖析时把基线纳入 CI（如压测脚本、阈值报警），下次任何人改慢了会红灯，而不是靠你口头提醒。

• 交接的“退出机制”：

  • 明确 DRI（Directly Responsible Individual 直接责任人）制度。你写完 20% 的骨架，指定1名DRI在接下来两周内把 80% 完成，并在站会复述方案与风险。
  • 把 Code Owner 配好。核心目录加 Code Owners，后续你只做架构 Review，不再写实现。
  • 用“影子负责人”接棒。你带着排一次难点，下一次类似问题由影子负责人独立跑，你退到二线。

写还是不写，各自的收益与坑（对照）

• 你亲自写代码的收益：

  • 信息密度更高，能更快识别“真正的瓶颈”。很多卡壳来自误解或依赖错配，下场 2 小时可能顶 2 天拉扯。
  • 以身作则的示范效应。代码风格、测试覆盖、分层边界，写出来比喊口号有效。
  • 和一线共感。你能更准地估工期、识别“看似简单其实很难”的需求，减少拍脑袋。

• 你亲自写代码的风险：

  • 角色错位，团队把你当“高级救火队员”。久而久之他们不上报风险，等你收尾。
  • 授权被反噬。你越能顶，别人越不练，关键时刻还是你。
  • 管理债务。你在代码里做了很多隐性决定，但没有被团队理解或文档化，后续沟通成本更高。

我的经验是：收益主要来自“定锚”，风险主要来自“代劳”。所以用“定锚型编码”替代“代劳型编码”。

具体落地清单：明天就能用

• 建一个“卡点分级”制度：

  • P0（阻断上线/线上事故）：你可下场止血≤半天，同时拉起跨职能战情群，产出复盘和长修项。
  • P1（关键路径卡顿）：你做 Spike≤1-2天，产出结论与样例，指派 DRI 接棒，周会跟踪。
  • P2（非关键/可并行）：只给方法论与资源，不写代码，让团队在时间盒内自解。

• 定义“写到哪儿停”的技术边界：

  • 只写“不可逆决定相关”的部分：数据模型、接口契约、关键算法接口、性能基线测试。
  • 遇到实现细节，留 TODO 和设计意图注释，开两条任务给 DRI：实现+补测试。
  • 提交前加一条“Architecture Notes”变更记录，简述取舍和替代方案。

• 让“速度”不依赖你个人：

  • 把 Code Review 从“质量把关”升级为“知识扩散”。要求 PR 描述写清问题定义、思路、权衡，评审关注“能不能让别人复用这套做法”，而不只挑错。
  • 建立“问题库/复用库”。每次难点解决都沉淀到团队 Wiki 或示例仓库，下一次遇到直接套件化。
  • 周期性轮岗难点模块。让更多人经历“卡点→解卡→交付”的闭环，降低你作为单点。

• 度量有没有“越写越好”而不是“越写越累”：

  • 看三项趋势：卡点平均恢复时间（MTTR）是否下降；同类问题复发率是否下降；不需要你介入的关键任务占比是否上升。
  • 如果你介入次数上升、但复发率没降，说明你在救火而非治火，要收手做系统性改造（需求梳理、依赖治理、测试左移等）。

如果只能选一个，我选“定锚型下沉”

我不会完全不写代码，也不会长期代打。我会在P0/P1场景用1-2天做PoC/基线/骨架，产出可复用的范式与决策依据，随后把实现与演进交给明确的DRI，并用制度把“退出机制”和“复用沉淀”固化。这样既保留一线敏感度，又把团队带起来，长期速度更快、风险更可控。

补一句现实的话：当组织短期交付压力很大时，你偶尔要“硬上一把”。关键是把“偶尔”变成“机制中的例外”，而不是“大家默认等你来”。把边界说清、把标准立住、把功劳让出去，你就能既写得动、又带得起来。