Tech Lead 练级指南

TL 在不同公司、不同语境 可能会有不一样的含义,

本文将开发团队中的角色分为以下几类:

  • IC(独立贡献者):一线开发,主要工作是写代码

  • TL(Tech Lead):小组长,虚线带人,带项目

  • Manager:团队负责人,实线带人,有行政权利和绩效权


本文所说的 TL,指的就是 Tech Lead,

他可能是某一个或多个领域的业务负责人,虚线带人做项目。


很多 “年长” 的开发,职业生涯发展的某一个阶段,就会要求他们带人了。

大团队会分成几个小组,这些 TL 是某个业务方向的小组长。

他们没有绩效权,只能发挥非职权影响力,带领团队高绩效的完成工作。


在整个职业发展过程中来看,TL 所做的工作,会跟一线开发有很大的不同。

尤其是思维方式的转变,尤其困难,

本文就对这些转变进行总结,希望能帮助少走弯路。

从方案到问题

一线开发的任务大多数是其他人分派的,如果习惯了一线开发视角的话,

会经常陷于,在同一个问题的不同方案中进行考量。

经常会出现一线开发在争论,是这种方案好,还是那种方案好。


而 TL 则不得不摆脱方案视角,因为他是为结果负责的,

需要随时问自己:我们要解决的问题是什么?

TL 应当在问题领域进行考量,是解决这个问题,还是解决另外一个问题。


问题领域比方案领域更难,因为这涉及到很多系统化的思维方式,比如要考虑

  • 为什么要解决当前这个问题,当前问题是不是一个问题

  • 当前问题值得解决么,为什么现在必须解决

  • 谁适合解决这个问题,有哪些合作方

  • 解决这个问题需要多大成本,有哪些收益


以上这些问题,TL 必须考虑清楚,否则就会把团队带错方向,

或者是,在不恰当的时机,做了不恰当的事情。

又或者是,事情的结合点不合理,导致事情很难执行。

少管事多服务

有些新晋 TL 习惯上让大家把所做的事情汇报给他,以消除不安全感,

但实际上这样做,会让 TL 成为整个团队的卡点。

离开 TL 之后,团队就转不起来了。


这也是实现 “非职权影响力” 的核心秘诀:

  • 不要干涉开发所做的事情,让他们为自己的事情负责

  • TL 应当尽一切可能做好服务工作,帮助他们解决自身角色不好解决的问题


比如说,技术讨论、周会、团建、项目 等等一切团队内外事务,

都应该交给团队本身来负责,而不是全部由 TL 一力承担。

这不但能提高每个成员的参与感,也能让每个人有更大的施展空间。


这一点说起来容易,但其实很难做到,

每一个 TL 都得在 “事无巨细” 和 “两袖清风” 之间寻找一个平衡点。


有句话是说 “善战无功,善医无名”。

那些擅长带领团队的 TL,往往看起来很清闲,反而不被别人认为他做了很多事情。


从这一点上来看,TL 得抗住压力,以结果为导向。

不要装作一副很忙的样子,或者瞎折腾。

文化是最好的激励手段

好的氛围,可以让大家工作轻松愉快,从而让员工更想来上班。

这种积极情绪所产生的效果,是 “压榨员工” 的方式不可比拟的。

高效工作所创造的价值,远大于 “内卷摸鱼”。


一个最基本的要求是,作为 TL 能否做到不让开发加班。

  • 明确的传达不加班的想法,并以身作则,避免别人不好意思下班

  • 不要承接超出团队负荷的工作,要敢于拒绝,灵活调整优先级

  • 努力提高工作时间的效率,少开会,少让大家写周报


其次,提升团队凝聚力,让大家充满责任心,互相帮助不要甩锅。

  • 任何事情不要抱怨,只要接过来以后就是自己的事情

  • 先确定负责人再解决问题,避免胡乱指点但不负责

  • 保护好团队,扛住外部甩过来的锅,时刻保持警惕


一个优秀的 TL 不应当是 “劳模”,而是一个俗人。

TL 从开发过来,要能站在开发角度看待问题。

让大家早点下班,轻松工作,比什么都好。

多做向下汇报

一线开发的很多决策偏差,源于 “信息差”,对大环境发生事情不太了解。

所以 TL 应当做好向下汇报,尤其是主动发送周报给团队阅读,

而不是要求每个开发向上汇报工作。


向下汇报,有助于让开发了解自己的工作在 TL 眼里是什么样子,

也有助于开发之间互相了解彼此的工作,

更有助于 TL 在团队与团队之间讨论问题,不用每次都带着人去开会。


任何新闻、计划,都应该由 TL 向下分享,并把决策权交给一线开发。

TL 应当记录这些关键决策,对外向其他团队或向上同步。


只有锻炼向下汇报,才能少折腾开发,让开发把大部分精力都放在解决问题上,

而不是浪费在汇报怎样解决问题上。


关于怎样解决问题,TL 应当给出建议和指导,并促进团队内部沟通,

让团队有自行得出结论的能力。

向上/对外 对齐

除了怎么管理好团队之外,TL 还得为团队成员的工作绩效负责,主要看几点,

  • 目标设置的是否合理,目标达成效率如何

  • 内外预期是否对齐,是否存在高预期低产出的问题

  • 项目风险是否及时暴露出来了,不要憋大招


要想规避以上几点,TL 还要做好向上沟通。

及时 向上/对外 展示团队中每个人做了哪些工作,以及阶段性成果。


实时同步进展,是一种很好的解决不确定性问题的办法,

这有助于我们随时调整预算,及时止损。


在向上汇报工作的时候,切记不要邀功,TL 做的事情越少,团队就越强。

团队的战斗力,轻松远超一个人的工作产出。

成果都应当归属给开发,TL 是帮助开发尽快拿到这些成果。

结语

TL 这个角色,有很多方面的思维方式是跟一线开发不同的,

即使自己是一名很出色的开发,也要坚信并鼓励团队自行解决问题。


如果团队内外大部分事项,都必须由 TL 来拍板,那就是危险的。

而且更危险的是,很多团队会将上述情况习以为常。

TL 也会觉得自己更重要,这其实是 “自欺欺人” 的一种表现。


TL 的为难之处在于,无法通过绩效来影响开发的行为,

只能通过 帮助获得更好的绩效、提供更好的文化,来售卖服务。

所以很多事情,如果缺少共赢点,根本推动不下去,每个开发都可以拒绝合作。


反之,如果能提供更好的文化,更轻松的工作环境、团队环境,

也就能让组内开发更乐意跟随 TL “吃香喝辣”。


以上这就是 TL 的练级指南,其实只要做好为开发着想、为结果负责的心,

那也就离优秀不远了。