著作权归作者所有。商业转载请联系 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 邀请入群，二维码见下方：