从Google工程师到创业CTO，他的8项理念也许可以帮到你

雷锋网 • 8年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

雷锋网 (搜索“雷锋网”公众号关注) 按 ：本文作者Lan Langworth，翻译周萌萌 Betty，首发公号”董老师在硅谷“。

Lan Langworth是前Google软件工程师、O'Reily作者，现在他是Artillery的co-founder/CTO，致力于把游戏机质量的游戏带进网页浏览器。下文是他从Google离职到创业的心路历程。

不久以前，我还是一名筹划着自己第一家公司的软件工程师。显然，有许多需要考虑的地方，但是最让我兴奋的是那些「未知的未知」——我知道会出现、但不可预知的挑战。虽然有一群可靠的商业伙伴和我这个技术宅一起工作，但是我深知从第一行命令开始，要建立一家成功的公司还要付出很多。正如你想象的，有许多我没有预计的东西都发生了。所以，我写了下面这些「未知」，献给那些憧憬着去创业公司当co-founder的工程师们。

1、方向和信念

2006年当Google给我offer的时候，我开心地接受了。那个时候，Google几乎是一名软件工程师工作的最好选择，意味着你可以和世界上最聪明的一群人一起工作，还可以随意使用世界上最先进的工具。

然而，它好坏参半。一方面，我真心相信在Google这样的公司你距离参与创造奇迹近了一步，心安理得地享受Google提供的优厚待遇。Google提供的基础要求，如季度目标，使命，核心价值观，代码规范等能为你创立公司提供帮助。

另一方面，在Google，很难保持冲劲和创造力。离开Google、加入Redbeacom是我做过的最好的决定之一。我是他们的第一位雇佣的全职工程师，并帮助建立了整支队伍，还为产品开发制定了排期。这些都是在Google做不到的，因为在大公司，软件工程师很容易被隔离在业务线外，你唯一的责任就是输出优质的代码。但是，如果你以第五个人的身份进入一家公司，你会看见整个公司正在运转的所有事情，你也在业务的前线，有机会参与重大决策。任何相当技术Leader的人都应该加入一家早期的公司获得这种体验。

今天，作为Artillery的CTO和co-founder，我的生活一半是巨大的自由，一半是巨大的责任。Artillery正在努力创造一项发明（让浏览器编程高质量的游戏机）。这是我作为工程师的冲动，可以任意地按我们的路线创造。同时，我们都知道，如果我们的技术可行，很快就会面对更多的用户，同时承受随之而来的更大的压力和期待。

在某些时候，你得相信自己做的是正确的事情。 将「我想我们可以这样做」换成「这就是注定要发生的」这种心理暗示并不容易，但这就是让我进步的原因 。有人认为这是信心，我不这样认为，我想它更关乎一种信念。

2、沟通的失败

在加入Artillery的头几个月，其他的founders和我都已经数次激怒了对方。我开始想在这样一支小的队伍，相对于在Google沟通应该不在话下。但是我错了。

三位co-founders的沟通很混乱，一个人说给另一个人，第二个人又传话给第三个人。作为一名软件工程师，如果你在一支全是工程师的队伍，沟通是相对容易的。当这支队伍混入了其他职位的人，且多于10个，沟通会变得有点棘手。相信我，沟通会比你想象的难，但是必须好好地掌握。

所以我们准备花更多的时间一起筹划，花一个小时的时间坐在房间，清楚地写出来当下在进行的事情。第一次这样做的时候，在不到60分钟的时候，我们就解决了能想出来的大部分问题，这些问题大部分都是由于沟通失误造成的误解（!）。从此每周， 我们都会开一次这样的founder's meeting。同时，我们会把决定都记在一个常用的Google文档，方便随时查阅 。从此我们再也没有出现过严重的分歧。

但是，仅仅增加沟通的量是不够的，更重要的是要更好地沟通。当我们刚开始例会的时候，我们经常陷入无休止的浪费时间的争论中。过了30分钟后，我们才意识到方才是在用各自不同的话语表达同一个观点。一个简单的短语，比如「需要一项政策」，可以意味着一本10页的手册，也可以是一句话的规则。所以现在，在我们开始反驳的时候，我们会先花时间确保理解我们的出发点是什么。这样会提高沟通效率，节约时间。

我们制定了这类会议中的三个原则：首先，会议是私人性质的，所以我们会给与彼此最坦诚的反馈，这就让我们把自我关在了门外，可以开诚布公地讨论。这会导致我们中的某人说：「哦，我不认为它会这样。」建设性的批判对话让我们更好地完善自我。

其次，e-mail的问题。通过e-mail很难传递情绪，很容易成为误解的发源地。误解一封e-mail，变得心烦，甚至影响表现——实在太容易了。同样的话语，如果是面对面的对话就会有完全不一样的效果。

我有一个简单的小技巧可以在e-mail中传递情绪： 当我怀疑我发出的某条信息可能会有歧义，我会加一个表情，比如[mood: agreeable]，从而确保传达出我乐意的态度 。如果你也这样做，你会发现它非常有效，可以让所有人保持冷静的情绪，避免争端。

3、建立「程序员乌托邦」并不容易

开始组建团队的时候，我们会说很多在Artillery工作的美好愿景，包括各种各样的福利待遇。我们希望用有趣又有意义的工作来吸引最优秀的人才。

于是我们在网站上挂了很多福利：免费午餐、完善的医疗保险、交通报销、无限的假期、workstation预算、从东京买来的游戏原型手办……然而，列出这些福利简单，将它们落实，建立一个「程序员乌托邦」却是困难的。

开始，我以为无期限的假期是一个好主意。毕竟，它是Netflix（美国顾客满意度最高的公司）著名的文化甲板，在他那里很奏效。然而，在我这儿，似乎却给员工带来了更多的压力，优秀的员工害怕他们休假太多而不敢提出请求。最后，我们决定还是采取固定期限的带薪休假模式——既能缓解员工焦虑，又能足量地满足员工的度假需求。

在有新员工提出各种奇怪需求前，自主选择编程装备是一个好主意。但是，谁知道20美元的Razer Goliathus鼠标垫值不值？有员工提出用他们自己的笔记本工作，把它们的预算花在昂贵的外设上。还有员工想要高昂维护费用的组装系统。至此，我终于确定每个人都应该用Mac OS X——因为它足够干净、简单。

4、「福利」可能并没有什么用

要解决问题首先要理解福利的实质是什么 。比如说买设备，它的目的不是无限制地满足员工的每一个细微的需求，而是为他们提供良好的工作环境，确保没有人还在使用老旧、迟缓的电脑。让每个人理解政策、福利背后的逻辑，可以帮助他们做出更好、更谨慎的决策。

福利一旦实施，就很难轻松收回。可能除了你自己，并没有别人理解福利的目的。那些员工看似在浪费你的好意，其实并没有恶意。你得提醒他们理解这个福利的机制。

5、离开舒适区

我知道CTO的职位意味着更多的责任，却不代表冗长的会议和官僚主义。除了技术，CTO还要承担更多的管理职能：雇佣合适的员工，解雇不合适的员工，持续地创造和输出idea，带着目标团结队伍。

当我们筹集资金的时候，我第一次遇到这些挑战。和投资者周旋对一位软件工程师来说真是一件苦差事，如果你也习惯了坐在自己的工位，仅通过GChat彼此交流。突然之间，我得穿上没有洞的衬衫参加各种大型会议，并试图说服在场的人我们能实现不可能的事。

对于工程师来说，承诺一周以后的deadline已经很难了。投资人却会challenge你承诺今后1~2年的事情，并会在每一个节点问你问题。「真的吗？」他们中的有人说，「你要做一个AAA游戏？你怎么把2G的内容放进浏览器？你怎么让它有趣？」

幸运的是，多年的软件工程师生涯赋予了我一项珍贵的技能：直觉。我毫不怀疑我们在做的事情是可行的。一旦我自己深信不疑，让其他人相信也就轻松多了。

就像说服投资人，团结新的队伍也是一项挑战。多个月之前，我们决定做游戏，虽然不知道它会成为什么样子，但是开始做是第一步。一位合作的艺术家给我发来了一张游戏的图片，是一片郁郁葱葱的草地。我把它做成了36"X24”的大海报，挂在墙上。从此，无论谁问我他们接下来要干嘛，我都会指着这张图说：「只要能让我们离这里更进一步。」这是自我驱动型工程师需要听到的话。 我们有一个清晰的目标，就踏踏实实地挂在墙上，我们要做的就是努力实现它。

6、选择正确的技术

Web开发是一个有创造力的快速发展的世界。各种各样的新idea和工具层出不穷，似乎换一个新框架或代码就能解决你所有的问题。但是 作为CTO你要记住，挑选怎样的技术相当于你花了一笔真金白银，一旦你做了决定，很可能你就没有时间和资源再走回头路了 。

在Artillery，我们清楚我们会写很多JavaScript，即使大家都懂，JavaScript有各种让你不爽的地方。我们之前有使用过CoffeeScript，它运作得不错，我们也喜欢它的作者做的大部分决定，所以我们最终选择了它。然而最关键的原因是，我们并不会被困死在CoffeeScript上。如果哪天我们想丢弃它，我们可以将轻量级的CoffeeScript全部编译成JavaScript，并从那里继续前进。这么做合情合理，而且成本也很低。

服务器端的决定就没有那么容易。Node.js显然是我们的首选，它可以轻松分享客户端和服务器端的代码。然而，那个时候Node.js还很年轻，而且它的生态圈也不成熟。当时很难评估Node.js的第三方库的质量和安全性，有很多相似功能、但又在开发的不同阶段的库。

这让我们停下来思考了一下。但是经过更多的研究，一件事情提醒了我们：Node.js的更新速度很快。Node.js基于的V8，已经被证明在Google Chrome上跑得又快又干净。如果只有一家公司拥有最多值得信任的聪明人在致力于语言，那就是Google。依靠这个框架似乎是一个安全的选择。Node.js的代码新版本是一致的，而且强大的 Github 社区又提供了频繁代码更新的便利。在仔细的审议后，我们决定用Node.js，现在很庆幸我们做了这个决定。