不会带团队的领导,只能自己干到死.pdfVIP

不会带团队的领导 ，只能自己干到死 仅仅用了 4年 时间 ，A dam Piso ni 就帮助 Yammer 从一个仅有 5 个人员 的小团队发展成一 家员 数超过 500 人、市值数十亿美元的大公司。如今的他再次启航 ，重新创办了一家目前 同样只有几个员 的新公司。这时有个问题一直在他脑海中挥之不去 ：“这次创业 ，我想要什 么不一样的东西呢 ？” 作为创业者 ，你当然希望自己能创办一家伟大的公司 ，所有员 都能相处融洽 ，大家都很拼命地 作 ，也能为公司盈利。然而现实情况是 ，你会发现自己在很多时候并不是非常信任自己的同事 ， 每天都像疯子一样在公司里跑来跑去 ，想试图去跟踪了解每一个员 的 作情况。你想通过这种方 式确保大家都没有犯错 ，不过这无形中已经影响了大家的 作效率。而你还在想当然的认为 ，如果 不确保自己时时刻刻都掌控着这一切 ，整个公司就会乱套。 上面这个现象反映的就是目前大家对如何成为一位出色的公司领导者存在的一个普遍误解。如果你 是公司创始人 ，你很有可能会将自己的全部精力都聚焦在研发优秀的产品上。但很快你就会发现 ， 你需要将自己的思维方式从开发优秀产品转变为打造一个能够开发优秀产品的公司。这是一个很微 妙但非常重要的思维转变。如果在公司什么问题都需要你出面解决 ，你的公司就不可能发展壮大。 不久前 ，Piso ni 在 First Ro und CEO 峰会上就公司创始人思维如何从自己开发优秀的产品转变如何 打造成一家能如何开发出优秀产品的公司分享了自己的看法 ，这对创始人和团队负责人都很有借鉴 意义。此外 ，他还分享了创始人如何从日常琐事中抽出身来 ，从将有限的时间用在最重要的事情上 。 康威定律 ，从琐事中抽出身来 曾经有一段时间 ，我努力确保每一件小事都不出问题 ，然而我却发现 ，在这个过程中我我忽视了很 多其它我更应该思考和重视的问题。我当时甚至不知道这些问题的存在 ，过了很长时间以后才知道 。那段时间 ，尽管我们已经有几十号员 了 ，但我还是忙得脚不离地 ，尽最大努力自己多做事。我 会参加绝大部分的公司会议 ，员 遇到不管遇到什么问题都来问我 ，而我必须要为他们提供解决问 题的方案。这种忙其实并非好事。 这里存在一个真正的危险 ：作为领导者 ，你可能会为自己的异常忙碌而自我感觉良好 ，感觉就像自 己为公司创造了多少价值一样。其实背后隐藏的是正在快速堆积的层层危机。 那段时间 ，我没有时间停下来去思考。然而当其中一位 程师向我说起康威定律时 ，我顿时愣住了 ，立刻决定花时间对此进行反省。康威定律的大概意思是这样的 ：“公司开发的产品和服务其实都是 公司自身组织架构、沟通与 作方式的反映。” 确实如此 ，很多时候 ，我们从产品和服务的架构就能 看出公司的组织架构。 在 Yammer 发展初期 ，我只负责监督一个小的 程师团队开发最初的产品 ，他们都在代码库里开发 ，然而随着越来越多 程师的加入 ，那个代码库变得日益庞大 ，也愈加难以管理 ，就像日益庞大的 程师团队本身面临的问题一样。只有当他们将所有 程师分为不同的小组后 ，他们也得以将庞大 的代码库巧妙地分解成不同的小服务。我发现 ，人员的组织架构是可以改变产品的架构的。 在上个世纪 90年 代 ，我还是一位 web 开发者 ，那时还没有任何流程的概念 ，人们也不重视这一块 。 程师只是简单地在网络服务器上编辑活动文件。那时也没有所谓的测试 ，更没有版本控制。如 果放在今天 ，那样绝对乱套了。现在我们要想让众多 程师在一块高效 作 ，我们就需要有一个开 发方法学。除了适用于 程师的开发方法学外 ，现在很多公司甚至缺少一个有效的组织方法学 ：一 个不是什么 作都要你亲自来管的情况下依然能确保公司高效运转的系统或流程。 在 Yammer 的时候 ，我们做的非常正确的一件事是 ：持续迭代和完善开发方法。随着团队规模的 扩大 ，团队的开发效率反而降低了 ，这迫使大家不得不思考这样一个问题 ：“一个团队在黑客马拉松 上开发产品的速度为何比平日里开发快那么多 ？” 大家开始意识到 ，因为我们平时同时在开发的东 西太多 ，而在开发过程中的沟通效率却又非常低效。大多数时间里 ，人们需要同时兼顾多个项目。 后来我们制定了一个规则 ：在一个新项目所需的全部人员没有齐备并可以完全投入到这个项目里 之前 ，我们是不会启动这个项目的。一旦人员齐备 ，我们会赋予这个新组建的项目团队绝对的自主 权和决策权 ，不需要外部授权审批就能独自把项目做好。一般情况下 ，一个项目 2- 10 周能完成。 一个项目完成后 ，团队就会解散 ，大家再各自进