读代码就像读书一样，时间久了不读书，会失去对文字的感觉。但不一定要全读。核心系统的核心代码，和公司碰上的大 bug 时候，都应该经常看看。前者对于自己公司的最核心的技术实现有个第一手的了解，知道强在哪里；后者可以了解自己的团队通常是磕磕碰碰在什么地方，知道弱在哪里。

CTO 是否应该参加核心系统的架构讨论？

　　应该。

　　如果一个 CTO 来自己最核心的系统的大体实践都不了解的话，没法在必要的时候介入做最终的技术仲裁；也没法知道需要招什么样的技术人员来发展团队。前者是做事，后者是做人。而事和人都是应该为了系统服务的。系统，当然是为了产品服务。

CTO 是否应该参加核心产品的讨论？

　　应该。

　　产品需要实现，只有清楚核心产品是什么，才知道需要什么样的核心系统，然后才是什么样的技术和人才。所以 CTO 参与核心产品的讨论非常重要。

CTO 该不该主导工程师文化和制度建设?

　　CTO 的主要职责之一。

　　CTO 是一个 leadership role。团队小的时候，管理相对容易，大家主要就事论事即可。团队大了，不管你愿不愿意，会逐渐分层，你需要逐渐的去发展中层干部，也要逐渐思考文化建设。所谓文化建设，就是一个形成共识的过程。这种共识是关于什么样做事做人的风格是被鼓励。文化无关对错，文化是一种选择。

　　很多创始团队的早期 CTO 如果没法随着公司的成长而成长起来，还是天天陷入到某块具体代码的局部战争中去，动辄就介入具体的执行，一不放心就自己啥都管管，不懂得delegate，要不就是放手就完全不管，不懂得 validate。师长做了排长的工作。

　　如果一家公司的 CTO 只想管事，不想管人。要么加一个 VP of Engineering分管人，要么把 CTO 的位置让出来给到更合适的人选。

CTO应不应该经常走出去和外界交流？

　　虽然并非必须，但这是区别于一个合格 CTO 到卓越 CTO 的重要的点。

　　走出去，一方面可以将自己公司在技术这块的事和人方面的问题暴露出去。达到高水平的前提是你和高水平之间是联通的，这样两个水面才有机会平起来。除非你很自负的认为自己就是比剩下的世界要牛很多。另外一方面，可以将自己公司取得的一些成就展现出去，自己公司的文化特点展现出去，能够更好的吸引牛人进来。前面提到 CTO 一个重要的角色就是要打造团队。团队的前提是牛人；吸引牛人的前提是别人要知道你。CTO 不走出去和业内多交流，指望猎头找来牛人多半是不靠谱的。