作者|周明耀
编辑|小智
初创公司和成熟公司,CTO 与 VP 的定位都是不一样的。究竟怎样更好地去理解 CTO 与 VP 的区别呢?
写在前面
有天中午和同事吃饭时聊起了工作上的愿景,我说愿景分为技术愿景和业务愿景,技术愿景是对于技术的憧憬,需要有人画饼,光画不行,还需要有人指导落地。业务愿景是让产品能够落地的期盼,因为只有落地了才有企业的美好未来,才会让我们这些工程师持续赚钱。今天我们文章要讲的两个角色,实质上分别对应的是技术愿景和业务愿景。
大家一定经常听猎头说某某公司正在寻找一位合适的 CTO,大多是 startup(创业)公司,给出的要求通常是“他需要很会编程,需要热爱技术,具有很强的产品设计意识,需要能够有较强的团队管理能力,需要能够接待各类投资者,需要能够进行技术和专利布局,需要。。。”,反正,对这个 CTO 角色的要求挺多的。
随便搜索了一下网上对于 CTO 职位的招聘信息,如图:
另一位 HR 对我说过,希望找一位工程 VP,这个人要能编码,然后能够管理团队并负责团队文化的建设。
从以上两个岗位的描述要求来看,貌似工程 VP 的要求和 CTO 也大同小异。
除了这些,相信你也曾经听说某互联网公司 CEO 讽刺离职的 CTO,“来了就没干过编程的活”,我们这里不对是非进行论述,到底怎么回事可能只有当事人自己清楚。从我个人的角度理解,我觉得凡事不能只从单一层面评价一个人的工作能力。CTO 到底要不要写代码,应该具备什么样的素质,是很多人在讨论的问题。在我看来,CTO 是可以不写代码的,但是这也意味着,他必然是因为有更重要的与技术相关的事情要去做。而从本文的角度来看,我们只针对美国的一些较为成功的科技企业进行调研,看看他们是如何对 CTO 和工程 VP(或技术 VP、Header of Engineering)岗位进行定义和区分的,So, let’s see, what title is what?。
CTO 角色
定位
毫无疑问,硅谷的公司大多认同这一观点,即 CTO 是公司第一号技术大师,他对于技术非常敏感,需要具备对于技术发展的深远见解,并借助他的能力保持公司在行业内技术上的竞争力。CTO 需要保持自己对于专业领域内的前沿技术的不断搜寻,此外,他也会对那些可能对公司的技术方向产生影响的旁系领域进行调研。
为什么 CTO 需要非常热爱技术?因为 CTO 的任何一项技术决策,或者提出的技术方案,面对的客户就是本公司的工程师们。干过工程师的人都知道,工程师才不和你讲官场上的那一套阿谀奉承,他们大多思想简单,喜欢以技术为讨论内容,会绝对尊重具有技术领导力的人。如果 CTO 不只是能够提出方案,自己也意愿动手尝试新的技术,那就太棒了!
一般来说 CTO 也会有自己的“CTO 办公室”,很多时候这个团队其实虚拟的,会有几位全职或者兼职的下属,他们会帮助 CTO 一起做技术调研或者原型产品。
技术影响力
国内外的技术领导风格其实有很大的不同。在美国,每个科技公司的技术副总裁、CTO 和高级架构师都很注意影响力,我们经常看到当公司内部有技术分享的时候,很多人主动去讲,尽可能展现自己在技术或者管理方面的长项。
如果一个工程师、技术主管、CTO 或者架构师,有了这种技术领导力,当他跟同事一起讨论问题或者一起协调问题的时候,大家往往会有一种倾向的感觉,他说的事情一定不会假,往往有这种效果。美国各大公司的 CTO 经常参加业界的分享,做各种技术委员会的委员,包括出书、参加各种活动都非常活跃。除了对公司有利以外,其实这也是给自己的职业发展铺一条路,所以影响力不仅仅为了企业,也是在规划个人职业发展。
写博客
国内的技术博客已经开始走下坡路了,一些大牛纷纷开始转战技术平台(比如 InfoQ), 也有一些开始通过开设个人微信公众号形式继续传播影响力,最主要还是由于国内读者的阅读习惯更倾向于手机客户端,而且技术博主的收入几乎为 0。欧美人还是有很多喜欢访问网站,而对于写技术文章这个工作来说,由于 CTO 常年耕耘于技术前沿,所以很多公司的 CTO 义无反顾地承担了公司 Blog 的重责,是博客文章的重要贡献者。
我们来看一个例子。美国 Amazon 公司的 CTO Werner Vogels 博士是一位具有代表性的 CTO,他有自己的技术博客,我对他最近的帖子进行了截图:
大家可以看到,博士除了写一些和所在公司相关的深入技术和方案介绍、产品设计分享以外,他也会针对一些基础知识进行分享,就有了“Back-to-Basics”系列,我上个月决定开始写的技术杂谈系列,也是源于他博客的启发。
架构师
一些公司设有首席架构师,国内很多公司设立这个职位的初衷是为了解决员工的进阶问题,其实我个人觉得团队是否一定需要一位架构师?技术团队 Leader 本身就应该具备架构能力,并且最好是热爱架构,这样他才能不断前进,既然他可以架构,那还需要专职的架构师吗?
回到我们的话题。根据对多家美国大型科技企业的研究,公司的首席架构师一般是 CTO 的备选人物,这是因为首席架构师和 CTO 关注的领域较为相近。首席架构师和 CTO 之间通常的差距是经验,首席架构师有点类似于小号的 CTO,积累足够的经验后,他们可以走向 CTO 岗位。
工程 VP
CTO 角色说完了,该轮到工程 VP 了。简单地说,工程 VP 的职责是交付软件解决方案,确保业务健康,因为只有业务健康,工程师们的努力才有价值,团队才有可能继续发展。
前面提到了 Amazon 的 CTO,我对应地在 Google 上搜索了 Amazon 公司的工程 VP,只在 LinkedIn 上搜索到他们的资料,按照名字去搜索,没有能够找到博客或者发表的文章。
工作要求
工程 VP 首先需要是一位杰出的管理者、团队构建者,具体技能包括招聘、沟通、问题解决等,工程 VP 的工作时确保工程团队内的每一个人成功,而他的工作是解决成功过程中遇到的问题。由于工程 VP 需要面对的人大多是工程师,所以最好他自己也是工程师出身,只有自己做过类似工作,你才能更容易理解大家讨论的内容。
和 CTO 对于技术的专注不同,工程 VP 的工作内容更宽泛,通常包括以下职能:
-
人员管理:对于少于 10 人的团队,工程 VP 直接管理团队内所有员工,对于 10-100 人的团队,工程 VP 下设多位经理,他负责管理这几位经理,对于大于 100 人的团队,工程 VP 还会上设工程总经理,他会向这位总经理汇报。
项目管理和执行:工程 VP 需要对产品的开发、交付负责,他需要在公司内部糅合各个团队之间的关系,包括开发部门、资源部门、审计部门等等,确保产品开发的正常进行。
财务管理:这里指的是工程部门范围内的财务管理。具体包括人员投入、原型设计费用、设备费用、出差、娱乐等。
技术领导:首先他需要和 CTO 一起制定公司的技术战略规划,然后根据规划制定技术演进到产品的 RoadMap,确保产品上的技术能够保持创新。对于架构师这个职责,工程 VP 可以自己担任,也可以委派组织内的其他人担任。大多数工程 VP 会指派架构师代替自己的架构职责。
战略发展:工程 VP 不一定是技术大牛,但是他一定是跨学科人才,因为他的工作需要和多个不同部门的人打交道,包括市场 VP、业务发展 VP、制造部门 VP、运维 VP、CEO、CTO、COO,共同开发公司的战略和产品战略。这其实涉及到了一个人的对外管理能力、向上管理能力,即对于你同级的其他部门人员的沟通,对于你上级(例如 CEO)的汇报和沟通能力,只有让他们理解了你的工作,才能体现出你的价值。
我也搜索到了一位比较典型的工程 VP,Coursera 的 Richard Wong。Richard 出生于香港,11 岁时第一次接触计算机程序设计,斯坦福硕士毕业之后,在微软干了 11 年分布式软件开发工程师,而后又在 LinkedIn 呆了 4 年,接着就去了创业公司 Coursera。他认为杰出的程序员和一般的程序员的巨大差距是多久你可以把自己的想法转变为代码。
同样的问题也会落在工程 VP 身上,要不要写代码?从我个人的理解,研发人员很重要的是需要一位能知道他们、了解他们的大哥,也要参与代码过程,原因在于可以通过写代码去理解大家、了解大家在想些什么。你作为技术领导者,必须进入这个氛围,了解一线员工他们在做什么,作为他们的发言人,代表技术团队跟公司管理层争取一些利益和福利,大家会觉得这是我们自己的带路人。
CTO 和工程 VP,我的观点是,两者应该是合力开发产品,而不是谁领导谁的关系。创业型公司容易出现这种情况,由于没有第一时间找到或者雇佣一位靠谱的工程 VP,导致开发过程总是被各种情况打断、团队的氛围很差、工程师和产品经理之间隔阂很深,这些都是因为没有一位称职的工程 VP 在产品开发流程内进行统筹管理。
对于一家科技公司来说,CEO 和工程 VP 之间的合作至关重要。CEO 负责明确需求,将市场的需求精简为产品需求,工程 VP 则从专业角度上确保团队可以按时发布产品,即便在 CEO 时不时地修改需求的情况下,优秀的工程 VP 依然可以确保按时完成任务,并且他也起到了 CEO 与技术团队之间的润滑剂作用,将压力挡在了技术团队门外。
写在最后
前面说了这么多,我们可以对 CTO 和工程 VP 的工作用下面这张图来表示:
前言里提到的猎头要寻找的“CTO”,其实更像是创业公司的技术合作人,什么都需要干,各方面能力要比较均衡,也喜欢自己动手写东西,但他不是真正的 CTO。需要明确的是,公司业务稳定之后的 CTO 和工程 VP,这两个角色所承担的责任是存在很大区别的,两个角色都对业务的扩展有重要作用,只是所需要的技能及工作内容截然不同,因此,对于人才的技能和性格要求也是不同的。个人感觉,CTO 与工程 VP 之间的关系是互相紧密地交流,工作上各有各的分工,CTO 规划技术愿景,工程 VP 更多负责业务愿景。
作者介绍
周明耀,2004 年毕业于浙江大学,工学硕士。13 年软件研发经验,近 10 年技术团队管理经验,4 年分布式计算、大数据技术经验。著有《大话 Java 性能优化》、《深入理解 JVM&G1 GC》、《技术领导力 – 码农如何才能带团队》,InfoQ 专栏作家、IBM 开发者论坛专栏作家,个人提交发明专利 16 项。个人微信号 michael_tec,个人公众号“麦克叔叔每晚 10 点说”。
今日荐文
点击下方图片即可阅读
微服务在微信的架构实践
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。