在阿里作了5年技术Leader，我总结出这些套路！

今天的文章，他将继续深刻探讨这一话题，从管理的角度分享技术 TL 的核心职责，主要分为以下几个方面与你们共同探讨、交流：

团队建设 团队管理 团队文化 沟通与辅导 招聘与解雇

互联网公司的技术团队管理一般分为两个方向：技术管理和团队管理，互联网公司的技术 TL 与传统软件公司的 PM 仍是有很大的区别。

传统软件公司的 PM 更多注重于对项目的管理，包括项目任务拆解、项目进度以及风险等。

对于多数互联网公司而言，技术 TL 更多的职责再也不局限于项目角度，而是对业务与技术都要有深刻的了解，就像黑夜里的灯塔，可以引导和修正团队成员前进的航向。

综合技术和业务角度去深度思考问题，具有必定的前瞻性，并在技术领域投入持续的学习热情，向团队成员传道，补齐短板，提升整个团队的战斗力。

技术 TL 职责不只须要制定平常规范，包括开发规范、流程规范等，推进规范的落地，以公有的强制约定来避免没必要要的内耗。

另一多半的时间可能花在了开发任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，剩余的时间则花在为了保障系统按时交付所需的各类计划、协做、沟通、管理上。

管理大师彼得·德鲁克说：“组织的目的，就是让平凡的人作出不平凡的事。”

然而，不是任何一群平凡的人汇集到一块儿，都能作出不平凡的事。甚至一群优秀的人汇集到一块儿，也可能只是一个平庸的组织。

大到一个国家，小到一个团队，任何一个卓越的组织，都必须有一个卓越的领导者。领导者是一个组织的灵魂，领导者在很大程度上决定了组织所能达到的高度。

阿里有句土话“平凡人、非凡事”，技术团队一样如此，管理者的战略眼光、管理方法、人格魅力等，都会给团队的工做结果带来决定性的影响。

其实每一个公司、每一个团队的背景不太同样，从管理学的角度探讨一些问题，没有统一标准的答案，本文中一些观点仅是我的观点，更可能是我我的成长为技术 TL 的一些观点理念。

同时我也是吸收了前辈们一些优秀的管理理念，包括我最为尊敬的通用电气 CEO 杰克·韦尔奇、苹果 CEO 乔布斯、Intel CEO 格鲁夫，国内我最推崇的技术管理者 Robbin（丁香园的技术副总裁）。 团队建设

从 2014 年开始带这块业务技术团队，至今有 5 个年头。回想起来，团队管理中全部能赶上的问题都遇到过了。

其中的磕磕绊绊数不胜数，彻底是在实践当中吸收教训，团队建设这块在这里和你们简单分享一下，固然这里面也有作得不够好的地方。

在阿里每一个人都能感觉到拥抱变化，基本上每一年组织架构都会调整，甚至有些团队每半年都会调整一次。

2014 年我也算是被分配到这个团队负责这块业务，这块业务是集团收购一家子公司的业务，整个团队文化和技术体系与阿里有很大的差别化。

通常来讲新官上任三把火，新的技术 TL 空降以后每每会大肆招人，快速推动改革，并且有些技术 TL 喜欢把原来的一些旧将搬进来。

当时我没有急于这么去作，没有招过一个新员工，而是立足于稳定现有的团队，主要基于如下缘由：

团队和业务了解不够深：对于目前团队的人员以及业务，我不够了解，不清楚这里面有哪些坑和陷阱，一旦初战不利，领导的信任度被透支，在公司恐怕难有立锥之地，更不用谈论改造团队，发挥本身的才能了。 流程与制度：针对团队现状存在的一些问题，我初步判断并非人的问题，不少问题是一些组织、流程、制度上的问题。 我认为只有好的制度才能造就好的团队，在没有解决现有团队的痼疾以前招聘新人，不但不会带来新的生产力，反而会形成团队的混乱，应该先打下一个好的根基，再招人，才能事半功倍。 团队安全感：不想让团队现有的成员感受一朝天子一朝臣，担忧本身在团队中会被边缘化，成为弃儿。另一方面可以让现有团队心理比较安全，能够安心地好好工做，不至于发生更多的动荡。 通过了几个月的摸底了解，大概清楚当时团队存在的一些问题和缘由：

业务配合不规范：产品、运营、研发部门之间配合没有创建合理的工做流程，好比对于产品需求的 PRD 评审没有标准，对于运营需求没有量化指标，你们都是疲于奔命作需求，致使你们的积极性不够高。 跨团队协做混乱：跨部门之间的工做配合毫无规范可言，部门之间相互推诿，随便什么业务人员都会随时给研发人员下命令，久而久之，伤害了研发团队的积极性。 针对以上问题，我主要把协做流程规范梳理了一番，制定了相对合理、规范的产品合做流程，同产品同窗约法三章，明确了 PRD 输出的标准和规范，运营的业务需求也统一由产品输出，杜绝一句话需求。

同产品、前端、UED、QA 团队的协做统一标准流程，下游对上游依赖方输出的工做必须有明确的标准规范，口头说的通通无效，拒绝合做。

针对跨团队协做乱的状况，我特别想说明一下，因为研发部门不是直接创造收入的业务部门，而是承担业务部门的服务者角色。

做为一个服务者，每每站在一个被动和弱势的位置上，很容易被业务人员举着收入的大棒指挥你无条件的服从。

业务部门人员随便指派任务，随意变动需求，团队同窗无所适从。这样一来，部门内部不管怎样合理的计划都会被外部的力量轻易打破，让团队同窗无所适从，致使你们的工做积极性不高，喜欢互相推卸责任。

长此以往，员工就产生了自我保护意识，凡工做尽可能日后退，凡责任尽可能往别处推，不求有功但求无过。

为打破员工养成的这种自我封闭的保护意识，鼓励员工更加积极主动作事情，我可以作的就是把这些责任都扛在本身身上，亲自去协调每项工做。

让团队成员没有后顾之忧，让团队同窗相信我能够搞定他们担忧的事情，出了任何问题我能够来背锅，给本身的团队创造一个相对宽松和自由的工做空间，保护团队不被外部的各类琐事伤害到。 团队管理

人每每会高估本身而低估别人，不少管理者都会以为手下交上来的工做作得不够完美，这里考虑不周那里作的啰嗦，但不少时候你只是看到了他人不擅长的地方，或者只是对方和你的出发点不一样给出了不一样的解决方案而已。

不少时候，咱们并不如本身想象的那么强。管理者在充分理解一些管理的理念以后，不断地在实际的管理工做中去实践并收集反馈和迭代，这样才可以造成本身的管理风格，并找到最适合当前团队的管理方法。

做为一个团队的管理者，一般会有两种风格管理策略，简要归纳为：

集权式的管理风格 放权式的管理风格 集权式管理：管理者的风格是偏细节的，定义清晰的工做目标，而且把工做目标分解得很是细致，让手下的团队能按照整个计划步步为营往前推动，这是一种风格，相对来说比较集权。

能够说我带这个团队的第一年是这种风格，我甚至会参加每一次需求评审，不管需求大小，会和研发同窗一块儿去写代码。

对研发团队我会作详细的 Code Review，亲自带领研发团队作技术交流和分享，参与技术讨论确认架构方案，这样以来和你们创建起了充分的信任。

放权式管理：定义大的目标，把握大的方向，作关键性的决策。可是并不深刻每一个细节去管控手下团队的执行细节，以结果为导向。

我到这个团队一年后，业务流程已经清晰的创建起来了，骨干员工在业务上可以彻底领会而且达到个人要求，这个时候放权能够充分调动团队的自主性和创造性，多数技术人员他们喜欢被领导，不喜欢被管理。

以上这两类管理风格没有对错之分，究竟哪一种方式更适合彻底取决于团队的情况。

其实这里我更想说一下关于放权式的管理风格，对于一个制度刚刚创建，流程尚未跑顺畅，团队残缺，骨干员工业务能力不及格的团队，采用放权式管理是错误的。

你必须事无巨细，从第一线的业务细节抓起，手把手的带员工，教会他们怎么正确的作事情，怎样达到你的要求，手把手的培养业务骨干，搭建团队核心架构。

这些年我看到过太多的案例，管理层本身从不真正深刻业务，也缺少对业务的深入理解，没有找到问题的本质缘由。

老是寄但愿于招人来解决问题，结果换了一茬又一茬人，问题永远解决不了，并且历来不深入反思本身是否亲自尝试解决业务问题。不少时候架构反映出来的问题，实际上是组织、流程的问题。

总之，做为管理层，若是本身没有深刻一线去发现问题，本身动手去解决问题的决心和勇气的话，那这个团队很难有新的突破和成功。

团队文化

在我刚参加工做的前几年，就听过一些关于团队文化和企业文化的一些概念，并无特别深入的印象。

尤为我读了《基业长青》这本书后，让我感觉到对于一个企业而言，决定短时间的是技巧，决定中期的是战略，决定长期的是文化。

企业文化对一家公司来讲真的很重要，一样团队文化对于一个团队来讲也很重要，我在带团队之初也曾经忽视了团队文化的冲击。

在带领这个团队之初，我私下找一些团队同窗作 1on1 沟通，我发现这里面的问题仍是比较严重的。

不少人为了不故障遭受惩罚，不敢去重构优化代码，把本身封闭到一个很小的圈子，也没有过多的追求和理想，之前也没有末位淘汰机制，你们以为能够继续吃大锅饭。

当时部门都是工做多年的老人，老的风气和习惯已经造成了很顽固的不良文化，工做情绪受到很大的影响。

老的不良的文化包括：

作事情没有积极性。 永远不认可本身的错误，永远找借口推卸责任，永远都是别人的问题。 不求有功但求无过；责任心差，对待工做自我要求低。 对工做安排喜欢讨价还价。 在一个很差的文化氛围下，优秀的员工会被排挤，团队没有向心力，也很难留住好的人才，员工流失率会很是高。

我认为衡量一个团队文化氛围是否有吸引力，有一个很重要的指标，是新员工的流失率：

若是一个团队氛围很是好，新员工入职之后每每可以快速融入进来，流失率很低。 若是团队氛围差，新员工入职之后比较茫然难以融入，每每会很快离职，流失率很是高，实际上留不住新员工远远比留不住老员工更可怕。 接下来我但愿给团队树立的文化是：

坦诚，公开，透明。 平等相处，消除等级感。 工做气氛轻松，团队关系和谐。 勇于担当，主动承担责任。 成就他人，乐于分享。 关于团队文化这个话题其实很泛，能够单独写一篇文章出来的。这里我主要基于团队文化以上几点，谈一下个人一些我的的见解。

坦诚的力量

首先，我以为坦诚不管对于一个 TL 仍是团队成员来讲，坦诚也是一种价值观，对于一个团队的发展来讲是很是重要的。

做为一个 TL，带领一支团队，我以为最重要的是 TL 本人必须作到坦诚的态度，只有对团队坦诚，才能和团队之间造成信任，只有和团队造成了信任，才能成为一支默契的团队。

通用电气 CEO 杰克·韦尔奇说过：什么是信任？当一个领导真诚、坦率、言出必行的时候，信任就出现了，事情就是这么简单。为何坦诚精神能行得通？很简单，由于坦诚有化繁为简的力量！ 坦诚的性格是管理者最基本的要求，只有管理者坦诚，才能得到团队的信任，做秀式的演讲和奖励并不可以真正得到团队的心，仍是须要在工做中脚踏实地一点一滴去作好最平凡普通的事情。

坦诚可以让你直面自身的缺陷，有针对性地改变本身，解决团队的问题，造就一个互相信任的团队氛围。

我见过一个比较典型的案例，平常工做中主管对于下属不够坦诚，下属与主管的平时一些工做沟通中，下属作的不够好的地方，主管不及时进行沟通与辅导，结果最后 KPI 考核被打了低绩效。

换位思考一下，这个被打低绩效的人是我，我也会不服气，有问题你为啥不提早告诉我，让我提早去改正。

对待下属要有勇气，勇于指出他们的问题，对于表现很差的员工要勇于批评和管理，例如为何解雇你。

这些谈话和冲突每每让人感到不舒服，我也认可每次谈低绩效是硬着头皮的，可是你必须有这样的勇气，坦诚不只仅要对那些表现良好的人，还要对那些表现糟糕的人。

苹果创始人乔布斯是一个对本身、对别人坦诚得可怕的人，坦诚的残酷，直面事情最真实的一面。

的确坦诚的态度在不少时候会让别人感受不舒服，乔布斯粗暴的坦诚态度也备受争议，但我以为，若是你是一个结果导向的人，仍是应该尽可能坚持坦诚的态度，不然最终的结果可能远远偏离你的目标。

容许你的下属 challenge 你

其次，我再聊一下关于平等相处，消除等级感，这点我以为最重要的是让你们感觉到你的亲和力，不是一个高高在上的领导。

好比不少时候团队一些技术方案的决策不是你一我的来决定，有时候仍是要善于倾听一下团队成员的意见，要容许团队成员 challenge 你。

其实，国内外要求下属服从的企业文化很广泛，这不必定是坏事，特别是公司若是有想法的人太多，想法又没法统一块儿来，公司的总体战略呈现精神分裂状态，那基本上就离死不远了。

因此管理层统一公司战略，一线员工强调使命必达。

国内的外企格外强调下属的服从性，把这一点做为员工的基本职业素养来培训，经常使用来说解的故事就是《把信送给加西亚》，强调上司安排一项工做之后，下属不容许谈任何条件，不容许 challenge 上司，必须无条件服从，克服一切困难也要完成工做任务，以解领导之忧。

这种执行力让上司感受很舒服，并且公司管理实施难度也比较低。

多数管理者都喜欢比较听话的下属，认为顺从的下属更好用。心态上高人一等，不会放低心态倾听下属的意见，即便本身错了也不会认可错误，一方面惧怕本身的权威被挑战，另外惧怕向下属认错，以为抹不开面子。

我不是圣人，做为 TL 曾经也犯过一些错误，我也曾私下里和个别同窗道过歉。放开心态，不须要过多的太在乎别人的见解，这些我以为都是无所谓的小事。

从我我的自身的一些经从来看，其实一味地要求下属服从是有害的，要适当容许你的下属 challenge 你。

若是一味地要求下属服从，不能进行任何反驳，长时间下来会致使团队的人缺少思考，只是一味的按照 TL 的想法去执行，当下属心里并不承认工做自己，仅仅出于职业性完成工做，成绩最可能是合格，很难达到卓越。

同时会致使下属缺少工做积极性主动性，容易养成下属逃避责任的习惯。

相反我以为做为 TL 必定要鼓励下属积极主动地思考，让下属可以本身设定成长目标，对工做拥有归属感和责任感。

尽可能给予下属更自由的空间，不要设置过多形式主义的约束；要容许下属去 challenge 你，参与你的决策，甚至质疑你的决策。

用这种方式增长下属对工做的归属感，工做责任心更强，更积极主动，可以自我驱动。

当你的决策错误的时候，下属能够帮你纠错，集体的智慧毕竟高于我的，俗话说“三个臭皮匠胜过诸葛亮”。 Owner 意识

“Owner 意识”主要体如今两个层面：

认真负责的态度。认真负责是工做的底线。 积极主动的精神。积极主动是“Owner 意识”更高一级的要求。 自私确实是人的天性，不是本身的东西，很难谈什么责任感，更不用说主动性了。

所以，团队管理就是要努力地培养你们的责任感，主人翁意识，想作到这一点，就须要加强团队成员的参与感，让他们知晓并理解所作事情的价值、前因后果，不断地强化使命感。

例如能够将系统、业务范围等根据团队成员的兴趣点、以往项目经历等多种因素划分给指定人负责，并明确赏罚机制。

要清晰地传达一种思想，那就是：这块东西就是你的，干好了评优、升职、加薪等都会优先考虑；干很差，出事情了，你要负责，我也会负责。

若是有一天你看到团队成员像呵护本身的孩子同样，去对待本身的工做，那么你的目的已经达到了，他已经彻底具有 Owner 意识了。

创建学习型的组织

最后一点我要谈的是创建学习型的组织，团队成员要尽量地分享本身的知识和想法，你们互相学习，也经过分享可以总结本身学习过程当中零散的知识点。

如何创建人才梯队的，其实就是要创建学习型组织，让你们积极参与学习与分享。

具体作法 KPI 里设置一项技术分享与团队贡献，团队内部轮流进行技术分享，一方面让你们去学习、研究一些前沿技术。

尤为是团队可能会用到的一些技术储备，若是他真的能把这个技术给你们讲明白的话，那他就是真的掌握了，同时也让其余人开始了解并学习这项技术，同时还可以锻炼其演讲与口才。

鼓励团队成员勇于去分享，乐于去分享，开放心态成就他人。把技术培训和分享坚持下去，造成这样一种学习型的文化之后，你就会发现整个研发团队的技术能力的提高速度是很是惊人的，而且不会再占用太多额外的时间。

当你再招一个资历较浅的新员工时，他也能在这种环境中快速提高，一般半年左右时间就能达到很是好的水平。

固然，一开始的团队可能没有这样的意识，就须要你做为管理者强行去推进，把要求列入 KPI，很认真地考核他，慢慢地，团队就会造成这样的氛围和文化。

固然创建这种学习型的组织，也能够创建一些读书分享会，把读的一些书籍感觉分享给你们，另一点团队的 Wiki 知识库必定要创建起来，让团队同窗把一些平常的技术方案、项目总结、故障总结经过文档的形式积累起来。

沟通与辅导

根据美国普林斯顿大学的调查报告，在全部对工做产生影响的因素中，沟通占的比例高达 75%。而咱们工做中出现的 80% 问题都是由沟通不当形成的，可见沟通的重要性。

多数时候，咱们只想着表达本身的观点，只关注本身想说什么，咱们会尽可能使用漂亮的 PPT、华美的语言、一堆的数据、甚至引章据典，而不关心别人听懂没有，没有思考别人是否想听，别人是否听得懂。

沟通在咱们的工做中无处不在，你会发现尤为在技术这个圈子里，可以进行高效沟通的人占比会更少一些。

沟通按照沟通对象类型一般分为向下沟通(同下属沟通)、横向沟通(跨团队沟通)、向上沟通(同老板沟通)，接下来只讨论如何同下属进行沟通，最为有效沟通方式：一对一沟通。

一对一沟通，又被称做一对一会议、One-on-one 等，是互联网公司经常使用的沟通方式。

一对一沟通虽然被普遍使用，可是涉及的文章却不多，这里我给你们推荐《格鲁夫给经理人的第一课》、《创业维艰 : 如何完成比难更难的事》，这两本书有更多关于一对一沟通的介绍。

格鲁夫是 Intel 公司的总裁，成功带领 Intel 公司完成了从半导体存储器到微处理器的转型，也是我很是欣赏的一位 CEO。

《创业维艰》的做者本·霍洛维茨是硅谷的顶级 VC，投资了 Facebook、Twitter 等公司。

在《格鲁夫给经理人的第一课》一书中，格鲁夫对「一对一沟通」的介绍以下：

在英特尔，一对一会议一般是由经理人召集他的部属召开的，这也是维系双方从属关系最主要的方法。一对一会议主要的目的在于互通讯息以及彼此学习。通过对特定事项的讨论，上司能够将其技能以及经验传授给下属，并同时建议他切入问题的方式；而下属也能对工做中碰到的问题进行汇报。

在我看来，技术研发同窗多数比较内向，不轻易向别人表达本身心里的一些想法。

一对一沟通的意义是能够使得信息从下而上地传递，同时能够把一些疑问、想法、意见、问题、规划等等和管理者作沟通，从而得到在其它渠道不易得到的信息，保证透明。

1on1 沟通聊什么

在《创业维艰：如何完成比难更难的事》这本书中专门拿出了一节提到了一对一沟通（1on1），具体聊那些内容给了一些建议。

做为 TL 我一般会与团队的人聊如下话题：

你有没有认为本身的价值和能力被低估了吗？为何？ 你以为在工做中能学到东西吗？你最近学到了什么？你还但愿在哪些领域进行学习？ 近期这段时间，对本身有哪些满意、不满意的地方？ 目前工做中，有哪些困惑？但愿我如何去帮助你？ 对团队和个人一些期待和建议。 在公司战略和目标方面，你最不清楚的是什么? 以上这些内容，除了在一对一沟通中交流以外，很难找到别的渠道来有效解决。

经过这些 1on1 的沟通，真的能够获得不少反馈信息，甚至获得的一些信息令我感到吃惊，原来还有这些细节问题我没有作好。

一对一沟通构造了一个渠道，这个渠道自下而上，使得以上这些内容都可以被倾听，从而被解决。

1on1 沟通的一些注意点

①找个私密的环境

找个空会议室或者别人听不到谈话的角落，不要在工位或嘈杂的环境中进行，由于私密的环境才能下降沟通中某些话被他人听到的心理压力，才能更轻松和真实的表达本身。

②最好提早告知 1on1 的团队成员

通常须要提早 1 周把 1on1 沟通的话题、具体时间通知到团队成员，这样的好处是团队成员能够提早准备下聊的内容，由于临时性的沟通很容易出现由于人类记忆力的问题，致使一些想聊的问题在当时没想到。

③按期进行

在《创业维艰》一书中，本·霍洛维茨认为一对一沟通须要保证至少一个月一次。而格鲁夫认为，须要根据部属对工做的熟悉度，而进行不一样程度的掌控。

另外，格鲁夫还认为，事情变化的速度也是影响一对一沟通频率的因素。做为技术研发部门，我一般会 1-2 月进行一次 1on1 沟通。

④用心倾听并行动

沟通要有效，用心倾听、保持真诚是必要的前提，不然员工不可能将心中的问题提出来。

保持真诚须要不敷衍任何团队同窗提出的问题，无论这个问题有多尖锐。若是你也不知道如何解决这个问题，不妨和团队同窗一块儿讨论讨论，看看你们能不能一块儿寻找可行的办法。

切忌不要讲空话和套话，一旦团队同窗发现这是一个无效的沟通渠道以后，「自下而上」的通道就被关闭了。

⑤适当引导

并非每个员工都懂得一对一沟通的重要性，也不是每个员工都能主动倾述问题，寻求帮助。不少程序员的性格都是比较内向的，有一些甚至不善于表达本身。

因此，虽然员工是一对一沟通的「主角」，可是上司也是须要进行适当的引导。

对于上司已经发现的员工工做中的困难，能够适当的主动提出来，以便于更好地讨论，这也会让员工感到很体贴。 招聘与解雇

对于一个团队来讲，人才是最核心、关键的。招聘和解雇尤为对于一个新上任的技术 TL，都是一个很大的挑战，接下来咱们重点讨论这两个话题。

招聘

招聘不少时候取决于公司在什么发展时期，须要招聘什么样的人。在初创时期，本不太可能招聘到清一色的专家人才，这个时候活下来比啥都重要，态度和味道是重点看的。

在高速发展以后，可能须要引进能带来新思路的一些人才，这取决于业务、技术、组织三者的对齐。那么这个时候，就是既要高技能，又要好的作事态度、习惯。

在搭建技术团队招聘前，要先明确所搭团队的类型，通常来讲有三种不一样类型的技术团队，即：

项目驱动型 业务驱动型 技术驱动型 不一样类型的技术团队在招聘时也有很大的不一样，好比技术驱动型团队你可能须要一个在中间件、语言功底很是深厚、有大局观的人，业务驱动型的团队可能须要有业务 Sense，而且具有良好技术和业务架构能力的人。

在招聘这条路上，我也走过弯路，一开始我对候选人的背景、语言功底、架构能力以及运维、数据库方面比较关注，但愿能招到全栈的技术人才，后来发现我忽视了一个很重要的点沟通与协做能力、态度。

后来致使新人来到团队后，虽然技术牛 B，但喜欢闭门造车，不喜欢和别人沟通，团队协做能力不够好，总体产出和效率不高。

因此在招聘新人的过程当中，不可以只盯着候选人有什么经验，会什么框架等技术面，也须要着重考量他们的综合素质，一个领导力好的候选人，可以很是快速地融入团队，也可以很是快的学习一些知识。

招聘步骤：

根据搭建团队的目标，作好招聘计划。根据团队自身的定位，招聘合适的人才。 有几点须要 TL 特别关注的，做为 TL 要对候选人的成长负责，切忌因人设岗、因单独项目而招人。 好比前端团队招聘一些后端开发，工程团队招聘算法，这样以来可能会致使候选人进来后很难融入到团队，没有存在感，长时间下来会致使新人离职。 肯定招聘需求（定岗定责）：列出每一个岗位的职责、须要具有的技能及其余要求。招聘需求归根结底是须要什么样的人，与总体业务和组织发展匹配。 合理利用人才招聘渠道。从我自身的经从来看，人才招聘渠道多数经过互联网招聘渠道以及朋友推荐更可靠一些，对于高级别的人才能够采用猎头定向挖人。 人才筛选：做为技术面试官，对于人才的筛选也是很是重要关键的一个环节，要根据本身团队的目标来选取合适的人才，设定完成的时间期限，将面试的重点放在专业技能、管理能力、价值观（公司认同）等方面。

通常要求以下：

和岗位须要的专业技能高度匹配：专业技术技能面试过关，定岗定责。 沟通力强：理解公司的业务，知晓管理层，了解公司的发展方向。 责任心：凡事有交代，件件有着落，事事有回音。 靠谱并自带正能量：不抱怨，主动解决问题，懂得纪律的重要性，一言既出;驷马难追。 价值观认同：认同公司，有目标有理想、有激情有冲劲。 背景调查：很是有用的一个办法，能够大幅度下降选人风险，不用怕麻烦，这个工做的付出永远都是值得的。 另外，我想说的对于技术面试官须要有必定甄别人才的能力，同时有意识地提升这方面的能力。

我提供如下几点建议给技术面试官：

若是对候选人有些犹豫和纠结，请你放弃这个候选人，你最担忧的问题每每很大几率上会发生。 明确咱们招聘的候选人标准，好比后端 Java 研发：Java 基础和分布式领域知识技能考察是必须的，少问记忆性问题和太理论性问题，更多地从候选人的一些实践经历中，提取出对这个候选人的更有价值的判断。 一面很是重要，要保证客观、公平，后面的交叉和终面每每参考前面的评价反馈，咱们今天不只是为咱们的团队选拔人才，更是为公司选拔人才，仍是要高标准的要求。 从心理学角度讲，必需要交叉面试，并且交叉面试官给出的反馈每每是比较客观、中肯的，并且要以交叉面试官的评价为主。 面试官切忌拿本身擅长的东西去考察候选人，须要认真的看候选人的简历，从候选人的经历中去考察这我的的综合能力。 一个团队的健康发展，最重要的是核心技术人，因此招聘工做必须谨慎，一旦有人加入就等于同上了一艘船，其中的纠结、痛苦、欢喜都要一块儿面对。

招募一个不合适人员的成本不只仅是薪资那么简单。因此请必定要放过那些经验不错、资质不错可是很犹豫匹配度、落地融入堪忧的面试者，其结局大部分都是彼此痛苦。

做为技术 TL 最成功的是招到比你更优秀的人，你不须要担忧本身会不会被取代：

一是成就我的和成就团队，做为 TL 应该抱着如何成就团队的发展思路，不能让本身成为天花板，自己技术就不该该是你最擅长的事情！ 二是兼容并蓄，发展多样性。刘邦善用汉初三杰，单项能力不如韩信、张良。TL 不要以本身的长短来衡量招聘的人，而是看团队技能视图的缺口和发展项。 解雇

解雇员工一般更多的是针对触犯公司文化、原则红线，或者持续没法跟上公司节奏的员工进行的处理。

在阿里也有这么一句土话：“若是你没有开除或解雇过一位员工，算不上真正合格的管理者”，大多数技术管理者性格比较随和，不喜欢开除员工。

可是出现触犯红线的员工或者跟不上节奏的员工，尤为是不承认团队价值观的同窗，会把一些负面情绪、行为影响到团队其余同窗，所以须要杀伐决断，当机立断采用合适的方法让员工离开。

固然，若是只是能力跟不上的员工，你也能够推荐给其余公司适合的岗位，让和本身一块儿奋战过的兄弟有一个好归宿，也会让在职的员工感受温暖。

总体上“慈不掌兵”，在开人这件事情上，高级管理者不要过于犹豫，为了一两我的最后影响总体团队的士气反而得不偿失。

多数互联网公司对于技术人员都有相应的 KPI 考核，对于达不到预期的人员会进行淘汰。

解雇尤为对于新上任的技术主管仍是有必定挑战的，我相信人的本性仍是善良的，做为技术 TL 不想让团队成员面对这一难题，包括我本身在内。

一家公司在成长，组织确定要升级，人员的新老交替也是正常的。若是团队成员的表现达不到预期，不经过 KPI 考核机制告诉他，也许他不会意识到自身的一些问题，他永远不会成长起来，相对短时间这些经济回报而言，我的的成长更为关键重要。

在阿里有这么一句土话：“不经历 3.25 的人生，不是完美的阿里之旅”，当你处于发展的低谷时，经历一次末位考核结果也许可以让他完全清醒，认识到本身的不足，完全激发本身的潜能，可以触底反弹。

心理学上有个著名的邓宁-克鲁格效应，又称达克效应。大意是，人很容易对自我产生认知误差，最简单来讲，就是会过于高估本身。

上面的图片上反映出，大部分人其实都处于愚昧之巅。人可以成长为智者和大师要先从愚昧之巅，掉到绝望之谷，而后辛苦攀爬，积累知识和经验，成为智者和大师。

有担当的管理者的一个重要责任，就是把下属从愚昧之巅推向绝望之谷，至于可否爬上开悟之坡，看我的造化。

一个合格的技术 TL 必需要给团队成员塑造一个绝望山谷，同时还要让他看到一个开悟之坡，这样员工会不断突破自我。

做为一个有担当的管理者，咱们不该该是一个老好人的角色，也要有冷酷无情的一面。

阿里也有一句土话：“心要仁慈，刀要快”，当团队中出现一些达不到团队要求的人，管理者应该主动去拉他一把，若是屡次尝试，最终达不到预期，应该请他离开。

由于到了中途，再被残酷淘汰，不管对组织，仍是对我的，损失都更大。

每一位开发者眼中，都有本身理想中的技术管理者。你认为优秀的技术 TL 身上有哪些特质？欢迎在留言区讨论，与你们分享交流。