前端领域主管是刚需，中小前端团队Team Leader如何养成？
作者丨Scott
编辑丨张笑菊
中国互联网产业高速发展，很多互联网创业公司应运而生，在带动前端行业蓬勃发展的同时，也带来了前端工程师的成长与管理问题。如何在业务达成过程中帮助前端工程师更快更好地成长，如何挖掘工程师的价值，考验着每一位前端团队管理者。
农业电商“宋小菜”前端负责人 Scott 近五年一直活跃在创业公司和前端社区，也活跃在编程知识领域与⼯程师能力领域，伴随着成千上万的前端工程师走上管理岗位。他在自己的团队中不断探索与实践，特别是针对工程师的年轻化，有独特的中小规模创业公司前端团队的管理视角和解法经验。
去年 Scott 在 GMTC 深圳 2019 全球大前端技术大会上分享了《中小前端团队 Team Leader 的管理之路》，本文即根据他的演讲整理而成。
我是 Scott，写了 9 年代码，任职过三家公司：
第 1 段，在阿里工作（2010～2014 共 4 年），在我离开阿里的时候，阿里就已经有七八万员工了，已经是超大型公司了，那几年我做前端并没涉及到管理，只是受到一些管理上的熏陶。
第 2 段，我 2014 年去创业（2014~2017 共 3 年），联合创立了 Moveha&CR 并担任 CTO，最开始只有 2 人，属于是微型企业，在我们创业 3 年快倒闭的时候，公司有 20 多人，公司也从微型企业跨入到小型企业。
第 3 段至今，我在杭州 “宋小菜” 带前端团队，我刚进去的时候，公司规模 200 多人，研发只有 20 多个人，已经初步算是中型企业，现在我们公司已经有 700 人左右，算是一个比较典型的中大型企业了。
无论是阿里这样的巨无霸超大型企业，还是后面的微型企业，再到小型企业、中型企业和大型企业，每种类型的公司研发模式和管理模式都大为不同。
我走上管理岗位是从创业开始的，但那时候因为带的是产品、运营和技术，团队也小，业务复杂度也低，所以都是弱管理，真正完全深入管理也是最近 3 年的时间，我带的团队也经历了很多深刻的变化，前端团队所负责的应用数量从个位数到 60 多个，团队从最少的 6 人到了 20 人，是典型的中小型团队，团队的专家培养也从 0 到 7 个（含招聘的 2 个），能独立带团队的主管也起来了 4 个，算是完整地经历了从弱小到成熟的过程，我个人也完成了管理转型。
这三段职业生涯让我从技术型选手逐渐走向技术管理者，当我回顾这段历程的时候，发现自己踩过很多的坑，也走了很多的弯路，其实很多前端工程师都有相同的焦虑。比如，做管理还是写代码做架构？工程师有没有年龄的天花板？什么时候可以考虑管理转型？在做技术这条路上，遇到分水岭，到底怎么选？今天我就把自己的经历分享出来，希望能给大家带来一些启发。
今天跟大家分享的内容会分为四部分：首先是从行业的视角，通过抽样，让大家大概感知一下行业目前的中小型前端团队的生存现状（这里所说的中小型团队，特指 20 人以内）；其次跟大家分享一下新晋管理者的自我突变；然后简单跟大家回顾下我在宋小菜前端这两年管理上的经验；最后是我对管理的一些看法和建议。
2017 年，国家统计局出台了一个区分企业大小的标准：
公司的总人数小于 10 人，年营收小于 100 万属于微型企业；
公司的总人数小于 100 人，营收小于 1000 万的属于小型企业；
公司的总人数小于 300 人，营收小于一个亿，属于中型企业。
上图是我自己的一个前端管理群（截至 2019 年底，已有近 500 个前端 TL），里面都是前端主管。每个前端主管至少带 3～4 人，多的话 70～80 人。我对这个群做了一个调查，当时群里一共有 340 个前端主管，其中 170 个前端主管作为样本，调查数据如下图。
调查的主要方向是：他们的工作经验、团队中的痛点、未来两个季度的招人计划，也就是他们的用人需求。
从这张表格可以看到，340 个前端主管，所带的人数全部加起来超过 2000 人，也就是说，平均每个主管带 6 个人左右。其中，在作为样本的 170 多个前端主管里面，他们未来半年要招聘的总人数是 700 多人，而对于专家的诉求，实际上的需求占比差不多 30%。
这对招聘来说几乎是不可能的事情，10 个候选人里面有一个专家就不错了，通过这张表格，我们可以得出这么几个结论：
这个行业对于前端主管是刚需，特别是好的前端主管。
现在的互联网公司从前期走向中期的时候，它对于资深的专家的和主管诉求越来越强，要求也会越来越高。
招聘技能慢慢成为一个团队负责人或者前端主管的必备技能，如果你不具备招人能力的话，未来公司扩张中，包括组建新的梯队时会非常困难，你可能会成为团队的瓶颈。
管理技能（人的管理、项目的管理）也会慢慢成为一个资深前端的加分项，资深前端往下走会也会成为专家，走上架构，大概率你未来也会走上管理，真到了这一天，你之前储备的对于管理的认知、方法和经验也会很重要。
最后一个就是大环境，即便是经济下行大环境不好，前端的优质人才市场依然是供不应求，大量的前端主管招不到心仪的人。
上图是对这 170 个的前端主管抽样后做的图表。可以发现，大部分主管所带团队人数是在 10 人以下的，占比大于 65%，这些都是属于是中小型的团队，或者说是比较小型的团队。然后这些主管的工作经验，3~8 年的占比是最多的。他们的管理经验在 1~3 年这个阶段是最多的。说明从 2016～2019 年近 4 年的时间里，前端主管在整个行业中的需求量越来越大了。
新上任的主管，无论是他空降过来，还是晋升上来，还是被他老板拔苗助长提拔上来，一般都会遇到很多问题。之前调查的 170 个主管反馈的问题非常之多，我就简单对他们做个归类，抽离了共性的部分，这里面标黄的几个痛点是反馈最多的：
向上管理：实际上是搞不定老板，很多时候无法获得足够授权。
精力分配：我要参加各种会议评审，还要去定绩效，还要找时间招人，我没有时间写代码，我的技术会荒废。
团队氛围：团建普遍就是跑出去玩一圈或者吃顿饭，做起来效果往往不太好，或者说跟自己的期望值是有 Gap 的。
人才培养：到底怎么培养？对于这一块的认知是比较弱的，也没有具体的方法论。
绩效考核：公司的绩效考核可能整个体系都不是非常完善，导致我在团队里面考核也会比较难做，无论是规则的制定、执行甚至是最终的评估。
技术探索：在团队里想要尝试一些更好的技术选型和方案，首先是自己和身边的同学想不想迈出这一步，其次是老板让不让我做，都要打个问号，再次是公司各方面的条件是不是允许或者适合来做，当这些都不能满足的时候，技术探索总是停留在业余时间，而技术的成长也势必受到影响。
管理服众：可能这个主管是刚空降过来，提拔上来或者是补位过来，面对非常个性也情绪化的前端同学，软了不服你，硬了人逼走了，上面对你不满意，下面对你不认可，夹在中间两头为难。
综上所述，发现前端团队虽然小，但是它可能比服务端还难带。另外从前端一个写代码的身份，慢慢走向到管理的过程，看似很简单，写页面做项目就好了，但实际上要复杂得多。
最后万众创业的背景下，诞生了那么多的中小型企业，每天在经历生死存亡各种倒闭的状况下，它们制度体系和晋升空间都参差不齐的，更不要提技术成长的土壤，在这样的环境中做管理，难度大家可想而知。
通过上面那张“管理人数分布”表格可以发现，很多前端管理者的工作经验是 3~8 年，但他的管理经验只有 1~2 年，他的技术目前可能还没有储备的非常好，这时候做管理就有点拔苗助长了。最终的结果就是，管理技能没有得到非常好的历练的同时，技术又荒废掉了，所以职业生涯在这个节点上可能很难规划也是一个客观现状。
刚才聊的是从管理者的视角看他面临的问题，再切换到管理者下面同学的视角来，会发现同样是挑战：
目前前端管理者经常感慨的是，现在的年轻人没有以前的人好带。我的团队里面平均年龄是 26 岁，之后陆续招进来的很多 95 后，发现有明显不一样，但这个不好带，并不是说人本身的问题，比如年轻人就有什么缺点和劣势，实际上是不同年代的成长背景和职场烙印是不同的，也就是新的雇佣关系中，新的员工的这个族群比起之前的员工从认知、三观和职场理念都发生了变化，但公司的体制各方面并没有保持同样的速度在变化，这时候就让夹在中间层的管理者左右为难，他能感知到年轻人在意的点，他却很难修改整个公司体制。
我这里也单独对很多前端新人做了调研，大概有五六十位同学提交了调查，他们非常 Care 的点主要分为四大类：
成长：现在的同学对于成长诉求是非常强的，不管你是大公司小公司，如果新同学在这里得不到非常好的成长，那是留不住人的。因为前端的技术变化很快，他很担心成长跟不上，呆个两三年就废掉了，失去了自身的竞争力。
薪资：这个我觉得是从前的 80 后不太好意思拿到明面上去讲的一件事情，大家都在讲愿景都在讲情怀，讲钱好像太庸俗，但这个是非常现实的问题，公司是要正面地面对年轻一代的诉求的，他们就是要旅游，要赚钱养家，需要比较好的收入，对他而言，当他成长明显的时候，公司也要给予相应的激励。
氛围：团队的氛围非常重要，关乎每个人的工作体验。可能这个同学的技术也不错，业务也还行，但相处氛围不好的时候，比如有所谓的办公室政治，这个同学的感受就很不好。
平等关系：平等这个词可能不太准确，实际上就是公司的扁平化管理体系，是不是有严苛的上下层级关系，是不是硬邦邦缺少温度的管理模式，特别是处理问题有偏颇、一碗水明显端不平的时候，看到员工眼里，他是很难接受的。
所以有些时候，一些潜力很不错的同学，你把他招进来，但慢慢他的状态不太好了，背后的原因很可能就是进来的头几个月他在成长、薪资、氛围和平等关系这里感受到了自己无法接受的公司的一两个短板，这时候他内心 OS 就变成了：反正我已经进了这个坑了，我就再忍忍吧，忍个一两年我就走，他就开始在为走做储备了。
那么在整个全中国的中小型团队中，带一个小小的前端团队看着很容易，而对于这些新主管来说却很难，从前这些同学做项目如鱼得水，一走上管理就举步维艰，到底为什么呢，那是因为前端的这个生存现状，在大公司和小公司，天然就有着巨大的不同：
这些不同在中小型公司里面，会暴露的更为彻底，我总结一下，对于中小型公司团队里面的前端主管，他面临的问题主要分为六个方面：
公司不给力：首先是公司创业赛道选的有问题，公司的商业模式有问题，公司不给力，这是非常致命的。
老板不给力：老板拥有决策权，但是他可能不太懂技术、产品、运营，这些方面的认知薄弱导致无法完全拥抱更人性化更高效的互联网协同模式。
组织不给力：HR 部门跟老板无法达成共识，搭建的整个公司台子组织混乱、通道模糊，这样的组织关系会给员工带来不好的感受。
业务不给力：业务方可能是偏销售或偏线下，他是非常强势的，对互联网的认知不一定是科学的，一会儿风来一会儿雨，可能导致整个产品技术部门非常被动和弱势。当他们的目标不清楚，KPI 天天变的时候，作为管理者就变得更为被动，慢慢成为了上下连通的传声筒，而非参与者和决策者。
产品不给力：市面上一个好的产品经理是很贵的，没个三四万是拿不下一个真正靠谱的能 Hold 复杂产品线的产品经理的，但是很多公司老板是不愿意花这个钱的，一般就会招个工作一两年的产品经理先过来，顶个位置把这个工具给做出来就行了。恰恰因为这样一个认知导致产品经理这一层他既没话语权，又不能让自己闲着，所以层出不穷的需求全堆上来了，而对于公司长久型的产品架构就把控不住。
技术不给力：通常这个创始团队的 CTO 可能不是纯技术出身的，或者说目前不太懂更为前沿的技术生态，或者懂技术但对工程师不够友好，导致团队内部只能用一些比较陈旧的技术，不愿意探索创新和梳理规范，以及做更长久的有价值的基础设施与人才储备。
总体来看，上图右边这些象限里，每一层出了问题，都会让这个带团队的前端主管非常难受。可能你带这个团队的过程中，优秀的人越来越少，又或者带着带着，人没少，你自己先走了，显然这对于公司都是损失，所以这些问题无论是对于公司的哪个管理层的当事人，都不能视而不见，因为所有的代价最终也都是由公司和整个投资团队买单。
基于上面讨论的行业现状和管理环境，假如我真的处在一个中小型公司里面，在这样的创业环境里面，我到底怎么定位自己呢，总不能听了这场分享，下午就写个邮件说世界很大，我想出去看看吧。
问题还是要面对的，作为管理者要如何在这样的环境中做事呢，因为所有的公司也都经历过过这样的早期阶段，越是创业早期越是如此，我这边截了一个图，有一个主管带了一个 8 人团队，他问了我很多问题，我把他的问题总结下来，其实就是三个问题没有想清楚：
我是谁？我在公司作为技术主管，我们开口都是发展他人，成就他人，那首先要问问我自己能达成什么成就？我想要达到什么成就？如果要辅导他人，带团队成员给他们做规划，那前提是我自己总要有能力给自己做规划吧。然后带团队肯定是在为公司“打仗”做项目，在打仗前中后，我会需要什么样的资源，那所有这些问题，都要在带团队的初期尽量想清楚。
如果“我是谁“想清楚了，接下来就要看我的屁股既然在这里，我到底对什么负责？
先看下图红色的部分，作为一个技术类的前端主管，一定是要对技术决策负责的，然后是项目结果，这两个最核心的一定是逃不掉的，这两个做不好，一切都免谈。
然后在此基础之上，我们要尽可能去为产品结果负责，因为作为管理者，你要跟平行的部门去沟通，参与评审、排兵布阵、资源协调、搭台子等，进而可以为业务结果负责，那如果这时候在产品上和业务上的感觉不够强的话，就会很难发力。
无论是技术决策、项目结果还是产品和业务结果，这都是管理者要负责的事，在整个过程里面，我们是希望团队越做越大，人越来越强。
大和强怎么体现呢？实际上就是人才能够成长起来，也就是人才梯队。那么让人事合二为一，交叉在一起，要让事能成，人也能成，在整个过程中的手段就是排兵布阵。
排兵布阵是分摊在公司的每一次作战计划中的，可能是拿下华南的销售市场，可能是用户规模的快速扩张，从最顶层的战略制定，到核心决策层的战役规划，准备打多少场什么样的战役，最终到各个战役过程中前线指挥部的战术布置。中小前端团队的管理者大部分时候处在战役这一层，比较少参与战略制定，但在战役规划和战术部分是能参与进去的，特别是到更偏执行层的排兵布阵部分，安排什么人以什么角色进什么项目做什么内容对什么负责，你对他又怎么考核。
排兵布阵本质上是为了什么呢？公司就是铁打的营盘流水的兵，同样是铁打的工程师流水的项目。所以从长周期看，人的成长非常重要；短周期看，业务结果非常重要。所以既可以看作是短周期内通过排兵布阵来完成一个又一个产品项目的研发，长周期可以看是让团队通过一次次的排兵布阵在项目中反复历练，从而不断地选拔出有潜能的技术骨干，来不断重塑这个人才梯队的形状，为公司打造一支能打硬仗的研发劲旅。
所谓的选用育留，实际上就是通过一场场战役，把人才梯队的地基夯实，把成员的潜力统统激发出来。那么你就需要有套有效的用人体系，只不过在选用育留的过程中，会基于这个公司的核心价值观（文化、氛围、做事的基本原则等）来作为定海神针左右用人标准和人才匹配，也只有这样，才能在长达数年的创业历程中，不断往上推动到公司决策层面，最终促成公司的愿景、使命的不断达成。
那么作为一个前端管理者，我们具体是对什么负责呢，除了上面更务虚的部分，拆解到员工身上，如果再具象一点，实际上是对右边三角形负责：员工能力、员工意愿、组织环境，也叫组织能力杨三角。关于杨三角，有一本书，大家有兴趣可以看下。
这里的能力、意愿和环境是作为管理者需要负责的对象，翻译过来就是员工有没有能力完成一个个他面对的项目，他的态度、认知和格局是如何的，有没有意愿接受和完成这样的任务，是抗拒被动的，还是兴奋主动的，另外就是整个组织环境是不是有利于他去做事，部门间扯皮甩锅严重不严重，晋升通道顺畅不顺畅，公司配套的激励手段完善不完善，培训机制是否跟得上，甚至是技术团队内的规范、流程和文档成熟不成熟……如此种种。
作为前端管理者，面对上一节提到的负责对象，我需要具备什么能力呢？
下面分别从三个角度进行拆解：
从团队角度，对我而言一定是团队的养成，为了促成这个目标，这个团队在我们公司是需要具备研发、技术创新、数据应用、制定行业技术标准推广布道、知识产权壁垒的搭建和技术商业化等能力。
从管理者角度，作为管理者，即是公司的腰，也是团队的头，但团队又是公司的腿，所以这时候头不能晕，腰不能软，腿不能短，我自身也要具备架构、编程、运维、产品、业务、管理等能力才不至于成为团队的瓶颈。
从管理对象角度，作为管理者，面对员工个人，我要具备能够让组织内的个体向好的方向发展的能力，也就是我训练和培养他的能力，具象化就是我让员工有能力去做，有意愿去做，且让这个组织环境有利于他去做的能力。
基于这三个对象：团队、我自己和所带的小伙伴来确定自己需要具备的能力（当下没有的将来要练习），最终合体后才能对组织负责，也就是对公司的战略目标负责，对人才成长负责。
而在这里，新的前端主管往往会过度重视架构编程和运维的能力，因为过往的三年五年八年，已经在技术领域走到技术专家了，但也会成为职业惯性，反而忽视了其他能力成长的紧迫性。
这些能力都是偏技术侧的自我要求和团队要求，但这些能力合体后放到管理者的能力矩阵中，仅仅是基础技能，只有基础技能对于前端主管来说是远远不够的，你需要被动和主动的做更多事情。
除了基础技能外，要把管理者的价值打足，就一定需要有产品、业务包括管理的综合能力：
对于中小前端团队的管理者，有一些很简单的方法是可以直接应用的，我提炼了可复用的方法，简单总结为 4 步，自我定位、摸底诊断、规划执行、沉淀输出，其中的定位和摸底是双向影响的，要花足信息来做，那么时间关系，这里我主要讲下规划执行。
规划执行中价值共识非常重要，这是很多管理者栽跟头的地方，当然要形成价值共识，它也是有前提的，就是在前面的定位和摸底要够，比如对于公司的、业务的、历史技术包袱的、组织环境等信息了解不充足的话，无论是跟业务方还是跟老板同步都可能不顺利，导致项目在规划后无法执行，甚至无法得到有效授权。
项目很多时候无法顺利的时候，我们都要反思一下，是不是在价值共识这一层没有达成，可能是一个新技术栈的采用，可能是一个新研发模式的尝试甚至是一些业务上的建议输出，在最开始的时候大家的认知和评判标准就已经不同了，这一点尤其值得管理者花心思。
那么整个事情做完之后，我们要尽可能的把数字、案例沉淀出来。比如能力沉淀、套路打法等等，再对内对外去做分享，甚至是可以共享给整个社区，这样做会带来三个好处，第一个是为了让能力经验进一步在团队中传播得到复用，第二个是证明自己的决策是有效的，第三个是可以作为下一次达成共识的佐证素材，来降低未来达成共识的门槛。
首先说一下我带团队时候的现状，我是空降过去的，一开始团队里有七个人，人名还没有完全记熟的时候，就有两个同学离职了。第二个月发现有个同事，因为能力问题转正很难，后面也劝退了。所以，接手团队的头三个月就走了三个人，七个人的原始团队就剩四个人了。如果面临这样的状况，你会怎么办呢？
我这里先不去叙说故事，因为故事梗概太多了，而是用表格的方式，把我面临这个状况所决策的关键节点梳理出来复盘给大家看，特别是摸底的部分，帮大家了解我的做事路径长什么样子：
如果你没有能力给自己做规划的话，怎么给别人做规划呢，上图是我在 2017 年刚进公司的时候做一张表格，现在表格上的维度只是比那时候更加丰富了，基本结构是类似的。
我按照时间线把能力全拆分出来，上半部分是我的专业能力，就是跟技术相关的，下半部分是一些通用能力，分层分阶段的剖析我的心理状态、事业目标、精力分配的强度、对行业思考的宽度和深度等等。做一个长时间轴的广视角的能力矩阵和职业路径的观察，这是我进公司后做的第一件事，就是把我自己给弄清楚了，这也是我平时对微信群小伙伴做辅导的一个基础工具，再叠加上其他的工具以及我的人生和职业经验，我就有把握对任何一个年轻的前端输出一些通用的方向指导、点拨和启发，帮他更好地规划自己在每一个职场每一次项目中如何定位自己，以及何去何从。
接下来，我们摸底同行业的是怎么做的？小菜这个公司最开始只有 React Native App 和少数中后台 PC 端系统，也就是一个 ERP 系统，如果我要带这个团队走的更远，那我就首先要去看采用 RN 技术栈的公司和团队他们这些年遇到了哪些问题，做了哪些建设，用了什么方法论和工具，而不是闭门造车全靠摸。
实际上互联网都是三度人脉，找到这些领域的同学都是不难的，私底下邀请他们吃个饭聊聊职业和技术，基本不会有人抗拒的，所以我有的是在大会上约讲师聊，有的是联系到东南亚的电商团队夜里发红包打电话，有的是我本人跑到上海，请人家私底下吃饭去聊人家团队多少人前端，App 多少个，公司多少人融资什么阶段（不同阶段的公司重心是不同的），技术栈做了哪些基础建设等等。这个样本不需要很大，找十来个人就把 RN 的 APP 生态内的团队问题和经验都收拢到自己这里了。
也是在通过这样的方式了解了其他公司的状况后，横向一对比，发现我们公司处于整个水平线的下面，那么这个团队定位和起点就搞清楚了，也知道自己几斤几两，也知道行业中好的团队做的程度如何，同时吸收了行业中可复用的经验。
诊断是需要在每天的工作里去跟一线的同学一起深度的去看、去听、去观察。实际头一个月两个月时间摸底下来，问题会特别多，防不胜防。比如，周三的正式发布版本，我们把一个测试环境包发上去了，用户打开的时候登不进去，然后销售进去之后提了个单，发现单的数据没有体现，用户根本就没看到，因为它的数据产生在测试环境里面，所以这是非常大的线上 Bug，更不要提整个 node_modules 包源文件中直接修改，然后在仓库中直接 Push……这些问题周三强调之后，可能第二周又犯了。
所有这些问题我写下来，写了满满的一页纸，然后把这些问题全部归类抽象，就总结了上图的几类大的问题：
职业规划不清，大家都不太理解前端能做什么、该做什么，对什么负责，可以做什么亮点，未来的职业路怎么做，做当下这些对未来职业路线有什么影响，自己将来做管理还是做架构，团队处在行业什么水位……大家都理不清楚。
人心不稳定，我去的时候团队陆续走了 3 个前端，在我没去之前，团队的上半年走了更多的前端，这个问题其实是一直存在的，我也才弄清楚并不仅仅是我的空降导致了团队异动，而是这个团队的稳定性问题始终都存在，需要挖出背后的原因。
技能短板多，只能用 RN 开发 APP，在 PC 端、Node.js 方面的技能储备特别少，无法支撑未来业务体量扩大带来的更多产品形态。
合作意识差，跟产品跟后端跟运营沟通带有情绪，自测不充分上线后也概不关心，遇到问题也不擅长沟通解决，投诉较多。
工具基建弱，几乎没有任何提效的研发工具，包括可执行的规范制度。
业务无感知，来活就干，也经常加班，但不清楚这个业务前线的销售在做什么，公司下一个季度的目标是什么，以及产品背后真正的问题和价值。
梯队未搭建，技术好的同学可能在做最没有技术含量的业务，而一些比较有难度的项目可能是一个技术一般的同学在负责，又缺乏足够的辅导，导致问题频频，整个团队的人才梯队也很难补位，人员只能换来换去的临时支撑。
我就是通过这种方式去诊断团队中的问题，只有把这问题诊断的足够清楚，才能对症下药，比如针对工具基建弱这一点，我们从 0 到 1 做了一些工具，并且有数据有案例有评估标准。（如下图）
那么经过一年多的建设，到 2018 年的 10 月份，这些问题基本上大幅缓解，甚至是比较好的解决了。
接下来的几张表格，可以看做是在显微镜下团队的切片，当团队问题解决了，同学就会面临晋升问题。这件事很重要，他意味着团队同学能不能有更大的授权空间，包括公司薪资福利上的回报，如果这个事情藏着掖着或者不执行，那对于同学来说，感受就会非常糟糕。
实际上，之前我们公司是没有一个明确的晋升通道，只是口头上讲。直到 2018 年底，我们公司终于有了非常完整的一套晋升体系，在过程中包括我以及其他的主管，也都在推动这件事情。我每年都会去做盘点，看团队里面有多少同学可能达到晋升标准，如果这个东西不透明，员工就很容易没有目标。
我每年会对团队成员进行摸底和诊断，比如有多少初级、中级、高级、资深专家，我会看团队里面有多少同学能够晋升，哪怕在晋升通道不透明时，我们也可以用能力梯队来判断成员的能力。
另外就是整个梯队的形状是不是健康的，是头大腰瘦，还是有腰无腿，那就要通过内部培养和外部招聘来优化这个梯队形状，包括有足够的腿和强壮的腰，尤其是你的团队到了十几人之后，可能要分小组，这时候每个小组长都会从这些腰里面选拔上来，成为一个新的头，你就需要来综合盘点整个梯队结构，以及做好必要的人员 Backup。
对于管理者，了解业务产品现状很有必要。我的建议是，前端主管刚进公司或者刚切换到新的业务域的时候，对业务不太熟悉的时候，脸皮子要厚实，即使业务开会不叫你，你也应该蹭进去听，除非被撵出来，否则就在里面听，这是一种方式。
还有一种方式就是到业务现场，不管是打电话去了解产品使用，还是跑到业务现场看公司员工他们是怎么推广你的产品的，你要对业务上上下下各个脉络节点有充分的判断，不能只听产品经理讲的东西。
这些方式实际上都要组合着使用，尽可能对整个公司的产品质量也充分摸底，不求摸的有多全，但要摸的相对准确，争取自己参与进去拿到一手素材，产品经理反馈给你的，还有业务反馈给你的，不一定全部真实。
比如很早的时候，我们跟着销售去转服务站，看他们怎么使用 App，就发现了一些问题，我们的用户下单，在 App 上点一下“下单“按钮，这个事情居然不是用户下单，个别销售会拿个本子记下来之后，销售用他自己手机帮用户下单，这叫做非自主下单，我们以为我们产品是用户自己在用，没想到是销售在用，类似这些问题，如果你不到现场，是永远也接触不到、也永远无法理解的。你辛辛苦苦几个月，做了个 App 说要解决用户下单需求，但结果会成为一些销售的下单工具，这就是为什么你一定要充分进业务现场，以及摸底产品和用户使用方式的原因。
当公司的业务起量或者重大项目并行的时候，经常发现人力瓶颈。实际上，往往就是团队的基建体系不完善导致了生产力无法得到释放。上图是我 2019 年做的一个盘点，各种技术设施我们都有，但是目前很多都只是刚刚起步不久。
比如像 H5 的组件，我们目前才做到 20%，因为 2018 年之前，我们只有 App 和 PC 端，我们在 H5 上没有任何的需求，但是 2019 年开始，我们就开始拥抱微信、社群生态，所以这个时候微信、H5，以及买家、卖家、商城各种全起来了，越是这种时候越要鼓励一些同学去做基建的工作。
做这样的盘点图的重要性是，当你在管理团队，分配业务和基建比重的时候，让所有同学都了解到我们的瓶颈在哪里，告诉大家我们重点会做什么，到什么时候希望做到什么程度，期望大家以什么方式来参与共建，又可能获得什么样的成长，所以基建很多时候是团队面临成长难题的一剂非常好的解药，可以帮助同学在技术栈宽度深度上得到比较大的拓展。
所以前面这些着重聊了摸底，因为如果这些信息不充分不清楚，跟业务方跟老板讲价值很多时候都是不成立的，而跟老板讲通价值的能力，也就是我们最前面所说的向上管理的能力。
如果你要走上前端技术管理，你就会面对一些心理要过的关，我总结了以下 4 个关键点：
管理的抓手很核心，背后就是选、用、育、留的能力，我还加了一个开，就是要优化人、劝退人，甚至辞退人这个能力，你只要做管理，迟早你要具备这个能力。
首先，管理的起点实际上是结果达成，这个结果是你团队业务、产品、项目上能拿到的结果，这个结果能拿到了，才算是管理及格了，然后才是人的部分和组织的部分。
实际上，我们说选育留好像是一个非常虚的东西，它的背后其实是有逻辑的。对于人怎么选、选什么人、做什么事、怎么去定目标，怎么评估？都是要想清楚的，并且对技术、产品、业务以及管理全部要兼顾，在整个过程里面，基于事练就人，基于人成就事，而靠管理智慧链接人和事的关键人物，就是作为管理者的你，最终所谓的人事双修，也是对你而言可以达到心力脑力体力上的综合提升。
如果要带团队把它带到自己理想中的状态，除了背后的公司薪资福利整个激励体系的支撑外，我这边还列了另外几个，这些都是管理者可以在不同的阶段，来花精力关注的，比如团队文化建设、组织架构的设计和调整、能力层级的共识晋升通道、人才结构升级、新人融入保障、团队氛围促进、培训体系完善、团队影响力的建设等等，今天时间有限就不做展开了。
这件事最难，我的理解就是，对上要有交代，然后对下要有启发。
最后跟大家念一段话，也是这段话让我对整个前端行业的思考有了更多的维度：
第 4 次全国经济普查系列的第 2 份报告《中小微企业成为推动经济发展的重要力量》中指出，2018 年末，我国中小微企业中，信息传输软件信息系、技术服务，互联网企业总共是 91 万家，比 2013 年末增加了 69 万家，也就是说增长了三倍，增长了 300%。
我们都知道现在的公司提倡拥抱互联网，不管是“+ 互联网“还是“互联网 +“，所谓的流程线上化、业务数据化，包括很多政府部门这里会有最多跑一次这样的政务系统建设，那么所有的这些自主的非自主的系统前台，都需要安装连接背后业务数据的物理界面，也就是我们所说的屏幕甚至是语音设备，无论是车载、移动还是 PC，而界面的建设一定是需要前端的，对于要转型的传统公司也好，新创的互联网公司也好，它们对于前端技术团队的诉求都是刚需。
在这个背景下，对于所有工程师来说都是机会， 所以基于这样的分析，相信我们所有人都能感知到，虽然有很多挑战，工程师前景是依然非常好的，前端这个行业依然是处在中前期的红利阶段，前端管理者也随着时间推移大有可为，接下来就跟大家共同努力来让这个前端生态越来越好，帮助越来越多的开发者得到更多的成长和回报。
Scott（微信：codingdreamer），9 年工程师生涯。曾任职阿里巴巴前端工程师、Moveha|CR CTO，现任宋小菜前端团队负责人，搭建团队从 6 人到 20 人，专注供应链大前端的跨端工具工程化，专注年轻工程师的成长与潜力发掘。
随着云的发展，为进一步推动“大中台、小前端”，我们邀请到行业里具有丰富中台建设经验的同学同大家分享中台建设优秀实践案例，解决问题后带来的效率提升，期待给予大家新的思考。
疫后复工，提升战力，InfoQ 技术大会送来开春福利，大会购票限时 5 折起，还不快行动起来！联系票务经理鱼丸：13269078023（同微信）
可以扫描下图二维码或者点击【阅读原文】，查看官网了解更多详情！
相关内容
微信扫码咨询专知VIP会员