三月中下旬的一个晚上，快十一点了我还在工位上赶代码。这段改动本来安排给了别人，时间紧，我觉得自己写得快，就接了过来。与此同时还有几件事压着没处理：两个人的排期冲突没人定，一个跨团队的依赖拖着没确认，第二天的一对一还没准备。代码可以靠加班写完，加班解决不了后面这几件。这样的晚上，那段时间出现过好几次。
先把背景交代一下。晋升之前，我长期带一个 3 到 4 人的小团队，成员自驱、背景整齐，每个人都能独立交付。那样的团队里，管理动作大多是隐性的：目标靠共识，沟通靠日常高频的非正式同步，授权近乎天然全权，成员能力不用操心，风险大家会主动喊出来。2019 年 3 月晋升后，我接手的是一个 10 多人的业务团队，成员的背景、能力和动机都参差，原来不言自明的做法开始一件件失效。同期我参加了公司给新任管理者安排的管理培训。对我来说，培训的作用是把过去靠默契的那套隐性经验，升级成大团队需要的显性做法。这篇是这个系列笔记的第一篇，先把最基础的一个问题说清楚：管理者到底该对什么负责。
职责的变化
晋升之后，我的日程没有立刻变化：还是参加原来的项目，还是写代码，只是多了一轮一对一，多排了几个会。只看日程的话，很难意识到哪里不一样了。
真正的变化在管理对象上。小团队 3 到 4 个人，目标、进度、风险都在每天的同步里，每个人的状态我天然掌握，不需要专门去管。现在 10 多人，我不可能再靠日常接触覆盖每个人：信息不再天然对称，不是每个人都自驱，给了上下文也不一定能自己跑，问题会被压到临近交付才暴露。还是原来那些动作，覆盖不了现在的对象。
培训第一节课谈的就是这个。课上对管理职责的原始表述我记不全了（待确认：翻一下当时的培训笔记，把原文补在这里），我理解下来的意思是：组织对你的评价标准换了。个人贡献者对”我交付了什么”负责，代码量、解决的难题、守住的线上质量，都是可以直接数出来的东西。管理者的产出没有这么直接，他要为团队整体的几类结果负责，哪怕这些结果里没有一行代码是他写的。在小团队里这个界限是模糊的：三四个人时，我交付的和团队交付的几乎是同一件事。人数上来之后，两者分开了。
这个区别听起来像常识，做起来很容易滑回去。写代码有即时反馈，改完跑通了就是跑通了；而”目标有没有被理解""风险有没有提前暴露”这类事情，做了短期看不到结果，不做短期也看不出问题。人天然会退回有反馈的事情上。开头那个晚上，就是我在用个人贡献者的方式，缓解当管理者的焦虑。
管理者负责的几类对象
按我当时的理解，管理者的负责对象可以分成四块。这四块在小团队里都靠默契覆盖着，换到现在的团队，每一块都得专门做。
团队目标。方向从业务和上级那里来，落到团队这一层，目标要变得可执行、可检查：这个阶段要交付什么，交付到什么程度算完成，谁对哪一段有最终判断。目标停在口号层面，成员各自理解，最后拼不起来，这算管理者的责任，不能归到成员的理解力上。目标这条在小团队里靠共识自然对齐，几乎不用专门做；10 多人的团队里共识不会自动形成，对齐成了管理者要反复做的动作。
协作关系。团队内部的分工、和外部团队的接口，都要有人维护。二月份我写过一篇 RASCI 模型，当时是为了对付”看起来人人都在负责、实际上没人负责”的事。带现在这个团队之后发现这类问题更多：跨团队的事情双方都以为自己只是配合，需求变更没有人有权确认，出了问题找不到接口人。主 R 不定出来，事情就挂在两个人之间。把每件事的主 R 尽早定出来，是管理者要做的日常动作。
成员成长。这一条最容易被压缩。项目紧的时候，把任务分给做得最快的人永远是效率最高的选择，代价是能力一直集中在少数人身上，其他人长期拿不到有挑战的事。以前团队里成员都是高潜，这条大半被上进心消化掉了；现在成员处于不同阶段，有的需要带，有的需要放手。状态怎么样、能力有没有在涨、有没有人一直在做低于自己水平的工作，这些问题不会有人主动汇报，只能靠管理者自己盯。
风险暴露。团队里的大多数问题，在变成事故之前都有征兆，关键是征兆停在谁那里、有没有人往上递。如果每次都是临近交付才集中爆出来，说明前面的环节里风险没有被接住。小团队里风险暴露是主动的，有问题当场就说；新团队里有人会压问题，觉得说出来显得自己不行，或者之前说了也没人接。让问题早一点浮出来，比亲手解决几个具体问题更有价值。
还要不要写代码
培训里没有人说管理者不能写代码，我自己也没法接受很快变成一个只会开会的人。要换的是判断标准。
以前接一个技术任务，看的是我想不想做、能不能做完。小团队里这个标准够用，因为人手少，我多做一点就是团队多交付一点。现在要先多问一句：我来做这件事，解决了团队的什么问题。我自己整理的结论是，管理者下场做技术工作，合理的理由大致有三种：消除团队的瓶颈，比如某个关键模块只有一个人懂，进去把这块知识摊平；补足关键能力，比如团队暂时缺某个方向的经验，需要有人先把路蹚出来；降低决策风险，比如影响面大的技术选型，需要有人花时间把方案验证掉。
反过来，“这个需求比较急，我做得快，我来写吧”，看起来是帮忙，实际是替成员完成日常任务。一两次无妨，形成习惯之后，团队的能力分布不会改善，我自己的时间也会被切碎，上面那四件事反而没人做了。
切换初期的几个观察信号
以前在小团队，团队状态是日常接触中顺手获得的信息；现在要靠定期检查来补。那几周我给自己留了几个定期检查的问题，用来判断自己是不是又把管理做回了个人贡献：
- 任务是不是集中在少数人身上。关键模块的方案、联调、评审如果永远围着同一两个人转，要么是分工问题，要么是能力梯队问题，两者都归我管。
- 成员是不是理解当前优先级。找一两个人问”这两周最重要的事是什么”，答案如果对不上，说明目标传递断在了中间。
- 风险是不是临近交付才暴露。迭代后半段冒出来的问题，往前追一下它在哪一周就有了征兆、当时卡在谁手里。
- 协作方有没有明确接口。跨团队的事情问一句”这事找谁确认”，如果答案是”在群里喊一声”，这个协作关系就是悬空的。
这几个问题不需要专门开会，平时过任务、看排期的时候顺手就能核对。它们的作用是把我从”我做了什么”的视角，拉回到”团队现在是什么状态”的视角。
什么时候仍然要下场
上面这些不是说管理者要把手洗干净。有几个场景下，管理者必须亲自上。
小团队没有冗余人力，管理者本身就是梯队的一部分。这一点我有直接体会：以前带 3 到 4 个人时，我就是梯队里的一环，关键模块缺人我得顶上去，该写的代码还是得写。线上出故障的时候止损优先，谁最快谁上，这时候谈”借故障培养成员”是奢侈的。影响面大、不可逆的关键技术决策也一样，管理者有责任把判断过程做扎实，不能一句”你们定吧”就把决策权连同责任一起交出去。
需要区分的是介入的原因。因为故障、因为风险、因为暂时没人能接，这些介入都是正常的；因为”我做比较快""交给别人不放心”而介入，做多了，团队就会一直停在需要你下场的水平。
负责对象发生变化后，管理者要持续检查团队目标、协作接口、成员成长和风险暴露，而不是只用个人完成的技术任务衡量自己的工作。
