2012 年，建立还不到两年的 Instagram 被 Facebook 以 10 亿美金收购，当时 Instagram 的月活为 3000 万，现在其月活超过 7 亿。怎样的工程团队能够支撑公司的业务如此高速持续发展？创始人应当在何时放手、引入外部管理者？团队壮大过程中又有哪些其他问题？创业初期的多面手人物与公司壮大后的专业型人才需求之间的矛盾如何协调？来看看 Instagram 联合创始人兼 CTO Mike Krieger 的经验分享。

无论以何种标准衡量，Instagram 发展的几个里程碑都让人叹为观止。Facebook 以 10 亿美元收购，为之赢得了世人关注。这既是其用户数量快速增长的结果，也是全新的开始 —— 2012 年被收购时，其用户月活为 3000 万，2 年后达到 2 亿，如今已超过 7 亿多。

在公司内部，联合创始人兼 CTO Mike Krieger 也设立了自己的一系列里程碑时间。这些里程碑与其技术团队如何扩展和发展，以达到其庞大的用户数量密切相关。在 Facebook 收购 Instagram 的时候，Mike Krieger 只有 6 个多面手开发人员。如今，他掌管着 300 多人的工程团队，并不断推出新功能和新产品。在 7 年的时间里，Krieger 自己从首次担任管理者成长至领导专业而多层次的工程师团队，其中许多工程师是各自领域的最强者。

在这次专访中，他分享了从这些经历中学到的东西，以及他希望自己在 2010 Instagram 初创时就明白的道理。对于其他想要复制 Instagram 成功的创业公司来说，他介绍了如何优雅地从早期技术团队过渡到成熟团队、如何引入新的管理层级，以及如何建立持续改进和创新的动力引擎。

早期团队必须满足早期需求

要想让一家创业公司正常起步，几样东西要供应充分 —— 勤奋、动力和解决问题的人。专业型的工程师在这时候通常是不必的。这一阶段，多面手才是最重要的。Krieger 定义了多面手应该具备的关键特质和能力。以他的经验，这些特质和能力对于将初创公司顺利带进下一个阶段是至关重要的。

知道何时给牦牛剪毛

“你听过那种说法吗，给牦牛剪毛？”Krieger 问到，“有时候编程是要解决超级复杂的技术问题。但很多时候，你最终得解决一长串不那么困难的其他任务，例如要让这个 APP 在 iPhone 上运行，这意味着需要生成配置文件，而后者意味着需要设置账户等等。最后，你要给牦牛剪毛才能完成初始的任务 —— 而这些工作都是完全脱离最初目标的。”

在打造对面手工程团队时，你需要的是准备好并且愿意随时出击、坚持到最后的人，那些渴望学习的人 —— 对于不知道的事情，他们马上就会学习，最终保证完成任务。

为了找到这些人，以下是一些可以尝试的面试问题：

聊聊最近的个人项目或工作项目。在开始真正工作之前，他们都给哪些“牦牛”剃毛了？

一个项目涉及多个学科，甚至他们根本不熟悉的时候，他们怎么完成项目？

知道何时不必给牦牛剪毛

话虽如此，对于早期初创公司而言，没有什么比时间更宝贵了。必须确保自己没有浪费时间。Krieger 说：“人们给牦牛剪毛可能会上瘾，一个高效的多面手工程师要知道何时继续前进，而不是留下来消耗在边边角角上。

Krieger 迄今依旧认为在 Instagram 早期获得的最好建议之一是监控一切。

一开始，为了这一目标，我们需要花费 4 到 5 个小时来完善 Nagios ，这是一项顶尖的基础设施监测服务。后来我明白了我得赶紧打造产品了。我需要的是一个不那么完美的警报解决方案，它不必那么灵活，但是够用就行。这个是我今天就能完成的，然后我就可以专注在产品上。

类似地，你可能会遇到一些情况需要自己搭建工具。如果市面上已经有好的产品了，还要继续自己做吗？早些时候，我们想的是可以自己弄清楚怎么完成自己的推送通知系统。但是 Urban Airship 已经有现成的东西了，所以别想那么多了，你的目标不是做推送系统，而是发布软件、让人们使用 Instagram。

以下就是他用来鉴别是否对给牦牛剪毛成瘾的方法：

Krieger 和团队会让工程师花几个小时构建一个简单的 APP 或后端系统。如有问题，他们可以随时咨询 Instagram 团队。他不开玩笑的说，真有工程师会画 2 个小时配置编程环境，这些显然不应该这时候做。这就直接让务实的工程师脱颖而出了。关注点应该是合理利用时间，而非只关注结果。

聚焦于行动导向

你不能一次完成所有的工作，那么创业公司要解决的主要、次要和第三重要的任务分别是什么？记录这些东西不需要多么详细，只要有就够了。在 Instagram 早期，Krieger 和他的团队使用的是谷歌文档，按照主题排列内容。

我们的目标之一是成为世界上最快的照片分享应用。我们应该朝着这个方向做出什么努力?我们想让照片看起来特别漂亮，远远超乎你对手机拍照的想象。为了这个目标，我们应该做什么？任何不符合这些目标的工作全部搁置。我们想要的工程师也需要接受这一点。

对 Krieger 来说，建立早期团队，并利用谷歌文档专注于与公司成功相关的任务，这是至关重要的。不要雇佣那些不按照公司计划行事的人，或者哪些只挑拣不那么重要的工作来做的人。

如何找到行动导向的人，这是 Krieger 的建议：

讲一个你特别自豪的，在功能完整、团队协同和时间安排之间平衡得非常好的项目。这个没有绝对正确的答案，“我们不打无准备之仗”和“时间节点既在，无论如何都要交付”的说法我都听过。

招聘充满激情而灵活多变的多面手

大公司享受了标准化招聘团队的好处，小公司也有自己的优势：灵活多变，招聘那些不符合大公司条条框框却适合自己的员工。 Krieger 回忆了和联合创始人 Kevin Systrom 雇佣的第一位员工 Shayne Sweeney ，也是他俩的经典成功案例。“他没上过大学，是个完全自学成才的程序员。我们在 Dogpatch Labs 孵化器，他就坐在我们对面，所以我们才有机会见面。他完美体现了创业精神：我有一个很好的想法，我愿意学习任何东西，只求实现这个想法。”

一个人坐你对面，怎么做到看两眼就能够完美评估是否具备创业精神呢？在 Krieger 看来，一定要具备普遍而强烈的好奇心。所以需要倾听谈话中有关对方求知欲的迹象。“让我们兴奋的候选人就是那些会说‘这周我对围棋很感兴趣，所以我建了个原型并学习了这些东西’的人，而不是说‘公司都在用 React ，所以我也在用 React‘。”

灵活性也至关重要，这往往意味着不能雇佣那些某项技术最牛的人。“我们面试了一个 iOS 工程师，他是我知道的最牛的 iOS 工程师之一。聊天的过程中他说，‘我不做服务器端的工作，我觉得那纯属浪费时间。’我觉得这样坦诚出来是很好的，不过他这样的专才并不适合当时的 Instagram 。我们不想找一位员工，他在遇到问题时不是自己想办法解决，而是跟我们说‘我需要一个服务器端的人来支持一下’。”

雇佣能够在不同的技术栈之间灵活切换的工程师，才能保持早期的团队灵活敏捷，同时还能避免很多未知问题。“我记得有次和 Kevin Rose 聊天，他说自己犯的最大错误之一就是，招聘的工程师完美符合当时的工程技术需求。这有两个问题，一是技术总要不断演进的，二是如果工程师只会某项技术，比如 PHP ，就会直接影响后续的技术选型。”

他的最后一个建议是，招聘多元化的团队。多元化团队的好处很多，并且也有很多相关的科技报道。初创公司在快速发展的早期会认为这条经验并不适用，或者把此事的优先级排在最后。

Krieger 说，“我们早期没有重视团队多元化。一旦团队壮大起来，就很难把女性和少数族裔融合进团队。女工程师面试时会说‘哇，这个团队这么多人，全都是男的’，这只会让隔阂加重。如果能从早期避免这种情况，那就好多了。”

不要对抗专业化

Instagram 的故事已经成为硅谷传奇故事的一部分：2012 年，这家由 13 人组成的公司被 Facebook 收购。这时候，Krieger 和 Systrom 既可以独立招人，也可以从 Facebook’s bootcamp 招人。他们名气正盛，所以招到的员工也对公司有着不同的期望。当然，并不是每一家创业公司都会由如此经历，但无论如何，在团队的多元化和专业化方面，下述内容与你息息相关。

随着对功能和增长的需求增多，团队有必要引入特定领域的专业人才，也就是职业的 iOS 和 Android 工程师。他们可以分解产品，把产品打磨的更为优秀。在创业公司中，这是一个再正常不过的时刻。需要往这个方向转变的迹象有如下几点：

1. 需要发明的东西超出了现有平台正常提供的能力。
2. 进入新的市场需要更加优质的代码和技术。在 Instagram 的案例中，是让视频功能在新兴市场表现良好。
3. 代码库已经扩展，需要技术领导者引领未来增长。

随着越来越多的专业化人才加盟 Instagram 发布，现有团队的无所不能多面手与专业化人才终于出现了矛盾。

“我们这时候才明白，很多事情都有规范的做事方式。有时候很教条主义，有时候确实是有很好的理由。“Krieger 表示。他还回忆了一个简单的、甚至是愚蠢的例子。Instagram 是他和 Systrom 的第一个大型 Python 项目，所以他们在早期约定了一些代码规则。“后来，专业的 Python 工程师问我们，‘为什么要在等号两侧加空格?’我们只是觉得好看，他们的反应却是，‘不应该那么写‘。”

你想要的是标准化，这样新来的人才会更容易融入。最终，Krieger 回去把他的 Python 代码全部修改了一边，终于看起来跟其他人的代码一样了。你可能会忍不住要抵制专业化，坚持你早期的、随性的方式。忍住。雇佣专家是有原因的，就应该让专家发挥他们的专业性。

我用胶带把需要的基础设施粘在一起，按照我当时的理解水平，我觉得已经做得很好了。但是未来总要在某个时候，你需要专业人士来搭上脚手架，好好的搭建结实的建筑。

将现有团队成员纳入到日益专业化的体系中，大家自己就会适应的。前面提到的多面手也会喜欢一面胜过另一面。只需要向每个工程师解释，这是成熟组织的需要，并看看你们在哪里更合适。有些人选择 iOS ，有些选择基础设施服务。他们每个人的技能都是我们需要的。

专业化也不意味着放弃多面手而只留一面，或者为了专业化而专业化。Krieger 说：“早期的多面手有广泛的认知，这能让他们成为更好的工程师。”

以前面提到的第一位员工 Shayne 为例。“有段时间我们想让测试流程更快，建造和部署都花费了很长时间，最终解决方案是在于基础设施，而这需要写大量的 Python 脚本。我没有从基础设施团队抽调人员过来，而是对 Shayne 说，‘你很懂端到端的东西，利用这些东西，写个 MacBuildServer 出来吧。”

招聘新的管理者

随着工程师团队不断发展，你的领导力也需要长进。一开始，组织极可能是扁平型的，管理的条条框框都不适用，他们反而会损害小公司的开放性和灵活性，而后者正是初创小公司最为宝贵的资产。尽管如此，这并不意味着创始人可以简单地任由团队自我管理。

在公司颁布像样的管理章程之前，你就应该在团队中实施管理行为。

怎样就算“实施管理行为”了？拿一对一谈话（ one-on-ones ）举例。“我们大概过了两年才开始做一对一谈话。” Krieger 表示。最终，Instagram 的合伙人 Matt Cohler 推动 Krieger 开始了一对一。“我记得第一次和大家进行一对一谈话的时候，我震惊的发现，大家在私底下讨论着这么多的问题，而我们根本不知道。”

现在回想起来，Krieger 认为那时候问题已经开始汇聚了，幸运地是他们及时将问题化解了。“但对我来说，这让人大开眼界。”他说，“如果你是创始人，你会感到很幸福，或者你都不会问自己幸不幸福，因为公司就是你的孩子，你在努力让它成长。后加入的员工收益与公司的成功，但他们也得生活，有需求、有欲望、有各种生活中的问题。从多面手向专业型人才转变的时候，我们开始加强了管理。回想起来，应该开始得再早些。”

实施管理行为本身是至关重要的，但它也是一项重要的衡量标准。作为创始人或早期的领导者，你不能满足当下工作中产品和管理的需求时，就应该引入新的管理者加入董事会了。当你觉得自己可能需要引入新的管理者是，十有八九你的确是需要的。

Krieger 表示：“在 Instagram 和请我做咨询的公司里，我一次又一次地看到，一旦引入新的管理职位——也许你甚至都不确定自己是否准备好了 —— 你就会发现，你之前一直在做的只是所有该做的工作中的前 5% 。其他的 95% 你根本没做，因为没人来做这些。对于我们来说，这包括完善招聘流程、策划活动、未来规划等。之前的那种每周花一天时间思考的方式是根本不够用的。”

让团队接受新的管理者

即便你和管理团队能够从容接受新的管理者，你仍然要让工程团队成员了解到形势正在变化，他们的角色也在调整。首先，不要害羞，招聘新的管理者的时候，让每个人都知道。“要从事情的根源着手，‘我忙不过来了，我们要引入新人来帮助扩展团队规模’。这样一说就能奠定基础。”

在招聘的时候，有几种方法可以选择。“你可以采用共识驱动法（ consensus-driven path ），让团队的所有工程师都去面试候选人。要让他们达成一致意见，明确他们愿意和这个人一起工作。”不过要记住，这些团队成员自己不是管理者，他们的评估常常取决于他们是否喜欢这个人。“这很困难，有时候可能不会达成共识。”

Krieger 倾向于对招聘早期管理者采取一种相关但温和的方法。首先，评估候选人的资格，优先选择经验丰富的领导者；他还罗列了一个 Facebook 上的管理人员名单。然后，一旦对方接受 Offer ，在正式签署任何文件之前，让新的管理者候选人在办公室待一整天。

Krieger 说：“毕竟，这是为团队引入了新的管理者，大家很少会拍手称快喜迎变化。这个团队过去是向你汇报的，马上就要向这个家伙汇报。但是，你至少可以在这时候获得一些信号，比如‘大家都不喜欢这个人，所以不要雇佣他’这样的红色警报。”

你可能不会直接得到那种“不要雇佣这个家伙”这样的反馈，但是仍然要对工程师可能存在的顾虑敏感些，他们担心的可能是不一样的方面。“多年来我一直在接收同一位执行教练的指导。她告诉我的一件事是，如果某人为某一事情忧心忡忡，而你在其他方面安慰辅导，那肯定是没用的。就像有人的情感生活不如意，你却说‘但是你的工作做的很棒’。他又不是因为工作才不开心的。”

接收专业执行教练的指导，这是 Krieger 对新晋领导者的强烈建议之一。“我从未管理过任何团队，到管理数十人团队，到现在管理数百人，如果没有教练之道，我根本不可能一路成功做下来的。”

在引入第一个或者前两个管理者的时候，必须反问自己：这会对团队成员产生怎样的影响？“当我们雇佣了第一位管理者时，一位工程师说，‘我在上一家公司，两年内换了 8 个负责人。新来的领导会不会过 2 个月就走人？这时候我需要给他们提供信心。我说：不会的，他是要长期在这里的。这些是我要向转交给他的工作。咱们可以每周一对一聊聊有关他的事情。”

此外，记得提醒早期团队，这些变化对公司和他们个人来说都是积极的。“告诉他们，你们也要向这个人学习，你们也将获得成长。我相信，所有早期工程师都会完全同意他们确实获得了成长。” Krieger 说。

从个人主义到集体主义

随着团队的成熟，你不仅仅是重新定位工程师的个人角色，而且是在打造团队的集体角色。“人们会觉得，过去他们什么都可以做，现在却不行了，现在是团队作战。我会问他，你在做的这个功能是什么样的？一旦产品发布了，你所做的这个功能的用户，可是会比你刚来 Instagram 时我们的所有用户数量都多的。”

这不仅仅是口头上的。随着团队规模增长，不仅是公司的产品，而且包括公司的精神文化也都会不断改变。Krieger 指出了这一过程中的两个关键阶段，而每一阶段都对公司增长产生了重大影响。

 从多面手到平台团队

在扩张阶段，你招聘和培养的工程师会决定整个公司的工程师文化。“当前 Instagram 工程师文化比较成功的关键，在于早期打造了良好的恰当的环境并把控了严格的招聘标准。”

早期的多面手工程师们并没有并没有多想过团队规模急剧扩大的事情。随着团队规模不断增长，专业化的需求会越来越旺盛，多面手的需求就不那么强烈了，需要他们意识到这个现实。“需要为员工创造明确的上升渠道，而不是毫无章法的随意提拔，否则两年后就会埋下很多技术债。”对于 Instagram 来说，这就意味这围绕平台来培养人才。

“我们在 Instagram 积极推动大家的专业身份，比如 Android 工程师、iOS 工程师、基础设施工程师。我想让大家思考，我们现在只有 8 个 Android 工程师，如果几年后，有了三四十位 Android 工程师，我们现在要做些什么，保证到时候能够顺利解决各种问题？”

通过围绕平台组织团队，Krieger 可以将他的团队重点放在质量上。“以 Android 为例，从一开始，我们就聚焦于做一款高质量、精美的 Android 应用，甚至超出 Android 平台的允许范围。”聚焦使得工程师们明确了他们应当如何工作以及在为谁工作。

“我们首先追求的是简单，要力求简单，而不要花哨。要为你的工作结果而自豪，而不是为那些花哨的东西。”Krieger 说。这些价值观对于 Instagram的成功是至关重要的，而他们正是形成于这一时期。

人们经常认为，由平台团队向产品团队转型总是会带来各种恶劣的问题。我倒是认为，这正是打造工程师文化的阶段。

从平台团队到产品团队的转型

多年以前，Instagram 围绕平台建立工程团队，现在他们在围绕产品来做。

说到这一转变，时机就是一切，太早和太晚都会有很大的问题。Krieger 说，“我们是在大约 150 人的时候做的转型，现在看来有些太迟了。我认为最重要的是，产品经理和工程经理开始掐架的时候，就该转型了。”

转换之前，产品经理需要去跟每个工程经理要人。Krieger 说，“现在好了 ，你需要同时和四个工程经理、四个工程师合作，才能把工作完成。这就要求你必须足够机灵，能够有效调度人员才行。每个人都只知道很少的局部信息，可是都想做出全局的优先级排序。”大家局限于自己的岗位分工，不清楚公司的整体目标。

然后，Krieger 恢复了目标导向。就像从多面手到专才文化的转变一样，这个过程在很大程度上也是自我选择。“你所做的只是把之前隐含的东西明确出来，例如问‘谁想做这项工作？’过去的泱泱大众各自为战，需要的时候他们就会合力作战。”

围绕核心产品建立团队时，随着产品规模扩大，你可能也会发现，有些工作是大家都没什么兴趣去做的。“这时候你要做的，就是招聘新人，招聘愿意从事这项工作的人，比如说 iOS 用户增长。”

从当初的谷歌文档开始算起，已经过去 7 年了，工程团队也壮大到 300 人了，“你不得不再问自己一次，目标是什么？要解决什么问题？用户不关心我们都做了什么、我们怎么做的，他们只关心产品好不好用。不管处在什么阶段，不过公司多大规模，这都应该是我们不变的指导原则。”

原文作者：Mike Krieger

原文地址：http://firstround.com/review/how-instagram-co-founder-mike-krieger-took-its-engineering-org-from-0-to-300-people

译者：Brother Zhao，微信公众号： EGONetworks

本文由@ EGONetworks 翻译发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自PEXELS，基于CC0协议