课程目标：系统了解TL的角色与职责；了解TL的知识体系与工具，包括风险管理、用价值流图梳理发布之路、技术愿景对齐、CFR、用干系人管理工具来识别客户、冲突处理等。
一、TL角色认知
技术发展路线：架构师、某个领域深耕成为技术专家、管理类、敏捷顾问。
心目中理想的TL：靠谱、技术好。
1. TL职责，和PM、架构师、senior dev职责的交叉与区分
1）阻止项目上不好的事情发生，如资源超过限制；2）给团队提供工作所需资源，保障团队顺畅工作；3）技能导航，合适的人做合适的事，同时兼顾人员成长，如让junior的人获得指导；4）做决定，对比不同技术方案、风险、目标，作出靠谱的决定；5）价值展现，将价值和知识做团队、客户层面的呈现，赢得团队、客户信任；不仅是通过交付了哪些功能来展示价值，还需要展示我们做得好的地方。
这5条是effective leadership的五要素，是PM和TL的交叉职责。
6）知识，按团队所需，为所有人呈现所需知识，做团队中可靠的知识传播者；7）指导，指导普通开发解决技术难题。8）梳理标准：为项目的代码质量树立高标准。9）解决难题：解决项目上最难的技术问题。15）整体理解：清楚的理解团队正在实施的工作的所有细节，知道影响当前工作的因子。
前四条是TL专属职责；最后一条也适用senior dev
10）责任，项目成功交付的总负责人；11）为团队创建好的工作氛围，让所有人愉快工作。
这两条是PM专属职责。
12）技术的深入理解：深入的技术理解和丰厚的技术背景，避免实现局部最优的解决方案甚至是不成熟的方案；13）拉通和标准化：通过过硬的沟通技能，帮助各部门就技术愿景达成一致，为整个公司的技术标准化提供建议；14）转化：将产品的创意或者粗略想法转化为可靠的技术方案。
这是典型的架构师职责，架构师需要丰厚的技术和过硬的沟通技能，是业务、技术部门的桥梁，也是多部门之间的桥梁。资深TL也会涉及这些工作。
成为一个TL，应该在哪些方向努力？可以看一下下面这张图。TL职责主要包括developer、leadership、architect等方面。或者分为engaging with business、engaging with team、architecture&infrastructure、delivery & risk。
如果你的团队有一个技术很厉害的人，那么你可以更多focus在leadership职责，但如果没有，那么tech也很重要。对于自己擅长的事情，在团队中寻找并培养第二梯队，并放权给第二梯队；对于让自己不舒服的事情，要有责任感。
作为TL在项目上写代码时间很少，更多的时间用在管理工作，那么如何保持技术水平？投入时间、热情在技术代码，做代码练习、订阅stackoverflow上的技术问题等。另外，伴随经验增加，技术判断力可能提升。
TL的光环与职责是相伴而来的。
2. 角色认知模型
junior的TL更跟你介绍TL工具集，senior的TL会强调管理的价值，如RM知道什么人适合安排在什么项目，有的时候，人分配对了，那项目就成功了一半；比如PM对人心更加洞悉，在跟客户沟通的时候，PM更能洞悉客户的目的，从而使得我们和客户的沟通事半功倍。认可管理的价值，把人的问题理顺了，做事情会变得更加顺利。
3. Leader与boss
Leader更倾向于lead by example，作为团队的role model。
SOW，售前的最后一步，和客户签署的合同，定义了什么是成功的交付，CFR如2w的TPS，99.999的可用性。售前的最后一步是inception。
二、从极客到带领团队
从极客到带领团队，从dev的视角切换到带领团队；用两匹马的马车来比喻，dev是拉车的马，TL是拿着鞭子赶马车的人，需要协调两匹马的步调，需要看好目的地和各个方面。从dev到TL，是一种升维，通常当某些问题解决不了时，我们需要升维思考，寻求解决方案。
面临的挑战从独立完成任务到团队协作。团队对技术方案、代码风格的统一认知很重要。也就是我们说的consistency over cleverness。TL的主战场：codebase、团队中的人、发布之路等。
1. Programming
编码时间过多可能会忽略与客户的沟通，团队培养等问题；编码时间过少则对项目的实际理解变少。推荐至少30%的时间用于编码。避免工作在关键任务，从而产生dependency导致难以脱身；参加code review，读git log等。做决定的时候，对于琐碎问题，如空格空行，需要尽快做决定；把更多时间精力放在更重要的事情。
TL影响力从何而来？respect。帮助团队，比如code review中的建议、帮助团队成员解决难题等等。这样后面你需要推行一些事情的时候，才更容易让别人接受。
TL引领团队文化，比如pipeline会不会红着过夜，大家有想法是否可以安全的说出来。常见的team smell：如avoid conflict（同事之间互现修改彼此的代码）、not admitting mistakes（指责他人）、not offering new ideas（开会的时候不讲话）、not asking for help（同事每天站会都说快做完了，却一直没有做完）。
2. people
1）Diversity，团队中的人有不同风格；并且每个人看到的东西，基于他的角度、认知、知识背景，看到的东西是不同的。集体精确度=平均精确度+diversity。
2）develop others
横轴是能力、纵轴是面临的挑战。如果能力不够但任务很重，则陷入焦虑；如果能力很强但没什么挑战就会无聊；flow代表的是一个正常的状态。我们在发展自身能力、或者发展他人的时候，可以先让他进入anxiety，也就是走出舒适区，来驱动他的能力提升，进入flow。
3）sweet spot是体育名次，指的是击球的时候击中的最有力的一个点。找到自己的、或者团队中人的sweet spot，帮助发掘潜能，更好的成长。
4）learning activities：code review、pair programming、brown bag session、book club、technical retro、spike showcase演示spike的结果。
5）bad apple：一个人有不好的行为，会影响到团队的其他人。bad apple并不是人，而是行为或者态度，TL需要尽早识别出团队的bad apple。
3. process
工作行为指的是是否会直接给予他指令；关系行为指的是对他的意愿的支持，比如在他自信不足的时候给予的鼓励。因此directing主要针对热情洋溢的初学者，coaching是对于困惑的学习者，supporting是针对有能力，但信心不足的贡献者；delegating则指的是独当一面的目标达成者。
当组建一个新项目团队的时候，通常会有上述过程发生。
TL需要给自己一些时间
评估团队状态，项目技术栈和团队技术能力的gap；团队中每个人的工作能力、意愿；在加入团队初期和各个成员f2f，了解他们的工作能力、意愿、对未来发展的预期。
