阿里技术Leader是如何带兵打仗的？

送福利啦

关注 鸿蒙技术社区 ，回复 【鸿蒙】 送 价值 399元 的 鸿蒙智能小车 开发套件 （数量有限，先到先得） ，还可以 免费下载 鸿蒙 入门资料 ！

👇 扫码 立刻关注 👇

专注开源技术，共建鸿蒙生态

“

作为一个技术 TL（Team Leader），除了自身技能，还会面临诸多团队管理上的困难和挑战。

图片来自 Pexels

如何定义和明确团队的目标？怎样建立优秀的工程文化？让团队长期发挥战斗力和创新能力的核心是什么？

本文作者基于四年的团队管理经验，分享他在招聘、目标管理、团队沟通和工程文化等方面的思考与总结。

介绍相关的经验方法，并推荐几本关于体验、思考的书籍，希望对同学们有所启发。

曾子曰：吾日三省吾身，反思是人类进化出来的一项异常宝贵的能力。

我在阿里带团队也有四年多的时间，有必要总结一下此间得失；另外，前几天和一个刚开始带团队的同学聊天，他觉得角色转变对于他有不小的挑战，因此我想做一点不算成熟的总结并分享出来。

当然，此文第一不代表我必然是一个多么成熟的管理者；第二不代表我的总结放之四海而皆准（事实上很多人的管理方式和我推崇的方法是反的，但是如果从某些角度评价，这些人更成功）；第三我并无雄心壮志解答所有问题。

总结仅仅是期望通过反思，帮助自己成为更好的管理者，而分享是希望能够多多少少帮助到其他的管理者。

本文会重点讲述我对招聘、目标管理、团队沟通和工程文化的理解。挑选这几个主题讲述，主要是因为在带团队的这一段时间内，我认为这几个要素是团队长期发挥战斗力和创新能力的核心。

得到这个认识对我来说并不容易，市面上有纷繁复杂的书籍（机场书店尤其多）尝试告诉你什么叫领导力，公司也有相关的培训介绍，周围也有很多 TL 用每日的言行告诉你他们是怎么做的。

但是我认为这些来自周围的知识，很多是无效的，有更多是错误的。

例如有 TL 每天在办公室坐到半夜下班，给团队巨大的加班压力，表面看起来是奋斗，实际上会让大家趋向于更多关注工作时长，从而降低对了对工作价值的思考。

又有一些例子是，当团队同学犯错后，把故障和绩效强关联，在我看来这不仅无助于大家深入思考系统健壮性，更是鼓励推责，扼杀创新。

更常见的例子可能是 TL 积极向上汇报，承诺超出团队负责的交付能力，导致团队完全无视工程师文化，久而久之优秀的人才逐渐流失，团队整体研发能力实则越来越弱。

很多事情是知易行难的，技术 TL 实践更是这样，之后不断学习，执行，反思，才能慢慢做得更好。

如果我团队的同学在离开这个团队五年或者十年后，回想起这段时间，会感慨：“我们当时的团队多好啊，大家一起做了很多有意思的事情。” 那我这个技术 TL 的工作，就算做的出色了。

招聘的第一原则是宁缺毋滥。

这么说出来大家都会认同，但是实际执行往往会因为短期压力而变形，尤其是招聘越来越难，好不容易面到一个看起来差不多的同学，难免会内心有点小倾斜，算了，先招进来了。

这其实是非常危险的，因为一旦招聘了错误的人，对于 TL 需要耗费的管理时间会成倍增加，这些时间本来可以用来做更重要的时间。

更危险的是，错误的人可能会对团队整体产生负面的影响，例如需要其他人不断地补位，或者和人不断争吵，消耗大家的精力。

因此招聘一定是要严格要求的，如何面试我就不详细讲了，通常我会关注以下一些方面，基本上是缺一不可：

• Coding 能力

• 对技术的热情

• 能简明扼要地沟通
  

• 积极乐观
  

• 对团队目标的认同

招聘是个长期的事情，如果仅仅是在有名额的窗口去找人，通常是非常困难的。

遇到合适的人，我会长期和他保持沟通，了解对方工作的状态，这其实也是一个不断建立信任的关系。当机会合适的时候，对方肯定会优先考虑你。

当候选人选择机会的时候，团队的 TL 是个怎样的人肯定是他重点考虑的因素之一。

因此 TL 一定要做技术发声，不论是开源项目的参与，撰写技术文章，还是在技术大会做演讲，都是充分体现 TL 个人技术能力，技术思考，以及个人特质的重要机会。

近期比较流行谈 OKR（Objectives and Key Results，目标与关键成果法），我认为这就是一种协同团队聚焦目标的方法。

定方向 O（Objective），定数字目标 KR（Key Result），就是期望团队能够凝聚在一起，朝共同的方向努力，相互理解和支持。量化的指标（KR）用来指导方向，暴露问题。

我比较反对用 KR 或者其他量化指标来简单粗暴地考核工程师，数字指标如果用来考核，很容易导致大家舍本逐末。

例如有人 KR 完成了 200%，却挖了一堆坑；而有人 KR 完成 50%，但的确解决了棘手问题，代码扎扎实实。我必然会把好的绩效给后者，差的绩效给前者。

定义团队目标实际上是个非常困难的事情，因为这个目标的定义要求你回答：

• 是否和你的用户/客户做了充分沟通，是否理解他们真正需要什么，你能给他们解决什么问题，他们的工作因为有了你团队会发生怎样的改变。

• 和上下游协作方能够做好协同，要兑现你给客户承诺的价值，你会依赖于谁做什么事情？需要谁和你一起参与？这些依赖和协作方，是否认同你的目标？

• 你定义的目标和价值，和你自己的的 TL 的目标，或者自己部门的目标，是否是一致的？

• 在技术团队，你的目标定义中有没有考虑技术竞争力？持续建设技术竞争力不仅能帮助团队长期发展得更好，也能帮助吸引更多优秀的人才。

当然，如果这个目标有那么点理想主义，那就更好了。工程师骨子都有那么点容易被理想主义吸引。

有了清晰的团队目标后，就是要和团队不断的沟通了，让每个人都清晰地理解目标，不要怕重复，不要怕啰嗦。

下一步是把团队目标分解为每个人的目标，这件事本质上是产品架构或者技术架构。

为什么这么说呢？在做软件设计的时候，我们都会说高内聚，低耦合；会说面向契约设计。