如何做好一个技术 TL

子曰：吾日三省吾身，反思是人类进化出来的一项异常宝贵的能力。我在阿里带团队也有四年多的时间，有必要总结一下此间得失。另外，前几天和一个刚开始带团队的同学聊天，他觉得角色转变对于他有不小的挑战，因此我想做一点不算成熟的总结并分享出来。

当然，此文第一不代表我必然是一个多么成熟的管理者，第二不代表我的总结放之四海而皆准（事实上很多人的管理方式和我推崇的方法是反的，但是如果从晋升角度评价，这些人更成功），第三我并无雄心壮志解答所有问题（例如阿里的361问题）。总结仅仅是期望通过反思，帮助自己成为更好的管理者，而分享是希望能够多多少少帮助到其他的管理者。
本文会重点讲述我对招聘、目标管理、团队沟通和工程文化的理解。

挑选这几个主题讲述，主要是因为在带团队的这一段时间内，我认为这几个要素是团队长期发挥战斗力和创新能力的核心。得到这个认识对我来说并不容易，市面上有纷繁复杂的书籍（机场书店尤其多）尝试告诉你什么叫领导力，公司也有相关的培训介绍，周围也有很多 TL 用每日的言行告诉你他们是怎么做的。但是我认为这些来自周围的知识，很多是无效的，有更多是错误的。

例如有的TL每天在办公室坐到半夜下班，给团队巨大的加班压力，表面看起来是奋斗，实际上会让大家趋向于更多关注工作时长，从而降低了对工作价值的思考。再比如当团队同学犯错后，把故障和绩效强关联，在我看来这不仅无助于大家深入思考系统健壮性，更可能鼓励推责，扼杀创新。更常见的例子可能是 TL 积极向上汇报，承诺超出团队负责的交付能力，导致团队完全无视工程师文化，久而久之优秀的人才逐渐流失，团队整体研发能力实则越来越弱。

很多事情是知易行难的，技术 TL 实践更是这样，之后不断学习，执行，反思，才能慢慢做得更好。如果我团队的同学在离开这个团队五年或者十年后，回想起这段时间，会感慨：“我们当时的团队多好啊，大家一起做了很多有意思的事情。” 那我这个技术 TL 的工作，就算做得出色了。

招聘

招聘的第一原则是宁缺毋滥。这么说出来大家都会认同，但是实际执行往往会因为短期压力而变形，尤其是招聘越来越难，好不容易面到一个看起来差不多的同学，难免会内心有点小倾斜，算了，先招进来吧……这其实是非常危险的，因为一旦招聘了错误的人，对于 TL 需要耗费的管理时间会成倍增加，这些时间本来可以用来做更重要的事情。更危险的是，错误的人可能会对团队整体产生负面的影响，例如需要其他人不断地补位，或者和人不断争吵，消耗大家的精力。
因此招聘一定是要严格要求的，如何面试我就不详细讲了，通常我会关注以下一些方面，基本上是缺一不可：
coding 能力

对技术的热情
能简明扼要地沟通
积极乐观
对团队目标的认同

招聘是个长期的事情，如果仅仅是在有 HC 的窗口去找人，通常是非常困难的。遇到合适的人，我会长期和他保持沟通，了解对方工作的状态，这其实也是一个不断建立信任的关系。当机会合适的时候，对方肯定会优先考虑你。

当候选人选择机会的时候，团队的 TL 是个怎样的人肯定是他重点考虑的因素之一。因此 TL 一定要做技术发声，不论是开源项目的参与，撰写技术文章，还是在技术大会做演讲，都是充分体现 TL 个人技术能力、技术思考以及个人特质的重要机会。

目标

团队之所以为团队，是因为这些人有共同的目标，如果没有共同目标，这些人就是散兵游勇，不可能相互协同，无法成就巨大价值。而团队的目标，主要还是由 TL 去负责定义和明确的。

近期比较流行谈 OKR，我认为这就是一种协同团队聚焦目标的方法。定方向 O（Objective），定数字目标 KR（Key Result），就是期望团队能够凝聚在一起，朝共同的方向努力，相互理解和支持。量化的指标（KR）用来指导方向，暴露问题。我比较反对用 KR 或者其他量化指标来简单粗暴地考核工程师，数字指标如果用来考核，很容易导致大家舍本逐末。例如有人 KR 完成了 200%，却挖了一堆坑；而有人 KR 完成50%，但的确解决了棘手问题，代码扎扎实实。我必然会把好的绩效给后者，差的绩效给前者。

定义团队目标实际上是个非常困难的事情，因为这个目标的定义要求你回答：

是否和你的用户/客户做了充分沟通，是否理解他们真正需要什么，你能给他们解决什么问题，他们的工作因为有了你团队会发生怎样的改变？
和上下游协作方能够做好协同，要兑现你给客户承诺的价值，你会依赖于谁做什么事情？需要谁和你一起参与？这些依赖和协作方，是否认同你的目标？
你定义的目标和价值，和你自己的TL的目标（或者说自己部门的目标），是否是一致的？
在技术团队，你的目标定义中有没有考虑技术竞争力？持续建设技术竞争力不仅能帮助团队长期发展得更好，也能帮助吸引更多优秀的人才。

当然，如果这个目标有那么点理想主义，就更好了。工程师骨子里都有那么点容易被点燃的理想主义。有了清晰的团队目标后，就是要和团队不断的沟通了，让每个人都清晰地理解目标，不要怕重复，不要怕啰嗦。

下一步是把团队目标分解为每个人的目标，这件事本质上是产品架构或者技术架构。为什么这么说呢？在做软件设计的时候，我们都会说高内聚，低耦合；会说面向契约设计。人与人协作的时候，我们也希望每个人的目标足够清晰（对比软件交付功能的定义，或者非功能性指标的度量），以及人和人之间的协作边界清晰（对比软件系统之间的契约）。因此我们要不断去思考团队负责产品的架构，和团队同学不断讨论细化，直至架构及目标足够清晰。当然还有一些横向的目标，或者项目管理的工作目标，需要有同学去承担，这没什么问题，但我非常不建议在研发团队中，让一个同学有超过一半的时间在做横向，因为技术没有深度是谈不上广度的。

沟通

如果团队同学找你，那就要尽可能立即响应。立即响应的意思是，如果你当下有时间，就立刻和他沟通；如果你白天时间排满了，那就晚上和他沟通；如果你实在晚上的时间也被占了，那就立刻安排明天一个时间，发出会议邀约。同学如果没有他认为重要的事情，一般是不会主动找主管沟通的，立即响应是和同学建立信任的重要方式。如果同学找你一次两次都没得到响应，或者响应比较慢（给人不重视的感觉），那慢慢的很多事情就不会找你了。最差的情况，同学下次找你的时候可能是提转岗了。

要尽量和同学做 1-on-1，国外专职做管理岗位的，把 1-on-1 作为一个非常正经的日常工作在做，频率也很高，例如两周一次。在阿里巴巴，技术 TL 通常没有这么多的时间，因为身上承担的职责除了管理外，还要带技术，带项目等等。但还是应该做好日常的 1-on-1 沟通，而不仅仅是绩效季。比较理想的频率是一个月一次。在 1-on-1 的时候，一方面要给到非常具体的反馈，例如：

你做的 x 方案，在设计上非常好，考虑到了和隔壁团队的协作。
你近期的代码，在 UT 覆盖上做的不够。
我看到你推进的 y 项目，进展不及理想，是遇到了什么问题吗？需要我提供什么帮助？

除了反馈， 1-on-1 更重要的是倾听，同学在表述自己工作的时候，状态好不好？在什么地方遇到了问题，作为 TL 能提供什么帮助？其实很多时候，即使你暂时帮不了什么，但是用认真的态度去听一下同学的心情，无论这个心情是充满热情，还是沮丧，还是迷茫，对于同学来说都是非常重要的。我在做 1-on-1 的时候，都会做个简单的记录，留着下次 1-on-1 的时候 review，做好追踪。

工程文化

要建设一支有战斗力的团队，优秀的工程文化是必不可少的。什么是优秀的工程文化？那就是对自己写的代码，写的测试，写的设计，做的产品，所有这些工程师的产出物，对其质量和细节有足够的尊重。为什么说，优秀的工程师文化必不可少，我通过以下几点解释下：

从团队产品的长期发展来看，只有保证优秀的质量，才能保证产品可以长期高效率的持续迭代。如果设计凌乱，代码质量差，无测试覆盖，那么渐渐所有人的精力都会被消耗在各种“安全生产”问题上。渐渐的，一个需求的上线实现，从数小时演变成了数天，甚至数周。
只有拥有优秀工程文化的团队，才能吸引优秀的工程师。优秀的工程师，真心把编程当作一门手艺，以自己的手艺为傲。如果团队TL
不认为这是一门应当引以为傲的手艺，大家渐渐地会都把事情看成和搬砖无异的性质，区别只是工资高低。这样的氛围下，团队的人才构成必然是二流甚至是三流的。

建设工程文化，就是要鼓励大家做 Code Review，写 UT，做好 CI，做知识分享。这些事情听起来很容易，难的是，如何在项目压力很大的时候，依旧坚持住。另外，就是要承认 technical debt 的存在，产品上线一段时间后，必然会有很多“临时方案”存在，作为 TL 要给团队创造空间，鼓励他们花时间去偿还 technical debt。

工程文化是技术团队的根基，可以让所有人有一个正确的参照，什么是对的，什么是应该学习的，什么是需要遵守的。我们可以看到很多丢失了工程文化的团队，演变成了一个什么样的状态，写看起来都差不多的 ppt，天天拉会推动这个推动那个，遇到问题自己不去查根究底弄清楚原理，而是拉群，组会，沟通…… 这样团队的技术人才往往会逐渐流失，剩下的人继续用他们擅长的非技术技能生存。

TL 对自己说

除了对外，我还经常对自己说：

做真实的自己
Don’t Panic！
耐心点

**做真实的自己。**每个人都有自己的性格特质，虽然因为人生经历，人的个性会发生变化，但在短时间内一个人最本质的东西是不会变化的。或温文儒雅，或狭义豪情，或积极勤奋…… “真实不装”是阿里价值观中我最喜欢的一条。伪装一时是很容易做到了，常年累月把自己伪装成一种人设，一来自己会非常累，二来团队同学也不是傻子，早晚会看出这其中虚伪的一面。而一旦一个 TL 让人感到虚伪，信任建立就无从谈起了。当然，对自我分析，认识自己也并不是一件简单的事情，心理学分析的书浩如烟海，我喜欢夜深人静的时候读一些。

**Don’t Panic！**TL 会面临各种各样的压力，目标变化，目标难以达成，绩效考核，人和人之间的冲突，团队和团队之间的冲突，这个时候大家都在看着你怎么处理。在这么多压力下，人的自然反应就是焦虑，甚至惊慌失措。

我们知道，在运动的时候，演讲的时候，过度的焦虑会导致动作变形，乃至连自己的正常水平都无法发挥。而 TL 在这种状态下，更容易做出错误的判断，而且严重焦虑的情绪很容易传导给整个团队。越是这种时刻，越要稳住自己，在有限的条件下，努力做出最合理的判断，我们必须要承认自己再怎么聪明勤奋，也只是普通人而已，并不是漫威中的超级英雄。

**耐心点。**程序员可能是最没耐心的一批人，代码写下去，首先期望机器必然给反馈，其次期望机器立刻给出反馈，对了还是出错了，一切都要清清楚楚，明明白白。可当程序员的角色转变成管理者的时候，一切就发生了巨大的变化。你给团队宣导的目标，可能有人记住了，有人没记住；你给同学指出的问题，可能他几个月半年都改不了，或者他根本不想改；你想在团队建立的工程文化，好像进展非常慢，和预期相差太远……其实这一切都很正常，人脑接受和转化信息，除非是性命攸关的信息，否则效率都是很低的，一个人自身积累几十年的行为模式，哪怕做出细微的变化，也需要很长的时间。

因此，重要的信息，不要嫌麻烦，可以说三遍甚至更多。而当你好心给同学指出问题，也不要期望对方立刻接受并改变，很多时候他不做任何改变也是很正常的。但这也不是我们不做正确事情的理由，如果十个同学中有一两个因为你的指导，在职业生涯上突破了自己的一些瓶颈，那已经是作为 TL 能实现的巨大成就了。

后续

关于技术竞争力

前文中在目标部分，第4点提到了技术竞争力目标。在这里我的观点是，技术竞争力不仅仅是为了做好业务，也是为了帮助团队同学发展得更好，也帮助团队吸引人才。

关于这一点，珍琳提了一个问题：“您这里指的技术竞争力，具体体现指标是什么呢”，这就更具体了，这个问题可以更精确的如下描述：

假设1：业务目标是可被量化的
假设2：业务目标是可被分解为技术目标的
假设3：技术目标是可被量化的
假设4：符合一定可量化标准的技术目标是技术竞争力

上述的逻辑推导，通常是 TL 或者资深的技术同学完成的。我用一个 PaaS 平台的例子来说明这个逻辑推导的过程：

业务目标是可被量化的
对于 PaaS 来说，用户在发布页面停留和关注的时间越短越好，这个时间可以度量出来

我们服务的 PaaS 要服务数千研发每日使用，涉及的 Pod 数量在数百万

业务目标是可被分解为技术目标的
Pod 状态的实时性影响了用户对发布页面的关注时长，例如如果已经调度成功的 Pod 需要很久才能刷新状态，用户就不会不断刷页面看发布单子的状态，因此需要追求 Pod 状态的实时性。

此外还要考虑数百万 Pod 规模下实时性如何保障，这个和保障几十个 Pod 的状态不是一回事

技术目标是可被量化的
上述技术目标可以被量化为 x Pod 数量规模下，Pod 状态同步实时性（ms度量）（P95）

符合一定可量化标准的技术目标是技术竞争力
Pod > 1,000,000 & P95(Latency) < 200ms 是技术竞争力

而最后完成这个技术指标，需要做大量的工作：包括熟悉链路的所有细节，在正确的地方使用好缓存，在正确的地方处理好数据的聚合和过滤，思考大规模下对资源的使用，保障系统的可靠性等等，这些对于技术同学来说都是非常好的挑战。（完）
如何做好一个技术 TL