子曰：吾日三省吾身，反思是人类进化出来的一项异常宝贵的能力。我在阿里带团队也有四年多的时间，有必要总结一下此间得失。另外，前几天和一个刚开始带团队的同学聊天，他觉得角色转变对于他有不小的挑战，因此我想做一点不算成熟的总结并分享出来。
当然，此文第一不代表我必然是一个多么成熟的管理者，第二不代表我的总结放之四海而皆准（事实上很多人的管理方式和我推崇的方法是反的，但是如果从晋升角度评价，这些人更成功），第三我并无雄心壮志解答所有问题（例如阿里的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 能实现的巨大成就了。
延伸阅读
杨绛有一句话我非常喜欢，她在一封回复青年学生的时候，写了这么一句话：“你的问题主要在于读书不多而想得太多。”
今天在工作中看到的很多人，所谓创新，所谓 idea，都是属于读书不多而想得太多的瞎折腾。做技术领导者也一样，体验、思考是必要的，但是如果仅仅靠自己思考和体验，往往会走很多弯路，甚至南辕北辙。因此我建议大家阅读一些相关的书籍。
以下是我读过的一些，推荐给大家：
- 杰克韦尔奇的《赢》
https://book.douban.com/subject/24700113/
361末位淘汰考核制可能是从这里学来的 - 谷歌的《如何定义公司》
https://book.douban.com/subject/26582822/
人才至关重要 - 《驱动力》
https://book.douban.com/subject/10484712/
除了使用金钱之外，如何激励人 - 《门后的秘密》
https://book.douban.com/subject/5401859/
为什么 1-on-1 沟通如此重要，以及如何做好 1-on-1 - 《非暴力沟通》
https://book.douban.com/subject/3533221/
说话大家都会，但是好好说话很多人就不会，擅于倾听的人更是少见
后续
关于技术竞争力
前文中在目标部分，第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