技术负责人
技术负责人承担的是一个团队的技术方向：工作如何构建、以什么顺序推进、达到什么标准，以及此刻哪些妥协是可以接受的。这是一份仍然动手的工作，而不是人员管理工作，它依靠的是可信度而不是汇报关系。以下说明这个职责包含什么、在哪里结束，以及它在团队中如何发挥作用。
技术负责人做什么？
技术负责人是对单个团队工作的技术方向负责的工程师。这份工作包括决定一项工作如何构建、在设计变成代码之前完成评审、让质量标准在所有参与者之间保持一致、在交付与已积累的技术债之间安排先后，以及清除阻碍其他工程师推进的障碍。技术负责人通常继续写代码，通常也不承担直线管理职责：薪酬、绩效与晋升在别处，而团队所构建之物的形态与稳固程度归他负责。
这个角色的特点是「有责任但没有指挥权」。技术负责人很少有可以命令谁的地位，因此方向必须靠其他工程师认可的推理，以及靠过往站得住脚的判断来赢得。在这个岗位上最吃力的，往往是那些以为头衔可以终结争论的人；做得好的人则把每一个决定都当作必须经受住质疑的东西。
长期存在的张力，在于亲自做与让别人能做之间。花一小时亲手写掉最难的部分，会产生一个确定的结果；花一小时拆解同事的设计，会产生一个更好的团队和今天看不见的成果。过度偏向个人产出，负责人就成了唯一理解这套系统的人；过度偏向另一侧，技术可信度会被侵蚀，直到他的推理不再有分量。逐周去把握这个比例，构成了这门手艺的大部分。
这个岗位的时间视野短、范围窄，而这正是它的价值所在。技术负责人以周和月为单位，思考一个团队的代码库以及它所拥有的系统，这使得决定可以足够具体、并且立刻落地。跨越多个团队的问题，或者会把组织绑定数年的问题，属于范围更广的角色——把两种视野混为一谈，是这个职位被划错边界最常见的方式。
团队何时需要这项能力
多数团队在没有指定技术负责人的情况下也能运转，直到这一缺位开始产生一组可辨认的症状。以下是最先出现的那些。
局部合理的决定加总成一个不连贯的整体
每位工程师的选择都说得通，却没有人把这些选择连起来，于是同一个问题在代码库里有了三种解法。在任何单次评审里都看不出毛病，这也正是这种状态能长期存在、直到有人把它点破的原因。
工作卡在没有人负责的问题上
一张工单做到一半停下，因为方案有争议，而没有人有资格结束这场争论。代价表现为交付变慢，真正的原因是一个悬而未决、且无人认领的决定。
质量标准取决于谁来评审
两位工程师提交相当水平的工作，得到的却是不相当的审视力度。只存在于个人脑中、而非共识里的标准，会让代码库的质量随作者而变，也会让被评审的人觉得评审很随意。
技术债天天在讨论，从来排不进计划
所有人都同意那次迁移很重要，而它在每一次规划会上都输给功能需求。要在同一场对话里为两边定价并为结果辩护，才谈得上可信地权衡治理与交付。
技术方向由一位经理与人员工作一起兼顾
一个人同时做两件事，往往只做得成紧急的那一半。设计问题被推迟回答，或者在信息不足的情况下作答；而当一个棘手的技术问题占据了几周时间，人员方面的工作又会受损。
团队规模已经超出非正式协作能承受的范围
两三位工程师共用一个代码库时行得通的方式，一旦有更多人同时改动就不再成立。合并冲突开始变成架构冲突，必须有人替所有人把这个系统的整体形态记在脑子里。
核心能力
把技术决定收敛掉
收集足够的背景、权衡选项、做出选择，并把这个选择讲清楚——包括推理本身，以及在什么条件下应当重新审视它。一个一直悬着的决定比一个后来被证明错误的决定更贵，因为团队每天都在为这份含糊付费。
设计评审
从一份方案里读出它没有写的部分：失败路径、迁移方式、运维成本、那个关于数据量的不成立的假设。在实现之前抓住这些，是这个角色创造价值最多的地方，因为同样的问题一旦有了代码，代价就高得多。
维持一致的标准
把质量标准讲明白并均匀地适用，让工程师能够预测什么会通过。这既关乎执行，也同样关乎判断某项工作的标准应该定在哪里——一个用完即弃的实验和一条支付链路，本来就不该得到相同的严苛程度。
拆解与排序
把含糊的需求变成可以独立构建、评审和发布的增量，并排出顺序，让风险尽早暴露、让后续步骤不被前面的猜测卡住。拆解不当，是工作停在「差一点就完成」处的主要原因之一。
排除阻塞
注意到某个人从周二起就卡住了而且不会主动说，然后在不把工作拿走的前提下把它解开。这是这个角色里最不显眼的部分，往往也是负责人时间回报最高的用法。
在交付与技术债之间取舍
判断哪些捷径值得走，把它们记录下来使其保持可见，并清楚哪些必须在复利之前偿还。判断力在于区分哪些债会滚利息，哪些只是不整洁但无害。
选择自己要亲手做什么
有选择地保持动手：接下真正需要最深上下文的工作，同时刻意放掉那个有意思的问题，好让别人在其中成长。什么难题都自己接的负责人，会带出一个离开他就无法运转的团队。
向非工程人员解释技术风险
把一个结构性问题翻译成它的业务后果——什么将变得不可能、什么会变慢、什么会在何时出问题——既不夸大以逼出行动，也不弱化到被忽略。
通过工作培养工程师
把授权、评审和问题的表述方式当作人成长的手段，这与管理职业发展是两回事。技术负责人会影响一个人成长的速度，却不拥有他的考评、目标或晋升。
运维层面的归属
确保团队跑得动自己交付的东西：有意义的告警、保持更新的操作手册、追到根因而不是恢复即关闭的故障处理，以及由此产生的修复确实被排进计划。
这门学科是如何实践的
技术领导并不由某套工具链定义，因此以下不是一份技术栈。这里列出的是业界普遍与该角色相关联的实践、方法与产出物——它描述的是这门学科通常如何运作，而不是任何个人的工作方式。熟悉这些词汇远不如有证据表明其背后的判断力确实存在来得重要。
决策与记录
- 设计文档
- RFC 与方案评审
- 限时技术调研
- 取舍说明
- 决策记录
质量机制
- 代码评审约定
- 完成的定义
- 测试策略
- 静态分析关卡
- 重构预算
交付实践
- 需求切分
- 待办事项梳理
- 在制品限制
- 风险优先的排序
- 发布计划
运维实践
- 值班轮换
- 操作手册
- 告警调优
- 不追责的故障复盘
- 服务水平目标
技术健康度
- 技术债清单
- 依赖升级节奏
- 构建与流水线健康度
- 不稳定测试跟踪
- 交付流动指标
这个角色如何与您的团队协作
工程师在您的团队内部工作，遵循您的优先级和标准。日常开发方向由您掌握，Talent.ID 负责雇佣关系。下面的分工就是全部安排。
由您掌握
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
由 Talent.ID 负责
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
实际协作大致是这样
这是一个假设场景，用于说明协作方式如何落地。它并不描述 Talent.ID 的客户或已完成的项目。
- 挑战
- 某个团队交付稳定，但代码库已经开始漂移：相近的问题有好几种解法，设计问题在代码评审里而不是在代码评审之前解决，一项长期被推迟的治理开始拖慢日常的功能开发。工程师们都有能力，只是没有人在把握这项工作的技术形态。
- 做法
- 一位追加的资深工程师在团队既有的安排下加入——客户的架构、客户的标准、客户的规划节奏、客户的路线图。技术方向仍由客户设定；追加的能力在这个方向之内工作，与团队一起参与设计评审和日常交付，而不是在团队旁边另起一摊。
- 为团队带来什么
- 客户获得了资深工程能力，同时完整保留对产品决策、架构与工程标准的所有权。团队的技术方向由谁决定，这一点没有任何改变。
常见问题
- 技术负责人与工程经理有什么区别？
- 技术负责人负责团队的软件如何被设计和构建；工程经理负责这个团队作为一群人如何运转。招聘、成长、绩效、薪酬、团队构成与跨职能协调属于经理。技术决定、设计评审、标准与交付排序属于技术负责人。有些组织把两者合成一个岗位，这在小团队里行得通，随着规模扩大往往会失效，因为这两组职责争夺的是同一份注意力，而紧急的那一组总是赢。
- 技术负责人与软件架构师有什么区别？
- 范围与时间视野。技术负责人对一个团队数周到数月的工作负责，并且贴近代码到足以评审它。架构师跨系统、跨团队，以年为单位处理拆分、边界、集成与非功能性需求，通常动手更少。一个糟糕的架构决定之所以昂贵，是因为难以撤销；一个糟糕的技术负责人决定通常局限在一个团队之内，可以在一个迭代里纠正。
- 技术负责人还写代码吗？
- 通常写，而且写多少不如写什么重要。写到足以保持技术直觉在线、并且能感受到团队所感受到的摩擦，这接近于必需；写到评审排在个人交付后面，则与这个角色的目的相违背。完全不写的负责人会逐渐失去这个角色赖以存在的可信度，而什么都写的负责人会成为团队离开他就无法推进的原因。
- 技术负责人是晋升，还是另一份工作？
- 是另一份工作，尽管它常常以晋升的形式被授予。它依赖的技能与资深个人贡献者不同——说服、排优先级、能容忍由别人负责的未完成工作——一位出色的工程师可能并不擅长它，而这并不说明他的工程能力有任何问题。把它当作职级而不是一组职责，会造就不情愿的负责人，也会让本应是常规安排的回退路径显得像降级。
- 技术负责人实际上有多大权力？
- 在正式层面通常很小。这个角色几乎总是要为自己无法强制的结果负责，因此推理必须好到能说服人，可信度也就成了通行货币。指望头衔本身承载决定的组织，往往会造就两类负责人：不停向上升级的，和发出没人执行的指令的。
- 一个人可以同时带多个团队吗？
- 可以，而且通常会打折扣。这个角色依赖于近距离——知道谁卡住了、评审队列是什么样子、哪个假设正在悄悄出错——而这种感知在跨团队之后会迅速稀释。把一位负责人拆到两个团队，常见的结果是一个团队有半个负责人，另一个团队没有。
- 技术负责人如何与现有的工程团队协作？
- 在您已有的安排之内，而不是取而代之。在技术团队扩展的模式下，架构、工程标准、技术方向、路线图和优先级仍由贵组织设定，工作的日常方向也仍然掌握在您自己的人手里。雇佣关系归 Talent.ID——薪资发放、员工福利与人才管理，仅此而已。工程领导权不会转移，这种安排中也没有任何一项会把技术决策移出您的团队。
告诉我们您的团队需要什么
描述一下缺口——工作内容、技术栈、团队的运作方式——我们会告诉您能支持到什么程度。如果这不是我们能帮上忙的事情，我们会直说。