如何衡量自己是否是一位合格的技术领导者？
关于技术领导者的具体职责和能力要求，每个企业都会给出自己的定义。同样的职位，由于企业文化的区别以及具体的业务和发展阶段不同，相应的要求也会有所不同。但总体来说，有一些核心能力，是衡量一位技术领导者是否优秀的通用标准。
我们整理了几位大咖 CTO、技术总监的精彩观点，供大家参考。他们结合自己工作中的体会，总结出技术管理者需要具备的核心能力，也根据这些核心能力给出了如何提升团队效率、如何与技术团队沟通、如何与团队之间建立信任、如何建立技术团队能力模型的方法论，希望大家有所收获。
以 CTO 为例，说说这个职位的核心能力。CTO 首先是一个 O，O 本身代表着一个管理职位，其次还有 Owner 这层意思，他要很了解这家公司的业务，包括市场战略、用户战略、增长战略甚至必须参与这些战略的制定。
技术说到底是为业务服务的，除非技术就是业务本身，在绝大部分场合里技术是为业务服务的。在很多公司里技术真的就成了实现其他部门需求的工具，我觉得这样做 CTO 肯定是不合格的。首先它不能影响战略，需求提出方会经过很多转化，如果不是基于战略去推导，整个过程会失真。
第二个，我认为最最重要的是业务架构的能力，可能管理能力还次之。对于管理能力我认为最重要的是对团队的感知能力，因为一旦到了 CTO 这个级别，他已经脱离一线，很难再把一些细节还原。如果没有很细腻的感知能力，很多的决策会有偏差。
如果他不是一个业务架构师，不是一个能给团队指明更强方向的人，他最终会沦成一个需求翻译器，产品经理说怎么做就怎么做。他更多的只是负责保证产品的质量、开发的速度，最终被肢解成一个很琐碎的人。一旦团队上了一定的规模，团队就会从单纯的需求实现走向团队运营，而运营是需要方向的，业务架构就是一个基于运营和数据的一种综合的能力。
总结一下，我觉得最重要的就是战略，参与战略制定、战略实施和战略分解的能力。其次，就是这个业务架构的能力和对团队感知的能力、微观事物感知的能力。
管理的一个整体目标是：自我修炼内功，提升能力。我经常跟我的团队讲，能力提升最重要，但能力不能只是你一个人提升，要升华到整个团队的提升。
管理的一个最基本的原理是：提升能力，打造高绩效的团队。什么是团队？一群人只是简单地凑在一起叫团伙，而从团伙变成团队，需要增加使命和愿景。在这个过程中大家不断地建立信任，为共同的使命和愿景不断地奋斗，所以管理团队比聚拢一个团伙难。团队的成立说明大家都接受了这个目标。目标有了，怎么能变成高绩效？这里的高效是指一个高绩效的团队，而不是一个人、两个人的高效。
整个管理体系就是围绕着追求卓越、建立信任制度。管理要分层，包括对人、团队以及体系的管理。什么叫高绩效的团队？如果团队里的人都不想着追求卓越，而是觉得我随便做做就行了，这不叫高绩效团队。要做到团队里的每个人都有更高的追求，要达到卓越。
一个高绩效的团队，信任是必须的，互相之间都要建立信任。信任的建立是需要时间的，作为管理者要去建立这种信任的氛围，塑造追求卓越的文化。一件事情怎么就能称为“卓越”？这取决于你敢不敢去想，你看到一个产品，你有没有去思考想要做到比它好十倍，有没有去实践你的思考。
追求卓越、建立信任，这两个是相关联的，如果没有追求卓越，一帮人只是很信任，有可能做出来的就是一个很平庸的产品。如果整天想追求卓越，一帮人心都不齐，没有信任，也做不出好产品，这涉及到人和体系。
与许多技术人员“非技术不关心”的局限思维不同，陶真的工作经历都是同时负责产品和技术，因此，谈及技术人员的职业规划，陶真认为，技术人的规划应该有两个方面，除了要不断地自我提升，学习最新的、最前沿的技术能力，还要去对问题好奇，去了解自己的技术是被如何使用，可以解决哪些问题。
“当我们并不了解自己的技术是怎样解决问题的时候，就把技术和产品分离开甚至对立起来了。好比我们有一把锤子，我们不是一定要去找个钉子，而是要去了解，我们找到的是一个钉子还是一个螺钉，如果是螺钉，我们必须要有螺丝刀的能力。有些工程师太喜欢自己的解决方案、钟爱自己的技术了，以至于忘掉了要解决的问题是什么？客户的痛点是什么？当他有一个特别强有力的锤子的时候，他把什么东西都当钉子看，其实有时候我们需要的可能不是一个锤子，而是一个扳手。
很多时候我会提醒我们的产品和研发团队，要爱上问题，而不是爱上我们的解决方案。学会从客户痛点的角度出发，而不是从解决方案的角度出发。当了解了问题以后，我们可以用最契合的、最高新，甚至是最简单的技术，给客户做好一个解决方案。所以我觉得技术人不仅技术上要有不断的突破，了解我们解决的问题是什么也十分重要。只有这样，才能把最契合的技术，用最适合的方法去提供一个解决方案。这是我觉得在成长中最受益的一个自我训导。”
建立能力模型是技术团队快速解决问题、提高效率的好办法。在我看来，技术人员一般分两种，一种是喜欢思考业务能拥抱变化的，另一种是喜欢钻研技术希望少被打断的，要让合适的人做合适的事情。在我们内部，根据团队成员的特点，我们内部会尝试让有的团队做业务创新，负责从 0 到 1 的试错，而让其他对技术很感兴趣的人去做基础设施。
仅仅是在个人工作内容上进行简单的分工还不算建立了技术团队的能力模型，因为如何衡量团队的能力要复杂很多。我们内部是通过一些公开化和看板化的指标，来衡量整个技术团队的能力的。这些指标包括一些效率上的衡量，比如上线次数，lead time 等等；也有一些质量上的衡量，比如 MTTR，回滚次数等。
这件事情的难度有三个，一个是挑对指标。因为我们建立的模型和衡量的结果是对全公司公开的，大家就会去互相比较和比赛。如果挑选了错误的指标，就很容易让团队跑偏。比如衡量产出，有的公司会记录工作时长，有的公司会记录完成的 story points 等等，用这些指标来衡量团队的能力，就很容易造成错误的价值导向。
第二个难度是在全公司内做到统一。我们公司也是矩阵管理的形式。有职能这条纵向的线，比如前端后端测试等，也有横着的线里是定向支撑业务的技术团队。在我们公司，职能这条线是实线，这么做主要目的有两个：第一，站在公司角度负责任地评估他是不是在做合适的事。通过实线汇报的方式，避免研发被业务方指挥去做一些对公司没有价值的事；第二，事业部的老大往往评估技术团队的能力并不完备，对技术的最佳实践落地也缺乏动力。
第三个难度是如何做到代码化和自动化。这些指标一定不能通过人力来搜集。人力搜集，一个是数据容易不准，一个是对研发流程侵入性太强。