技术负责人
技术负责人承担的是一个团队的技术方向：工作如何构建、以什么顺序推进、达到什么标准，以及此刻哪些妥协是可以接受的。这是一份仍然动手的工作，而不是人员管理工作，它依靠的是可信度而不是汇报关系。以下说明这个职责包含什么、在哪里结束，以及如何辨认一个能扛得住它的人。
技术负责人做什么？
技术负责人是对单个团队工作的技术方向负责的工程师。这份工作包括决定一项工作如何构建、在设计变成代码之前完成评审、让质量标准在所有参与者之间保持一致、在交付与已积累的技术债之间安排先后，以及清除阻碍其他工程师推进的障碍。技术负责人通常继续写代码，通常也不承担直线管理职责：薪酬、绩效与晋升在别处，而团队所构建之物的形态与稳固程度归他负责。
这个角色的特点是「有责任但没有指挥权」。技术负责人很少有可以命令谁的地位，因此方向必须靠其他工程师认可的推理，以及靠过往站得住脚的判断来赢得。在这个岗位上最吃力的，往往是那些以为头衔可以终结争论的人；做得好的人则把每一个决定都当作必须经受住质疑的东西。
长期存在的张力，在于亲自做与让别人能做之间。花一小时亲手写掉最难的部分，会产生一个确定的结果；花一小时拆解同事的设计，会产生一个更好的团队和今天看不见的成果。过度偏向个人产出，负责人就成了唯一理解这套系统的人；过度偏向另一侧，技术可信度会被侵蚀，直到他的推理不再有分量。逐周去把握这个比例，构成了这门手艺的大部分。
这个岗位的时间视野短、范围窄，而这正是它的价值所在。技术负责人以周和月为单位，思考一个团队的代码库以及它所拥有的系统，这使得决定可以足够具体、并且立刻落地。跨越多个团队的问题，或者会把组织绑定数年的问题，属于范围更广的角色——把两种视野混为一谈，是这个职位被划错边界最常见的方式。
团队何时需要这项能力
多数团队在没有指定技术负责人的情况下也能运转，直到这一缺位开始产生一组可辨认的症状。以下是最先出现的那些。
局部合理的决定加总成一个不连贯的整体
每位工程师的选择都说得通，却没有人把这些选择连起来，于是同一个问题在代码库里有了三种解法。在任何单次评审里都看不出毛病，这也正是这种状态能长期存在、直到有人把它点破的原因。
工作卡在没有人负责的问题上
一张工单做到一半停下，因为方案有争议，而没有人有资格结束这场争论。代价表现为交付变慢，真正的原因是一个悬而未决、且无人认领的决定。
质量标准取决于谁来评审
两位工程师提交相当水平的工作，得到的却是不相当的审视力度。只存在于个人脑中、而非共识里的标准，会让代码库的质量随作者而变，也会让被评审的人觉得评审很随意。
技术债天天在讨论，从来排不进计划
所有人都同意那次迁移很重要，而它在每一次规划会上都输给功能需求。要在同一场对话里为两边定价并为结果辩护，才谈得上可信地权衡治理与交付。
技术方向由一位经理与人员工作一起兼顾
一个人同时做两件事，往往只做得成紧急的那一半。设计问题被推迟回答，或者在信息不足的情况下作答；而当一个棘手的技术问题占据了几周时间，人员方面的工作又会受损。
团队规模已经超出非正式协作能承受的范围
两三位工程师共用一个代码库时行得通的方式，一旦有更多人同时改动就不再成立。合并冲突开始变成架构冲突，必须有人替所有人把这个系统的整体形态记在脑子里。
核心能力
把技术决定收敛掉
收集足够的背景、权衡选项、做出选择，并把这个选择讲清楚——包括推理本身，以及在什么条件下应当重新审视它。一个一直悬着的决定比一个后来被证明错误的决定更贵，因为团队每天都在为这份含糊付费。
设计评审
从一份方案里读出它没有写的部分：失败路径、迁移方式、运维成本、那个关于数据量的不成立的假设。在实现之前抓住这些，是这个角色创造价值最多的地方，因为同样的问题一旦有了代码，代价就高得多。
维持一致的标准
把质量标准讲明白并均匀地适用，让工程师能够预测什么会通过。这既关乎执行，也同样关乎判断某项工作的标准应该定在哪里——一个用完即弃的实验和一条支付链路，本来就不该得到相同的严苛程度。
拆解与排序
把含糊的需求变成可以独立构建、评审和发布的增量，并排出顺序，让风险尽早暴露、让后续步骤不被前面的猜测卡住。拆解不当，是工作停在「差一点就完成」处的主要原因之一。
排除阻塞
注意到某个人从周二起就卡住了而且不会主动说，然后在不把工作拿走的前提下把它解开。这是这个角色里最不显眼的部分，往往也是负责人时间回报最高的用法。
在交付与技术债之间取舍
判断哪些捷径值得走，把它们记录下来使其保持可见，并清楚哪些必须在复利之前偿还。判断力在于区分哪些债会滚利息，哪些只是不整洁但无害。
选择自己要亲手做什么
有选择地保持动手：接下真正需要最深上下文的工作，同时刻意放掉那个有意思的问题，好让别人在其中成长。什么难题都自己接的负责人，会带出一个离开他就无法运转的团队。
向非工程人员解释技术风险
把一个结构性问题翻译成它的业务后果——什么将变得不可能、什么会变慢、什么会在何时出问题——既不夸大以逼出行动，也不弱化到被忽略。
通过工作培养工程师
把授权、评审和问题的表述方式当作人成长的手段，这与管理职业发展是两回事。技术负责人会影响一个人成长的速度，却不拥有他的考评、目标或晋升。
运维层面的归属
确保团队跑得动自己交付的东西：有意义的告警、保持更新的操作手册、追到根因而不是恢复即关闭的故障处理，以及由此产生的修复确实被排进计划。
这门学科是如何实践的
技术领导并不由某套工具链定义，因此以下不是一份技术栈。这里列出的是业界普遍与该角色相关联的实践、方法与产出物——它描述的是这门学科通常如何运作，而不是任何个人的工作方式。熟悉这些词汇远不如有证据表明其背后的判断力确实存在来得重要。
决策与记录
- 设计文档
- RFC 与方案评审
- 限时技术调研
- 取舍说明
- 决策记录
质量机制
- 代码评审约定
- 完成的定义
- 测试策略
- 静态分析关卡
- 重构预算
交付实践
- 需求切分
- 待办事项梳理
- 在制品限制
- 风险优先的排序
- 发布计划
运维实践
- 值班轮换
- 操作手册
- 告警调优
- 不追责的故障复盘
- 服务水平目标
技术健康度
- 技术债清单
- 依赖升级节奏
- 构建与流水线健康度
- 不稳定测试跟踪
- 交付流动指标
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应关注什么
这个职位考察的是判断力，而判断力确实很难面试出来。候选人带着一个在每家公司含义都不同的头衔前来，因此最有力的证据几乎总是关于某个具体决定以及它之后发生了什么的叙述，而不是任何关于「我如何带团队」的描述。
在信息不足时做决定
任何有分量的技术判断都是在信息有缺口的情况下做出的。请他们讲一个信息始终没有到位的例子，然后去听他们如何圈定风险，而不是他们当时有多确信。
- 能说出自己当时不知道什么，以及用什么方式弥补
- 为重新审视这个决定设定了触发条件，而不是当作定案
- 能描述一个后来被证明错误的判断，以及纠正的代价
他是放大团队还是吸收团队
这个角色的典型失败，是负责人变成所有事情都必须经过的那个唯一节点。追问工作是如何分配的，以及他不在的时候发生了什么。
- 让出了自己想留着的工作，并且说得出是哪些
- 能描述团队在他缺席时依然做出好决定
- 会注意到自己的评审队列已经成为瓶颈
设计评审的实践
问他们在实现开始前会从一份方案里看什么。弱的回答谈风格与结构；强的回答直接指向失败模式、运维成本，以及那些在生产环境面前站不住的假设。
- 先问失败与回滚，再问结构
- 把没有被否决过的备选方案的方案视为不完整
- 能描述自己在一次评审中改变了想法
处理技术分歧
有能力的工程师之间出现分歧是常态，而分歧如何收场比任何架构答案都更能说明问题。两个极端都值得警惕：总是让步的负责人，和总是取胜的负责人。
- 能区分值得解决的分歧和可以留着不解决的分歧
- 采纳过自己一开始反对的方案
- 基于实质问题升级，而不是基于情绪
为技术债与交付定价
问他们是如何决定推迟某项治理的，以及如何知道再推下去就不安全了。这个回答能区分「谈论技术债的工程师」和「在商业压力下管理过技术债的工程师」。
- 能区分会滚利息的债与只是不整洁的部分
- 让捷径可见，而不是让它悄悄存在
- 说得出一次被自己成功争取进交付计划的偿还
当前的动手能力
这个角色需要一个技术直觉仍然对准当下工作方式的人。上一次认真贡献代码已经是数年前的候选人，会拿一个不复存在的系统作为评审的参照。
- 谈最近的代码时给得出细节，而不是泛泛而谈
- 在对话中对某个技术细节判断错误时并不难受
- 对团队近期采用的某个工具有基于实际了解的看法
知道这个角色在哪里结束
一个悄悄把人员管理揽过来的技术负责人，或者开始对自己不参与的团队做出约束性决定的技术负责人，会制造出数月后才浮现的混乱。清楚边界是正面信号，不是缺乏进取心。
- 能干净地把自己的职责与经理的职责分开
- 把跨团队的问题提出来，而不是单方面拍板
- 能描述与架构师并肩工作而不产生摩擦的方式
值得一问的面试问题
供您自己的面试流程参考。每一位候选人都由您在自己的语境下评估，以下说明的是值得留意什么，而不是标准答案。
讲一个你为团队做出、后来又推翻的技术决定。是什么让你推翻它的？
What a strong answer shows
看他们把决定当作可修订的立场，还是当作需要捍卫的承诺。要听促成这次推翻的具体信号，以及这次推翻是否因为他们当初就为可撤销做了准备而变得便宜。
团队里两位工程师对方案有分歧，而两种说法都成立。请说说你实际上会怎么做。
What a strong answer shows
在没有权力的情况下如何行使方向。较强的回答会找到分歧的真正根源、判断这个选择的可撤销程度，并让投入的精力与判断错误的代价相匹配。
上个季度有什么是你刻意没有去做的，即使你是做得最快的那个人？
What a strong answer shows
看他们是否明白自己的产出并不是衡量标准。在这里答不上来的候选人，通常正是团队里那个最勤奋的瓶颈。
你怎么知道团队的质量标准是被一致地适用了，而不是取决于评审者是谁？
What a strong answer shows
看标准是被显性化了还是仍然只是默会的。要听产出物、校准过程和实例讲解，而不是一句「大家都知道什么算好」的保证。
讲一个团队在交付压力下走过的捷径。你做了什么来确保它一直是可见的？
What a strong answer shows
技术债是被有意处理的，还是默认累积的。较强的回答会包括让它留在记录上的机制，以及它最终的去向。
一份能跑通、但不是你会选的设计交到你手上。接下来会发生什么？
What a strong answer shows
分寸感。仅仅因为不是自己偏好就否决一份可行的设计，是让团队停止独立思考的可靠方式，回答里应当出现一个阈值，而不是一种条件反射。
如果构建某个部分的人明天离职，你们系统里哪些部分你会讲不清楚？
What a strong answer shows
对知识集中程度的诚实认识。声称对一个真实系统有完整覆盖的候选人，描述的通常是愿望而不是现状。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 某个团队交付稳定，但代码库已经开始漂移：相近的问题有好几种解法，设计问题在代码评审里而不是在代码评审之前解决，一项长期被推迟的治理开始拖慢日常的功能开发。工程师们都有能力，只是没有人在把握这项工作的技术形态。
- Approach
- 一位追加的资深工程师在团队既有的安排下加入——客户的架构、客户的标准、客户的规划节奏、客户的路线图。技术方向仍由客户设定；追加的能力在这个方向之内工作，与团队一起参与设计评审和日常交付，而不是在团队旁边另起一摊。
- What this adds to the team
- 客户获得了资深工程能力，同时完整保留对产品决策、架构与工程标准的所有权。团队的技术方向由谁决定，这一点没有任何改变。
Related disciplines
Frequently asked questions
- 技术负责人与工程经理有什么区别？
- 技术负责人负责团队的软件如何被设计和构建；工程经理负责这个团队作为一群人如何运转。招聘、成长、绩效、薪酬、团队构成与跨职能协调属于经理。技术决定、设计评审、标准与交付排序属于技术负责人。有些组织把两者合成一个岗位，这在小团队里行得通，随着规模扩大往往会失效，因为这两组职责争夺的是同一份注意力，而紧急的那一组总是赢。
- 技术负责人与软件架构师有什么区别？
- 范围与时间视野。技术负责人对一个团队数周到数月的工作负责，并且贴近代码到足以评审它。架构师跨系统、跨团队，以年为单位处理拆分、边界、集成与非功能性需求，通常动手更少。一个糟糕的架构决定之所以昂贵，是因为难以撤销；一个糟糕的技术负责人决定通常局限在一个团队之内，可以在一个迭代里纠正。
- 技术负责人还写代码吗？
- 通常写，而且写多少不如写什么重要。写到足以保持技术直觉在线、并且能感受到团队所感受到的摩擦，这接近于必需；写到评审排在个人交付后面，则与这个角色的目的相违背。完全不写的负责人会逐渐失去这个角色赖以存在的可信度，而什么都写的负责人会成为团队离开他就无法推进的原因。
- 技术负责人是晋升，还是另一份工作？
- 是另一份工作，尽管它常常以晋升的形式被授予。它依赖的技能与资深个人贡献者不同——说服、排优先级、能容忍由别人负责的未完成工作——一位出色的工程师可能并不擅长它，而这并不说明他的工程能力有任何问题。把它当作职级而不是一组职责，会造就不情愿的负责人，也会让本应是常规安排的回退路径显得像降级。
- 技术负责人实际上有多大权力？
- 在正式层面通常很小。这个角色几乎总是要为自己无法强制的结果负责，因此推理必须好到能说服人，可信度也就成了通行货币。指望头衔本身承载决定的组织，往往会造就两类负责人：不停向上升级的，和发出没人执行的指令的。
- 一个人可以同时带多个团队吗？
- 可以，而且通常会打折扣。这个角色依赖于近距离——知道谁卡住了、评审队列是什么样子、哪个假设正在悄悄出错——而这种感知在跨团队之后会迅速稀释。把一位负责人拆到两个团队，常见的结果是一个团队有半个负责人，另一个团队没有。
- 技术负责人如何与现有的工程团队协作？
- 在您已有的安排之内，而不是取而代之。在技术团队扩展的模式下，架构、工程标准、技术方向、路线图和优先级仍由贵组织设定，工作的日常方向也仍然掌握在您自己的人手里。雇佣关系归 Talent.ID——薪资发放、员工福利与人才管理，仅此而已。工程领导权不会转移，这种安排中也没有任何一项会把技术决策移出您的团队。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.