易观CTO，TGO 鲲鹏会北京分会会长郭炜做客极客live，分享了他的管理经验—— 做技术管理的造钟师，而不要做报时人。
人物名片
郭炜先生，易观CTO，全球中小企业创业联合会副会长，TGO 北京分会会长，中国软件行业协会智能应用服务分会副主任委员。郭炜先生毕业于北京大学，加入易观就任CTO 之前，曾任联想研究院大数据总监，万达电商数据部总经理，并曾在中金、IBM、Teradata 公司担任大数据方向重要岗位，提出IOTA 大数据架构、“数据河”等理念，对大数据前沿领域研究做出过卓越贡献。
1. 报时人 VS 造钟师
1.1 指挥别人的报时人
在国外，一到12 点你就会听到有人在教堂里敲钟；古时候在国内，会有人在晚上打更。这种人就是报时人，时间是由他“定义”的，别人都遵照他报的时间来做事。有些初级管理者采用的就是这种报时人的管理方式，他作为团队的拥有者、掌控者，指挥大家应该怎么做事。但是，如果团队超过30 人，你就会发现这种模式行不通了。因为所有人全向一个人汇报，全听这一个人报时，使这个人非常累，根本忙不过来。
1.2 让别人自驱动的造钟师
造钟师就是做出钟表让大家看的人，大家需要看时间的时候，抬头一看钟表就知道了。我们做管理的时候，可以通过这种体制和体系，让技术团队能够自己运作起来，而不是通过别人来“报时”。这样，才能有好的团队，才能在不断扩展的时候保持自动运行。
2. 技术管理核心能力模型
在我看来，技术管理的岗位技术能力主要有五个纬度：
1. 领导力，就是把事做成的能力；
2. 文化构造能力，是指影响意识的能力；
3. 人员的管理能力，是“人×100”的能力；
4. 体系搭建能力，即“建巢、管事”的能力；
5. 技术实力。
2.1 领导力，把事情做成
领导力对管理者来讲非常重要，它决定了能不能把事情做成。比如烧水，领导力就是99 度和100 度之间那一度的差别，99 度烧不开水，差的就是那一度。同样，做产品的时候，光研发出来是不够的，得让市场上真的有最终用户、C 端用户在用，用户数要呈线性指数往上涨。大家可能会发现，技术VP 和CTO 之间在决策能力上有明显的差别，其实现实当中，真正需要决策的不是两好选其优，而是两害取其轻，除了要快速决策，还要做好背负骂名的准备，这就是技术管理者的担当。
2.2 文化构造能力，影响团队意识
我们通过流程体系，能管理员工在看得见的地方是怎么工作的。那么看不见的地方呢，就得靠文化了。作为管理者，得具备文化构造能力，营造文化氛围去影响员工的意识。我认为一个团队，首先要构建一个MTP（即Massive Transformative Purpose），也就是一个宏大的目标，它像一颗北极星指明我们究竟走向哪里。以我们易观为例，技术团队的MTP 是未来科技开箱即用，让我们的最终用户可以很轻松地使用非常先进的科技技术。我们还要对结果负责，除了开箱就能用，还得用的爽。这些，就形成了我们自己的文化。有了共同的文化认知，才能让程序员真的从最终用户体验出发，以创造性思维为用户带来更好的体验。
2.3 人员管理能力，人×100
我把人员管理能力叫做“人×100”的能力。如果一个人把一件事做好，是×1。后来做了总监，带着一个团队在做，就变成了×10。再后来做了CTO，管理10 个总监一起带团队，就变成了10×10，也就是100。我认为，CTO的目标不是做成×1 和×10，而是找十个能×10 的人，做成100。而CTO 在很多时候，其实主要工作就是招人，找志同道合的人，大家为了一个共同目标一起做事，让大家充分发挥自己的能力，使整体可以更好地运作起来，做到×100。
2.4 体系搭建能力，“建巢、管事”
我认为靠人去管人是不可行的，因为人永远是变化的，不能因为某个人不在了，整个团队停摆了。所以要建一个体系，让它能够很顺畅地和产品、运营、最终用户产生互动和反馈，整个团队可以很快地运作起来，使大家可以自下向上地自驱动做事，而不是依赖别人去驱动。所以，技术管理者得具备体系搭建能力，我把它叫做“建巢、管事”的能力。
2.5 技术过硬，一专多能
我在这里强调技术，并不是说技术很牛了就可以做管理，而是说技术实力很重要。每个人可能有不同的技术专长，对于技术管理人员来讲，除了要有一技之长，也应广泛地涉猎其他技术领域。因为做技术管理，不仅仅要判断自己熟悉的技术，还要判断原来不太熟悉的技术，所以势必要让你的技术实力更加均衡。
3. 人+ 文化+ 机制= 卓越团队
我觉得所谓管理简单来讲就是建立一种环境，让员工团结到一起，全心全意地自主发挥他们的技术能力、创新能力。身为管理者，要找到那些志趣相投的人，推动我们心中的理想，把它变成现实。做管理，其实就是管理人+ 文化+ 机制。
3.1 招到牛人、用好牛人
团队中最重要的就是人了，所以管理的第一要务就是找人，招聘。大家都知道，优秀的人一定是和牛人在一起的，怂人一定和怂人在一起，团队如果都是怂人，就成了乌合之众，所以一定要严把招聘关，找牛人。什么是牛人，第一是要和公司有同样的价值观，这是最重要的，志不同不相为谋；第二是潜力，就是这个人现在的会什么不重要，重要的是他是不是在学习，是不是能学习，能不能激发他的潜力不停的向上成长；第三重要的才是能力，就是他现在会什么。
3.2 管好人，靠文化
我觉得要想管好人，还得靠文化。我把易观的技术文化戏称为花果山文化。每人都有不同的脾气、喜好，有的人脾气特别不好，见谁怼谁，但只要他不做人身攻击，发脾气是为了追求把事情做好，那么就可以容忍他；有的人就是秉承不加班的原则，在上班时间力求把事做好，然后按点下班，那只要他的价值观与公司一致，又有能力把事情做好，就应该容忍他，因为按时把事做好就是我们的目标。但如果有人与公司文化不符，比如如果我发现有人搞心机，就会很快请他离开。
文化的建设，就是要让大家具有包容心，找到既有特色又志同道合的人，彼此协作。大家团结到一起，像在花果山一样，自由发挥自己的能力。
3.3 以机制保持团队运作
究竟是考核KPI 机制，还是用OKR？究竟是激励大家自己的自主能动性，还是具体管理每一个员工怎么去做？这些是不同的管理思路。你把体系建成什么样，往往最终团队就是什么样。我们做技术管理应建立一种机制，把大家都变成明星，这样团队才有力量。
至于绩效考核，我个人不喜欢采用360 度评价，那样把每个人都变成了老好人。我喜欢以目标为导向（Object），制定出可衡量的目标（Key Result），比如TCO 减少30%、性能提高20%，这样大家都能很容易看到是不是完成了，既公平又透明。
4．最终我们要打造的产品是“人”
现在这个世界瞬息万变，市场会变化、环境会变化、融资会变化，所有伟大的产品、构思、服务，无论现在多么厉害，最终都会过时。什么东西不过时呢？团队不会过时，它包括人、文化、机制。所以，最终我们打造出来的不是最后的这个产品，而是这个团队，是团队里的人。有句话叫“地失人在，人地皆得；人失地在，人地皆失”，讲的就是人远比一城一地更加重要。如果做管理不重视每个团队成员的成长，不重视每一个人的主观能动性，只是一味的“填鸭”和布置任务。最后团队带废了，就会人地皆失。在整体目标确定的情况下，放手让大家去创新，勇于试错，让团队自己根据市场的导向快速迭代。最终整个团队得到了锻炼，我们得到的是可以自己运行和变革的组织，也就是可以自我驱动的“钟表”。所以，我们最终要打造的产品就是“人”，也就是我们领导的这个团队。
Q&A
Q 有种观点认为，程序员是吃青春饭的职业，30 岁还没走上管理岗基本上就没有前景了，你怎么看待这个问题？
A 我觉得它是职业规划问题。从短期来讲，一个人的职业规划是投资回报率的问题。从职业长期发展角度来看，得清楚自己要做什么。只有让自己的本心和世界产生真诚的互动，才能知道自己要做什么，把自己活成自己，才不辜负这一生。所以无论是做技术还是做管理，人到30 岁的时候，对世界要有个宏观的认知，再选择走哪条路，不一定非要转管理，每条路最终都可以走向成功。
Q 管理者应该有什么样的性格特质？什么样的性格才适合当管理呢？
A 我觉得做管理者，首先得喜欢和人打交道，而不是和机器打交道。无论和同级、上下级，还是你的团队打交道，都需要做人和人的沟通，得真诚的把一些意见反馈给相关的人，有创造性地解决大家的问题。
Q 有的技术人员不愿意转管理，认为会耽误技术，您怎么看？
A 这是对的，不一定每个人都要去做管理。有的时候公司会因为各种原因让技术专家去尝试做下管理，首先可以和公司沟通，解释技术好的人不一定做管理好，不如继续在技术上发展。另外也可以体验一下，如果觉得很有意思，就继续往这个方向发展，如果还是想继续做技术，也未尝不可。条条大路通罗马，让每个人做好他自己，这非常重要。
Q 如何做一个合格的Code review？
A Code review 简单分为Peer review 和Team leader review，国内一般做得比较成功的是Team leader review。Code review 一方面可以帮你看下代码有没有问题，另一方面，可以帮助你纠正团队错误的理解。我们每周五都有个分享会，Team leader 会把代码拿出来，将一些Code review 发现的典型问题分享给大家，让大家共同提高。
Q 属下都培养成项目经理了，怎么再向上提升，做整体的技术架构和技术文化？
A 一般的公司管理模式，有这么几种：一种是项目制，公司下面有四五个项目，这些项目的项目经理汇报给项目总监，项目总监在某种程度上是一个技术VP 的角色；第二种是职能型结构，团队按职能划分，项目团队都是临时搭建起来的，可能项目经理偏弱势；第三种是矩阵式，是以上两种的结合，项目经理由项目管理团队任命，负责这个项目的实施周期，或者这个产品的迭代周期。如果下面的人都培养成了项目经理，可以先考虑一下技术团队的组织结构，我喜欢把它变成一种矩阵式架构，一方面要培养一些人事经理或总监，另一方面，培养项目经理能够支持更多的项目。
