在创业的各个阶段，CTO 必须要扮演不同角色
导读：CTO顾名思义就是技术的总管，听起来似乎就是跟技术打交道为主的了。但是对于一家初创企业来说，公司的不同发展阶段对CTO的角色要求是很不一样的。
CTO顾名思义就是技术的总管，听起来似乎就是跟技术打交道为主的了。但是对于一家初创企业来说，公司的不同发展阶段对CTO的角色要求是很不一样的。如果到规模扩大后还想像当初那样把大部分精力放在自己写代码上的话，公司是没办法快速发展的。Gusto联合创始人兼CTO Edward Kim 分享了自己在这方面的感悟，里面有一些非常值得借鉴的最佳实践，不妨参考一下。
图中为作者，左右为Gusto另两位创始人
我跟两位联合创始人一起创办了Gusto，这个公司的使命是让中小企业的工资、福利和HR工作变得容易一点。我和Tommer、Josh当初是在Palo Alto一所房子的主卧那里成立这家公司的，除了对未来的愿景以及愿意做任何将其变为现实的事情的承诺以外，我们一无所有。
6年后，我们服务的小企业已经超过了60000家（超过美国雇主总量的1%），雇佣了超过600人（包括约100名工程师），我们一起实现了超过10亿美元的估值。
我会定期在Gusto安排接访时间，任何工程师都可以过来问我任何问题。我有时候被问到的一个问题是：作为CTO和公司联合创始人，你的角色是如何变化的？
一位工程师的时候：车库，呃，衣帽间里的技术宅
我们开始起步的时候，我住在旧金山，我的两位创始人一起住在Palo Alto的一间房子里。我认为在我们开发第一个原型的时候大家住在一起（当时我们都还是单身）非常重要。不幸的是，那里已经没有更多卧室可以租给我了，但是主卧那里还有一个相当大的步入式衣帽间。在说服屋内所有租户让我以300美元/月租用这个衣帽间之后，我借了朋友的空气垫，打包好行李，然后就搬进来了。
我是CTO，但在公司的那个阶段，这么称呼感觉会很傻，因为其实并没有任何可以称为“首席”的。软件工程师用来描述我的角色更加合适。我尽可能地学习非常烧脑的工资系统以及ACH系统的机制，同时每天用12到14个小时戴着耳机来编程——这种感觉很棒。我的日程上唯一的会议是午饭、晚饭以及去健身馆锻炼。这期间我们的目标？开发一套工资后端系统从而让我们能够通过它来付费。
2到10名工程师：一支团队，一个梦想
在让一个基本的工资系统跑起来之后并且完成了种子轮融资之后，我们搬到了旧金山的一栋阁楼公寓里面，这时候我的编码时间占比从90%缩减到60%了。剩下的时间花在了寻找、面试以及聘用工程师上。我作为CTO的角色已经发生了很大的变化，但花在招聘上面的时间却一直没少（而且可能会一直如此）。从这时候开始，我总要花30-40%的时间用于招聘。
成为球员兼教练
在我们招了一些工程师之后，我从成为唯一一名全职开发者变成了跟一小群开发者合作。我仍然要花很多时间在编码，代码审查以及修补bug上，但我偶尔会摘掉耳机向团队解释ACH是如何工作的，或者跟大家商量是否应该开始进行代码审查了。只要我能为其他工程师保留制造者的时间，比如购买和配置计算机跑我们的CI管道，我就会去做。像1对1对话、冲刺计划以及每日站立会议等开始爬满我的日程。我要听取工程师的汇报，但大部分都没有层级之分，工作气氛仍然感觉像是一群同行一起在一间房子里编码。
在此期间，关于Gusto（当时叫做ZenPayroll）发布的消息被封锁了，经过一昼夜通宵达旦的忙活之后，工程团队紧张地监视这服务器日志，不断刷新页面以确保我们的Linode服务器在被TC报道之后还能存活。
11到50名工程师：坚持写代码
紧跟在公司迅速获取客户并且进行A轮融资之后，我的工程师团队已经超过10人了。对这些工程师进行协调变得更加困难。除了规模以外，其中一些早期工程师的资历也要求我必须让我们的工程组织变得更加结构化。比方说，我们的一些工程师已经在Gusto工作了将近2年了，他们开始要求补偿框架以及自己的职业发展路径规划。说实话，在这方面我没有给予充分的考虑。
与此同时，尽管团队规模变大了，但是要发布的功能以及待修改的bug的清单仍然没完没了。最熟悉我们代码库的人可能仍然是我，所以当出现问题或者需要交付一项功能时，我总是忍不住跳出来想自己写和修补bug。这经常是我干的事情。
纽约之旅
2015年，我知道我需要从编码这件事情上退下来了专心成为一名好的管人的经理了。为了实现这一点，我决定飞赴纽约窝在一家酒店内用3天的时间读一些推荐率很高的管理书籍。在飞行过程中，我认为编个工资的新功能应该不会有任何伤害的——毕竟嘛，落地后我有整整3天的时间去专心看书。伙计们，我错了。当我落地后，我对不能彻底写完那项功能感到耿耿于怀。到了3天结束之后，那些书我只看了一点点，我的腾出更多时间专心研究人事管理的目标非常糟糕地失败了。
一天就只有那么多时间，要同时兼顾人事管理（在Gusto，我们称之为“人员赋权”）以及个体贡献者责任是极其困难的。作为编码的爱好者，我自然是倾向于完成后一项任务而把管人方面的事情搁置到后面才做。对我来说，代码问题总是觉得要更紧迫一点。除此以外，我还要跟没有做完自己那部分事情的内疚做斗争。
当我的确抽出时间去做人事管理方面的事情时，我并没有花费同样的时间去做到像写代码一样的质量。因此我的团队也稍微出现了一些动摇，可以说我不放弃编码所带来的伤害要比做出的贡献还要大。
你必须做出的二元对立选择
到了这个时候，我相信技术联合创始人要做出二元选择：要么继续走技术路线，聘请一位专业经理人（通常给一个工程副总裁的头衔）；要么放弃编码自己专注于管理方面的事情。想两全其美真的是不可能的。
我决定专注与壮大Gusto的工程团队，而不是我们的代码。我案头的技术书开始被《Mindset（终身成长：重新定义成功的思维模式）》、《格鲁夫给经理人的第一课》、《 The Score Takes Care of Itself（完美主义者的完美主义）》这类书所取代——直到今天这仍然是我最爱的三本书。《Mindset》对于帮助我在对待个人前途的心态上做好准备非常关键。《格鲁夫给经理人的第一课》帮助我学到了管理团队背后的许多流程。《The Score Takes Care of Itself》教会了我如何超越管理成为一名鼓舞人心的领袖。
对我来说，学习和应用这些经验同时抵制编码的诱惑是一段异常艰难的转变，但对于以健康的方式扩大团队规模来说却是必要的。
51到100名工程师：拥抱新角色
等到我们达到50名左右的工程师时，我开始把60%的时间放在尽量成为直接下属最好的经理上，并且培训团队的其他工程师经理也做到这一点。剩下的40%时间则花在了招聘上。
我在人事管理方面的职责做得越好，我就开始约享受其中。我会花时间在改善工程入门培训、绩效管理、多元化和包容性、文化、变更管理等事情上，并且用流程去管理平衡技术债务之类的大项目。我唯一会去编码的时间是在半年一度的黑客马拉松期间。
热爱我的新角色
并不是现在所做的任何事情我都享受其中。整天开会仍然给人的感觉非常糟糕，跟个别人展开艰难的对话从来都不是有趣的。不管如何，我已经真正向我在公司的新角色敞开了怀抱。比方说，我花了几周的时间去协商一项计划，将我们工资领域更多的代码所有权移交给Denver。其中一些会议相当的漫长和艰难，但作为那项工作的结果，我们现在已经有了一直迅速成长的Denver工程团队，对此我感到极其自豪。
我的愉悦现在更少地来自于我自己所做的事情，而是更多地来自于我帮助他人产生的影响。有时候你只有在一段时间之后才能看到这个，所以你要通过学会从更宽广的时间范围内看待事物来获得满足。
100到250名工程师
接下来会发生什么？下一篇章要求将我们的团队规模进一步扩充，同时还要维持我们在过去的品质水平。这意味着招聘、发展以及挽留人才仍然是我的角色最重要的工作。对我来说，我致力于用一种我们感到自豪的方式去做，通过建立一个多样化的、生机勃勃的、让我们能够做出最好工作的环境来做到这一点。如果说我从一家快速成长的初创企业里学到了什么的话，那就是唯有变化是唯一不变的东西——我也非常兴奋地期待着未来将如何展现。