技术总监每天还写代码正常吗？感觉自己有点不务正业

你这情况我太熟了, 因为我经历过几乎一模一样的阶段。

技术总监写代码本身不丢人, 但你现在的写法和频率, 已经不是“保持手感”而是“挤占了管理职责”——老板已经明确指出来了, 这件事的性质就从“个人偏好”变成了“岗位失职的风险”。继续这么下去, 你被架空或者降回去只是时间问题。

下面拆开聊聊, 也说些我自己踩坑之后的调整方式。

技术总监到底应不应该继续写代码?

要回答这个问题, 先得把你写的代码分成两类——生产代码和非生产代码, 这俩差别巨大。

生产代码是指会合入主分支、上线、跑在业务里的代码。这类代码本质上是把技术总监绑在了交付链路上: 你写了就得维护、出 bug 了得修、别人不敢动你的逻辑, 久而久之你会变成系统的单点瓶颈。带20多个人还写生产代码, 等于花总监的工资雇了一个半吊子高级工程师。

非生产代码则完全不同——技术验证的 PoC、架构选型的 Demo、写个脚本测试新框架的性能、甚至自己搞点开源小工具。这类代码不直接上生产, 但能让你保持技术直觉, 评审方案的时候你不会被架构师忽悠。我给团队引入新中间件之前都会自己先搭一遍, 跑通核心链路再丢给架构组落地, 这是合理的技术管理手段。

所以答案不是“该不该写”, 而是“写什么、在哪个环节介入”。你现在的问题是把生产代码当成了日常, 老板当然会觉得你不务正业。

如何平衡管理和技术?

先说一个前提认知: 技术总监的核心产出不是代码行数, 是团队的技术决策质量和交付稳定性。你帮组员解决一个难点, 看似高效, 实际上你剥夺了他们成长的机会, 也让自己陷进了细节里。用得不好听的话说, 这叫“跟下属抢活干”。

我给自己定过一个硬性规则, 到现在基本能守住——生产代码一行不写, 技术研究控制在总时间的 20%-30%。具体可以这么拆:

• 每天最多留 1-2 小时给技术深度研究(不是修 bug, 不是赶需求), 放在早上开会前或者晚上。
• 遇到组员卡住的问题, 忍住不替他写。换一种参与方式: 让他画个方案图, 你帮他挑逻辑漏洞; 或者你写几行伪代码示范下思路, 具体实现由他完成。你守住“只示范不交付”这条线。
• 如果确实碰到团队没人能搞定的硬骨头(这种情况在小团队常见, 带20多人不太应该频繁出现), 那就作为结对编程参与, 但代码 review 权给另一个人, 你自己不持有这段代码的长期维护责任。

管理那块不能放, 更要命的是, 你现在不会觉得它“产出”有多大。写代码写完跑通, 成就感当时就来; 做管理, 你排好一个季度规划、培养出一个能独立扛模块的人, 效果要三五个月后才显现。这种延迟反馈很容易把人推回代码的舒适区, 但越往后拖, 团队越散, 你自己也越危险。

你是不是根本不适合这个位置?

先别急着否定自己, 不适应的阶段几乎是每个从 IC 转管理的人都会经历的。区别在于, 有些人硬扛过去、找到了管理层的技术参与方式, 有些人确实发现自己更喜欢纯技术路线, 那也有对应的岗位路径——比如首席架构师、技术专家、Fellow 之类。

但有一点得说清楚: 如果你抗拒管人、抗拒业务规划到了“完全不想做”的程度, 那这个岗位长期对你和团队都是消耗。技术总监不是高级码农的进阶, 它的技能树确实偏掉了, 要求你把 70% 以上的精力放在人和事上。这种角色转换有些人的确不喜欢, 也不丢人, 但硬撑下去容易两头不讨好。

给个判断标准吧: 你试着按前面说的, 强制自己两周不碰生产代码。如果这两周你感到的不是“解放了”而是“浑身难受、上班没意思”, 那你可能真的更适合走 IC 专家线。如果只是担心技术落后, 那说明问题不大, 非生产代码和技术研究足够帮你维持竞争力。

最后说一下你现在的风险点。老板已经谈过一次话了, 这不是随口一提, 而是正式的管理反馈。下次再谈很可能就是绩效考核时你被标记为“角色认知不清”。比较务实的做法是, 接下来一个月做几件能让老板看到变化的事: 把周会质量提上去, 主动发起一两次正式的 1v1 和团队分享, 季度规划写出一版有业务视角的文档(不是纯技术路线图)。技术上继续搞, 但别让老板和团队看到你在 IDE 里每天趴着。

如果只能给一条建议的话: **停下生产代码, 把技术热情往架构评审、技术债务治理、新技术预研这三个方向引, 同时把 1v1 和业务规划当成你必须交付的“新代码”来对待。**过了这个坎, 你会发现技术总监这个位置能调动的技术影响面, 比你自己写那几行代码大得多。

老哥你这状态我见过太多了，升总监还天天上手写代码，其实本质是没接受角色转变。20人团队管人、排优先级、review方向才是正事儿，代码可以偶尔救火，但天天沉进去管理肯定崩。你老板那番话已经很直接了，再不松手后面麻烦会更多。