CTO 最核心的职责是什么？

　　保证核心产品能够保质按期发布。

　　不管是前面提到的技术，还是技术人员的管理，『最终』不是为了建立一个『伟大』的技术架构。最终目标是为了能够发布产品，解决问题，满足客户，占领市场 - 这是一家商业公司的核心所在。CTO 的职责是为核心服务。

　　重点虽在今天，但也要为未来产品快速迭代和持续发布做好准备。

CTO 到底需不需要coding?

　　不需要。

　　但是，早期除外。

　　早期的时候啥都缺，很多事情都需要 CTO（有时候包括 CEO）亲力亲为。这个时候是不需要讲太多规矩的。没有队员就自己上，没人会，组织人学了上，包括自己。但 CTO 作为 IC (individual contributor) 应该是暂时的行为。尽可能通过寻找到更加专业的人来做具体业务的编程。不管是前端，后台，数据，全栈等等，刀应该是越磨越锋利。CTO 是操刀的人，不应该是刀本身。

CTO 需不需要懂编程?

　　CTO 必须懂编程，很懂编程。

　　他应该是个很好的工程师。如果他需要，不应该超过 3 个月可以重操旧业成为很好的程序员。只有这样他才能和其他工程师有好的沟通，在必要的时刻介入到技术框架讨论中不会鸡同鸭讲，被自己的手下鄙视。

CTO 要不要参与做核心技术的选型？

　　只有在自己擅长的领域内或者团队没法自己做出有效决策的情况下才介入。

　　这里涉及一个做核心技术决策时候的原则 "let the expert decide"。 如果你就是那个最好的 expert，你来。这个时候你不是以 CTO 的角色，而是以一个领域专家的角色参与讨论。另外一个原则就是尽可能让负责实践的团队来决策。一个施工团队是受一个技术选型决定的影响最大的一方，他们最有动力花时间来深入研究，去做一个将来不会让他们难堪的决定。如果有必要，CTO 可以利用自己在行业里的关系链邀请最合适的外面专家给团队分享案例提供建议，但不要将决定权交给外面的专家。

　　而当团队陷入一种争论而无法独立做出决断的时候，假如你相信你的队员们，这个时候你可以参与做个仲裁；因为如果胶着的双方都优秀的话，被争论的技术选项不应该存在一种会比另外一些选项明显好很多的情况。Just pick one and move on. 作为 CTO，你要明白争论在什么时候是足够了，什么时候该做个决断了。

CTO 要不要参与代码审查(Code Review)？

　　首先，不积极推动 Code Review 的 CTO 不是合格 CTO。明显没有全局化视野和对长期效率的深入思考。

　　有了 Code Review 的机制后，我建议 CTO 应该经常看看核心部分的代码，j2直播，以保持对于自己团队代码的熟悉程度。