【CXO观点】阿里巴巴CTO鲁肃：CTO就是要给CEO扫清障碍和风险

一、阿里巴巴CTO鲁肃的经历

我的经历很简单，2004年之前一直在学校读书，读到30岁。2004年跟着一个师兄做外包项目，为淘宝网做一个重要的架构升级——把原来PHP/MySQL架构换成Jave EE架构。2005年2月份正式以实习生身份加入支付宝。

2005到2014年，我主要的岗位是支付宝架构师。2013年，蚂蚁的CTO要回美国，蚂蚁CEO彭蕾找我谈过话，我那时候对带这么大团队完全没有信心。我最没有信心的不是带技术团队，而是CTO另外一半的职责，作为公司经营管理的一部分，怎么跟CEO对话。

前任CTO会在公司管理会议上和业务吵得面红耳赤，我觉得我做不到。后来王坚博士约我去喝茶，他说没有关系，每个人都是不一样的，但是每个人都能用自己的方式解决问题。这给了我信心。

于是，2013年我开始带支付宝整个技术团队，经过一年的考察，在2014年公司任命我为蚂蚁CTO，2014年到2019年我一直在这个岗位。

2018年，公司发现技术确实会对某些业务起到更加关键作用，需要更强的技术背景同学进入业务。当时对技术有很强需求的是蚂蚁的国际业务，就让我做了两年蚂蚁国际业务的COO。2019年年底，转任阿里巴巴的CTO。又过了一段时间，菜鸟也需要一位CTO，就让我兼任菜鸟CTO。

二、商业与技术共同进化之旅@蚂蚁

2003 首推担保交易“支付宝”应运而生

2005 CTU上线，开创互联网支付实时风控

2007 金融型系统分布式“服务化”

2010 阿里小贷上线

2011 条码支付

2013 “余额宝”上线，支付最后一台小型机下线

2014 OceanBase首次支撑“双11”核心交易，峰值支付破3万笔/秒

2015 “三地五中心”异地多活，网商银行开业，蚂蚁金融云发布

2016 印度PayTM钱包上线，蚂蚁技术向海外开放

2017 “刷脸支付”上线

2018 蚂蚁BASIC金融科技全面开放：蚂蚁链、金融智能、安全风控、小程序、蜻蜓、金融PaaS、OceanBase

我挑了几个蚂蚁CTO工作的节点，非常好地印证了“商业和技术的共同进化”。最早期支付宝非常简单，就是要做一个互联网的第三方支付平台，技术只要能把业务需求实现就好了，项目最大特点就是快、轻量。

2005年，某个国际支付巨头要进入中国，很多同事很紧张，那时陆兆禧是支付宝的CEO。他说：这有什么可怕的，他们一个需求两个月才能实现，我们支付宝两天就能实现，他们肯定不是我们的对手。

到2007年，公司面临一个技术分叉点：互联网支付一定会成为行业非常主流的支付方式，我们已经能够看到业务的规模，但需要做一个判断——该用什么技术架构支撑。

支付宝最早对技术架构没有很强的要求，什么好用就用什么。我们既有非常互联网的架构，脱胎于淘宝网;也有非常金融的架构，2005年我们敲锣打鼓、披红挂彩买了一台小型机处理核心账务。

但在2007年我们必须做一个判断，未来我们更像一家银行，还是更像一家互联网公司？幸好后来没有走弯路，我们判断未来必须要用互联网架构去解决支付相关的问题。

于是决定把系统做一个面向未来的架构设计：分布式改造。整整一年时间，我们将核心交易、核心账务、核心会员、核心支付，全部分布式化。

但涉及到一些核心技术如何解决的问题，比如在这么大的分布式系统里，怎么解决核心事务的问题——这其实不容易。

2007年某个国际支付巨头也曾经想解这个问题，结果系统上线后宕机两周，CTO离职。在对这个问题的改造过程中，我们也胆战心惊，但最终还是把这块硬骨头啃下来了。

第二个关键节点是2011年，移动业务起来了，但移动场景下支付到底是个怎样的形态，需要做一个非常关键的判断。当用户拿着手机和商家支付时，到底用什么方式进行?

那时智能手机的格局并没有完全定形，一些手机还没有摄像头。当时公司部署了很多方案，有扫一扫的，当时叫悦享拍，拍一下就能完成支付;有叫“咻一咻”的，让手机发出声波，商家接收这个声音;还有靠蓝牙的。几轮下来之后，其实很多商家装了咻一咻的设备，很多商家用二维码，最后发现用户能接受的是扫码支付。

2013年，也是我担任蚂蚁CTO的第一年，发生了很多重要的事情。我们内部起了非常多的重要项目，编号从1号到9号。

2013年这一年，1号项目是网商银行；2号项目是余额宝上线，让支付宝业务实现真正破圈，真正做数字普惠金融；3号项目是花呗。当然还有456，我们酝酿了很多项目，有成功的，也有不那么成功的。

这个过程对整个技术架构造成了非常巨大的冲击，从原来互联网支付脱胎的技术架构，开始往数字金融这个方向走。在这个过程中，我反而觉得技术正好可以发力，帮助公司技术实现变革。那一年支付宝开始正式“去IOE”，最后一台小型机下线。

三、商业与技术共同进化之旅@阿里巴巴

1999

阿里巴巴成立，开启B2B业务

阿里巴巴的技术其实非常广，后半程的发展会以阿里云为主线。

2003

淘宝网上线，开启C2C业务

第一阶段非常清楚，就是技术支撑商业发展，从淘宝网上线开始。那时淘宝网为什么能够赢，除了它商业上有很多创新之外，“快”也是非常关键的因素。在这个过程中，CTO要能在业务快速增长时，提前在技术上做布局，让商业成长能够持续。2004年，我做淘宝架构升级外包业务的阶段其实是淘宝网非常关键的时期，Jave EE架构的形成对淘宝的增长奠定了非常好的基础。

2004

淘宝网全面转向Java开发，奠定高性能网站基础

2005

支付宝正式成为第三方支付平台

2006

淘宝网服务平台化

2007

阿里妈妈“直通车”上线开启互联网营销

2008

淘宝商城（天猫）上线，五彩石项目实现，淘宝商城与淘宝网全面打通

2009

阿里云成立、阿里团队在北京写下第一行代码

2009年有一个神来之笔——那个时间点阿里巴巴敢于判断云是未来，敢于为云写下第一行代码。阿里巴巴内部很多人都不看好云，但是为什么那时候能判断对呢？我觉得阿里巴巴有一句话说的非常好:“因为相信，所以看见”。就像电商业务也一样，很早阿里巴巴就判断电子商务一定是未来，先发先至，所以在很长的一段时间，坚定相信这个方向、持续地走，只要时机到来，就自然可以取得商业上的成果。技术其实也一样，阿里巴巴很早就做了一个判断：云计算一定是未来，后面所有发展都以这个为主线。

现在回头来看，后面每个关键节点都是和云相关的。比如阿里云2009年写下第一行代码后，内部找了一圈都找不到客户，这时候CEO就指定阿里小贷业务必须用阿里云，给阿里云一个场景去打磨，这才给了阿里云一线生机。2010年孙权是阿里小贷的负责人，后来当了阿里云的负责人。

2010

手机淘宝上线，阿里云正式对外公测

2011

阿里云开始大规模对外提供云计算服务

2013

阿里巴巴去“IOE”完成，阿里云成为首家对外提供5K云计算服务公司

2014

大数据计算平台MaxCompute上线

2015

启动“大中台，小前台”战略

2016

手机淘宝实现“千人千面”，城市大脑正式上发布

2017

达摩院正式成立，天猫精灵上市

2018

宣布芯片战略，成立平头哥，张北30万台服务器数据交付中心

2019

开启阿里云智能时代

2020

“全面上云”封顶，进入云原生时代，云钉一体

我自己印象比较深的是2013、2014年，经过几年和阿里小贷的打磨，阿里云开始有一点技术了，大数据处理开始慢慢成熟。当时有一个很重要的“5K项目”，阿里云开始具备5000台机器大集群处理数据的能力。具备这个能力之后，公司又做了一个重要决定，阿里巴巴和支付宝所有的数据全部要上到阿里云的大数据平台上，那时我正好是蚂蚁的CTO，我举双手支持——因为我知道即使不支持，集团也会按下来。阿里云也因此又上了一个台阶。

2015年，大家都听过“大中台、小前台”，听上去很牛。“大中台、小前台”背后完成了一件事情：把阿里巴巴和支付宝所有的基础技术全部统一到阿里云上，这是个重大的技术变革，为了完成这个技术变革，阿里巴巴做了非常好的组织设计，让当时的阿里巴巴CTO行癫兼任阿里云CTO，把技术收在一起，加强阿里云。“大中台、小前台”策略执行了三年，阿里云整个技术架构就非常完整了。阿里巴巴是集全公司之力支持一个技术战略的达成。

2017年之后，这个阶段用行癫的话讲，是“用技术创造新商业”，开始去探索技术本身能不能成为商业的一个部分。2017年达摩院成立，同样是“因为相信，所以看见”。因为我们判断未来一定是数字经济，围绕数字经济所需要的核心技术达摩院要进行布局，无论是AI、计算，还是芯片，都是围绕数字经济的核心问题的思考和布局。

2020年，我已经是阿里巴巴集团的CTO了，我们完成了上云的封顶，所有核心业务基本都跑在云上，包括最具挑战性的业务，比如搜索、推荐、广告业务，云都能支撑，我觉得这是云非常大的技术进步，也是集团非常重大的技术变革。

现在我们进入一个新的时代，要把云和业务技术的边界定义清楚，边界就是云原生。我们未来业务应用全是云原生的应用，这是一个云原生时代。另外，云本身也在升级，就是大家都知道的“云钉一体”。

四、不同业务阶段下的三种技术领导力

三种技术领导力，我是受到俞永福的启发，他觉得企业发展就是这样波浪式的发展过程：一开始要先找到一个方向，进入一个业务的轨道;如果这个方向判断准了，企业就会进入快速增长阶段；发展到一定阶段，就必须要脱离现有的惯性，再去找新的发展方向——就是这么一波波的过程……

在波浪式发展过程中，技术在每个阶段起的作用不一样。在入轨的阶段，CTO应该是整个公司业务一号位班子的成员，是支持一号位的二号位，班子一起看清方向，把业务带入正轨。

一旦入轨之后，业务进入快速增长期，CTO的核心不是看方向，而是怎么做好技术，这时首席架构师会变得非常重要，技术让业务更高速增长、加速成长，业务不要被技术拖慢增速。同时，组织设计在这个阶段和技术架构一样重要。然后不能等到业务停滞时才去判断未来，CTO要提前判断未来会发生什么，第二曲线是什么，设计一条未来的路线。

我是觉得整体上组织需要有两种领导力:一、专业的领导力：CTO、首席架构师、技术总监和VP；二、组织设计的管理领导力。CTO在不同时候戴着不同帽子，有时会承担一个专业角色，有的时候会承担一个管理的角色，有的时候会承担一个战略的角色。

很难说一个CTO是万能的，CTO一定有强项和短板。比如我自己，我的定位是一个工程师，工程能力是我相对比较强的一项能力，组织是我的弱项。在这个过程中，一个核心班子里需要非常好的配合，具备不同的领导力，给不同的人戴上不同的帽子。

五、CTO的职责

1.建立商业与技术的“共振”连接

CTO在一个公司中到底扮演什么角色和职责?

我觉得第一个非常基础的职责，是要建立起商业和技术连接。前面讲到商业和技术是共同进化的，而共同进化的过程中两者要发生很好的共振连接。为了实现社会价值、客户价值，企业要判断需要怎样的核心能力？这个判断不是一个纯粹技术判断，也不是纯业务判断，而是一个公司核心班子共同的判断。

这个过程中，CEO和CTO怎么对话就变得非常关键了，能不能说一样的语言？CTO要和CEO问清楚几个框架性的问题:一是我们公司服务谁，要把客户定义的非常清楚；二是我们为这些客户创造什么样的核心价值、差异化价值；三是我们的商业模式，用什么样的商业模式实现核心价值；四是为了实现这样的商业模式，我们需要什么样的能力、走过什么路径、构建什么样的组织。把这些问题理解清楚之后，技术就能理解业务要干什么了。

我在阿里巴巴接到任何一个新业务，都一定要对它进行新的理解，后续可能还会有多的问题、更深入的理解，但这是我做的第一件事情，这是CTO的职责。

2.一张图、一场仗、一颗心，愿景牵引前行

很多时候，牵引团队往前是非常有挑战的事情，小团队还可以靠关系。大团队里大部分人你都不能认识，怎么还能“一张图、一场仗、一颗心”?这时候就需要有领导力了。

我分享几个例子，比较有挑战，也有很多不一样的方法。

第一个例子，我在团队里建立领导力的方式，是跟团队一起定义非常清晰的目标。2013年经过一番犹豫之后，我决定接受负责蚂蚁整个技术团队的任命。当时我遇到的最大的挑战就是和团队之间的信任——本来大家都是平级，突然我要成为这个部门的总负责人。当时大家给我的反馈是，觉得鲁肃做技术可以，但不懂业务技术。

我觉得信任是要靠跟大家一起把事情做成，甚至没有必要让大家建立起对领导者的认同，就看大家能不能相信共同的目标，并把目标实现。2013年，我跟团队共识了“1234”目标:

1.公司从互联网平台向数字普惠金融平台转型，我们的技术架构怎么去支撑？需要重新定义支撑数字普惠金融新的平台。做平台架构这件事情，至少是我的本行，大家认同。

2.蚂蚁哪些核心技术是我们今年必须要突破的？当时定了两个核心点:一是OceanBase在这一年能落地；二是我们要把蚂蚁的平台建在云上。

3.我们能不能在这一年大促的时候实现3万笔/秒的支付？大家知道从2010年开始，每年会有一次大考：大促能扛多高的峰值。前两年，蚂蚁都是非常吃力的去扛。甚至2012年对团队来说是个很大的耻辱——大促前50分钟系统被冲垮了，50分钟后才恢复。2013年大家都想一雪前耻：2012年时峰值是每秒3000笔，已经是性能极限了。我们定一个10倍的目标实现3万笔/秒！

4.因为我们的服务不仅仅是支付，还开始提供金融服务，稳定性必须像银行一样，甚至比银行更稳定。我们定下可运行目标4个9(99.99%)，之前3个9都很吃力。

这四个目标，大家非常认同，虽然都很有挑战。年底的时候，经过大家的努力，四个目标里实现了三个半：完成了平台的转型，余额宝、花呗业务都起来了；OceanBase在蚂蚁系统里落地了；做到4个9；但我们没有做到3万笔/秒，只做到1.5万笔/秒，是5倍的提升。之后大家开始建立起对我的信任。

我到了阿里巴巴之后，第一件事情也是需要大家聚在一起，一起定下目标。空降到一个平台，其实很难给团队定一个全新的愿景。如果新CTO上来就先画一张未来的图，基本是不太靠谱的，还是要和团队一起定下非常扎实的目标、一起达成目标。于是，我选择先在云这个关键战略上稳中有进，全面上云必须全部完成。二是在云之上，如何从“上云”到“用云”，把云原生做深入，将阿里巴巴中台做深入，包括AI中台、数据中台和业务中台。另外一个目标是组织数字化，阿里巴巴虽然生于数字时代，但也需要做数字化升级和转型，阿里巴巴数字原生商业系统和数字原生组织是去年和团队一起确定的方向。

CTO和团队在一起要有一个面向未来的思考，不只是当下与业务的连接。未来是什么，关键的路径是什么，核心的几场仗是什么，这是CTO的牵引力。

3.关键决策，扫清前进中的障碍

CTO需要帮团队解决问题，扫清一些障碍，做出一些关键的决策。在蚂蚁做CTO时，第一个关键的决策是技术架构往金融方向还是互联网方向?最后决策是互联网。第二个关键决策是关于OceanBase的转型。

2010年，阳振坤老师带着团队开始打造OceanBase。最早OceanBase还不是一个真正的数据库，当时第一个场景是解决淘宝的收藏夹问题，需要海量数据但不需要很强的数据处理能力。但到了2012年，OceanBase面临一个发展决策，要不要成为一个真正的数据库。

蚂蚁团队对OceanBase的怀疑有合理的理由，我们现在的业务对数据库要求这么高，Oracle那么先进的数据库团队打造了几十年，才刚刚能满足我们的业务需求。阳老师带着几十个人花两年时间打造一个数据库，能把Oracle替代掉吗？

我觉得王坚博士是很有领导艺术的，当时他做了一个选择，他说:“把OceanBase送给支付宝吧。”到了蚂蚁这边就成了我当时定的“1234目标”中“2”的部分:看OceanBase能不能再往前发展。

当时我们采用了什么办法呢?第一先了解清楚OceanBase能干什么;第二，既然公司整体不能做，就搞一个小场景，在蚂蚁的核心交易里切了1%的流量给OceanBase，让它在1%流量里证明能力。OceanBase也很珍惜这个舞台，撑住了1%的流量，最终在这一年完成了从非关系型数据库向真正关系型数据库的转变。2014年我们再大胆往前迈一步，把“双11”大促10%的流量切给它，让它进核心账务系统——账务系统比核心交易系统要求更高。当时这个决策是有一些冒险的，但现在回头看，正是这些决策让OceanBase有了不一样的未来。

后面几个决策也类似，作为CTO如何拿捏好风险和稳定，是非常关键的。

比如余额宝上线的第一天我们就知道这个产品一定会成功，因为它的客户价值特别清晰，让用户每一块钱的余额都有收益。但我们没有料到，它成功得那么快，一个月时间迅速就把原来准备的系统容量全部用掉了。我们自己还好，因为蚂蚁的平台已经完全分布式化了，可以快速扩容。但我们的合作伙伴天弘基金，因为老系统无法支撑余额宝这么快速的增长，扩容成了核心难题。

于是我们做了一个非常重要的决定:把天弘的系统搬到云上，用分布式架构重写一遍，三个月内必须完成。这件事也证明了金融云的价值，金融云的业务也就起来了。

这些都说明，CTO要在关键决策中发挥作用，帮助团队下决心并把握好不确定性。

4.应对风险，化危为机

公司的技术风险有几类。

第一类，技术架构不能够支持业务发展，这是业务不能接受的风险。但这类的风险，相对显而易见。阿里巴巴为什么在2009年启动“去IOE”，就是判断到这个风险早晚会出现，“IOE”架构已经不能支持公司业务发展，必须去掉。蚂蚁在2010年开始启动“去IOE”，因为那一年“双11”大促让我们看到原来架构基本不能支持业务了。

2010年的“双11”大促被我们称为“人肉云计算”。大促开始，我们看到流量疯涨，判断白天肯定会冲破设计容量，就赶快把服务器库存全部加进去了，结果发现还是不行，又马上去“杀”服务，把不必要的服务全部关掉，把容量放在核心关键链路上，结果还不够，我们又去看关键服务里还有没有能“杀”的。那年“双11”最后几分钟，我们的核心账务数据库和会计数据库都到了极限，还有10秒钟就要挂掉了。最后关头，团队非常果断，把会计数据库杀掉了。会计记账本身很重要，但断个几分钟还能承受，核心账务不能挂，否则整个业务就全部中断了。就这样，2010年的“双11”大促是硬撑下来的。

其实后来很长一段时间，都是“人肉云计算”，人在做资源调配的事情，人来做决策判断。这太痛苦了，这一切逼着蚂蚁非常坚定地拥抱云的分布式架构，要上云。

第二类风险不是技术架构的问题，而是稳定性出现重大问题。CTO必须要判断出这个情况，CEO一定要给CTO相应的资源支持。

比如蚂蚁的“527”。2015年我们实现了整个支付宝系统的异地多活，华南机房和华东机房异地可以做分布式交易，这在金融系统里应该是第一次。我们还特地做了断网演练，直接把华东区域全部关掉，华南直接接管业务，结果非常成功，大家非常开心。我还给当时的CEO彭蕾发了一个战报，说蚂蚁首次实现了异地多活，你们可以放心睡觉了，以后任何情况下系统都会稳如磐石。

2015年5月27日，我开车在路上收到了报警，通常遇到这种情况团队就直接处理了，但那个报警就一直响。我就把车停在路边，才发现光纤被挖断了，系统中断将近2个小时。原来异地多活，光纤一断，系统就切不过去了。从那之后，我再也没有发过任何一份战报，没有和CEO报过任何一次喜。

当时这个事情对蚂蚁技术团队打击非常大，公司受到最大的打击是客户的信任。外面有很多文章调侃蚂蚁的技术，蚂蚁的技术形象和外部的信任丧失了。内部从我到整个团队与CEO的信任也开始出现了危机——以后再讲话，别人只听一半，因为说的话不见得靠谱。

危机也可以是好事情。“527”之后，我们做了几件非常关键的事情，第一，开始跟公司沟通，我们需要在蚂蚁成立一个专门的部门，叫技术风险部。这个部门就一个职责，守住蚂蚁技术底盘的风险，公司额外拨10%的技术资源给到这个团队。也就是说，我们愿意付出额外10%的技术资源专门确保蚂蚁系统未来没有风险，这件事情至少帮我们争取到这个资源。第二，立刻启动实战演练，前面说其实我们做过异地多活的断电演练，但这是有准备的演练。从那一天开始我们要做无准备演练，一直到今天。第三，我们确定把5月27日这一天作为蚂蚁的技术日，蚂蚁未来无论是存在102年还是更长的时间，所有技术工程师都要记住这一天，让我们永远能够记住风险。

这三件事情做完，反而让团队更加凝聚了，蚂蚁技术的风险防控水平有很大的提升，我觉得这是转危为机。

第三类风险，可能是CTO和CEO都最担心的，一个新技术出现之后会不会颠覆原有的业务模式。不仅是很多发展中的公司会担心，即便阿里巴巴这样规模的公司也非常担心。当一个新技术出现，无论公司大小，都有被完全颠覆的风险。蚂蚁面对移动互联网时代时，我们有一段时间很担心，通过好几年努力定义移动支付，基本上算是渡过这个危机，但当时对蚂蚁的挑战还是非常大的。当比特币开始成为一个现象时，我们也是非常担心的：它会不会把支付完全颠覆了？2019年6月Libra出现，更让人担心了:全球支付会不会被一种新的货币重新定义，这是一种降维打击。

这时候CTO必须要站到一号位班子里去，帮助CEO做判断。每一次对未来危机的判断，都可以触发未来新的商业机会。大的策略是:面对任何技术风险不能只是看，要亲自去试，需要公司投入一些有价值的浪费。

第四类风险，是温水煮青蛙。技术会不会反过来伤害公司，它不像风险那么直接，但是如果因为技术、架构或组织问题让公司效率变慢了，公司会慢慢丧失竞争力、创新力。随着时间的推移，这是最大的危机。阿里巴巴的中台就是一个很好的例子，中台的优点在于可以减少很多重复建设，让业务可以基于中台快速创新，因为重复建设的繁忙约等于效率低下。但阿里巴巴的中台已经非常完善了，开始进入了另外一个阶段。目前，业务中台里有面向核心电商的中台、数字供应链的中台、职能线业务中台、数据中台、AI中台等一系列技术中台。当我做一个新业务的时候，我需要跟这么多中台打交道，需要他们去支撑我，过程中如果有任何一个中台支持不能到位，我的业务可能就做不成。我们现在开始大力推动中台能力进一步升级，改善中台的交付方式，把中台再升级。这里涉及到很多技术架构的变化。为了防止温水煮青蛙就是要一直做系统化的梳理，再去一个阶段一个阶段的解决。

5.组织设计与治理——平衡秩序与创新

一个人当CTO的时间越长，专业能力下降得就越严重。我判断自己的专业能力大概每隔两年会降一级。也有好处，你可以跟团队一起做，团队会更强。组织设计的核心是要既有秩序又能创新。这是有矛盾的，创新是在一个混乱的土壤里长出来的，秩序让效率高，但会把很多创新吃掉。这个过程有点像踩钢丝，处理秩序和创新的平衡。

阿里巴巴围绕技术的组织，是有两条线的。一条线是实的管理线，是分层分布的:

前台，面向业务的，为客户赢;中台，是能力中心，中台的客户是前台，让前台更加高效，让前台更有竞争力；底层后台，是强调技术先进性的，确保业务永续。这个组织每一层都是独立的业务经营单元，现在我们在做一件事情，让每个独立的业务经营单元都有CTO。这个CTO会对这个业务经营单元负全责。实现管理机制的核心就是把每一层之间的界面定义清楚。

这种治理让每一块业务都很灵活，都可以自主发展，但又带来了一个新问题，我们该统一发展的技术怎么形成合力，所以我们有另一条虚线:技术委员会，下设二三十个核心的技术小组，把所有的共性领域横向拉通。通过技术委员会和技术小组的专业领导力，实现策略通、人才通。这两条线会同时运作，随着管理线越来越清晰的分层，这条专业的虚线就会变得非常重要。比如音视频技术，每个业务里都会用到音视频技术，中台也有音视频能力，底层需要优化以提升音视频技术的竞争力。前台、中台和底层跟音视频相关的技术专家组成一个技术小组，由一个专家带领。

这条虚线会转化成实线的管理决策，我们必须要打通这个链路，这个体系的运作会比较有挑战。作为CTO，我觉得要在过程中保持非常开放的心态，要信赖每个领域技术专家的判断。技术专家意见不一致时要有独立思考，做出自己独立判断，要知道创新和秩序的平衡点在哪里。

组织大到一定程度之后就会遇到这样的问题，我确实也不建议技术组织还不大时就把组织结构搞的太复杂，这会带来额外的管理和沟通成本。

6.凝心聚气、薪火相传

凝心聚气其实是最重要，也是最难的，这是一个技术文化的事情。每隔一段时间，我们都会聚在一起讨论阿里巴巴的技术文化。去年我们讨论了一轮，三年前我们也讨论过一轮。三年前定下阿里巴巴技术的slogan叫“技术创造新商业”，再之前的slogan是“技术拓展商业边界”。

除了slogan，阿里巴巴的技术文化底色是务实、有一说一，不要打花腔，不要做包装，事实是什么样就什么样，用事实说话。没有数据、没有事实的时候，就不要说话。如果大家都能践行这个文化的话，很多事情会变得特别简单，但其实践行文化并不容易。

我们有一些技术土话，比如“面向未来去思考”、“因为相信，所以看见”,是需要看准未来，敢于投入，真正做到先发先至。因为如果别人做、你再去做，永远是追赶者，会非常累，但看准未来、敢于投入，也不会轻松。

这些文化、愿景能不能在一个大的场景里形成共识，尤其这个组织每年都有人离开、有新同学进来，还能保证一致的文化，其实是非常有挑战的。但只有文化做好，很多事情才能顺理成章。

CTO可能不是思想家，但一定是行动派

前面是我思考的CTO的六个职责，虽然不完整，虽然不可能每件事情都做得非常好，但核心思考是，我是相信CTO或者说技术团队需要跟着公司业务发展不断进化。我从蚂蚁到阿里巴巴，差不多经历了前面六个阶段，我称之为CTO的六步曲:

1.跟团队先一起定义好目标，先一起做成一些事情。

2.多了解团队、了解业务，知道未来要去哪里，跟团队一起共创一个愿景，把大家热情点燃。

3.CTO的一个核心工作，是怎么能够让自己不要成为团队的天花板，而是把自己当成团队的地板，用人做事。如果CTO是公司技术天花板的话，那你把公司技术就压在一定的高度和范围内，公司技术永远是在一个小的、狭窄的领域。当CTO的技术能力是公司的地板时，公司可以通过新同学扩展边界。成为CTO还是用人做事为主，而不是做事用人为主。

4.一切都很好时，别忘了晴天去修屋顶，永远居安思危。一旦危机出现，乐观地看待，每个危机背后都有机会，转危为机。

5.过程中不只看当下，也要布局未来，为公司建立技术纵深。在业务发展早期，技术的纵深就是一个点。当发展到像阿里巴巴现在这个规模时，技术纵深就是一个多面体，必须有充分的、多面的布局，才能支撑一个大公司的发展。决定布局投入多少，要和CEO充分对焦。

6.最后一点，人才。薪火相传，人才才是公司未来发展的关键。我记得阿里云曾经有一位技术负责人分享说：什么是一家公司技术的最高境界，就是谁来当CTO都能当好，我觉得这是我要努力的一件事情。

如何发展与培养CTO

最重要的事情放在最后，就是人才。

前面讲到我们的分层分布治理，每个经营单元要有一个小CTO，这个CTO怎么培养？基本上我们让他在战场里去练，为他设计发展路径，也有“奇点营”这样的班专门培养业务小CTO。

当然最难的事情就是培养接班人，自己的接班人和团队的接班人，这件事情其实是我上任第一天就在想的事。但选准人、选好人，有非常多的挑战。

我有两个小经验:

1.CTO发展是“Z”字型的路线。

直线成为CTO的人，往往会因为路径太单一、没有足够磨炼而出问题。行癫负责过淘宝的业务，负责过B2B业务，再做阿里巴巴的CTO，再做阿里云的总裁。我做过蚂蚁的技术，做了两年蚂蚁国际业务，再做阿里巴巴的CTO。做过业务再回头看技术，跟CEO对话会有共同的框架，这一点很关键。

2.做“L”型职责设计。

CTO最怕做虚了，毕竟这是公司里非常高的位置，每件具体事情都有相应的核心骨干帮你负责，但你手不伸下去就很容易做虚，看不到下面的实际情况，会导致决策出错。

阿里巴巴怎么解决这个问题呢？就是给CTO一横一纵：横向管理的CTO，也给你一个纵向的业务技术一号岗位，保持与一线的对接。比如我现在既是阿里巴巴集团的CTO，又是菜鸟的CTO。行癫也曾经既是阿里巴巴的CTO，也是阿里云的CTO，也是一横一纵。

CTO应该具备怎样的特质？每个CTO都有不一样的风格，但有几点是共通的:一是要求真务实，真正“No Data No BB”，永远不是高高在上地做决定，而是做决定时能够看得到下面，这很重要;二是要有担当，在做关键决策时敢负历史责任，有进取心;三是必须时时自省和开放。如果不具备自省和开放的能力，是很难去进化的;四是一个大组织和大业务的CTO要有全局观，能够做架构，能把各方面、各种信息形成一张大图。

曾国藩非常懂用人之道，他这么选人：“专从危难之际，默察朴拙之人，则几矣”。我特别喜欢这句话，把自己的钉钉签名都写为“朴拙”，这是对自己的要求。

到现在为止，我觉得自己很多方面做得依然不够，包括对未来的判断。CEO和CTO实际上是要共同成长、共同进化，在工作中形成默契的，这是非常重要的。

CXO UNION（cxounion.cn）转载而成，来源于《云栖战略参考》第二期；编辑/翻译：CXO UNIONCXO联盟小C。

如需加入CXO UNION（CXO联盟）高管社群，请联系社群小伙伴哦~

免责声明: 本网站(http://www.cxounion.cn/)内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。

本网站刊载的所有内容(包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等) 版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。