前言
笔者从 15 年 5 月开始从带 3 人小团队到目前 10 人左右规模, 从一线研发工程师到 Team Leader(下文简写为 TL) 身份转换的过程中, 曾经有过很多迷茫与困惑, 完成转换之后总结一些心得写到这篇文章中
降低编码的时间
多数技术团队的 Leader 都是从表现优秀的一线工程师中提拔上来的, 这个现象在其他行业也普遍存在而作为工程师本能的希望自己每天继续写代码, 沉浸在自己的代码世界中, 努力提高技术水平
针对问题上, 笔者的建议是, 最大程度的降低自己的编码时间
为什么?
首先需要想清楚 TL 该做的事情, 总结起来有以下两点:
对团队的产出结果负责
对团队成员的成长负责
如果 TL 每天花大量的时间投入到编码中, 那么最终带来损失的是整个团队
首先, 团队的成员会在 TL 高超的技术水平的光环下, 极度缓慢的成长, 因为如果大量的需求开发工作被 TL 搞定了, 团队成员就很难有机会得到锻炼
第二, 团队中的真正只有 TL 能解决的问题被搁置, 比如团队成员间配合时的摩擦比如同兄弟团队配合过程中流程上的问题等等这些问题一旦被搁置, 对团队自身的伤害非常大
TL 要时刻牢记自己如何发挥最大的价值, 给团队带来产出, 跳出自己原有的熟悉域, 站在更高的角度去思考
分配多少时间去处理代码?
首先一定不要走极端: 那好吧, 我不写代码了, 让团队内其他同学去写吧, 我就处理其他事情, 代码写成啥样也不关心了
笔者建议分配时间的 30% 来处理代码, 处理的含义在于, 可以是直接写代码, 或者是 Review 其他人写的代码
前面提到 TL 的职责, 你需要为结果负责, 对成员的成长负责, 因此花时间去 Review 代码, 给其他成员一些指导和建议是很有必要的在这个过程中也可以发现工程内潜在的问题, 并且作为 TL 推进解决
花时间做一对一沟通
作为 TL 很重要的一点在于为团队内的其他成员服务, 了解他们的诉求, 分析他们阶段性的问题, 并帮助他们去解决
周期性的一对一沟通是非常有必要的, 也是作为 TL 一定需要花大量时间去做的
很多工程师的性格都很内向, 但一定要迈出这一步, 经常性的聊聊天, 将你看到成员自身的问题及时反馈出来, 并且给出指导建议, 对于团队成员的成长是非常有利的
如何做一对一沟通?
首先沟通的诀窍只有两个字: 真诚
从团队成员成长角度出发, 能够达成共鸣, 并得到很好的沟通效果
及时直接的指出成员的问题, 并帮助他改进
不要让自己成为决策的瓶颈
很多 TL 自身不参与代码开发但非常喜欢拍板, 无论大小都要经有 TL 决策
从效率角度出发, 如果 TL 成为决策的瓶颈, TL 自身的效率将会大大降低, 每天需要处理无数的事情, 大脑基本要爆炸了, 团队推进事情的效率也将降低, 因为任何事情都要等待 TL 来决策
从团队成员角度出发, 不做决策意味着可以不对决策产生的结果负责, 长期下来也就不需要针对事情做过多的思考了, 思考少了成长自然也就少了与此同时他们更多的工作就是一个执行者, 对事情没有决策权, 每天的成就感也会大幅降低
该如何做
培养能够作出准确决策的人, 给团队成员更大的空间来发挥自己的才能
参与决策讨论, 决策过程中抛开 TL 的身份, 给出必要的建议, 但不要身份压制
对待决策的事情进行划分, 能够下方权利决策的事情明确负责人, 负责人对结果负责
传达价值观, 以身作则
一个团队的价值观决定了这个团队的行为方式, 以及战斗力
因此从一开始 TL 就要思考我希望的团队文化是什么样的, 团队成员的价值观应该是什么样的, 并且在工作的过程中去传达
比如希望打造学习型的团队, 希望团队中每个成员除了开发以外, 能够有提高, 那么 TL 就需要去思考一些能做的事情, 传达这个想法
TL 的行为方式也会潜移默化的影响到团队中的其他成员如果口号喊一套, 实际做事是另一套, 那么事情推进起来就不会很顺利所以一定要以身作则, 为团队成员梳理标杆, 让大家明白 TL 是这样做的, 那我也应该这样做
总结
Team Leader 是一个很关键的岗位, 在这个岗位上也需要非常多的思考 简单的做了几条总结, 希望能够帮助新人 TL, 文中的很多观点也是基于现有的认识和经验做的总结, 欢迎留言
来源: https://juejin.im/post/5a59c19351882573315c52be