CTO出了什么问题?

      CTO出了什么问题?无评论

For TGO鲲鹏会.

CTO出了什么问题?

标签(空格分隔):


note:


摘要

为什么企业和CTO总是败兴而归,摩擦不断?Paul Robinson给出了他的真知灼见。

作者Paul Robinson

正文

有句话我不吐不快:

从前是缺好码农,现在是缺好CTO。这周有3家公司找我问怎么招CTO。是不是当承包商给的钱太多,以至于没人想循规蹈矩,搞的公司高层都招不到人了?

我对CTO这个问题有一套:我自己为CTO招聘这件事做了5年咨询(虽然最终也没成什么,项目死的挺快挺惨的),自己也全职做过几次CTO。

如果你想成为CTO,或者想招聘CTO,我有一言请静听。

CTO每天做什么?

工程师(特别是小型公司的工程师)会觉得CTO就是“超级技术领导”:他们觉得CTO是一个特别高年资的工程师,领导全司的技术方向。

我担任CTO时做了一点点事情:

  • 和商业部门大佬沟通(CEO、董事会、投资人等),确定下面几个月的路线;
  • 和产品和分析师研究出可行的产品路线图,和商业规划匹配;
  • 按照产品和商业路线图规划技术路线图;
  • 当某个路线技术上不可行时,劝说其他人放弃这个想法;(注意:不是简单的说“开发不了”——需要谈判技巧!)
  • 设计开发团队,报告人和流程;
  • 在功能、BAU和技术债/bug间找到平衡点,最大化商业利益;(一般来说没有公司会把修bug当成头等大事的)
  • 关注技术开发涉及的合规性问题和法律变动;
  • 准备并申请开发预算——工资和研发预算一般是两条线;
  • 准备并申请运行预算,例如硬件、服务(数据中心、云服务等)、软件授权、专利授权等等;
  • 把上面所有的东西和管理层和董事会讲明白,而且要说人话——用财务数字。这步需要做很多Excel表,并加以解释;
  • 把上面所有的东西和投资人和未来的投资人讲清楚,而且留后手以免被开除;
  • 设定技术团队的文化。这件事和下层多多少少都有关系,但是你得定调子。你做的事情会被有样学样;
  • 把上面的所有事情和技术团队说明白,用程序员的人话。例如,对董事会汇报可以说“本司预计于18至24个月内由CAPEX模型迁移至OPEC模型”,但是对技术团队你得说“接下来一年到一年半我们要从自建机房全部迁移上云”。(注意时间要求被加码了:除非你得到充分信任,否则你必须这么做
  • 保证技术团队的运行不受阻碍:你可以对人大喊大叫,但是大部分人觉得大家互相信任,不需要管理的效率最高。我从Joel那里知道了这点;
  • 招聘高级别技术员工:这步是最耗时也是最难的,但是如果做好了以后就轻松了;
  • 管理、指导并支持技术高层;
  • 考虑薪酬,期权管理等,虽然从公司政治上不怎么愉快而且很难办;
  • 开除需要开除的员工。不能心慈手软。有人告诉我一条金科玉律:用人的目的评价人,而不是结果。尽可能不开除好心办坏事的人:想办法帮他们。
  • 做有争议的决策后把故事编圆,保证团队看起来团结一心;
  • 当团队做得好时一定要激励;
  • 出任何差错你去承担。我历史上辞职过很多次,不一定是因为我自己犯了错。如果你拉不下脸,就别进管理层:如果你想推卸责任,那么你下面的所有人都会恨你,而且你也干不下去了。

你已经注意到了,写代码的时间并不是很多。根据公司的不同,有可能CTO不会怎么碰产品,具体的说:

在非常小的公司,你自己必须亲力亲为做产品;在大公司你不会有时间亲自做产品的。

我上次当CTO时编了个笑话:我司大到我不需要写代码,但又小到我必须亲自写,搞得我两头不是人。

不同种类的CTO

虽然上面的职责相通,但是CTO还是分不同种类的。

一般来说,CTO可以分成“运营管理”型,和“技术领导”型。两种CTO的背景和角色区别巨大。

我去过一个咨询公司的CTO酒会。我们在伦敦中心的高级酒店聚会,社交一下,吃一顿公司提供的大餐。然后他们搞了个“圆桌讨论”,想听取“技术领导人”的看法。对他们来说这种事情是市场调研,但是考虑到上的菜和酒的确上档次,所以为什么去不薅羊毛呢?

于是我发现了很震惊的事情:在座的20多CTO中,我和另一位是仅有的曾经学过写代码的CTO。

那名CTO有工程背景,但是大家都觉得他只是个技术怪人而已。我是唯一可以自信地运用我的技术背景的CTO。

其他的CTO觉得有技术背景的人很奇怪:都要当CTO了,为什么还要学写代码?

读者肯定会奇怪了:难道CTO不是工程师一层层升上去的吗?

有些我共事过的CTO可能写过那么一两行代码(“当年写过几行COBOL”的程度),觉得代码写不下去,开始研究管理职务,跳过去了。

更多的人是从运营或产品经理升上去的,大家觉得他们懂技术,于是就把技术交给他们领导了。

从运营上来说,他们有可能学过金融、产品管理、运营、教学等工程师认为是“软技能”的技术,把纯技术交给他们能信任的人来处理。

这种模式于大公司的技术产品研发部门很常见,但是一般不会在科技公司中出现:这种模式一般在零售、公共事业、银行、政府中更多。

当然了,对于想成为CTO的工程师来说,上面所说的只是万千条路的一种:还有很多工程师类型的CTO职务,会更像“技术领导”。

技术领导更多是提供样板,当高级工程师搞不定时可以来求援,所有人知道你说的办法肯定是最佳方案。

不是所有公司都需要这种领导:有些公司可以让技术团队自己研究个方案,但是如果真需要技术领导而CTO没技术能力的时候,整个公司有可能直接死掉。

技术领导最适合纯技术公司:公司的主要产品就是技术,例如软件或B2B的组件,或者卖的东西会被商店划分到“科技”板块的那种。

这种公司的CTO必须是理解整个产品的工程师,而且是有同理心,可以领导团队的人。

这两个世界交集很多:服务行业越来越需要科技驱动,科技公司越来越需要关注市场。

我的第一份技术工作是在运营商的。我的CTO会Unix命令行,会八国语言写代码,能把表脑内转换成第三范式。

那个运营商被收购了,和几个运营商合并,成长了很多。现在那家公司是欧洲最大的运营商之一:我几年前看过他的CTO专访,很明显他的CTO不怎么懂技术。90年代的运营商是科技公司的代表:现在变成公共事业了。

所以,公司的不同阶段需要不同的CTO:要么你变,要么你让路,去小公司继续领导。对于希望领导技术团队的CTO而言,不是坏事。

CTO出了什么问题

总体来说:

  1. CTO的职称在不同的公司意义不同,职责也不同
  2. 一线工程师不知道这个职位不需要懂技术,自己也不懂运营和管理
  3. 非技术人员又不懂工程师每天在做什么,所以做不成什么技术决策
  4. 随着公司变化,CTO也要变化
  5. CTO如果搞错了形势,就得下台。CTO想跳槽不容易:不是所有公司都有CTO,即使有也很不一样,参见第一条
  6. 最后,CTO和别的CXO们工资一般相差很大:如果你对公司财政上没影响,那对公司的其他部分也没什么影响

所以我觉得不是因为大家都想当承包商,造成CTO难找:大家心里像明镜似的。如果你是高级程序员,考虑当CTO,那你肯定会认识个10年前改行当CTO现在痛不欲生的朋友。

简单的说:想做的做不好,做好的不爱做。

那么怎么办?很多人管理上不够格(例如,高级技术经理,但是不想当CTO),或者工程上不够格(运营的外行指导技术内行)。

有一个办法是,创立一些类似CTO但不叫CTO的职务:工程总监、工程副总裁,技术总监等等。有这些职务的公司一般也有个CTO。这些职务在不同的公司意义不同,但是我希望以后慢慢会有规矩。

我也见过CTO做纸面工作,技术总监做技术工作的设置,但是效果不好,因为两个人都有管理背景,都不想搞技术。我觉得也是因为其他管理层不知道技术领导的需求吧。

虽然很难,但是公司成败有可能真的在此一举。

如何招聘CTO

如果你想招聘CTO,好好考虑一下你需要的技术和背景。

如果你需要技术领导,那么找一个高级工程师,给他时间和空间熟悉非技术工作。帮助他,明确说明你需要CTO做什么。每步要汇报。

如果你需要管理领导,那么找一个管理背景的人,让他找一个技术总监,让他们自己划定职责。

如何当好CTO

想好你想得到什么,以及你想成为什么样的CTO。你有可能真正想做的是工程总监,甚至只是大部门的技术领导。

万事开头难:多问问题,寻求帮助。你肯定会筋疲力尽,但是如果一切顺利,那么你会为你的团队和同事感到骄傲的。

最后叮嘱一句:搞明白领导和管理的区别,知道何时用什么。

祝前途似锦!

查看英文原文

https://hackernoon.com/the-problems-of-the-cto-role-c2a143a1cec7

发表评论

电子邮件地址不会被公开。 必填项已用*标注