CTO出了什么问题？

note： 可选标题：《如何当好一条CTO》<-----冲着10W+去的

摘要：

为什么企业和CTO总是败兴而归，摩擦不断？本文作者Paul Robinson给出了他的真知灼见。

作者： Paul Robinson

正文：

有句话我不吐不快：

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

（译者注：在北美，由于累进税制，对于年薪8万刀以上的员工而言，为了少缴税，最好的办法是成为承包商，即contractor：开一家只有自己一个人的公司，把自己当做派遣人员派遣到原公司，原公司和这家单人公司签派遣合同，自己给自己开工资。这样的好处是缴税少（从45%以上变成统一的15%），而且可以将自己家的日常开销当做公司支出报税，进一步减少税额。然而缺点在于，公司可以随时解除合同，员工不受劳动法保护，没有福利，需要自己处理医保养老金税款缴纳问题。具体涉及的法律问题在美国需要按州进行个别讨论，加拿大的劳工法与美国不甚相同。译者不是法律专业人士。）

我曾经做过5年的CTO招聘咨询顾问，也曾经在几家公司做过几次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