14｜团队优化：如何妥善且优雅地做好解聘工作？

我们需要在思想上对这件事情有一个正确的认识，解聘对团队、个人和管理者三方都是有好处的。摆正自己的立场才能做出正确的决定。

1.公司发展太快，个人没有跟上脚步

2.个人的价值观和团队不匹配。

3.公司发展太慢，而不得不暂时“壮士断臂”，先求生存。

解聘前：需要持续的管理动作

解聘的过程并不是一蹴而就的，这只是一个最终结果，前期我们需要让员工对自己的能力和位置有一个基本的认识，这样他才容易理解你做出的决定。

绩效潜力九宫格

发现问题后，跟员工指出可能绩效不合格，被离开。

解聘时：注意沟通方式与态度

Leader 一对一沟通，解释解聘的原因，不要和他产生冲突，可以的话介绍其他公司的岗位给他，

解聘后：妥善收尾

工作交接，可以给被解聘的员工推荐合适的工作机会。

淘汰目的就是要维持以及提升自己团队的战斗力。简单说如果团队靠后的同学能够及时调整快速达到管理者要求的最低门槛，那就无需汰换，如果预期很难达成或者成本实在太高那就只能“心慈刀快”了。

15 空降负责人如何与团队建立信任

如何快速融入新团队，建立信任？

获取团队的认可和信任是这个阶段最核心的目标，

谋定而后动

一是要重点听业务团队的声音，他们的反馈会更中肯，而且大多是从业务困难的角度看技术问题，二是要多和 HRBP 沟通和交流，HR 信息渠道多，对团队理解更深刻，是管理者不可多得的好伙伴。

先落地小事

先落地小事，向上可以增强领导对我们的信心，缓解自己的压力，良好的心态是后续开展工作的必要条件。向下可以用“胜利”来让下属和同事了解我们的专业水平，实力是赢得团队信任的最好方式。

建设性沟通

选择理性、客观地看待这些现状，避免在沟通过程中直接评价，尤其是以质疑或者挑战的态度去评价。

受资源、时间等限制，技术方案的选择更多体现的是利弊折中，在看到问题时应该更关注这个问题产生的背后原因.应该以谦和友善的态度来了解问题，做技术探讨。切不能站在技术高地上进行批判和点评。最好是自己有了相应的解决思路后，再和对方进行平等、开放的讨论。

当然看到团队的亮点时，务必不吝赞美给大家肯定，指出其中的做得好的地方。

16｜有战斗力的团队，是打造出来的，也是争取来的

有战斗力的团队体现在两个方面：

平时做事靠谱。

关键时刻能打赢硬仗。

1.选人

愿意学习，有使命感

作为管理者，真正能掌控的是帮助员工成⻓，并且让员工切实感受到自己的成⻓。

关键是给他合适的机会、合适的指导、合适的激励。让更优秀、更进取的人成为表率，激励大家一起成⻓。

2.团队协作机制

协作机制的目标是建立良好的团队结构，避免出现太明显的短板。有踏踏实实、勤勤恳恳做日常工作的同学，也要有能攻城拔寨的攻坚手，还要有能够沟通协调的接口人。

根据业务不同，在一定时期内，对应方向的负责人和研发小组就能够专注地解决特定领域的问题，明确自己的研究方向和目标，相应的在技术上的进展，也能很快反应在业务中形成好的效果，得到正向的激励。

3.平台机会

有这样极具挑战的平台机会，不一定能历练出有战斗力的团队，但有战斗力的团队一定需要这样的平台机会进行打磨和历练。

17｜技术升级落地需要天时、地利、人和

天时：顺应团队整体发展需要

在提出技术升级之前，首先要想清楚它的必要性和紧迫性。

1.为什么要技术升级？2.为什么要现在做这个升级？3.技术升级对业务有什么影响？

尝试向一个非技术部门的同事解释，能听得懂并且基本同意你的观点。

换成用户体验或者业务指标等更通俗直接的表述，更容易得到非技术部门的支持。

地利：根据资源与现状规划升级范围

首先，要对项目的范围进行取舍，哪些做，哪些不做。明确边界。

其次，对于项目要坚持的技术标准和目标，防止项目执行过程中升级范围不断扩大，要求不断提高。

在实施上要做到规划先行，把大的项目分割成更为可控的“里程碑“，每个里程碑要有明确的可交付目标。在组件架构明确，功能协议完整，可以生产环境部署和测试。

人和：制定合理的规范

项目的顺利完成，最终要依靠团队成员的努力及合作，因此技术负责人要为团队成员制定出合理的规范。

项目初期预留了足够的时间引入业界留下的 Java 编程规范以及配套的生态，包括规范培训和认证，codeReview等。设定合适的标准并切实跟踪一线员工的反馈对技改项目的成功非常关键。

在团队还没有培养起来高度的信任和配合的情况下，这种有复杂依赖的任务最好明确单一的 Owner 来界定责任和权威。

18｜技术管理者如何发掘写代码之外的能力

抵制自己写代码的冲动

Deadline 到期大多是因为前期没有把控好节奏，到了临近交付的时间点发现有问题可能已经晚了，这个时候我们可以重新和业务方 Review 需求范围，看能否在有限的时间内，能够达成一些基本要求的情况下，对需求做一些简化，同时需要基于目前团队碰到的问题重新设计技术方案并协调资源。改善流程机制等等，而冲到前面写代码是所有事情中优先级最低的。

当你深入参与一些技术管理工作，比如技术方案评审、代码审核、事故复盘，并且在一些关键的技术决策上深入思考业务价值与实现成本之间的平衡

写一些特定的代码

提升效率的工具，为团队做一些基础架构相关的开发工作。

参与产品设计，产研融合

从下游到上游，这么做背后的目的是什么？解决了什么业务场景的问题？

技术类项目。从业务的角度、产品的链路、技术调优等角度切入，开拓自己的视野，转变技术思路。

技术规划不要脱离业务

向上管理

你需要先了解你的 leader 的阶段目标是什么，他 / 她在考虑的问题有哪些

19｜坚持技术or转做管理，我们该如何选择？

作为一名技术管理者，你需要有技术敏感度和前瞻性，能够融入团队，顺畅地沟通，保持清醒的头脑，不被忽悠，能够在关键时刻选择合适的技术方案、做出合理的技术决策，保证方向正确。此外，还需要有领导力和管理能力，能够激发团队成员的活力，达成公司 / 部门的目标，且能够让团队持续成长、进步。

20｜成为技术管理者之后，我们应该做出哪些转变

持续学习

我们需要通过持续学习，了解技术发展的方向和应用场景，唯有如此才能保持自身的技术生命力，处理各种事情也会得心应手。底层原理可以让技术永不过时。

转变思维方式

要从做事思维转换为管事思维。

首先要明确的就是团队的作用，作为管理者，需要不断重复团队愿景，并有坚定必胜的信念。

用科学的方法和工具管理团队，

管理与领导

管理对简单的事情行之有效，因为它强调控制和权威。而领导强调的是愿景，激发团队活力。

认可管理的价值

管理是公司组织最核心的事情，可以为公司降本、增效、提质，还可以预防风险。

转变工作方式

由原来重点关注技术到业务与技术结合，由原本重点关注自身到提升整个团队。

1和管理层沟通，尽量使用 ROI 投资回报率来表达，不讲技术时髦语言，不讲技术酷炫在哪里。

2和业务方沟通，说明可以解决哪些实际的业务问题（应用场景），岗位人员工作效率提升比例，客户满意度提升的比例，大屏展示的效果等。

3.如果讲技术，重点讲有效性（效果）、实现落地的成本，兼顾一下安全性和将来的扩展性。

团队的激励和绩效考核

考核是为了激励团队成员的积极性，考核不是目的，激励才是目的。没有激励也不要做考核。

1.小的即时激励是最有效、最需要做的，性价比很高。

2.在没有条件激励的情况下，不让团队成员受委屈，也就是减少反向激励。

3.技术研发领域，绩效考核的量化难度大，应减少团队激励之间的差异。

4.如果工作强度大，交付压力大，我们就需要申请额外的激励。

5.核心骨干成员，需要精神激励（信任）和物质激励双管齐下。

6.不恰当的绩效考核和激励将产生极坏甚至灾难性的后果。

7绩效考核一定要关注客户的反馈，在技术岗位，通常是指产品经理等需求方。有条件也要关注同事的评价，也就是当前比较流行的 360 度考评。

管理者的角色定位

管理者的下限：岗位思维

这里的岗位包括团队成员，也包括管理者自己，必须确保岗位及能力的匹配度，如果有问题必须及时纠偏，

管理者的中限：补位思维

首先是团队内的补位，在团队不完整的时候，这时候补位是不得不做的，因为“管理者的绩效是团队的绩效”，

管理者的上限：边界思维及组织上限

补位如果处理不好，就会引发误会，更极端的表现就是内斗，边界思维可以防止事情走向极端。

总结：

转变思维方式，转变工作方式，同时认清自己的角色定位。

管理者重要的不是自己能做多少事情，而是需要为团队的绩效负责、为团队的成长负责、为团队的结果负责，并通过多种激励方式来激发团队成员的积极性，提升团队整体的工作能力和效率。

21｜高效管理，让工作事半功倍

成员分类与管理办法

招聘和新员工阶段投入的时间足够多，新团队组建阶段几乎占了 100%，而一旦成熟后，花费的时间大概 30%。

1.管理好新员工

这个是管理工作的头等大事，一方面尽量提升新员工的满意度，激发新员工的潜力，入职做准备：高调介绍新员工给所有人，指定一名靠谱导师，一起吃饭拉近彼此的距离。紧接着，明确试用期目标：为其制定详细的目标任务分解，细化到第一周、第一个月、第一个季度试用期阶段需要达成的目标，并且定期检查和反馈，留与不留一定要在试用期结束前做出决定。