技术型创始人如何实现角色转型？

技术型创始人如何实现角色转型？

来源 | 宽带资本（bjkazb）
原文 | Gusto

技术出身的创始人可能会面临「技术」与「管理」的博弈。时间精力有限，往往顾此失彼，很难两全。在这场博弈中，如何选择才是对的？

本文来自Gusto的联合创始人兼CTO——Edward Kim。

6年前开始创业，三个合伙人中他是唯一的工程师，几乎100%的时间都在写代码。随着工程师队伍日益庞大，他对代码的沉迷反而成了团队的负累。

本期CBC热读探讨的主题——CTO如何成为好的管理者。以下是Edward的经验分享。

在Gusto，我会定期留出office hours*，工程师有问题的话都可以找我交流。我时常遇到的一个问题是：作为公司的CTO和联合创始人，你经历了怎样的角色转变？

office hours,类似“答疑时间”的这样一个概念，即某人固定时间待在office里，保证你在这段时间的时候能找到他，跟他交流。

单打独斗：车库里的……呃不对，衣帽间的程序猿

创业刚起步的时候，我在旧金山，另两位联合创始人在帕罗奥多，他俩住在一块儿。当时，我们正在创建第一个原型，我觉得大家非常有必要住在一起（我们那时都是单身）。非常可惜，房子的卧室都住满了，只剩下主卧里一个非常大的步入式衣帽间。

我和每一位房客谈妥后，以每月300美元的价格租下了衣帽间，借了朋友的充气床垫，收拾好行李就住了进去。

虽然号称首席技术官，但这个头衔其实很傻，公司一共三个人，谈不上是什么首席。软件工程师更符合我的角色。

我一门心思钻在复杂的薪资管理系统里，学习ACH系统*如何运行，每天编码12-14个小时，全程戴着耳机——这一切甚得我心。我的会面时间只限于午餐、晚餐和健身的时候。这个阶段公司的目标是什么？搭建薪酬管理的后端系统，让公司内部先用起来。

ACH是Automatic Clearing House的缩写，是一个批量处理、存储和转发的电子支付系统，在美国支付体系中占据重要地位。

2-10个工程师：同一支队伍，同一个梦想

薪酬管理基础系统完成上线（当时仅在加州可用），种子轮融资结束，随后我们搬到了旧金山的一处阁楼公寓。

我每天敲代码的时间从90%降到了60%。其余时间都用来搜寻、面试和熟悉工程师。CTO这个角色的工作内容一直在变，但花时间招聘优秀的人是我坚持做的事（也许会一直做下去）。现在，我30%到40%的时间都用在招人。

一面是选手，一面是教练

几位工程师加入以后，我从团队中唯一的全职开发变成了开发小团队的一员。我依然花大量的时间编程、审查代码、修复漏洞，但偶尔会把耳机摘下来，向大家解释ACH的运行原理，或者打个电话，询问大家是否需要开代码评审会。

只要能帮工程师们高效工作，我非常愿意做一些力所能及的事——比方说，购买配置一台计算机运行我们的CI 工作流( pipelines)。我的日程表上悄然出现了新的任务，一对一谈话，迭代策划，还有每日站立会议*。工程师向我汇报，但大多数时候，我们并没有层级之分，感觉轻松自在，像是朋友一起在房间里写代码。

每日站立会议，每天早上举行的短期会议。该活动起源于敏捷开发方法，在Scrum开发中很常见。日常站立会议一般用时五到十五分钟，有时候指代站立的早晨点名或每日例会。

正是在这个阶段，媒体宣布了我们改名Gusto的消息（原来叫ZenPayrol），整个技术团队非常紧张，大家通宵盯着服务器日志，不断刷新网页，确保我们的Linode服务器能够逃过这次“突发科技新闻”的影响。

11-50个工程师：抱紧代码不松手

公司紧锣密鼓地获得了大量客户，并且完成了A轮融资，此时的工程师团队已经扩充到10多人。协调所有工程师的工作变得更加困难。除了新增人员，还要考虑早期入职的工程师，打造一支组织化的工程师团队势在必行。几位在Gusto工作近两年的老员工开始问我，补偿框架怎么做，Gusto内部职业晋升怎么规划。说实话，对于这些问题，我没能给出清晰完整的答复。

在这个阶段，尽管我们拥有了更大的团队，仍需源源不断地发运功能点，修复漏洞。我对公司的代码库非常了解，所以一旦发现问题，或者要发运某个功能点，我就迫不及待想开始干活。大多数情况下，我正是这么做的。

纽约之行

2015年，我意识到自己应该远离编程，花更多的时间学习成为一个好的管理者。为了履行承诺，我决定飞往纽约，在酒店房间里待够三天，读一些大家强推的管理类书籍。在去程航班上，我开始编写一个新的薪酬支付功能点——毕竟，一旦到了纽约，我就有整整三天时间专心阅读。朋友，我这么做没毛病吧？但当我降落时，想把功能点完整做完的念头简直克制不住。三天终于结束了，我只读了一小部分书，为管理事业奉献时间的目标就这么惨败了。

一天的时间有限，员工管理（在Gusto，我们称之为“员工赋权”）和个人贡献很难两全。作为一个编程痴迷者，我当然更愿意完成后者，员工管理屈居第二。对我来说，一切和代码有关的事情总是难以抗拒。如果不能有我自己的成果产出，我会深感内疚，这是最重要的原因。

我确实抽空在学员工管理，但我付出的时间不足以把它做到和我的代码质量一样好。我的团队因此有些不稳定，我不愿放弃写代码，这对团队来说可能是个麻烦。

A还是B，你必须选一个

在这个问题上，我认为技术型的联合创始人有两个选择：留在技术这条路，并雇用一名职业管理人员（职称一般是工程副总裁），或者放弃编程，专注于管理。真的不可能同时把两件事都做好。

我决定集中精力发展Gusto的工程师团队，放弃写代码。我桌上的技术类书籍开始被Mindset（C位君：我们有推荐过哦）、High Output Management和The Score Takes Care of Itself取代——这仍然是我现在最喜欢的三本书。

Mindset帮助我为未来的个人旅程做好思维准备，High Output Management让我学到了团队管理背后的具体流程，The Score Takes Care of Itself教我如何突破管理，做一个具有感染力的领导者。

我经历了一段非常艰难的过渡期，在此期间，我不仅要学习和应用管理学知识，还要抵制代码的诱惑，但为了有效地组织工程师团队，这是必要的。

51-100个工程师：接纳一个全新的我

当我们的工程师人数达到50人左右时，出于对直属下级的负责，我会花60%的时间尽力把管理者的角色做到最好，也培训工程师团队的几位主管这样做。其余40%时间我用于招聘。

我对人员管理的职责了解越深，就越乐在其中。改善工程师入职手续，管理绩效，建构多元化和包容性氛围，树立企业文化，调整管理风格，制定流程以平衡技术债务等大项目，这些都值得花时间好好经营。我唯一的编程机会是在我们的半年度黑客马拉松(hackathon)*。

在黑客马拉松上，参与者需要在几十个小时里开发出一款插件，现场休息，做完当场交作品。参与黑客马拉松的，除了热衷钻研技术的软件工程师，还有来自风投公司的团队。

热爱我的新角色

我现在做的事并非都让人愉快。整天参加会议仍然很糟糕，艰难的商业对话永远不会有趣。但是，我开始发自内心地接纳我在公司的新角色。比如，为了将更多薪酬支付产品的代码所有权转移到丹佛，我花了几周时间和人斡旋商讨。一些会议非常漫长难捱，但功夫不负有心人，我们现在拥有了一支快速发展的丹佛工程师团队，我为此感到非常自豪。

我更享受帮助别人解决问题，而不是为我自己操劳。有时候，你只有在一段时间后才能发现这一点，所以用更长远的视角看待事物，回馈你的是一种满足感 。

100-250个工程师

接下来要怎么走？我们的工程师团队将跟随发展节奏进一步扩大，同时还要保持与过去相当的质量水平。这意味着，招聘、培养和留住人才仍是我最重要的职责。我很自豪能为大家营造一个多样化、充满活力的环境，使我们都能以最佳状态投入工作。如果说有什么经验是我从快速发展的创业公司那里学到的，那就是「变化即常态」——万分期待我们的未来。