CTO顾名思义就是技术的总管，听起来似乎就是跟技术打交道为主的了。但是对于一家初创企业来说，公司的不同发展阶段对CTO的角色要求是很不一样的。如果到规模扩大后还想像当初那样把大部分精力放在自己写代码上的话，公司是没办法快速发展的。Gusto联合创始人兼CTO Edward Kim 分享了自己在这方面的感悟，里面有一些非常值得借鉴的最佳实践，不妨参考一下。

我跟两位联合创始人一起创办了Gusto，这个公司的使命是让中小企业的工资、福利和HR工作变得容易一点。我和Tommer、Josh当初是在Palo Alto一所房子的主卧那里成立这家公司的，除了对未来的愿景以及愿意做任何将其变为现实的事情的承诺以外，我们一无所有。

6年后，我们服务的小企业已经超过了60000家（超过美国雇主总量的1%），雇佣了超过600人（包括约100名工程师），我们一起实现了超过10亿美元的估值。

一位工程师的时候：车库，呃，衣帽间里的技术宅

我是CTO，但在公司的那个阶段，这么称呼感觉会很傻，因为其实并没有任何可以称为“首席”的。软件工程师用来描述我的角色更加合适。我尽可能地学习非常烧脑的工资系统以及ACH系统的机制，同时每天用12到14个小时戴着耳机来编程——这种感觉很棒。我的日程上唯一的会议是午饭、晚饭以及去健身馆锻炼。这期间我们的目标？开发一套工资后端系统从而让我们能够通过它来付费。

到10名工程师：一支团队，一个梦想

成为球员兼教练

在此期间，关于Gusto（当时叫做ZenPayroll）发布的消息被封锁了，经过一昼夜通宵达旦的忙活之后，工程团队紧张地监视这服务器日志，不断刷新页面以确保我们的Linode服务器在被TC报道之后还能存活。

到50名工程师：坚持写代码

与此同时，尽管团队规模变大了，但是要发布的功能以及待修改的bug的清单仍然没完没了。最熟悉我们代码库的人可能仍然是我，所以当出现问题或者需要交付一项功能时，我总是忍不住跳出来想自己写和修补bug。这经常是我干的事情。

2015一天就只有那么多时间，要同时兼顾人事管理（在Gusto，我们称之为“人员赋权”）以及个体贡献者责任是极其困难的。作为编码的爱好者，我自然是倾向于完成后一项任务而把管人方面的事情搁置到后面才做。对我来说，代码问题总是觉得要更紧迫一点。除此以外，我还要跟没有做完自己那部分事情的内疚做斗争。

你必须做出的二元对立选择

我决定专注与壮大Gusto的工程团队，而不是我们的代码。我案头的技术书开始被《Mindset（终身成长：重新定义成功的思维模式）》、《格鲁夫给经理人的第一课》、《 The Score Takes Care of Itself（完美主义者的完美主义）》这类书所取代——直到今天这仍然是我最爱的三本书。《Mindset》对于帮助我在对待个人前途的心态上做好准备非常关键。《格鲁夫给经理人的第一课》帮助我学到了管理团队背后的许多流程。《The Score Takes Care of Itself》教会了我如何超越管理成为一名鼓舞人心的领袖。

51等到我们达到50名左右的工程师时，我开始把60%的时间放在尽量成为直接下属最好的经理上，并且培训团队的其他工程师经理也做到这一点。剩下的40%时间则花在了招聘上。

热爱我的新角色

我的愉悦现在更少地来自于我自己所做的事情，而是更多地来自于我帮助他人产生的影响。有时候你只有在一段时间之后才能看到这个，所以你要通过学会从更宽广的时间范围内看待事物来获得满足。

到250名工程师

<span style="font-size:12.0pt;微软雅黑","sans-serif"">接下来会发生什么？下一篇章要求将我们的团队规模进一步扩充，同时还要维持我们在过去的品质水平。这意味着招聘、发展以及挽留人才仍然是我的角色最重要的工作。对我来说，我致力于用一种我们感到自豪的方式去做，通过建立一个多样化的、生机勃勃的、让我们能够做出最好工作的环境来做到这一点。如果说我从一家快速成长的初创企业里学到了什么的话，那就是唯有变化是唯一不变的东西——我也非常兴奋地期待着未来将如何展现。