新晋 CTO ，这里有份过来人的经验要送给你
过去四年，David Mack 一直在 SketchDeck 担任 CTO ，如今，他即将离职并交棒给他的团队。在离开之际，他反思了作为 CTO 这四年来的经验教训，以及如果再来一次，他应该在刚开始担任 CTO 的时候注意的事情。包括最初的决策、技术选择和人才招聘等方面的思考，希望给新晋 CTO 一些启发。
反思过去的经验教训是一段充满激情的美妙经历，与传统工作相比，创业是一个相反的过程：最开始你并不知道公司能否启动，也不确定这能否变成一个全职的工作；随着公司的发展壮大，你开始面对各种蜂拥而至的问题，而且大多数问题你之前都没有碰到过。在这段时间里你会以飞快的速度积累并掌握各种知识和经验。
创业公司虽然灵活，但你最开始作出的决策将会在以后的时间里产生影响。一开始对基础设施、框架以及编程语言的选择，会影响相当长的一段时间。随着业务的发展，需要增加的功能和子系统越来越多，其中的每一项都会在未来影响后续的选择，而当公司进入快速发展期的时候，你会发现根本没有办法停下来考虑重构。
我对于我们最开始的选择还是比较满意的：Amazon Web Services 、Elastic Beanstalk 、Firebase 、AngularJS 、Coffeescript 、Kafka 、Simple Queue System 、SocketStream 、Docker 、SemaphoreCI 、MySQL 。其中，只有 AngularJS 和 MySQL 两个在后续的扩展上带来问题。我们的 AngularJS 代码是写在一个文件上的，该文件后来变得很大，导致初次下载的时候需要耗费一段时间，而且在系统运行时也感觉很慢。MySQL（ 用的是 RDS ）由于 BI 查询的复杂度增加而崩溃了好几次，并且不好修复。
一项技术的生命周期出乎意料地短。我们用到的 CoffeeScript 和 AngularJS 就是现在已显得过时了的组件（我们打算迁移到 TypeScript 和最新版的 AngularJS ），但它们在我们选用的当时都是比较前沿的。另外比较幸运的是，我对新技术的钟情并没有造成什么严重的问题。我很庆幸选择了 CoffeeScript ，在过去这几年里，它那简明的语法帮助我大大地提升了开发效率。
经历了上述这些事情后，我意识到，需要提前对技术的更新换代做好时间安排和策略准备。对于每一项技术的选定，你都有要有承受长期的“技术债”的心理准备。
同样地，你写的组件和库也会被长时间地使用。不管写得好坏，你都几乎不会再去动它。因此你最好在开始的时候多花一些时间进行设计和构建，以方便日后的维护。
我对那些暂停开发新功能并重写整个系统的“重构”做法一向是反感的。这曾让很多项目陷入死亡的漩涡。“童子军军规”里面有一条说得很好：
试着让这个世界比你认识它的时候好一点 —— Robert Baden Powell ，童子军与女童军的创始人。
于是我们尝试在代码中进行一些小改进。有时候想通盘考虑整个代码库的状态（往往都是不完美的状态）会让人感到头大，所以我会专注于持续、小幅的改进。
最后，关于测试的一些提醒：让我们的团队编写测试代码真的是难于登天。我给我们系统中的很多部分都编写了测试用例，并配置好了测试服务器，在每次有代码提交的时候会自动运行。尽管如此，我还是很少看到其他人添加新的测试用例。我本希望团队能自发地重视测试，但是，并没有。对此，我的一些解决思路是：
组织定期的讲座重温如何编写测试用例；
要求重要的功能必须包含至少一个测试用例；
优化测试服务器，让自动化测试在 10 秒内完成，而不是 10 分钟，让程序员及时看到测试结果。
除了技术决策以外，CTO 的另外一大责任是人员管理。CTO 每天的大部分时间会花在管理与领导、招人与解雇等事务之中。我不得不一边学习如何管理一边推进工作，所以不可避免会犯一些错误。
不管我阅读过多少次“员工是公司最重要的资产”，我都没有准备好应对招聘这么让人筋疲力尽的事情。如果你刚开始着手招聘，那我要提醒你：你可能要在上面花很长的时间，也可能要拒绝掉很多人，才能找到让你满意的那位。在此之前我从来没有想到，优秀的创业团队成员竟然如此稀少，我竟需要花如此之多的精力才能找到他们。
选择招聘的时机也是另外一个棘手问题：这个职位是现在就要招，还是晚点？哪个职位要先招？这些问题在你得到投资之后会尤其突出，因为你会觉得应该要把这些钱派上用场。幸好，Michael Siebel 和 YC 给我们提供了一些很有用的建议：
当你感觉某个职位需求非常迫切的时候才开始招聘（比如快赶不上合同进度了的时候）；
招人是为了满足业务发展的需要，不能本末倒置（这条主要适用于还没有形成规模化、可持续的业务流程的早期公司）；
不要招人来做一些你都还没想明白的事情（一些特殊的候选人也许能给公司带来新的动力，但通常最靠谱的办法还是靠创始人调整公司资源以适应新的发展）。
综上所述，如果你不确定某个岗位是否需要招聘，那可能就是太早了。我们犯过的错误就是：过早地招人来做一些我们自己并不擅长的增长方案，结果基本上是以失败告终。
员工管理基本上一路走来都比较顺利 —— 定期开展开诚布公的检查，明确什么是该做的，什么是不该做的，这些措施让我和我的员工保持着良好的关系。
解雇员工则比较艰难。你可以在别处找到很多有用的建议，我这里只简单说一点：你的直觉通常很早就告诉你应该解雇某个人，但你往往要经过很长时间才能接受这个事实并着手实施，而且实施过程通常很困难。拥有良好的检查制度可以帮助雇佣双方做好最坏结果的准备。另外，如果安排合适的个人发展计划，有些人的水平能得到提升甚至达到优秀，每个人都应该有这样的机会。
伴随公司发展的一大乐趣就是看到一些优秀的人才在各自的领域冒出头来，成为新的领导者。在此，我要向我的整个团队致以诚挚的敬意和祝贺。
查看原文：https://medium.com/sketchdeck-developer-blog/what-i-wish-i-knew-when-i-became-cto-fdc934b790e3