Ins CTO：内部提拔和外部聘请，如何才能找到合适的管理者？

　　编者按：Mike Kreiger 是 Instagram 的联合创始人兼 CTO，在仅仅创办一年半的时候，Instagram 就被 Facebook 以 10 亿美元的价格收购，堪称硅谷神话。被收购后，Instagram 用户数实现了指数级增长，月活跃用户数从 2012 年被收购时的 3000 万猛增至今天的 7 亿，Mike 打造的工程师团队在这个过程中发挥了不可替代的作用。在这篇文章中，Mike 分享了自己在过去几年中积累的工程技术团队管理经验。如何从一个早期的创业公司工程师团队顺利发展为一支庞大成熟的工程师团队？如何顺利地为工程师团队引入新的管理层级？如何为工程师团队打造一个能够持续改进和创新的引擎。Mike 的经验对于那些想复制这种工程师团队成功扩张的创业公司具有很大的借鉴意义。 因文章较长，为提升阅读体验，特分为上、下两篇。

　　不管用什么标准来衡量，Instagram 所取得的里程碑式的成就都是非常惊人的。在仅仅创办一年半的时候，Instagram 就被 Facebook 以 10 亿美元的价格收购，受到外界广泛关注。对 Instagram 而言，被收购不仅仅是一个结束，更是一个开始。被 Facebook 收购后，Instagram 用户数实现了指数级增长，产品的月活跃用户数从 2012 年被收购时的 3000 万猛增至 2012 年的 2 亿，如今，Instagram 的月活用户数已经突破 7 亿大关。

　　作为一家公司，Instagram 取得了一系列里程碑式的成绩，公司联合创始人兼 CTO Mike Krieger 本人也达到了自己的一个又一个里程碑，Mike 的里程碑与他所带领的工程技术团队的快速扩张和发展紧密相关。在 2012 年被收购的时候，Mike 负责的工程技术团队一共只有 6 个工程师，且都是全栈工程师。如今，他掌管的工程技术团队的人员规模已经超过 300 人，正是这些人在为数亿用户快速推出众多新的产品和功能。在过去 7 年时间里，Mike 自己也从一个管理新手迅速成长为一个能够熟练带领一个多层组织架构的专业工程师团队的掌门人，他管理的很多工程师都是各自所在领域内最牛逼的工程师。

　　近日，Mike Krieger 接受了 First Round Review 的专访，他在专访中分享了自己在过去几年中积累的工程技术团队管理经验。如果时间可以重来，他希望自己在 2010 年 Instagram 刚创办时就知道这些经验。他分享的经验包括：如何从一个早期的创业公司工程师团队顺利发展为一支庞大成熟的工程师团队？如何顺利地为工程师团队引入新的管理层级？如何为工程师团队打造一个能够持续改进和创新的引擎。Mike 的经验对于那些想复制这种工程师团队成功扩张的创业公司具有很大的借鉴意义。

　　一.  打造一支能够满足你早期需求的早期工程师团队

　　一家创业公司要想顺利起步，通常需要具备下面这些资源和能力：足够勤奋、充沛的精力和很强的解决问题的能力等。在创业最初阶段，是否需要专业化的工程师呢？通常不需要。这个阶段最需要的是全栈工程师。根据 Mike 的经验，为了将你的创业公司顺利推向下一个发展阶段，这个阶段的全栈工程师需要具备下面这几项特质和能力：

　　1. 知道何时该给牦牛剃毛

　　你听过“给牦牛剃毛”这个行业术语吗？大概意思是，有些时候在编程过程中需要解决一些超级复杂的技术问题。但很多时候你需要完成一长串必要的任务之后才能最终解决你想解决的问题。比如，我需要让这款 iPhone APP 在我的设备上运行，这意味着我首先需要生成这个配置文件，还需要对这个账号进行设置，等等。最后，你要将牦牛上的毛全部剃完之后才能完成你最开始想要实现的事情。

　　在你组建全栈工程师团队的时候，你需要的是那些已经准备好并愿意在这条路上一直走下去的人。你需要的是那些为了完成一项任务而愿意学习自己不知道的新知识的人，尽管需要学习的东西可能是他们的工作职责范围之外的知识。

　　为了找到并鉴别出这样的人，你可以面试的过程中提问下面这些问题：

　　（1）让他们说说最近做过的业余项目或工作项目，在做这个项目的过程中，为了解决项目中最重要最复杂的问题，他们必须首先剃掉牦牛的哪些毛？

　　（2）问他们之前是否参与过的一个跨学科的项目，或者是否有过在完全不熟悉的情况下就开始一个项目的经验。

　　2. 知道什么情况下是不值得花时间去剃牦牛的毛的。

　　对于一家早期创业公司而言，没有什么比工程师的时间更宝贵了，因此你肯定想确保自己是在明智地利用工程师的宝贵时间的。“人们很容易会陷入给牦牛剃毛这样的事情中无法自拔。一位高效的全栈工程师知道何时该从给牦牛剃毛这件事中国抽身出来继续前进。”Mike 说道。

　　Mike 想起了自己在 Instagram 发展早期的时候得到的一条建议：监控一切东西。他直到今天依然认为这是一条非常好的建议。

　　所以在最开始的时候，我们花了四五个小时的时间来尝试搭建一套免费开源的 IT 基础设施监控系统 Nagios。最后我想，我想要回去自己重新开发这款产品，我是可以接受一个不那么灵活的报警解决方案的，这项工作我今天就能完成，完成之后再做其他事。

　　对于你需要使用的产品，有时你自己就能开发出来。但是如果市面上已经有了一个比较好的解决方案，这时你还应该花时间去重新开发吗？一开始的时候，我们会想：我们知道如何开发一个推送通知产品功能，但是市面上已经有 Urban Airship 这个现成的推送通知产品可以使用，这时还需要重新开发吗？这时，将你的骄傲放在一边，你需要将你的主要精力放在你真正需要实现的目标上。你的真正目标不是搭建 Nagios，也不是开发一个推送通知功能，而是早点将你的软件产品推向市场，这样用户才能用上它。

　　Mike 通过下面这个方法能很容易地鉴别出一个工程师是否已经陷入了给牦牛剃毛中无法自拔：

　　Mike 和他的团队会让候选工程师花几个小时时间开发一款产品，比如一个非常简单的移动 APP 或后台系统，遇到问题时可得到 Instagram 团队的全力支持。这能够让你将那些务实的工程师与那些会将一半时间都用来设置编辑器环境的工程师区分开来。你要考察的不仅仅是结果，还要看候选人对时间的利用是不是非常合理。。

　　3. 注重行动导向

　　你是无法同时做所有事情的，那么问题来了：你的团队需要解决的首要问题、次要问题分别都是哪些。你对这些问题的分类记录方式不需要太精细，但是你需要一个问题的记录分类系统。在 Instagram 早期，Mike 和他的团队是用一个按主题分类的滚动的 Google Doc 来记录他们做的所有事情和要解决的所有问题的。

　　其中的一个分类主题就是：成为世界上最快的图片分享应用。在这个主题下，我们都要做哪些工作？另外一个主题是：我们想要让自己平台上的图片看起来让人觉得不可思议，远超人们对在手机上看图片时的期待。我们在这个主题下又有哪些工作要做？所有与这些主题不相干的工作都靠边站。

　　Google Doc 是用来跟踪一个团队所有任务的最合适的最小可行化产品，它能确保每一个团队成员都在为公司最重要的目标服务的。文档被分解成很多天，每天的任务都分为不同的主题。每个主题下未完成的任务都会被迁移到接下来一天的任务中。那些优先级最高的任务会被标记出来。这样一来，就不会出现遗漏丢和失任务的问题，每个人都可以很方便地对任务进行评论和提问问题，大家的注意力也都能投入到那些接下来需要完成的任务上。

　　Mike 在非常早期的时候就为团队引入这样的工作方式起到了很大的作用，这能让大家都专注在那些与公司成功息息相关的未完成的任务上面。这也可以让你杜绝让那些只知道做自己的事情、对全公司的执行计划完全不闻不问的人进入公司，或者远离那些仅仅为了完成任务而将时间浪费在只做那些不那么紧迫的任务的人。

　　你可以通过问下面这个问题来鉴别候选人是不是注重行动导向的人：

　　能告诉我们一个你在产品功能完整性、功能优化和时间把控三者之间平衡得比较好的项目经验吗？对于这个问题，你希望听到的是一个微妙的答案，而不是一个绝对的答案。例如，“只有当一切都准备好之后我们才发布产品”或者“我们的每一个任务都能在截止日期前完成。” 这两种答案我都听到过。

　　二.  招聘那些有激情、灵活性高的全栈工程师

　　虽然大公司有机械招聘团队带来的益处，但创业公司在招聘方面也有自己的优势：他们可以在招聘的时候跳出传统的思维局限：有些候选人表面上并不满足公司的招聘要求，如果按照传统招聘标准，这些候选人可能一点机会都没了，但实际上他们却是非常合适的人选。Mike 和他的合伙人 Kevin Systrom 招聘的第一个工程师 Shayne Sweeney 就是一个非常典型的例子。Shayne 连大学都没有读完，完全是一个自学成才的程序员。我们之所以认识他是因为我们在同一个孵化器办公，而且他的办公桌刚好在我们的对面。你能从他身上感受到那种强烈的创业精神：“我有一个想法，为了让这个想法变成现实，我愿意学习一切必要的知识。”

　　当然，大多数时候你是没法像我们一样在桌子对面就能直接观察你的候选人的，这时你怎么才能判断候选人是否是这种有激情、有创业精神的灵活全栈工程师呢？根据 Mike 的经验，强烈的好奇心是候选人应该具有的基本人格特质。因此在与候选人交流的时候，看看是否能自然而然地就感受到对方强烈的求知欲和好奇心。我们感兴趣的候选人一般都会说类似这样的话：“这周我对 Go 这款游戏非常感兴趣，于是我自己开发了一个 Go 的原型，从而更好地学习里面的东西。” 我们不希望听到候选人说类似这样的话：“我工作的公司使用的是 React，所以我用的也是 React。”

　　你也可以通过在面试的时候问一些问题来判断候人是否具有好奇心和求知欲。在创业早期阶段，我喜欢问候选人下面这些问题：“你做过的哪些业余项目让你感到最为兴奋？你最近一次因为做某一个项目而掉进了另外一个奇特世界里是什么时候？你从中都学到了哪些东西？”

　　当回答这些问题的时候，如果候选人双眼发光，明显有什么让他感到兴奋的东西，你就知道他做事情是出于激情，而不是仅仅将其视为一个工作。在创业早期，你需要的就是这样有激情的人。

　　在创业早期，工程师是否具有足够的灵活性也至关重要。这可能意味着不要招聘一些技术非常精湛的候选人。

　　我们当时面试的一个我之前认识的候选人， 他是我见过的最优秀的 iOS 工程师之一。但是在我们与他的交流中，他大概说了这样的话：“你是知道的，我是专门做 iOS 开发的，我拒绝做任何服务器端的工作，我认为那是浪费我的时间。” 虽然他说这样的话有他的道理。但问题是，他的这种思维方式是一种太过专业化的思维方式，可能适合大公司，但并不适合当时的 Instagram。

　　招聘那些能够在不同的技术之间灵活切换的全栈工程师能够让早期的工程师团队保持足够的灵活性和敏捷度，也能帮你避免陷入很多陷阱。我之前曾和 Digg 的创始人 Kevin Rose 交流过有关他在运营 Digg 时踩过的坑，Kevin 坦承，他在创业早期犯过的最严重的错误之一就是只招聘那些与公司当时所使用的技术非常匹配的工程师。这是非常有问题的做法，原因有二：一是，你最终是需要进一步升级和发展你的技术的；二是，如果工程师将自己的工作范围仅仅局限在某一种单一的技术上，比如 PHP，这会导致你最终做出错误的技术选择。

　　Mike 在这方面的最后一条建议是，要尽早地进行多元化招聘。组建一个多元化的团队能够让你在很多方面受益良多。很多技术文章也已经对多元化团队的重要性做了很多探讨。但是在疯狂甚至混乱的创业早期阶段，很多创业公司可能认为这条经验并不适合他们，或是将打造多元化团队排在工作优先级的末尾。

　　在公司发展早期阶段，我们也没有在打造多元化团队方面给予太多重视。随着公司慢慢发展壮大，公司招聘女性员工或少数民族员工的难度开始变得越来越大。如果你的团队中没有女性工程师，这时当你面试一位女性工程师的时候，她内心肯定会想：“这个大一个团队，都是男的，一个女工程师都没有。” 这难免会让她心生警惕，觉得你的团队对女工程师肯定不是特别重视，加入团队的意愿自然会大大降低。

　　如果你能尽早打造一支多元化的团队，这就能让你进入一个良性循环。如果团队中已经有了一些女工程师，那么你就能更容易地吸引更多女工程师加入。如何才能更好地吸引女工程师呢？不管是参加活动、接受采访还是写博客文章，你都可以找机会强调你对组建多元化团队的重视，让更多人知道你是重视这一点的。要在尽可能多的场合表达对这方面的重视。如果你仅仅想通过在面试的时候强调你是非常重视打造多元化团队的，这不足以吸引那些你欣赏的女性候选人加入。如果女工程师候选人之前曾在多个场合都听到或看到过你对打造多元化团队的重视，那么候选人就更有可能相信你们确实是非常重视多元化团队的打造的，加入你团队的意愿也就会更高。

　　三. 不要抗拒公司对专业化的需求

　　Instagram 接下来的故事堪称硅谷传奇：2012 年，当时只有 13 名员工的 Instagram 被 Facebook 以 10 亿美元价格收购。被收购后，Mike 和 Systrom 既可以继续独立招聘，也可以利用 Facebook 强大的招聘团队为自己招聘。随着他们手里开始有了真正的品牌，他们突然之间吸引来了众多各怀鬼胎的求职者。当然，并不是所有创业公司都有 Instagram 所拥有的条件，但是无论你公司的处境和 Instagram 是如何的不同，Instagram 在打造多样化和专业化工程师团队方面积累的经验都值得大家借鉴。

　　随着产品功能需求的增加，同时为了更好地应对用户增长，Mike 发现光靠全栈工程师已经无法满足公司发展的需求，需要为团队引入一些专注于某种特定技术领域的专业化工程师，如 iOS 工程师和 Android 工程师，这些专业化工程师可以将产品分解成很多模块，通过各个优化的方式将产品打造得比之前更好。每一家创业公司都会经历这个发展阶段。如果出现了下面这些明显的迹象，就说明你需要朝专业化方向努力了：

　　（1）你发明的东西已经超越了你工作的平台所能提供的能力

　　（2）你开始进入对代码要求更高的新市场。以 Instagram 为例，就是让视频能够在一些新兴市场正常流畅播放。

　　（3）你的代码库已经扩展了，因此需要有技术领导者来引领公司未来的增长。

　　随着越来越多特定领域的专业工程师加入 Instagram，如 iOS 何 Android 工程师，公司现有的全栈工程师的工作方式和内容将必然与这些专业化工程师的工作方式和内容发生一次激励碰撞。

　　我们都知道存在一套规范的做事方法。有时这个规范是一个教条，有时这个规范的存在是有充分理由的。Mike 举了一个非常简单甚至有些可笑的例子：Instagram 是 Mike 和他的合伙人 Systrom 做的第一个大型 Python 项目，所以在一开始的时候他们俩就制定了代码规范。后来加入的 Python 工程师都会不解地问：“你们为什么要在等号的两边都留有空格呢？” 我们当时制定这个编码规范只是觉得这样做会更好看一些。但后来加入的 Python 工程师心里就会想：“但其他人都不是这样做的啊。”

　　最终，你需要让自己的做法能够符合行业规范，因为这样做才能让新员工能更快地融入到团队重。（是的，Mike 最终回头重改了自己最初写的那些 Python 代码，让它看起来和其他人写的代码差不多）。你可能会在某种程度上想抵制这种专业化，想坚持按照你早期那种自由、不拘一格的方法做事。建议你不要这样做，你招聘那些专业化工程师是有原因的，你的目的就让他们带着他们的专业知识和技能为你公司的发展服务。

　　将团队中现有的那些全栈工程师插入到一个日益专业化的组织团队中，这其实并不是难事。全栈工程师也都有自己相对更为喜欢的一个专业细分领域。你要做的主要工作就是向每一个工程师解释这个日益成熟的团队需要的是什么，再观察他们都对哪块细分的专业化工作更感兴趣。有些全栈工程师显然对 iOS 开发更感兴趣，而有些则想朝架构师方向深入发展。在你观察到了这些信息后，就和他们坐下来聊，告诉他们如果他们愿意的话，他们是可以将自己的全部精力都投入到自己感兴趣的专业化工作上的。同时要明确地告诉他们，他们所掌握的全栈技术组合是非常难得和稀缺的财富，他们今后在各自更加专业化的工作上依然能利用自己掌握的技能组合继续为公司做出更大的贡献。

　　专业化并不是说就要抛弃最初那些让公司成功起飞时的灵活性，或是将专业化和灵活性对立起来。公司早期的那些全栈工程师的认知和思考方式相对更为全面，这能够让他们在今后成为更优秀的专业化工程师。

　　以 Mike 招聘的第一位全栈工程师 Shayne 为例。我们曾经试图让我们的测试周期变得更快。开发和部署花的时间都太长。后来发现出现这个问题的根源是基础架构方面的问题，需要重写一堆 Python 脚本。当时我们没有从基础架构团队专门抽调人来专门解决这个问题，而是直接和 Shayne 说：“Shayne，你了解其中所有的知识和原理，就由你自己来负责想办法看怎么搭建一个 MacBuildServer 吧”。

　　那些拥有深厚的全栈知识的工程师是一种非常宝贵的资产，这是那些专业化工程师无法比拟的。他们能够让团队的其他成员更有效率地开展工作。

　　四. 在你还没意识到之前，其实你就已经需要为公司引入新的管理人员了

　　随着工程技术团队规模的不断扩大，你的管理领导能力也需要变得更加成熟。最开始的时候，你的团队是一个非常扁平化的团队，这个阶段，不必要的管理只会对公司的开放性和敏捷性这两项宝贵的资产造成损害。但是这并不是说创始人就应该简单地任由早期的团队进行完全地自行管理。

　　在有正式的管理架构之前，你就需要团队中出现管理行为了。

　　“管理行为”是如何表现的呢？举一个简单的例子：和团队成员进行一对一单独沟通。在公司创办一年半后我们才开始做这件事。后来，Instagram 的投资方 Benchmark Capitald 合伙人 Matt Cohler 建议我们能定期和员工做一对一沟通。最开始和员工做完一对一沟通后，我才发现，原来有这么多事情是大家不想在公开场合谈论的，一派祥和的外表之下原来也积压了这么多的问题。

　　通过一对一交流谈话，Mike 发现很多压力正在慢慢积聚，幸运的是，他们通过这种一对一谈话的方式将压力很好地释放了出来，才没有引发更大的问题。对我而言，这件事确实让我大吃一惊。作为公司创始人的你要知道，那些加入你公司的人除了在为公司的成功努力拼搏之外，他们同时还是一个个鲜活的人，每个人都有欲望、有需求，也会碰到各种问题。

　　从打造全栈工程师团队向打造专业化工程师团队转型的时候，我们就开始对团队施加更多的管理了。现在回想起来，我们应该早点这样做。

　　实施管理行为而这件事本身是至关重要的，此外，它还可以充当一个非常有价值的衡量标准。当作为创始人或早期管理者的你已经无法满足工作需求和管理任务的需求时，这时就该引入新的管理者加入了。当你觉得可能需要引入新的管理者加入时，这时你十之八九确实需要这么做。

　　不管是在 Instagram 还是在我曾做过顾问的公司，我都会发现这样一个现象，当你新增一个管理岗位时（可能你不确定自己是否真的准备好了），你就会意识到你之前只关注了所有需要做的工作中的前5% 的工作，剩下的那 95% 的工作其实都没有做，因为没有专门的人负责做那 95% 的工作。对于我们的管理者而言，他们的重点工作是加快招聘进展、做任务规划、思考 App 的未来规划。我自己一周花一天时间在这些工作上面其实是远远不够的。

　　如何通过公司内部提拔和公司外部聘请的方式寻找合适的管理者呢？下面是 Mike 提供的一些经验和建议：

　　1. 从内部提拔

　　Mike 最开始主要是通过内部提拔的方式来寻找合适的管理者的。Instagram 早期的工程技术经理大都是那些加入公司时间最长、最资深的人。这么做有一些天然的优势，让团队其他成员也更容易接受。选择团队中最资深的那些员工作为工程技术经理的其中一个优势在于，现在需要向他们汇报工作的人当时大都是由他们亲自招聘进入公司的。这本身其实就是一种管理行为，而他们日常中的工作关系大概也是这样。

　　Mike 坦承，他为这种方式是行得通的感到很幸运。但并不是每次这么做都是最好的选择。根据在公司工作时间的资深程度来确定技术经理人选当然是一个不错的办法，但是这其中也有它自己的问题。因为你肯定只想让那些愿意走上管理岗的人来担任工程技术经理。因此在这一点上一定要鉴别清楚。

　　如今，Mike 确保让公司的所有经理们都和各自管理的团队成员就职业发展规划进行沟通，并让他们找到那些对走上管理岗感兴趣的或天生就适合做管理的人员。我的管理理念是，如果团队中有工程师对走上管理岗感兴趣，如果有可能我都会给他机会试一试，并为其提供一定的指导。

　　对于那些刚走上管理岗的人也要进行跟踪，让他们知道，如果他们不想做管理了，也是有退出通道的。因为很多人在没走上管理岗的时候非常渴望能做管理工作，但真正走上管理岗之后，却发现做管理让他们非常崩溃和痛苦。对管理人员定期回访，比如每半年一次，问他们：“你在目前的管理岗位上做得开心吗？是否想承担更多的管理职责？你是否想退出管理岗，回去重新做一个简简单单的工程师？不管怎样，要确保每个人做的工作是他们真正感兴趣和擅长的。如果不是，他们就会感到沮丧失落，最终会离职，这反过来也会对团队造成负面影响。

　　2. 从外部聘请

　　即使你刚开始主要是通过内部提拔的方式寻找合适的管理者，不过在有些情况下你还是要免不了从公司外部寻找合适的管理者。以 Instagram 为例，当时公司的技术架构团队需要一位技术经理，但团队现有的工程师中没有一个人对这个管理岗位感兴趣。如果说通过内部选拔管理者让你感到有些不安，那么从外部聘请管理者会让你更加不安。这个岗位也是我们通过外部面试的方式招聘的第一个管理人员。

　　很少有目前正在管理一支年轻团队的人会出来重新找工作，因此合适的候选人其实是少之又少的。通常情况下，你希望能招到的人是那些有过创业公司的工作经验、而且现在正在管理着一支规模很大的团队的人。这些人之所以想换工作，可能是因为他们现在做到管理工作已经与实际工作发生了严重的脱节，这让他们非常不爽，因此想重新回到之前能够做很多事情的时候。一定要搞清楚他们究竟为什么愿意离开现在的公司来加入你的这个小团队。

　　一定要避免招那些嫌弃你目前的团队太小、而且还看不到团队增长潜力的人。要知道，2012 年时的 Instagram 的工程技术团队一共只有 8 个人，产品月活用户达 3000 万。从这个数字你就能知道我们的团队规模肯定会继续扩张的。但即使需要招人，我们也不能招那些看不到我们团队扩张潜力的人。

　　Mike 还记得自己和 Jim Everingham 有过的交流，2015 年他将 Jim 招聘进来担任工程技术团队负责人。在加入 Instagram 之前，Jim 在雅虎管理着一支千人的团队，但是却愿意加入当时只有 120 人的 Instagram。Jim 告诉我 Mike：“这支团队的人员规模将在几年时间内超过 500 人。”  Mike 自己都被 Jim 给出的这个数字预测震惊了。但是 Jim 看到了 Instagram 的潜力。像 Jim 这样的人就是非常优秀的候选人，你不用向他兜售你公司的愿景来吸引他加入，因为他自己已经看到了公司巨大的发展潜力。

　　简而言之，你需要那种真正有激情开发产品的人来担任管理者，只有有充足的激情，他们才愿意从一个已经非常稳定的庞大团队离开来加入你的小创业公司。作为对这些人的回报，作为公司创始人的你必须要对这些早期管理者做到足够的开放和坦诚。

　　作为首次创业者，你必须首先做到诚实地面对自己，坦承你自己也在不断地学习中。你必须要能非常谦逊地告诉比你经验更丰富的管理者：“今后我将是你的领导，因为我负责的就是工程技术团队，但是我非常愿意跟你学习。” 不要试图对你手下的经理们掩盖自己在经验上存在的不足，你要做的是充分利用它们的专业知识、能力和经验。

　　建立这样的团队关系是非常有价值的。你要能够做到非常坦诚地说：“看，我们现在正在共同学习，我的优势是我知道为什么 Instagram 是这样运作的，我也知道我们接下来该做什么。而你们拥有的是丰富的经验，知道怎么能快速执行和落实接下来要做的工作。”

　　五.  让你的团队愿意接受新的管理者

　　尽管你与你提拔聘用的那些早期经理们能够很容易达成共识，你依然需要让团队的其它成员及时了解他们的工作环境和工作角色将发生怎样的变化。作为创业者，不要不好意思。当需要招聘新的管理人员时，要提前做好沟通工作，让团队中的每一个人都知道你要招聘新的管理者这件事，并告诉大家为什么要这样做，告诉大家：“因为我自己能力有限，所以我们需要招新的管理者来进一步扩充和壮大团队。” 这样大家就会更容易理解和接受这件事。

　　在实际招聘过程中，你有几种方法可以选择。你可以采用共识驱动的方法，即你让团队中的所有工程师都对候选人进行一次面试，并将 “当团队中的所有人都愿意与某一个候选人一起共事的时候，才决定录用这个候选人” 作为你的招聘标准。但是你要记住的是，这些团队成员自己并不是管理者，他们的对候选人的评判标准通常是自己是否喜欢这个候选人。因此要让所有人都能达成共识其实是非常困难的，可能你们永远也无法达成共识。

　　相比而言，在招聘早期管理人员的时候，Mike 更喜欢下面这种更加温和的方法。首先让公司里经验丰富的管理者去对候选人的能力资格进行评估面试，Instagram 在早期经常会请 Facebook 的一些资深管理者来帮自己对候选人进行评估面试，当然其它创业公司可能没有这个条件，但依然可以请自己的投资人或其它与自己关系比较好的创业者帮自己评估候选人。一旦经过评估觉得可以录用，在 Offer 条款已经确定但还没有签字之前，先让候选人来公司待一整天。

　　对于新招聘的管理人员刚加入公司这件事，其实你很难从团队现有成员那里看到他们的兴奋激动。毕竟，有新管理人员加入就意味着一种改变。团队成员之前是直接向你汇报工作的，现在他们却需要转为向新来的管理者汇报。通过在没签 Offer 之前先让候选人来公司与团队接触一天，你至少可以在这一天中看看团队是否会给你释放这个红色警报：“千万不要招聘这个人加入“。

　　对于新招聘的管理人员，你可能听不到团队成员非常强烈的反对声音，但是依然要多留意现有工程师可能存在的很多顾虑，而且每个人的顾虑可能都不一样。

　　在你为团队招进1-2 个技术经理之后，问自己这样的问题：“新招进来的经理是如何影响团队中的每个人的？”。在我们招聘我们的第一个技术经理的时候，团队中的一个工程师对我说：“你知道吗，在我的上一家公司，我上面的技术经理两年内换了 8 个，Instagram 也会出现两个月就换一个技术经理的情况吗？” 这个人希望我能确保不会出现频繁更换技术经理的问题。所以我回答他说：“不会出现这个问题的，我相信新招的技术经理会在公司干很长时间。这是接下来的工作计划，我会将手里的一些重点工作都交由新来的技术经理负责。接下来的几周我们会一起做一对一的沟通。”

　　此外，要让你的早期团队成员都知道，公司里发生的所有这些人员变化其实都是正面的、积极的，不仅对公司如此，对他们个人也是如此。告诉大家：“相信你一定能从新加入的技术经理那里学到很多东西，你们也能够得到更快地成长。” 我相信，我们团队的早期工程师们现在一定都赞同我说的话，因为正如我承诺的，他们现在都得到了很快地成长。

　　六.  从个人英雄主义向团队主义转型

　　随着公司团队的日益成熟壮大，你需要完善优化的不仅仅是工程师的角色，你还需要让大家都有团队主义和集体主义意识。在创业早期人很少的时候，大家通常什么都要负责做，现在不一样了，现在他们有了团队。这时，要想让大家在团队作战时有成就感，你首先要做的就是让他们知道自己做的工作能产生的巨大影响。我会这样告诉大家：“你们知道吗，你们现在正在开发的功能一旦上线，使用这个功能的用户书将会比 Instagram 最初时的用户总数还要多。”

　　公司的快速增长会带来越来越多的机会，这不仅会塑造公司的产品，同时还会塑造公司的文化气质。在 Mike 看来，工程师团队在发展进化的过程中会经历两个关键的转型阶段，每一次关键转型都会对公司的增长产生重大影响。

　　1. 从全栈工程师向平台团队转型的阶段

　　你在大规模扩张阶段招聘和培养的工程师将会长期地定义和影响公司的工程师文化。当然了，让公司顺利起步的是那些早期工程师。但是，我们之所以有今天这样成功的工程师团队，我主要归功于在这个阶段在为工程师团队营造的良好环境、制定的正确的质量标准以及为团队灌输的正确理念。

　　在公司发展早期，给牦牛剃毛的全栈工程师的目光可能没那么长远，也不能在开发和架构的时候为今后的扩张考虑。但随着公司转型为更专业化的平台团队，你必须要让员工有这样的意识：开发产品的时候要更多地为今后考虑，也不允许出现混乱的开发流程，否则，两年后你就会出现巨大的技术负债。” 对于 Instagram 而言，这就意味着要培养大家的平台身份意识。

　　不管是 iOS 工程师团队、Android 工程师团队还是架构师团队，我们都想让大家明白这样的道理：“虽然我们现在只有 8 个 Android 工程师，但几年之后我们可能就会有 40、50 个工程师。我们今天需要做什么准备才能让我们今后能更好地解决扩张时出现的问题呢？”

　　通过围绕平台来组织团队，Mike 能够让团队投入更多的精力在产品质量上。以 Instagram 的 Android APP 为例，从一开始，我们就希望推出高质量的精致 Android 应用，我们对质量的要求甚至超过了平台当时的能力范畴。这种对质量的专注和重视能够让大家更好地了解他们该如何工作以及该招聘什么样的人。

　　我们在一直强调，首先要做简单的事情， 力求做到简化，而不是太过抽象。要以结果为荣，而不是以你在过程中打造的抽象东西为荣。这些价值观对 Instagram 的成功至关重要，它们在公司这个阶段的转型中被进一步具化了。

　　2. 从平台团队向产品团队转型的阶段

　　几年之后，Instagram 已经过了将平台作为自己核心工程师单元的阶段。现在已经开始围绕产品团队打造身份意识。

　　在这个阶段的转型中，时间把控非常关键。如果太早转型，你就会丧失文化打造中间阶段带来的益处。如果太晚转型，就可能会在团队中种下不和谐的种子。我们在工程师团队规模达到 150 人时才开始这种转型，这确实有点晚了。我认为当你的产品经理和你的工程师开始憎恶彼此的时候，其实就该转型了。

　　在转型之前， 负责每一个新产品的产品经理必须要找到每一个技术经理，并从他们的团队中各自要一个工程师过来负责新产品的开发。

　　现在，你开始和 4 个技术经理和至少四个工程师一起完成一项工作。与此同时，团队中没人有足够宽阔的视野了解整个公司正在开展的工作。每个人都想做能够影响全局的优先级决策，但是他们的的认知和眼光有很大的局限性。

　　通过围绕产品组建团队，Mike 得以重新做到目标导向。和当初从全栈工程师文化向专业化的工程师文化转型时所做的一样，大家选择自己感兴趣的领域去深根细作，Mike 发现这次转型在很大程度上依然是一种自我选择。你要做的就是让人们之前的隐式喜好变得显式化。例如，对于一个新产品，你可以这样问大家：都有谁想从事这个新产品的开发工作？这时，你会发现对这个新产品感兴趣的工程师是来自不同平台团队的人，通过这种方式，可以让这些人围绕新产品重新组建一支团队，共同协作开发这个新产品。

　　当你围绕你的所有核心产品组建团队的时候，你可能会发现有一些项目是没人感兴趣做的，这也没关系，因为这时你可以招聘对这个项目感兴趣的人来负责这个项目。

　　从创办 Instagram 如今，7 年时间过去了，Instagram 的工程师团队人数也已经突破 300 人，但是 Instagram 工程师团队的使命却一直没有变过。你必须要不断问自己这个问题：我们的目标是什么？我们在解决什么问题？除了你自己之外，没有人真的关心你是怎么做到这一切的，他们关心的是你的产品质量。我们工程师团队的指导原则是：将开发高质量的产品作为我们共同的使命。无论公司规模有多大，公司处在哪一个发展阶段，这个都应该成为你努力的方向。