很多人讨论过 “大公司好还是小公司好” 的话题，我也不能免俗，写过一篇《身处大互联网公司的一些反思》。严格说来，Airbnb 说大还不大，成长空间还有很多；说小也不小，和很多创业公司相比，我们的很多结构和体制已经很完善。

其实后来有个朋友说过的一句话，我十分赞同。就是对于工程师来说，尤其是职场生涯偏早期的工程师来说，能够加入一家快速增长的公司其实是最好的选择和机会。虽然这样的机会往往十分难得。

经历的两家公司，在职期间都是以很快速度在各方面增长。而和类似经历的朋友聊天，大家都会有些这样的感触：刚来的时候，大家似乎都能彼此认识。而如今，公司看到一个人，有时候都不能够确定是同事还是访客了。组也是如此。你刚加入一个组的时候，也许所有的工程师一起吃饭，一桌子就坐下了。可是后来，一起聚餐的可能性几乎为零，因为哪怕一半人缺席，也得坐好几桌。坐一起，除了知道对方的名字，可能根本没有任何的交集。

组里的活也多，人也多。怎么有效的资源分配？怎么保证每件事都能按质按量的完成？怎么保证每个人的积极性和生产力都被最大程度的调动？怎么才能让公司发展的势头和步伐不会有所阻滞？在 Square 和 Airbnb，经历了一些好的，和不那么好的政策、举措。这里面有公司的成长，也有个人的成长。虽然，我并不知道怎样做是最好的。但是，对每种变化可能引发的效应还是有很多体会。

公司增长带来的一个几乎是必然的变化，就是：大组里就开始有了各个小组。

组里的各种工作开始细分，每个小组有了相对独立的目标和管理。

记得 Jeff Bezos 提出过一个 Pizza 原则：如果两张 Pizza 不能喂饱一整个组，那就说明这个组已经太大了。而一个组太大，在 Decision Making 和 Ownership 等方面，就很容易有比较大的资源或时间开销。

然而所有复杂问题的解决方案，都一定会带来一些其他的问题和考虑。分组会让 “做决定” 和 “Ownership” 变得简单，但前提是小组之间的协调和合作都有很合理的制度。

首先就是划分每个组的 Scope

每个小组都有自己很明确的职责范围，是所有跨组协作的基础。

从短期来看，这可能和如何划分组员是相关的。一个组负责的事情，尽可能的独立，并且尽可能保证组里有员工是完成相关该项目的最佳人选之一。但是从长期来看，增长中的团队一定还会不断纳入新人，工程师也都有很强的学习和适应能力。所以大部分时候工程师的技能集并不是一个决定性的约束。项目的划分，更多时候会相对按照产品，或者按照软件架构的 Service 来分。大部分时候，会是这三种的一个平衡和组合。

其次是跨组项目 Timeline，如何保证项目按期完成

以前有好几位读者留言，提到过：“根本没有太多时间放到代码质量的考虑上，项目的期限太紧了”。关于这一点，我觉得我们似乎比较幸运。最近思考为什么没有这个问题，觉得还是得益于团队及领导人的几个做法：

所有项目期限规划，组里 Senior 工程师还是很有话语权的。很多具体的工作还是我们自己列明细目标的流程和做法。在这个迭代过程中，各个组的产品经理和技术负责人间会反复讨论，权衡资源和目标，最终达成一个平衡和共识。

每次的讨论和会议，尽量保证小而精，切实解决一个问题。会议不是用来传达信息、传达决定的。很多信息传达可以避免使用会议模式，而使用邮件等模式。

后期执行中，如果产品有需求上的改动，影响之前的计划，那么或者适量延期，或者把部分需求置后，或者增加有效工程师资源（也就是说，如果是新人，还要考虑新人培训的时间开销）。

正是因为跨组项目的时间线很大程度上，取决于每个小组能够按期完成各自的任务定额。因此合理制定每个小组的 Timeline，对保证跨组项目的 Deadline 和 Milestone 也有着很重要的作用。

组和组之间在执行过程中的冲突

当大组的功能被拆分成小组后，有些时候，不可避免的会有一些冲突：可能是大家都需要改动一块共享的代码模块，增加不同的新功能，并行开发过于耦合；可能是一个产品线或数据管道上游和下游改动的衔接和协调；也可能是大家都想实现一个类似的产品，如何尽可能的避免重复开发。

以前我只会知道，几个组的 manager 在一起，似乎经过讨论总能协商出一个方案。最近慢慢接触一些这样的讨论，加上老板的点拨，发现解决各种冲突其实需要一些不同于编程的能力和学问。例如如何理清冲突的根源，如何把问题转化为一个具有可执行性的新问题，如何界定各自的责任等等。

New Manager Dilemma：空降还是内提？

一个团队快速增长，必然导致可能需要的技术领导人也会增加。而技术领导人，往往是跨组协作中的关键，因为大部分的沟通和全局协调，还是由他/她们来完成。

通常有两个途径：一是提拔组里的资深工程师。一是从外面招聘一些有经验的管理者。而经历过的人都知道，这两个途径都是有利有弊的。新的技术人转型的领导人，因为在管理、沟通等方面也有需要学习和成长的地方，初期不可避免的会有一个适应期。而空降 Manager 则有着不同的风险，怎么才能保证他/她能真的掌握全面和底层的必要信息？怎么才能保证他/她不是照搬一套可能完全不靠谱的模式？这一点，其实很多增长中的公司包括我们自己，也都在一个不断摸索的过程中。而不管是内提还是空降，提拔和面试过程中的谨慎，会在很大程度上降低风险。各个公司情况不同，做法也不同。

当然，大组分小组，跨组协作等，都还有很多根据实际情况不同的做法和好的案例。公司增长引发的思考和话题也很多。以后再写。

最后提一下，我的关于各种思考的文章，因为我个人视角的局限性，不一定都是对的。有一些好的想法，也是受益于身边各路大牛的启发，并不完全都是自己就能悟出来。我们公司里各层的技术领导人，尤其是我的老大，我觉得这些年确实从他们身上学习了很多。

昨天有个微信群里有人提出 “没几个老板喜欢自己员工是做网红的” “我要是老板，网红的第一个开掉”。当然，我离 “网红” 还有距离，但是我还是很庆幸我身边的人并没有这样的局限性。工作之余写文章也能得到组里甚至公司很多人的支持。这样看来，我是极幸运的。