作为公司的技术最高决策者,身上肩负了很多的职责,不光有公司的技术路线图、投资标的公司的技术尽职调查以及关键技术趋势研究等战略级事务;还有工程团队文化建设、技术布道等帮助公司健康发展的关键事务;还有跨部门沟通、为其它部门提供服务能力帮助他们一起成就公司愿景等。
在目前典型公司架构中,工程团队或技术团队的总负责人便是该公司的技术最高决策者,那么本文要讨论的技术最高决策者就是 CTO(首席技术官)或 VP of Engineering(技术副总裁或工程副总裁),这个一般根据公司的实际职位设置情况来,本文默认 CTO 为技术最高决策者。
技术或工程团队日常工作中会有很多的技术细节类工作,例如技术框架选择、高可用架构设计以及持续集成等,那么一般困扰我们的是,作为技术最高决策者跟这些技术细节的边界是什么?是否应该关注这些技术细节?
我接下来将先简单梳理下CTO的工作职责内容,然后我们再看是否应该关注技术细节,在本文阅读完毕后,希望你自己也能够根据现状进行思考。
CTO 的使命我们可以从三个维度来进行说明:长期的技术战略、技术布道者以及工程团队文化建设,里面仅第三项是完全的对内事务,前面两项都是内外结合型事务。接下来我们将分别来看看这三个维度的使命是怎样的?
CTO 负责一个公司的技术或工程团队,那么如何建成健康的工程团队文化便尤为重要。
上面我们提到了CTO的使命,从三个维度共8个要点进行了说明,希望大家能够对 CTO 的使命有些了解。如果我们要看作为公司技术最高决策者是否应该关注技术细节这个问题,我们还需要看下CTO对公司内部各组织的具体职责是怎样的。
一般分为以下5个主要组织或团队:CEO 或战略、工程/产品、销售、商务拓展以及市场营销。下面将针对这CEO或战略、工程/产品两个团队阐述下 CTO 的一些主要职责:
本文前面说了很多关于CTO的使命与职责,那么作为技术最高决策者是否应该关注技术细节呢?在此先说结论,符合其使命和职责方向的技术细节需要关注,此外的技术细节不必要关注。接下来本文将阐述此结论的由来以及会举证一些事例便于理解。
CTO 全称为 Chief Technology Officer(首席技术官),重点要注意的是 Officer,也就是高级管理者的角色,首先需要对公司的长期技术战略进行负责,保证公司在技术拐点产生时能够作出正确的判断并制定应对策略。这样就需要 CTO 对外部世界的技术动向和趋势能够收集到足够的信息并进行分析整理,从而得出结论。
例如 2007年6月苹果公司发布了跨时代产品——第一代 iPhone,成为了移动互联网发展元年,之前 Symbian 系统的智能手机更多的还是基于 WAP 网络,iPhone 全触屏体验、高速好用的内置浏览器、全新的智能手机操作系统 iPhone OS 以及应用商店体系给行业带来了翻天覆地的变化。
CTO 需要了解 iPhone 的详细产品功能以及技术规格等技术细节,并对 iPhone 相关移动网络技术进行调研,从而来分析判断 iPhone 及移动互联网发展趋势,来看公司的技术战略是否需要进行相应调整。
我们现在回顾移动互联网过去10年,是几家欢喜几家愁,有些公司借着移动互联网技术东风发展迅猛,有些公司没有及时调整战略进而发展受限甚至慢慢衰退,比如之前超级依赖短信 SP 的公司。
移动互联网的技术拐点来临的时候,我亲身经历过技术趋势分析和公司技术方向调整,当时公司在2007年开始做移动互联网方向的尝试,因为我分析认为未来的趋势是基于手机的移动互联网,只是当时是基于 WAP 和 Symbian 系统来做的,体验和能力都不好,因此决定先做互联网 Web 2.0 方向项目。
在同年 iPhone 发布后,研究后觉得 iPhone 走的方向是智能手机未来(当时国内 3G 牌照尚未发放),决定投入少量人力研究和保持关注 iPhone OS,次年苹果公司发布了 iPhone OS SDK 1.0,我们就立马组建了 iPhone 客户端团队进行移动互联网应用开发。由于国内 3G 牌照未发放,当时相应的一些 3G、GPS 测试就到香港和深圳进行,由于我们在移动互联网方面的提前布局,也帮助公司顺利拿下下一轮投资。
前面有提到 CTO 需要在外部激烈竞争下保证公司使用的是最佳技术,这里的“最佳技术”并非是指最为花哨或最为前沿的技术,每个公司有着自己的业务背景和历史债务问题,选用对于公司技术资源投入产出比最高,且为符合日后技术发展趋势的技术方案才是“最佳技术”。
那么这里我们以火热的技术架构设计风格——微服务——为例说明下。众所周知微服务架构设计风格并非只是技术上的,如果要在公司中选用的话,需要具备持续集成/持续发布的实践基础,同时要对企业组织架构进行相应调整,那么作为 CTO 需要针对微服务架构设计风格对于公司选用的收益及风险进行评估,以及需要来看跟公司业务发展方向是否一致,这样的微服务相关的技术细节是需要 CTO 进行了解和关注的,这样才能够尽量作出正确的判断。
前面用行业新产品带来的大趋势或技术拐点以及新技术架构趋势的例子,来说明哪些技术细节是技术最高决策者应该关注的,那么反例有哪些,也就是哪些技术细节不应该被关注?
作为 CTO 不应该将时间投入到产品日常迭代和编码这样的技术细节中,例如具体技术框架选取、架构方案设计以及代码评审等,其中亲自上阵写代码是最应该被禁止的。为何呢?因为每个人的时间都是有限的,CTO 需要将时间更多的花在跟公司未来、技术趋势以及商业拓展相关的事情上。
上述具体技术事务应该有技术副总裁和技术总监来进行完成,CTO 需要提前做好指引工作,跟工程副总裁制定好技术方向原则,以指引工程团队具体工作。
有的 CTO 会参与到具体执行工作中去,一般的理由有“团队小”、“该领域我是专家”、“这项工作团队其他人的交付速度与质量不如我”,其实这些理由后面恰恰对应的待解决的问题,例如:
作为公司技术最高决策者首先需要明确自己在公司承担什么职责,这样才能够清楚怎样的技术细节是应该关注的,哪些技术细节是不需要关注的。正如前面所说的结论 “符合其使命和职责方向的技术细节需要关注,此外的技术细节不必要关注” ,使命和职责是需要先明确的。
本文是以 CTO 的角色来进行的说明,那么实际工作中的情况可能会不一样,例如公司没有 CTO 仅有工程/技术副总裁,这样的时候就需要重新来明确使命和职责,再确认技术细节的边界。
总而言之,技术最高决策者需要明白的是,这个岗位的职责是要为公司业务发展及未来负责的,因此技术细节边界的确立有助于更好地分配时间来帮助实现公司愿景。
作者介绍
刘俊强(微信公众号:程序员精进)现任腾讯云资深架构师,TGO 鲲鹏会深圳分会董事会成员,小组委员,曾任迅雷技术总监、某互联网公司技术副总裁,10+年以上互联网开发经验,8年以上技术管理经验。