一个创业CTO的成长历程

原文：The CTO Journey at a Small Startup
作者： Bryan Helmig
翻译：黑色巧克力

译者注：作者以自身作为创业公司CTO的经历，讲述了随着公司的发展CTO工作内容的变化，以及如何进行转变，并列举了非常有益的四点经验。

随着创业公司的发展，我们需要对以往的工作方式进行调整。在工程学上也需要如此。作为一名联合创始人和首席技术官，我自己的角色多年来改变了很多。日常职责和挑战也已经发生了变化，不得不多次改变自己的做法，以帮助公司达到一个新的高度。

在Zapier的早期，只有三个人在晚上和周末工作，在地下室里加班，那就是Zapier。在我们最终推出之前，我们经历了Zapier的三四个版本。六年后，我们做了上亿个API调用，在全世界有超过80个员工，包括20多名工程师。

我们三个人之间的成长历程和今天的情况是相当不同的。如果你喜欢的话，你可以看下我的线上视频。或者，读一下我过去学到的经验教训，并问一下我第一次当CTO时的同事。

初创公司工程升级树

在我们进一步深入之前，有一个问题，那就是CTO是什么?它就像一个生命中的仁慈独裁者，它是软件社区里监视代码的吗？它是某种超级管理者还是超级黑客？

向很多人征求意见，联系了Buffer、Unbounce和其他一些比我们大一些的初创公司的CTO，最终得到了一个答案：没有人真正知道。这是一个模糊的角色，不适合在做规范的定义。但当我与人交谈时，确实发现了一些常见的模式，以便了解一个小型、以技术为中心的初创公司该如何成长，以及CTO在每个阶段需要做什么。

因为我是一个书呆子，喜欢玩电子游戏，所以对我来说，这像是一种升级树。当你在游戏中获得更多的经验时，你会升级，在某些时候你可以选择不同的升级分支。

下面是初创公司CTO升级树的方式。

独奏团队(1-2工程师)

这正是我们在地下室工作的时候的情景。这是一段非常有趣而且非常快的时间。你建造了很多东西，并且很快迭代，没有沟通或管理的开销，因为你们都是同步的。你只是想弄清楚如何进行下一步工作。

小团队(2-6工程师)

作为一个创业者，你想要拓展团队，所以你开始雇佣员工。这通常是你雇佣朋友的时候。有些人说不要雇佣你的朋友，但我认为在早期阶段这是很好的。你知道自己可以和他们一起工作，并且适合这个职位。这时候你仍然感觉很好，因为你只有几个工程师。通信开销很小，你仍然可以保持同步。

成长团队(6-12名工程师)

这个时候就有点奇怪了。你不再经常与团队中的每一个人交谈。你必须开始做一件可怕的事情，它叫做管理，对我来说是完全不同的东西，不像编码那样自然。这就是通信开销在你编写代码的时候发生的地方。你可能在想办法雇佣那些不是你朋友的人。这很棘手，因为你不知道的事情正在发生。在这个阶段，事情会很快发生变化，你会在升级树上面对你的第一个分支。

组织团队(12名工程师)

有了这样规模的团队，你可能在不同的领域工作。你不能在人员和代码管理方面都做得很好，因此到了你做出选择的时候。

副总裁:关注管理

CTO:关注编码和架构

副总裁通常是一个人，他把过程放在适当的地方，利用工具使团队更有效率，帮助工程师们完成工作。或者，你可以继续担任CTO，并维护你的程序员角色。CTO是一个熟悉系统的人，他知道所有的骷髅在壁橱里的哪个位置。

你还应该是CTO吗?

我并没有为这个决定做好准备。我甚至不知道必须在两者之间做出选择。我只是觉得CTO会是事实上的经理。这似乎是我所谈过的超过一半的创业公司的案例。无论你走的是经理还是程序员路线，你都要找一个会做相反的事情的人。

要做出这个决定，最好回想一下你从哪里来。你的时间花在哪里，你有多自信，你想重新审视哪个阶段?

在早期，它是一两个工程师。你把时间都花在编码上了。感觉很好，一切都太好了。无论何时，当你得到6个人的小团队时，感觉仍然很好。你花了80%的时间编写代码，大约20%的时间在交流。你仍然感觉很好。你对这个有百分之九十的信心。

然后当它变得有点不一样的时候，工作那就变得更加困难了。当你得到越来越多的人的时候，你花费的编码时间还不到50%。有越来越多的人来帮助你，但感觉却不太好，因为在保持编码计划的同时还要努力去管理。这就是你必须决定去做经理还是程序员的时候。那么，你该如何规划那棵树呢？

“你真的需要弄清楚你的荷尔蒙是怎么来的？”

我从另一位创始人那里得到了这个的建议。当你帮助别人做一些他们苦苦挣扎的事情时，你会感觉很好吗?或者当你解决一些技术问题时，你会内心振奋吗？这些问题应该会给你一些指导。

创业公司CTO的四点经验

当我决定在哪里集中注意力时，我采访了大约15名创始人和首席技术官。我问他们每一个人在旅途中所遇到的困难。在这些对话中，有四个方面不断被提到。

1. 拥抱断裂点

我问他们每个人犯过最大的错误——他们经历过最艰难的事情，以及他们是如何解决的。如何预防？他们说到，“你知道，我可能并不会预测。只有在经历这个阶段才能真正明白我们想要做什么。我不得不通过学习相反的一面来学习正确的一面。”

用CTO的技术术语来说，就是把这个断点当作扩展服务。遇到瓶颈，然后解决它，接着再次遭遇瓶颈。这比预测它们要有效得多，因为预测是非常困难的，特别是在一些类似创业的事情上。

2. 无人之地

这是我为6到12名工程师的阶段取的名字。所有的事情都在进行，并且有点让人困惑。你会发现自己在说“为什么这个人不知道这个？难道他们不知道自己该做些什么吗？”这类问题暗示着你在这个领域，在不需要一个人来填补另一边的空缺的情况下，你很难从一个方面走到另一个要么是程序员，要么是经理的方向。你没有足够的能力来保证扮演两个不同的角色，但是你也没有弱到可以忽略其中之一，你有点进退两难。

沟通是解决这个阶段问题的桥梁。当你发现自己在说“为什么xyz这么做?”你需要开始过度沟通。说一遍又一遍，几乎是所有人听到你再说一遍的时候，他们会转着眼睛说:“哦，他又来了。”但这很重要，因为每个人需要意见一致。

3. 模仿结构

我经常听到一些CTO说:“我们看到Spotify这么做”或者“我们看到亚马逊这么做”。然后他们会模仿。作为一家科技公司，如果你在创新，你不应该在管理上创新。你不应该在如何组织你的公司方面进行创新。你应该用你的技术，你的代码和你的产品来创新。

挑出你认为有趣的事情，并在你的团队中进行尝试。通过很多其他人不曾真正拥有的想法和方法来组织你的团队，随着时间的推移，你的公司将变得独一无二。你真正需要试着去做是捡起别人正在做的事情，并为自己省去麻烦。

4. 集中起来

当我们开始招聘工程师时，我们认为更多的人意味着可以做更多的事情。在早期，创始人和第一批员工在工作时，我们认为每个人做两三个项目是正常的。4个工程师，每次8到12个项目，对吧?不，那是个坏主意。

更多的项目意味着更多的沟通。它会变得越来越难追踪到底发生了什么，并且让每个人意见一致。回想起来，当我们加入更多的队友时，正确的解决方案是在工作量方面保持稳定，或者甚至稍微减少一点。

我们这样做的方式是挑选一个我们都关注的大项目，让每个人都知道它是我们的头等大事。而那些次要的事情则是第二目标。

我希望我自己的旅程对那些试图在早期创业，特别是作为一个技术创始人的人来说，有一点帮助。无论如何，有困惑很正常，可以推迟一些决定，并在你走的时候把它弄清楚。在不同的阶段，需要不同的东西。