著作权归作者所有。商业转载请联系 Scott 获得授权,非商业转载请注明出处[务必保留全文,勿做删减]。
Scott 近年面试或线下线上技术分享,遇到太多前端同学,由于团队原因/个人原因/职业成长/技术与管理通道,甚至家庭城市等等原因,在理想国与现实之间,在放弃与坚守之间,摇摆不停,心酸硬扛,大家可以找我聊聊南聊聊北,对工程师的宿命和价值有更多的看见与了解,Scott 微信: codingdream。
近期面试了一个工作 10 年的前端主管,带领了一个 9 人的前端团队,从他身上明显发现了两个致命的问题:一、他没有意识到成员拥有成长空间的重要性,二、他没有以培养接班人的心态打造团队腰部力量,最终事无巨细亲力亲为但整个团队并没有持续发生更快更好的变化,总结出一句话就是带领不是领导,而是领着冲刺成绩,管理不是权力,而是激励授权培养更多骨干。
抛开场景谈管理,跟抛开场景谈技术一样,很容易沦为干巴巴的教条,我这一篇会以小菜前端为样板,结合实际的案例,给大家引入我的管理思路,以及通用的方法论和观察视角,只要能给大家带来一点点启发,最终带团队少走了那么一点点弯路,本文的价值就足够大了,因为带团队本身就是一项因人而异的艺术,而艺术很难加上刻度进行量化。
另外,我会换用问答的形式,来跟各位对话,在每次往下看我的观点之前,请先在内心酝酿你的答案,酝酿成熟后,再往下浏览,这样可以保留属于你自己的思辨,避免被我先入为主,因为管理本身并非是寻求答案,更多是训练如何寻求答案形成落地 Action 的思考习惯,那我们先思考第一个问题:前端工程师这个群体身上有什么特质?
重新认识前端工程师
前端工程师虽是工程师,却与主流技术从业者有诸多不同,最大不同就是想象力创造力爆棚,浑身散发纯真的文艺气息,天真美好浪漫但是一放到荒漠沙洲却常常不堪一击,这是我两年前带团队时分享的一页 PPT:
以及关于前端主要工作场景的一页 PPT:
一群人会塑造和改善环境,而环境反过来也会重塑它之中的人,这也是为什么程序员在人群中很容易被一眼识别的原因,那就是特定的工种塑造出我们特定的性格、喜好、气质、观人看事的角度,这样的塑造在前端的行业中更加的深刻更加的剧烈,因此一个前端团队往往比想象中好带,也可能比想象中难带的多,这一群人真的可能会千人千面,与众不同,拢在一起别说团结一致,有时能否听从指挥都是问题,彼此的感情连接紧密程度可弱可强,前端的技术面积宽深度浅,这都是客观存在的事实,并且这个群体可千万不可小觑,如果不用心带不仅会让你目标错失,API 无法完成,甚至整个团队会分崩离散,那接下来让我们来面对这个课题吧,小型的前端团队到底应该怎么带?
要讨论怎么带,我们还要看看一个前端团队在不断成长的过程中,从 1 个人到 5 个人,到 10 个人,到 30 个人,到 80 个人,到 100 个人,你认为这个团队会经历哪些阶段,会有什么样的能力结构,也就是你现在 10 人团队的当下如何,未来怎样?大家对这个充分思考后再看下文。
小菜前端的几个时代
上文聊了前端的个性化特质,再来看下 10 人团队可能处于哪个阶段,2 年前看到蚂蚁金服的玉伯分享了前端的几个时代,非常认同,我把它进行了调整进一步转化到小菜的业务和组织架构上,最后草拟了这样的一张规划图:
这几个时代词如其意:
- 人工时代偏人肉,工具设施薄弱,业务繁重,资源紧张
- 工具时代偏效率,各种轮子往上凑,不太成体系还忙中带乱,业务支撑可圈可点
- 工程时代偏规模,规模化的用户和业务背后可复用的工程化体系与方案,业务支撑稳定有序
- 智能时代偏算法,通过对业务深刻的理解和运用来打造出非常好用的产品和服务,极大的解放人力
那我们带的团队在 10 人以内,如果不是在 BAT 这种大厂,往往处于工具和工程能力偏弱的阶段,也就是人工时代,业务越重基建容易越薄弱,如果是有很好的团队规划意识以及公司的资源支撑,那么 10 人团队往往会处在人工时代往工具时代的转型期,此时基建往往与业务并进,彼此互相影响,但总体依然会偏向人工,而人工时代的团队特征是什么,这是我们需要思考的问题。人工时代或者说人肉时代,我们对于人的依赖程度很高,这时候如果是纯资源管理的视角,那先思考下你最多能直接管理多少人,你觉得 10 人团队应该管理什么?好管理么?
管理半径与团队阶段
一周五天,一天重点照顾两个人,10 人的团队可以勉强覆盖,根据我的过往经验,一个管理者如果要对每一个成员都负责,都能拿到结果,基本上 10 个人就是一道坎,在 10 人以内,是有机会也有能力对每一个成员负责的,但高度负责后的团队主管会很累很忙,也就是人越少越依赖主管帮带和规划的个人能力,带小团队往往是这样的背景。
还是以小菜为例,我按照阿里的 P 系列来对团队能力层次的几个阶段做了整理,这些不是严格意义上的小菜前端层级分布,只做示意,供大家观察趋势和问题(18 人是当下,25 人是未来小半年后),看完后请思考每个阶段都有什么问题?
第一个阶段,7 人左右,整体工程师能力偏弱,极少数的技术熟练工,资深前端会成为团队的能力天花板,这样的状态如果没有新变化会磨削掉所有人的成长空间,逐渐沦为纯粹做事的工具或者资源,新同学没成长,老同学到天花板,离职率就会变高;
第二个阶段,10 人左右,有了带队的专家,但有大量的初级前端,而资深前端数量偏少,这样在腰部的传承这块就会断层,所以此时专家就必须对很多具体的事项负责,也需要对人才的成长和资源的解放负责,带队专家会成为团队瓶颈,如果不得到进一步的团队能力提高和解放,专家的综合能力也会遇到天花板;
第三个阶段,13 人左右,补充了更多的资深前端,整体分布看上去趋于健康,但专家变得紧缺,因为有更多的资深前端嗷嗷待哺,依然是在腰部短板,此时会有个别有管理能力的同学涌现,但管理意识和方式都很初级,需要有一些制度性培训性的流程来保障他们融入组织成长;
第四个阶段,18 人左右,有了更高层级的专家,专家整体数量变多,但初级前端也变得更多,此时需要有更多具备管理能力的腰部主管出现,这一层职责就落到了专家层,需要专家成为教练,来主导自己的小组方向,将更好的方法论实施起来,帮助同学更快成长,所以这个阶段对于资深前端和专家的需求依然旺盛;
第五个阶段,25 人左右,有了更多具备管理能力的资深前端和专家,整个团队的能力传递形成了梯度,整体分布趋于健康,但在初级前端和资深前端交接的这一层 P5+/P6- 成为了能力洼地,需要更多同学被发掘和帮带上来,通常这个时期会有大量意识好主动强有担当,并且能扛风险拿业务结果的同学快速晋升,这个阶段是一个团队真正意义的黄金成长期;
这里提供给大家一种从能力来看团队健康度的视角,实际上的团队所处环境会比图上复杂很多,比如有掉队同学的劝退,优秀同学的离职,有新同学的加入冲击,再加上各种不同的业务交叉时资源的冲突,技术栈的发展畸形,公司大组织架构的变化等等,每个阶段的侧重点都不同, 所有这些都考察者团队管理者的反应速度和决断能力,而正向的业务会带来人员数量的快速增长,因此管理能力与增长的动态变化,会变成团队能力的核心坐标,稍有不慎就会出现管理故障。
虽然每个阶段都不同,但每个阶段都是承接与上一个阶段的成果之上的,越早期时候的方向修正的正确,越后期的扩展和成长才会更顺利,否则团队整体的心智在这些阶段中历经冲击,反而会伤害到整体的团队心理状态和能力梯度,我们切回去到 10 人之前的团队状态,这个时期是整个团队最早期也是最最重要的原子阶段,这个时期所奠定的研发底蕴、工程师文化、分享与影响力、看待业务与技术的态度、自我认识与工程师价值判断等等都是在这个时期慢慢形成雏形,所以千万不要小看人数不足 10 人的时期,这个底子没打好,后面会变灾难。
对于小菜来说,10 人时期主要的管理工作,除了业务,就是技术栈的提前规划预研、工程师的稳定性、团队内技术资产的透明化、一定程度的效率与质量基建,包括工程师的成就感培养和有潜力员工的刻意栽培,这就是此时管理二字此时的含义。
我们花了大量篇幅讨论前端的职业特征、团队的发展阶段,你作为事实上的管理者,或者未来潜在的管理者,要拥有哪些能力,以及从哪些方面来带领这个团队快速成长,奠定必要(至少是不差)的早期基础呢?大家思考一下先。
技术 TL 必备能力清单
管理是一门很复杂的学问,团队越大越依赖管理手段,人越少越依赖带领能力,我们把 10 人团队的管理弱化,同时把此时主管需要的能力简化为带领能力,那么这样的能力如何训练呢?让他成为你技术管理生涯中的雏形能力,为未来你带领 20 人、 50 人团队做好铺垫。
大家可以先思考下,思考后再看下面这几张图,图上是 Scott 刚接手 7 人团队后半年多主要关注的事情(图是半年汇报 PPT 的截图),那时对于管理和带领的认识是没有今天深刻的,后面我会把当时半年多的过程整理成观点:
来到今天,我回头去看过往走过的路,把 10 人团队内需要训练的几个核心能力总结为:敢于担当、建立信任、善于规划、探索创新、培养成就感、扩大影响力。
为什么是这几个,做不做又有什么区别呢?对于我做管理意味着什么?大家可以先思考下,然后我们再针对每一个适当展开一些讨论。
担当是拥抱组织的前提条件
一个团队的管理者,如果没有担当,那就是一场巨大的灾难,这是对管理者最基本的要求。而担当讲着容易,做起来却很难,一旦你带领一个团队的时候,你就需要拥抱这个团队,无论他做的多好的地方还是多烂的地方,无论团队的能力和业绩是出众的,还是扶不上墙的,当你的屁股坐在这里的时候,当组织把你放到这个位置的时候,你对上级主管和组织就是背负着他们的信任和期待,对下面的员工则背负着责任与担当,除非你永远也不坐到具有管理职能的位置上,否则担当是你永远也无法回避的管理门槛。
信任是做好管理的黄金基石
当你要带领一个团队时,你的任何决定都是需要团队的大多数人支持和推进的,那么你就需要争取到绝大多数人的信任,即便一个事情他认为是百分百错的,但是你这里必须紧急执行,那么基于信任他也会尽心执行,否则就容易产生对抗或者过程偏离,而对抗和未尽心尽力伤害的不仅仅是管理者和当事员工,也最终会伤害到公司既定目标的实现,反之,员工需要获得你的信任,你也要获得你老板的信任,这样一层层的双向信任,才有可能在整体推进时候遇到最小的阻力。
规划是带领团队的必备素质
对于管理者来说,要把全团队人的时间用出相对较高的价值,就必须有规划能力,所谓规划,就是把想做的事情坐标化和里程碑化,坐标里的 x 轴是基于时间尺度的团队不同阶段,纵轴是不同阶段需要重点做的事情,而里程碑就是每个特定阶段每个重点事情,它在特定时间点需要达成的目标,这个能力是最容易被技术管理者忽略的技能,大家往往觉得脑海里有个模糊的概念和方向就行了,剩下所有的事情就靠 Coding,一直 Coding,这对于团队是很大的伤害,其实就算不是作为管理者,越是技术走向资深,越是承担更大的挑战,规划能力就越刚需。
探索是驱动组织的不二法宝
技术往往是有趣的,而技术做的事情往往是无趣的,在无趣中找有趣是一个永恒的课题,摆在管理者的面前。如果你是一个喜欢求稳的墨守成规的管理者,那么所有跟着你的同学,他们的成长空间就会受限,反之如果你是一个非常激进敢于冒险的管理者,所有跟着你的同学空间就会快速放大,但同时也会伴随较大的技术冒进风险,所以探索的速度和深度需要结合严禁的规划来实现,一定是基于深思熟虑的有实际价值的规划路径来做探索,而既然要探索,就要解放思想,放开手脚,不要犹犹豫豫左右徘徊。
成就是选拔人才的通关门卡
虽然工作只是混口饭(PS: 惨兮兮的说法而已..),但对于现代的年轻人,表里一致兴趣契合以及技术开发所能带来的成就感,这一点必须单独拎出来说,这里的成就感不仅仅指技术上实现所带来的成就感,更是他职业生涯上有所突破,做的事情能看到实际价值,包括技术深度广度上真真实实的收获,这些收获是个人努力得到的,但这些机会和道路是你为组员设定规划或者是指引的,因此这时候成就他人就是你必须培养的一种能力,也只有通过成就他人才能最终成就业务,成就团队,从而也成就自己。
影响是培育文化的终极魔法
我们通常讲影响力,都很容易联想到技术分享带来的影响力,所谓技术网红的样子,这一点没错,我们在前面专门有一篇文章探讨过影响力的意义和如何做影响力,那放到管理的视角来看,如果团队整体是一个社会化的人,那么影响力就是它的综合口碑,它的外部形象,它给外界所传达的人设,这些虚的东西往往发挥着着非常实的作用,比如对于你的招人,比如对于你团队内文化的促进,比如对于你团队与其他团队的合作关系等等,扩大影响力并且不断的塑造正向的影响力,也是一个技术 TL 不能回避的课题。
这几项能力在职业生涯中不断历练,一个 10 人的前端团队就能带的越来也有章法,但知易行难,在大家当下实际的环境中也一定会遇到种种的困难,我的建议是,选择一到两个作为主线,在特定的时期内重点推动,同时尽可能兼顾其他,通过周期性的轮转,来让团队不断的磨合前进,形成的合力越来越强,就像小菜前端 2019 年的主轴就是认知升级:
从问题抽象到行动聚焦
一旦我们对团队梳理后,脑海中有了明确的主线,那么就可以把团队现存的所有问题进行分类,分类是为了聚焦,在特定时间周期内聚焦到特定问题,投入主要精力进行改善解决,就比如前文提到的,小菜在初期也会有下面的 8 大类问题,此时的小菜刚好是在 10 人规模之内:
针对这些问题分别聚焦后,以半月到单月的长度,进行了持续半年的推进解决,有的是靠口头,有的靠文档,有的靠工具,有的靠分享,有的靠影响力,有的靠业务赋能,所以小菜才这样一步步克服过来:
当问题都陆续解决的时候,实际上就是管理更上一个台阶的时候,也是团队基础打好,准备打下一场大战役的时候,在这样的一个套路上,我们一直这样操作,2019 年的认知升级,也是为了 2020 年能更好的能力升级,只不过此时面临的挑战是人数超过 20 人的团队它的境况,而它的基础是当初 10 人规模的阶段。
最最后,大家在带这样规模团队时候,需要真的把心放进去,刻意练习担当、信任、规划、探索、成就感、影响力这几个关键词背后的能力,同时把眼光往后面多展望半年,聚焦当下的问题,形成具体的计划逐步推动,相信这个团队在你的带领下,一定会每一周都有一个新面貌。
近两年 Scott 观察到前端行业已经完全进入竞争的深水区,各大小公司的前端 TL 刚刚上任,初带团队,针对前端工程师这个群体,应该怎么管人理事,搭台拿结果,帮带有成长,就成立了这个全国的前端技术主管学习交流群,在人的选用育留上互相学习成长,入群的门坎是你有实线或者虚线在带团队,请加 Scott 微信: codingdream 邀请入群,二维码见下方:
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。