程序员如何用六年时间打造价值10亿的帝国？
之前，我和两位联合创始人一起创立了 Gusto 公司，旨在为小型企业提供工资和福利结算，以及人力资源。 Tomer、Josh 和我在 Palo Alto 的一座房子的主卧室里成立了这家公司，当时我们什么都没有，只有对未来的憧憬和尽一切努力将其变为现实的决心。
六年后，我们服务的客户达到了 6 万多家小型企业（超过了美国所有雇主的1%），员工超过了 600 名（包括约 100 名工程师），我们齐心协力达成了超过十亿美元的估值。
办公时间我一般都会在 Gusto，工程师可以随时过来问我问题。有时他们会问我：作为这个公司的 CTO 和联合创始人，你的职责都有哪些变化？
1名工程师：待在车库或壁橱里的书呆子
公司刚刚成立的时候，我住在旧金山，而另外两个联合创始人住在 Palo Alto 的一所房子里。我觉得在建立第一个原型期间我们住在一起很重要（当时我们都是单身）。不幸的是，没有多余的卧室供我居住，但是主卧里有一个非常大的步入式衣柜。我说服了房子里所有的租户，他们答应我每个月支付 300 美元租用那个衣柜，我跟一个朋友借了充气床垫，收拾好行李，搬进了衣柜。
我是公司的 CTO，但是对于一个刚起步的公司来说，这么说很傻，因为公司里压根没人可以“领导”。软件工程师更适合当时我的职责。我尽可能地学习复杂的工资管理系统和自动清算中心系统，同时每天戴着耳机写 12-14 个小时的代码——那种感觉非常好。我日历上唯一的会议是午餐和晚餐休息，以及去健身房锻炼。这个期间我们的目标是：建立工资管理后台系统，以供我们做自己的工资结算。
2-10 名工程师：一个团队，一个梦想
在基本的工资管理（仅限加利福尼亚州）可以运行，并拿到种子资金后，我们搬到了旧金山的阁楼公寓，我 90% 的编程时间缩减到了 60%。其余时间我需要寻找、面试并聘用工程师。作为一个 CTO，我的很多职责后来都发生了变化，但是只有招聘花费的时间却始终如一（可能要永远如此了）。从那以后，我总是需要 30-40% 的时间来做招聘工作。
兼职编程和教练
在我们聘用了一些工程师后，我从全职开发人员变成了负责一个小型开发团队。我仍然会花大量的时间编程、审核代码和改 bug，但偶尔我会摘下耳机向团队解释自动清算中心的工作原理，或者决定我们是否应该开始审核代码。如果有我力所能及且可以节约其他工程师时间的活儿（例如购买和配置计算机来运行我们的 CI 管线），我就会包揽下来。我的日历上开始出现：一对一、 Sprint 计划和每日例会。有些工程师需要向我汇报，但大多数情况下，由于公司没有等级制度，所以感觉像一群同伴在一个房间里一起编程。
在此期间，我们解除了媒体发布有关 Gusto（之后的 ZenPayroll）消息的禁令。在经历了一个通宵之后，工程团队紧张地监视着服务器日志，以确保我们的 Linode 服务器能够在“Techcrunch”的评论中活下来。
11-50 名工程师：紧紧围绕编程
在公司快速获得客户并通过了 A 轮融资之后，我的工程师团队已经壮大到 10 多人。协调所有这些工程师的工作变得更加困难。除了规模，一些早期的工程师的任期迫使我不得不将工程团队组织得更有条理。例如，一些在 Gusto 工作了近两年的工程师开始询问福利制度，以及 Gusto 内部的职业发展情况。坦白来说，我还没有认真考虑过这些问题。
与此同时，尽管团队更大了，但是我们仍然有无休无止的功能列表需要实现，以及 bug 需要修改。我可能是对我们的代码库了解最深的人，所以当出现问题或需要发布一个功能时，我按耐不住想介入编程或改 bug。而且通常，我确实这么干了。
纽约之旅
2015 年，我知道自己需要远离编程，并花更多时间成为一名优秀的人事经理。为了做到这一点，我决定飞往纽约，在酒店里住三天，阅读一些大家极力推荐的管理书籍。在飞机上，我觉得写一段代码实现一个新的工资管理功能应该没啥问题，毕竟飞机着陆后我有足足三天的时间可以专心读书。天啊，我大错特错了。飞机降落以后，我无法抑制内心对做完整个功能的渴望。结果，三天结束以后，我只读了一点点书，花时间学习人员管理的目标彻底失败了。
每天只有那么几个小时，兼顾人事管理（在 Gusto，我们称之为“人事助理”）和贡献代码非常困难。作为一个编程爱好者，我自然倾向于先完成功能，晚一点再做人事管理的工作。对我而言，代码问题总是让人感觉更加紧迫。最重要的是，我因为没有尽到自己的责任而深感内疚。
当我做人事管理的时候，我并没有花太多时间来完成与我的代码同等质量的工作。我的团队因此而人心浮动，不放弃编程似乎对团队的影响弊可能大于利。
你必须二选一
在这一点上，我认为技术联合创始人必须二选一：继续做技术并聘请一个专业的经理（通常以工程副总裁的头衔继续做技术），或者放弃编程，专心做管理。兼顾两者基本不可能。
我决定专心抓好 Gusto 工程团队，而不是代码。我桌子上的技术书籍换成了《思维模式》（Mindset）、《格鲁夫给经理人的第一课》（High Output Management）和《The Score Takes Care of Itself 》，这三本书至今是我的最爱。《思维模式》对于帮助我为自己的发展做好心理准备至关重要。《格鲁夫给经理人的第一课》帮助我学习了管理团队的许多过程。《The Score Takes Care of Itself 》教会我如何超越管理，成为一个鼓舞人心的领导。
学习和应用这些知识，同时抵制代码的诱惑，对我来说是一个非常艰难的过渡，但这对于以健康的方式发展工程团队是必要的。
51-100 名工程师：拥抱新的职责
当工程团队发展至 50 人时，我花了 60% 的时间努力成为最好的经理（那些向我直接汇报的人的经理），还负责培训团队中的其他工程经理。剩下 40% 的时间我负责招聘。
随着对人员管理职责的了解越来越多，我也越来越喜欢这个工作。我会把时间花在注入改善工程师入职、管理绩效、多元化和包容性、文化、变革管理以及为大项目指定流程（平衡技术债务等）等。只有半年一次的编程马拉松期间我才会写代码。
爱我的新职责
我现在所做的一切也不全是非常愉悦。整天开会让人很烦，与个人进行艰难的对话永远也不会有趣。然而，我真的开始接受我在公司里的新职责。例如，我花了数周的时间来协商计划，以便将工资管理模块的代码所有权转移到丹佛。其中一些会议漫长又艰难，但由于这些工作，现在我们拥有发展迅速的丹佛工程团队，我为此感到非常自豪。
现在，对于自己做的事情，我能得到的享受很少，我更加享受帮助他人时产生的影响。有时只有经过一段时间才能看到这种成果，所以你可以在更广阔的时间范围内看待事物，从而可以获得满足感。
100-250 名工程师
接下来会发生什么？下一步将要求我们的工程团队进一步发展，同时保持与过去相同的质量水平。这意味着招聘、培养和留住人才仍将是我职责中最重要的部分。我正在致力于通过一个让我们感到自豪的方式来做到这一点，那就是：建立一个多样化和充满活力的工作环境，我们可以在这个环境里把工作做到最好。如果说我从迅速崛起的创业公司中学到了一件事情的话，那便是：变化是唯一的常态，我对未来充满了期待。
之前，我和两位联合创始人一起创立了 Gusto 公司，旨在为小型企业提供工资和福利结算，以及人力资源。 Tomer、Josh 和我在 Palo Alto 的一座房子的主卧室里成立了这家公司，当时我们什么都没有，只有对未来的憧憬和尽一切努力将其变为现实的决心。
六年后，我们服务的客户达到了 6 万多家小型企业（超过了美国所有雇主的1%），员工超过了 600 名（包括约 100 名工程师），我们齐心协力达成了超过十亿美元的估值。
办公时间我一般都会在 Gusto，工程师可以随时过来问我问题。有时他们会问我：作为这个公司的 CTO 和联合创始人，你的职责都有哪些变化？
1名工程师：待在车库或壁橱里的书呆子
公司刚刚成立的时候，我住在旧金山，而另外两个联合创始人住在 Palo Alto 的一所房子里。我觉得在建立第一个原型期间我们住在一起很重要（当时我们都是单身）。不幸的是，没有多余的卧室供我居住，但是主卧里有一个非常大的步入式衣柜。我说服了房子里所有的租户，他们答应我每个月支付 300 美元租用那个衣柜，我跟一个朋友借了充气床垫，收拾好行李，搬进了衣柜。
我是公司的 CTO，但是对于一个刚起步的公司来说，这么说很傻，因为公司里压根没人可以“领导”。软件工程师更适合当时我的职责。我尽可能地学习复杂的工资管理系统和自动清算中心系统，同时每天戴着耳机写 12-14 个小时的代码——那种感觉非常好。我日历上唯一的会议是午餐和晚餐休息，以及去健身房锻炼。这个期间我们的目标是：建立工资管理后台系统，以供我们做自己的工资结算。
2-10 名工程师：一个团队，一个梦想
在基本的工资管理（仅限加利福尼亚州）可以运行，并拿到种子资金后，我们搬到了旧金山的阁楼公寓，我 90% 的编程时间缩减到了 60%。其余时间我需要寻找、面试并聘用工程师。作为一个 CTO，我的很多职责后来都发生了变化，但是只有招聘花费的时间却始终如一（可能要永远如此了）。从那以后，我总是需要 30-40% 的时间来做招聘工作。
兼职编程和教练
在我们聘用了一些工程师后，我从全职开发人员变成了负责一个小型开发团队。我仍然会花大量的时间编程、审核代码和改 bug，但偶尔我会摘下耳机向团队解释自动清算中心的工作原理，或者决定我们是否应该开始审核代码。如果有我力所能及且可以节约其他工程师时间的活儿（例如购买和配置计算机来运行我们的 CI 管线），我就会包揽下来。我的日历上开始出现：一对一、 Sprint 计划和每日例会。有些工程师需要向我汇报，但大多数情况下，由于公司没有等级制度，所以感觉像一群同伴在一个房间里一起编程。
在此期间，我们解除了媒体发布有关 Gusto（之后的 ZenPayroll）消息的禁令。在经历了一个通宵之后，工程团队紧张地监视着服务器日志，以确保我们的 Linode 服务器能够在“Techcrunch”的评论中活下来。
11-50 名工程师：紧紧围绕编程
在公司快速获得客户并通过了 A 轮融资之后，我的工程师团队已经壮大到 10 多人。协调所有这些工程师的工作变得更加困难。除了规模，一些早期的工程师的任期迫使我不得不将工程团队组织得更有条理。例如，一些在 Gusto 工作了近两年的工程师开始询问福利制度，以及 Gusto 内部的职业发展情况。坦白来说，我还没有认真考虑过这些问题。
与此同时，尽管团队更大了，但是我们仍然有无休无止的功能列表需要实现，以及 bug 需要修改。我可能是对我们的代码库了解最深的人，所以当出现问题或需要发布一个功能时，我按耐不住想介入编程或改 bug。而且通常，我确实这么干了。
纽约之旅
2015 年，我知道自己需要远离编程，并花更多时间成为一名优秀的人事经理。为了做到这一点，我决定飞往纽约，在酒店里住三天，阅读一些大家极力推荐的管理书籍。在飞机上，我觉得写一段代码实现一个新的工资管理功能应该没啥问题，毕竟飞机着陆后我有足足三天的时间可以专心读书。天啊，我大错特错了。飞机降落以后，我无法抑制内心对做完整个功能的渴望。结果，三天结束以后，我只读了一点点书，花时间学习人员管理的目标彻底失败了。
每天只有那么几个小时，兼顾人事管理（在 Gusto，我们称之为“人事助理”）和贡献代码非常困难。作为一个编程爱好者，我自然倾向于先完成功能，晚一点再做人事管理的工作。对我而言，代码问题总是让人感觉更加紧迫。最重要的是，我因为没有尽到自己的责任而深感内疚。
当我做人事管理的时候，我并没有花太多时间来完成与我的代码同等质量的工作。我的团队因此而人心浮动，不放弃编程似乎对团队的影响弊可能大于利。
你必须二选一
在这一点上，我认为技术联合创始人必须二选一：继续做技术并聘请一个专业的经理（通常以工程副总裁的头衔继续做技术），或者放弃编程，专心做管理。兼顾两者基本不可能。
我决定专心抓好 Gusto 工程团队，而不是代码。我桌子上的技术书籍换成了《思维模式》（Mindset）、《格鲁夫给经理人的第一课》（High Output Management）和《The Score Takes Care of Itself 》，这三本书至今是我的最爱。《思维模式》对于帮助我为自己的发展做好心理准备至关重要。《格鲁夫给经理人的第一课》帮助我学习了管理团队的许多过程。《The Score Takes Care of Itself 》教会我如何超越管理，成为一个鼓舞人心的领导。
学习和应用这些知识，同时抵制代码的诱惑，对我来说是一个非常艰难的过渡，但这对于以健康的方式发展工程团队是必要的。
51-100 名工程师：拥抱新的职责
当工程团队发展至 50 人时，我花了 60% 的时间努力成为最好的经理（那些向我直接汇报的人的经理），还负责培训团队中的其他工程经理。剩下 40% 的时间我负责招聘。
随着对人员管理职责的了解越来越多，我也越来越喜欢这个工作。我会把时间花在注入改善工程师入职、管理绩效、多元化和包容性、文化、变革管理以及为大项目指定流程（平衡技术债务等）等。只有半年一次的编程马拉松期间我才会写代码。
爱我的新职责
我现在所做的一切也不全是非常愉悦。整天开会让人很烦，与个人进行艰难的对话永远也不会有趣。然而，我真的开始接受我在公司里的新职责。例如，我花了数周的时间来协商计划，以便将工资管理模块的代码所有权转移到丹佛。其中一些会议漫长又艰难，但由于这些工作，现在我们拥有发展迅速的丹佛工程团队，我为此感到非常自豪。
现在，对于自己做的事情，我能得到的享受很少，我更加享受帮助他人时产生的影响。有时只有经过一段时间才能看到这种成果，所以你可以在更广阔的时间范围内看待事物，从而可以获得满足感。
100-250 名工程师
接下来会发生什么？下一步将要求我们的工程团队进一步发展，同时保持与过去相同的质量水平。这意味着招聘、培养和留住人才仍将是我职责中最重要的部分。我正在致力于通过一个让我们感到自豪的方式来做到这一点，那就是：建立一个多样化和充满活力的工作环境，我们可以在这个环境里把工作做到最好。如果说我从迅速崛起的创业公司中学到了一件事情的话，那便是：变化是唯一的常态，我对未来充满了期待。
来自：CSDN（微信号：CSDNnews），作者：Edward Kim，Gusto Engineering的CTO。译者：弯月，责编：屠敏，原文链接
本文为 @ 21CTO 创作并授权 21CTO 发布，未经许可，请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。
评论
