如何推动技术团队的成长
什么是管理
个人理解为：调配所能支配的所有资源，最高效最高质量的完成目标。
管理事项包含
- 人：选人、育人、淘汰、晋升等，人是团队的基础，也是一个好的团队的核心要素。
- 事：团队组建的目的，是为了完成目标的完成，主要包含两件事情，业务支撑和团队基建。
- 文化：文化是组织发展的核心内容，是推动个人成长、团队成长的动力引擎。
- 影响力：影响力是领导者的必备能力，包含对内影响力、对外影响力。影响力的塑造，可作为团队发展的第二动力引擎，侧面推动团队的成长。
人
选人
常规选人的两种方式：内部选拔和外部招聘，所偏向的重点不同。
-
内部选拔
- 价值观
- 利他精神
- 技术能力
- 业务经验
- 认知、思维
- 抗风险
-
外部招聘（经验的优质高潜，和具备经验的技术专家）
- 技术能力
- 业务深度
- 推动能力
- 沟通能力
- 好奇心
- 抗压
育人
用人长，补人短。关注团队成员的输入与输出。
可以通过以下方式进行团队培养：
1. 集体学习，团队共同制定目标，阶段完成学习任务目标。
2. 根据个人兴趣和优势方向，分别制定目标，定期进行团队分享。
3. 团队集体培训，可以采用引入外部讲师或定时集体学习直播课视频课等形式。
常规的几种团队学习成长方式，也可以交叉进行，最终的目的为提升团队成员岗位专业能力。
主动淘汰
关于主动汰劣，制定好目标、周期、标准后，跟踪过程。
过程中做好阶段性 Review，尽量避免过程中缺少沟通，最后来个一次定生死，给员工个惊喜。
绩效结果涉及到人去评价，多少都会有主观因素存在，个人的建议是，立场要站稳，对公不对私。
标准前置化，绩效看产出结果，尤其是对应的业务结果。
合适的前置目标和过程跟进，合适的考评标准，会让绝大部分的团队成员，对自己和团队内他人绩效结果的预测，八九不离十。
被动流失
关键岗位必须有 Backup，团队leader，小组负责人，技术建设者，都是关键岗位。每个关键岗位做好Backup，是团队保持团队稳定的手段之一。
绩效标准（参考）
- 3.25（不满足期望）：代表的是无年终、无加薪、无晋升。有些公司还会针对这部分员工纳入 Pro 改进流程，改进不到位就淘汰；有些公司是连续两次 3.25 解除合同。针对业绩不满足期望，一定是其工作有重大人为过失（如因个人疏忽直接导致线上 P0/P1/P2 等重大故障），或是明确不满足团队现阶段的用人标准。
- 3.5-（部分不满足）：这部分我的标准是，有 80 分的能力，却只拿到了 70 分的结果。可能是因为合作态度问题，可能是因为自己跟进不力，总之未能发挥该有的水平，浪费了天赋。
- 3.5（满足期望）：良好完成自己分内工作，属于得努力踮踮脚甚至跳一跳才 OK 的结果，但也没明确的亮点，只是做到了分内事。
- 3.5+（部分超出）：有亮点，除了完成分内事，还带来积极正向的改变，有明确的对外的影响和推动结果。
- 3.75（超出期望）：不止是亮点，更有惊喜。通过个人努力和推动，带来了突破性的变化。
晋升
晋升是一个结果而非目标。简单说，晋升的前提，是能像下一个层级那样思考问题，并在做下一个层级做的事并拿到结果。
绩效好不等于能晋升，前者是拿到了突破性结果，但不代表一定能胜任下一层级的综合要求。管理者也不应该将晋升等同于排队，晋升需要对结果及直接显著的贡献负责。
对于晋升提名通过者，管理者需要进行必要的晋升辅导，如演示稿、陈述内容结构优化的辅导等，必要时还可以组织几场模拟面试，帮助参加晋升面试的同学找找感觉。程序员很多人都是会做不会说，必要的辅导还是需要的。
这里特别强调一下晋升后新的目标的设定。部分流失是出现在晋升后，晋升成功就提离职不是玩笑，是确实存在的局部现象。晋升后，前期的持续努力得到了阶段性满足，新的目标感缺失（有些是晋升后待遇变化低于预期），会加大诱发离职的风险。
考评
考评维度的单一，是管理者的大忌。考评什么，就会得到什么。维度单一会导致团队能力单一，核心人员的输入、输出空间不足，诱发流失。考评维度单一，也会造成团队寒心、失心，严重的会导致团队核心离散。
制定每个岗位每个职级的能力模型，根据职级要求，进行标准制定，根据标准进行考核项目的输出，最后达到多维度，多角度，多层级的考评方式。
能力模型（图）
事情
- 业务支撑
优质高效的支撑业务，是活在当下。做完既定的业务工作，帮助业务达成既定的业绩目标，是拿工资该做到的最基本的事。
但做完绝不意味着结果 OK。好的业务支撑，在做完的基础上，还要能做好。
深入业务，对业务预期的把握和影响，面向业务支撑的流程、协作等优化，驱动业务乃至正向的影响到业务的产品架构，技术的方式优化支撑业务的基础模式，用更具效率、更优体验的方式为业务带来更多可能性，都是需要考量和衡量的点。 - 技术基建
必要的技术建设，是为了帮助业务和团队活好未来。
尤其是对于前端职能来说，太多的前端团队仅是面向最上层的 “用户界面层” 进行开发，基建也仅是一套三方的开源组件库 + 一套本地脚手架环境，技术范畴很薄，业务影响不深。
这也导致普遍的在研发体系的对话中，前端的话语权偏低，处于堆人力的资源型工种，经常被 “资源瓶颈” 的问题怼。
影响力
-
对内影响力
- 业务支撑
- 业务渗透
- 跨部门推动
- 向上管理
- 分享输出
-
对外影响力
- 平台品牌
- 产品输出
- 技术输出
- 内容输出
- 品牌化运营
最后
管理者是推动改变的人，从最初的执行，到开始承担对改变负责，到逐渐适应，一路上的心路历程和风景各不相同。
管理者是火车头，肩上负担着业务、团队方向，及身后一群人未来一个阶段的得失。
套用一篇讲企业发展文章的话，“朝哪个方向走，判断的核心是深刻理解市场、业务的趋势。
这其中，要对技术的未来做判断，对产品的未来做判断，相对而言，大部分人都能看到技术的发展趋势，困难的是判断未来的产品形态”。
运作一个团队，和运营一家企业，异曲同工。管理者，其自身也是创业者。
管理者同时也要面对结构性挑战与周期性挑战，只有活得久才能迎接更大的空间挑战。
结构性挑战，是在不同的业务及团队阶段，团队需要发展和落实的结构性能力、体系性能力。
人才体系、文化体系、组织架构、技术体系、业务体系，管理者首先要尽量成长为体系性选手，具备搭建体系的能力，否则会压低团队的天花板。
周期性挑战，亦是在不同的业务及团队阶段，管理者需要侧重面对的核心问题也是在变化中。
草莽期解决无到有，资源压力；快速发展期要快速搭建技术体系和优化梯队；技术体系相对完备时要跳出前端的事业，横向推动和打通，和业务产生更多互动；
平台期需要帮助业务和团队在新的曲线破局... 每个管理者必须要务实、要花足够的精力提高自己推动改变的能力。