Yammer创始人团队管理经验：打造一个能解决问题的团队

Adam Pisoni曾是Yammer的联合创始人，仅仅用了4年时间，Adam Pisoni就帮助Yammer从一个仅有5个人员工的小团队发展成一家员工数超过500人、市值数十亿美元的大公司。

不久前，Pisoni在FirstRoundCEO峰会上就公司创始人思维如何从自己开发优秀的产品转变如何打造成一家能如何开发出优秀产品的公司分享了自己的看法，这对创始人和团队负责人都很有借鉴意义。此外，他还分享了创始人如何从日常琐事中抽出身来，从将有限的时间用在最重要的事情上。

Adam Pisoni的核心观点是：作为公司创始人，你不能什么问题都要自己解决，你要学会打造一个能够解决问题的团队和公司。不会带团队的领导者，只能自己干到死。

以下是Adam Pisoni分享的团队管理经验：

康威定律，从琐事中抽出身来

曾经有一段时间，我努力确保每一件小事都不出问题，然而我却发现，在这个过程中我我忽视了很多其它我更应该思考和重视的问题。我当时甚至不知道这些问题的存在，过了很长时间以后才知道。那段时间，尽管我们已经有几十号员工了，但我还是忙得脚不离地，尽最大努力自己多做事。我会参加绝大部分的公司会议，员工遇到不管遇到什么问题都来问我，而我必须要为他们提供解决问题的方案。这种忙其实并非好事。

这里存在一个真正的危险：作为领导者，你可能会为自己的异常忙碌而自我感觉良好，感觉就像自己为公司创造了多少价值一样。其实背后隐藏的是正在快速堆积的层层危机。

那段时间，我没有时间停下来去思考。然而当其中一位工程师向我说起康威定律时，我顿时愣住了，立刻决定花时间对此进行反省。康威定律的大概意思是这样的：“公司开发的产品和服务其实都是公司自身组织架构、沟通与工作方式的反映。”确实如此，很多时候，我们从产品和服务的架构就能看出公司的组织架构。

在Yammer发展初期，我只负责监督一个小的工程师团队开发最初的产品，他们都在代码库里开发，然而随着越来越多工程师的加入，那个代码库变得日益庞大，也愈加难以管理，就像日益庞大的工程师团队本身面临的问题一样。只有当他们将所有工程师分为不同的小组后，他们也得以将庞大的代码库巧妙地分解成不同的小服务。我发现，人员的组织架构是可以改变产品的架构的。

在上个世纪90年代，我还是一位web开发者，那时还没有任何流程的概念，人们也不重视这一块。工程师只是简单地在网络服务器上编辑活动文件。那时也没有所谓的测试，更没有版本控制。如果放在今天，那样绝对乱套了。现在我们要想让众多工程师在一块高效工作，我们就需要有一个开发方法学。除了适用于工程师的开发方法学外，现在很多公司甚至缺少一个有效的组织方法学：一个不是什么工作都要你亲自来管的情况下依然能确保公司高效运转的系统或流程。

在Yammer的时候，我们做的非常正确的一件事是：持续迭代和完善开发方法。随着团队规模的扩大，团队的开发效率反而降低了，这迫使大家不得不思考这样一个问题：“一个团队在黑客马拉松上开发产品的速度为何比平日里开发快那么多？”大家开始意识到，因为我们平时同时在开发的东西太多，而在开发过程中的沟通效率却又非常低效。大多数时间里，人们需要同时兼顾多个项目。

后来我们制定了一个规则：在一个新项目所需的全部人员没有齐备并可以完全投入到这个项目里之前，我们是不会启动这个项目的。一旦人员齐备，我们会赋予这个新组建的项目团队绝对的自主权和决策权，不需要外部授权审批就能独自把项目做好。一般情况下，一个项目2-10周能完成。一个项目完成后，团队就会解散，大家再各自进入其它项目。通过这种方法，公司创始人就不需要凡事亲力亲为。例如，践行上面的规定后，我就不需要亲自过问开发架构或编码规范，他们自己完全可以高效完成。

作为领导者，你的目标是建立一个不再依靠你、甚至不需要你的组织架构和工作流程。