CTO到底应不应该写代码？听听硅谷大神们怎么说

还是需要好程序员，那 CTO 照样还得写代码。总的来说，CTO 应该撸袖子上阵的心态还是被大部分创立于 21 世纪的美国科技公司所接受。

　　Movidius 的 David Moloney 1985 年开始工作，曾在多家半导体业界知名公司担任工程师、主任设计师、技术总监等职位。他认为CTO 的确不用写代码就可以管理，有什么事情交给团队成员也行——尽管他强调那不是他的风格。

　　如果我这样做了，会感觉很不舒服。我认为作为 CTO，首先应该是一个技术问题上的破冰者。

　　集客式营销公司 HubSpot 总部位于马萨诸塞州，已于早年上市，现在员工人数也超过了500人。其 CTO Dharmesh Shah 2014 年曾经回答过"CTO 应不应该写代码"的问题。他认为 CTO 应该写代码，就像销售 VP 得去销售一样。

　　Dharmesh Shah

　　除非那种已经很庞大的公司，在创业公司里，每个人都要亲力亲为。我从来不相信纯粹的管理职位。

　　不写代码的 CTO 就失职了吗？

　　或者：写代码应该成为 CTO 的核心竞争力吗？

　　这才是见仁见智的地方。大多数采访对象都会告诉我，他们认为 CTO 不写代码可以理解。比如有些经验丰富，任职于大公司的 CTO，确实应该花更多精力把握大方向，设计架构、分配工作、优化整体性能、确保系统的稳定和安全。具体的执行和实现，由下手来完成。

　　比如，有些大的公司不设 CTO 而是设工程副总裁 VP Engineering，但也能见到 VP Engineering 转岗 CTO（比如 Facebook），或者两个职位共存的情况。曾在多家公司担任 CTO 的 Vijay Venkatesh 认为，VP Engineering 更多负责现有产品，而 CTO 担负的是设计未来项目，让它与现有产品在技术上能够更好融合的责任。

　　在这样的公司里，CTO 应该有着比普通工程师更全面的技能和更大局观的视野。不可否认的是，CTO 的编程能力越强大，越能跑好把公司规划、业务需求通过技术落实的这个流程。编程能力是应该是让 CTO 庞大的技能树更好地生根发芽的养分，而不是树根本身。

　　CTO 应该会写代码吗？应该。写代码是核心工作内容吗？不应该是。用代码写得好不好评价 CTO 合适吗？不合适。

　　——这不是采访对象们说的，是我总结的。

　　事实上，无论在硅谷还是中国，不少小型创业公司的早期技术员工都面临这样的状况：移动端和 web 开发都得懂，平时还得维护自己的邮件/日历系统，公司网断了又要负责检修和给运营商打电话，拉条电话线都得亲自出马。这哪里是首席技术官，分明就是首席全栈苦力嘛。

　　而当公司发展起来之后，中美的情况却发生了变化。

　　硅谷这些 CTO（除了 Carmack 大神），要么一人扛起整个公司的技术运转，要么在投入巨大精力亲力亲为。他们会这么做的原因，也在最一开始提到过：技术对于这些公司的重要性，比技术对于中国大部分创业公司的重要性，都高得多；而CTO们需要考虑的技术之外的因素，也少得多。

　　而在中国，CTO 却往往没有办法这么去做了。中国科技圈太崇拜靠运营、靠打仗和修建城池获得成功的神话。微信、淘宝、微博，哪一个不是这样成功的呢？相比之前，技术的重要性太低，太不被外界重视。技术不会决定生死，产品做得差不多就行，靠推广甚至靠博眼球才能成功。这也是为什么在硅谷，创业公司的 CTO 们往往撸起袖子写代码，而在中国这样的环境里，一名合格甚至优秀的创业公司 CTO 却得去考虑代码以外其他很多事，他们的价值，也就不能仅仅用代码来衡量。

　　所以，对于，一个没有技术缺陷，擅长运营具备网红人格，还为其带来了巨大的影响力的 CTO，却用单纯用"写不写代码"来评价功过，并不太合适。特别是当我听说，整件事情幕后真相的讨论点已经从"匿名指责CTO 不写代码"过渡到"团队拒不兑现 CTO 期权"的时候，我就更明白了：

　　指责 CTO 不写代码不过是一盆泼出去用来转移视线的脏水，背后藏的，却是希望借着"代码之争"来达到其否定 CTO 价值、继而撕毁契约目的的厚脸皮和小算盘。