醉创业
首发于醉创业
专题 | Greg Brockman:如何找到公司CTO的角色定位

专题 | Greg Brockman:如何找到公司CTO的角色定位

导语:

「打造公司文化」这个小专题来到了第三篇,这次我们来看看Stripe。

Stripe是一家近几年崛起超快的创业公司,他们专注于帮助商户和企业迅速搭建支付的通道和平台,让支付这件事变得简单。在他们背后你可以看到硅谷一系列最有名的企业家和投资人:YC, Peter Thiel, a16z, Elon Musk,Aaron Levie...

Stripe 由于是面向企业的服务,可能不太被大家所熟知。但他们也是一家发展十分迅猛且文化打理得非常好的公司。如果你想更多地了解他们,可以看看另一篇讲述 Stripe 设计文化的文章,36kr的翻译在此:Benjamin De Cock:在 Stripe 做设计的感觉是怎样的?。另外,Stripe的创始人Collison兄弟也在YC的Startup Class上讲了讲「如何招聘早期员工」。

之前关于公司文化的讨论更偏向于宏观层面,这篇文章的迷人之处在于,它从个体视角出发带着读者体会了一个公司的具体角色是如何影响公司文化以及被公司文化所影响的。在这个过程中,你可以看到一个公司在增长时所遇到的问题、困惑与感悟。

假期在重读 Ben Horowitz 的那本 The Hard Thing About Hard Things. 实在是手不释卷。书里面你也可以看到像这篇文章里所提到的一些公司必须面临的坑:雇佣一个高级职位、人数增长后的管理成本,当你不知道自己在干什么又要负责很多事情的时候怎么办...

哦,透露一下。本次文化专题的收尾文章就来自 Ben Horowitz 的这本书。写得非常好,大家敬请期待。


Figuring out the CTO role at Stripe

作者:Greg Brockman

翻译:爱小逗逗的@Fish、爱读书的@张文凭

原文链接:#define CTO

2010年我作为工程师加入Stripe。我最初的工作是处理后台的基础设施:设计服务器架构,建立信用卡保险库以及创建内部的抽象概念来让大家的工作变得更轻松。我那时热爱编程,但是我花了很多时间做其他事情:设计招聘流程,塑造公司文化,或设计我们的第一件文化衫(在我们招到第一个设计师后就被弃用了...)。我不是热爱这些胜过写代码:相反,我对公司有着强烈的愿景,并且希望能尽一切努力使其成为可能。

随着时间的推移,我承担了越来越多的非编程类工作。正如 Nelson Elhage 常讲的,我的工作变成了全职的「早期员工」。我的日程被编写公司文化指南,帮助新同事适应,启动招募项目等工作所排满。我常常想是时候放弃写代码了,但不知为何我总能找到办法回到写代码的工作中。

大概一年半以前,公司正式宣布我为CTO。这不过是给我正在做的事请一个名头——大家的反应大多是「等等,我以为Greg早就是CTO了」。职位公布后需要做的事情是:找个合伙人来建立我们的工程师团队,以及弄清楚公司变化后我的角色。

招募一个工程副总裁

大约去年夏天,为了满足工程师团队的需求,我开始和每个人进行一对一沟通。我把这事堆在周二,那天结束时我彻底精疲力尽。等我恢复精力时,已经是下周二了,又是时候重新再来一遍。

那段时间,我知道我面临一个选择:技术路线或管理路线。我从未找到比编程更热爱的事情,但是同时我知道,作为一个组织我们有责任去支持那些我们招聘到的牛人。我曾和一个在其他公司做CTO的朋友聊天,他告诉我招聘一个工程副总裁对他来说是件意义多么重大的事。我之前倒是听说过工程副总裁,但是我从未真正考虑去主动招一个。所以我下定决心一定要找到一位工程副总裁,并说服我们的CEO及其他内部人员这是一个很棒的主意。

在公司内部,没有人想要这个职位。我们最初招募的都是优秀的个人奉献者(individual contributors),一个像我这样希望自身有所建树的人。相应地我们不曾招聘过真正想去管理整个团队的人。所以很明显我们只能从外部招聘。

在过去一年半,我与很多职业经理人会面并向他们寻求意见。只有很少的几个人能真正给我留下印象,如果他们能就职,我马上就可以雇佣他们。但是时机总不对,所以我准备投向猎头公司。

在那段时间,刚巧有位管理者 Marc Hedlund 是有机会加入的。我和团队里的每个人都大概谈了关于招募一个工程副总裁的想法,特别聊到了这位候选人,然后团队的25个工程师坐在一起讨论。我们不知道这个职位具体要做什么,但我们清楚有一件工作是必需的:大量的一对一沟通(现在主要是和工程师沟通,当我们规模扩大后主要和管理者沟通)。所以我们发现最好的办法是关注这个候选者是否擅长一对一沟通,然后等他到职后再一起制定其他工作职责。

之后我们约了Marc面试,四天内紧凑地安排了和团队里的每个人一对一面试或一对二面试,从早上10点到下午6点,还包括和整个公司的沟通。我问他这些紧凑又累人的面试他是否还受得了:这似乎是一个需要超人耐力的事情。但是他请我放心,这完全没问题。很确定,他十分优秀。

我也和很多之前和他共事过的人沟通过,一些是来自Marc给我的名单,一些是其他途径得到的。在这些反馈中有一个很明确的基调:「他对我有很大的影响,是位很好的导师」,「我们仍保持联系」,「我希望再次与他共事」。我很想跟有着这样评价的人一起工作。

最后,同样重要的是知道私下里Marc和我共事会如何。我们两人有责任让工程师团队成长进步,如果我们行动不一致就会有麻烦。我们花了很多时间在一起谈论 Stripe 面临的问题以及Marc对管理和领导力的看法等等。

我问他:「我们如何解决分歧?」他回答:「嗯,我们需要讨论,正如我们现在这样。理想的组织使我们能互相信任也使得工程团队更有效率,如果我们其中一个人对某个方案有很明显的担忧,我们就商讨一下,如果还存在疑虑,那我们就推迟那个方案。」

之后,当我问他关于工作进度的看法,他说,「很显然,你们之前没有雇佣过职业经理。」他承担了设计管理层面试流程的任务。这也促使我去构思我们工程师面试流程的设计。

当我们有了工程副总裁

我们招募了Marc。在他开始工作前,我加他进入我的邮箱列表和IM。我们花了很多时间谈论公司正在发生的事情,如何着手解决一些特别的问题,互相审阅邮件初稿等等。

他开始工作后,我马上将一对一沟通的工作转交给他。他还告诉我我不想做的其它事情也可以随时转交给他(在当时我不堪重负的情况下,这句话对我来说简直太美妙了)。招聘这个部分正是他提出的合理建议之一。我实际上很吃惊:「我不知道去哪里招聘合适,而且从没真正地期盼能够停下来我们的项目。但结果变成招聘是工程副总裁职责的一部分。事实上,我慢慢意识到我以前所做的工作几乎全是工程副总裁的职责。」

随着时间的推移,一个重要的转变是确保大家会把问题反馈给Marc而不是我。在这方面我做的最好的事情是去夏威夷休假(有史以来第一次),然后躲起来和几个工程师一起创建CTF3。我也转交了越来越多的职责:因为Marc现在和很多人沟通,他更清楚每个团队面临的困难,或一个组织内部是如何变化的。

任何新高管的融合从来都不是那么的顺利。例如错误的开始以及人们对于改变的适应——在一些地方企业文化需要适应高管,在另一些地方高管自身需要转变以适应企业文化。我遭受过与很多工程师一样的困难,即难以区分「这不是我做事的方式」和「错误的方式」。Marc可能会采用和我完全不一样的方式来招聘、举行团队会议或沟通,我花了很长时间才明白一切工作均在正常进行。

我在这个过程中学到的最好的建议是,在委派任务时,你有两个传统的选择:你要么完全委任(你可能需要制定一些原则,但你无需参与执行),或者你参与所有的细节。后者是可行的——想想 Mark Zuckerberg 是怎么参与产品设计的——但是你只能在一个领域这么做。(也有一个非传统的办法,即训练一些真的很擅长模仿你的人,让他们来执行。这也许可行但不一定是健康。)但是通常来说,「稀疏的微观管理」(sparse micromanagement, 我听过的关于「插手一些随机的问题,推翻所有决定然后就消失了」的最好的术语)是最糟糕的。

Marc和我解决这个问题的方法相当简单:我们花了非常多的时间在一起。我们开始一周进行两次2小时的一对一沟通,一次在周一,一次在周五。也有些时候我们并没有很多事情要探讨,但是花大量的时间沟通我们担心的事情和工作进展及方向是极其重要的。因此,我从有一堆问题却不知道Marc会如何应对,到不超过几天就知道Marc的解决方案,再到最后心灵感应般地能猜到他会如何应对问题。我们采用了一些其他的沟通技巧,比如两个人同时用手机在即时通讯上沟通,或用「我打算做XX事;准备24小时内立刻开始不管有什么障碍」的方式。

当你在一个快速发展的公司,你会发现组织本身会不断变化。当Marc学着改变组织结构的时候,我发现自己同样需要再学习。我们从一个由亲近的朋友组成的组织发展为人数超过顿巴数(约150)的公司,在这个公司里,在有些同事我们从未见过的情况下,我们得弄清楚公司如何运作。公司里有一个合伙人(尤其是一个曾运营过更大组织的人)是极其珍贵的,否则我真不知道自己该如何应对。

我的角色

我期待我能有一个职位真空期,那样我便可以按自己的需要填充职责。这是非常吸引人的:自从约一年前,我的职责完全是在应对每天出现的问题。这将是我第一次有机会去选择我想关注的事情。

我去探索了一下CTO愿景,问了20个不同的CTO和工程副总裁来描述他们的角色。我原本以为每个CTO都是首席架构师。但是我想知道他们如何完成工作的:除了「早期员工」外,我试着去做首席架构师,我不知道如何兼顾这个工作。(最可怕的是,我感觉我们的组织滞后是因为每个人都认为我会负责所有问题。)

但是令我惊奇的是,我发现只有一位CTO是这样的。其他每个人都把自己视为技术组织的辅助者。这包括高级工程师间的沟通,或是工作指导。对我而言,一个令人深思的案例是有个CTO实际上是一个产品负责人。我意识到产品负责人和架构负责人有着巨大的差别:一个好的产品是简单和可以理解的,所以很容易区分好坏。相反地,你只能通过广泛架构来辨别架构的好坏。所以当一个兼职产品负责人比兼职首席架构师容易得多。

我意识到最重要的事情是去授权我们的工程师去做大的改变和进步(此外,最近我们已经招聘一些特别牛的工程师,其他事当然就不在话下了)。Marc和我开始授权并鼓励重大项目组以改善 Stripe 的核心领域。我也开始运行一个「架构工作组」,一组可以帮助其他人更好地建造系统的工程师团队,以及一个用来阐述我们组织架构发展方向的论坛。

然而,一件我未曾预料到的事情突然脱离了我的反馈回路。在Marc加入之前,我大致了解以前的组织,但是我却没有收到任何更新。如果我试图说服别人X是个问题,Y是个正确的解决之道,我的所有事例和证据均来源于过去。这就好像一艘船之前泊在海岸上,但突然被人剪断绳索在海上漂流。最令人担心的是,这个问题随着时间的推移愈发严重。

我花了很多时间思考如何让每个人了解公司正在发生的事情,或者如今的问题是什么。我提出了四个可能的机制:

1.工作:比如,你在编程,你可以明确工作的好坏。

2.和很多人沟通:你可以知道多人的观点,可以辨别观点的倾向。

3.观察工作:也许你可以试着做架构Y,看看所有的差异。(事实上我曾经花一个月这么做,但感觉像浪费时间——大多数的工作是再现作者的思考路径。)

4.为工作制定计划:你可以试着计划每件事,但我不确定在没有其他反馈回路的情况下,这是否是可持续的。

我意识到这些事我都没做。看看这个列表,我明确地知道哪一个能让我最轻松。问题在于如何达成。

我尝试了多种不一样的方式来写代码,但很多都不可行:比如,「躲在角落,做个原型出来,然后把它交由工程师维护(或许干脆不维护)」。我知道很多CTO这样做,但是我从没找到一个不错的方式(如果你看到过这种方式是可行的,请告知我)。一个更好版本是「和团队里的一个工程师一起做一个新的原型」。但是因为这会占用别人很多时间,所以似乎也并不容易。

我在晚餐时碰到过一个CTO,他告诉我他最近又开始写代码了。我与他见面请他透漏他的秘诀。他是如何做到的?他看着我说,「编程是我爱的事情。我知道我做编程比起其他任何事都能做得更好。我需要的是知晓如何用编程带动其他方面的发展。」于他而言,这是通过为他们的架构建造一个开源平台来改善他的公司和这个行业。

这是上个月。我开始和一个团队一起再次编程。这并不容易:因为总有一堆其他事情冒出来。但是我花越多时间在编程上,我就能够用不同的视角看待公司,也就能够更好地支持其他人的工作,让他们对我们构建的事情产生充满热情,并帮助他们改善工作。

有时候我怀疑做这个选择是否正确——专注写代码是否会让我错过有着更高产出的活动?但是我听过(来自另一位CTO)最好的建议之一是:这无关时间管理,而是精力管理。找到一个能让你充电的事情很重要,让你能有精力去处理具有更高影响力的其他事情。

之后我的角色会怎样,我还完全不能确定。我忙着写代码呢。

发布于 2015-02-24

文章被以下专栏收录