争论不是问题，问题在于没有争论
当然做自己喜欢的事情并不是意味着天马行空，因为没有人能够独立完成一个大型项目，只有当你的观点被大家认可，你的项目才能赢得更多同事的参与，才能够更快成为一个真正的产品被发布出来让用户使用。而在这样一个拥有着无数“最聪明”工程师的企业里，要说服别人，显然并不是一件容易的事情，因此争论无可避免。
这里，我们就不能不提及Google精神中的另外2个方面：用户至上(user-driven)和动手不动口(prototype)。“用户至上是Google精神的核心，也是我们去衡量一个项目价值的标准，关于这一点绝对不会有争论。”Peter说，“因此争论的焦点往往是，这么做是否对用户有价值;如何做更有价值……但是，语言的力量总是有限的，特别是对于产品和技术的讨论，同样的一句话，每个人的理解都不一样，如果这个工程师真的已经胸有成竹，觉得这个东西已经可以成为一个东西了，那他完全可以放手去做，动手不动口，先动手做出一个产品的雏形出来，把实物拿来讨论，胜过千言万语的争论。”
翻译团队里就曾经有过这样一个例子，一个工程师提出一个方案，无论如何给同事们讲，大家都不能理解，去向美国同事讲、向老板讲，人家都觉得不可行。这个工程师实在没办法，自己先做出一个模型，再拿去给美国同事一看，没想到对方拍手称赞：“哎呀，这就是我们两三年就开始想做的东西!”
除了个人做出雏形产品的方式提出新方案，团队也会定期开头脑风暴会，让大家说说最近的产品想法。然后大家再讨论，看哪些是比较可行的，到方案比较成熟的时候，还可能会联系其他项目、地区的团队，大家一起来讨论这样的应用是全球的市场需要，还是区域市场的需要，最后给产品做出定位。
对Google的工程师来说，要直接面对的批评，或者必须直接向同事提出的批评，更在于代码的评审。因为不论你做到什么级别，你写的代码必须请团队的另一个成员去重新看一下，只有当团队成员说：“OK!”你才能提交。并且在代码评审的工作中，没有任何级别限制，就算你是一个刚来的新人，仍然可以对代码提出任何意见。
Peter也表示：“代码评审其实还蛮不容易引起是非争论，其实在平常工作中，我们更倡导对产品的设计理念等直接提出不同意见。以前我的团队里就有一个同事，每次开会我讲到一半，他就会跳出来说：‘错!’我不但不会觉得恼怒，相反非常喜欢这样的风格，因为有多种不同意见是好事，大家要习惯接受好的意见。如果团队成员都抱着‘你不要得罪我，我也不会得罪你’的想法，一定激荡不出好东西。其实总体上来说，Google的工程师们都还蛮谦和，很喜欢为一些具体的事情去争吵，这个过程本身就挺能够增进友谊，往往带来的只是更多新的观点，而不是人与人之间的矛盾。”
老板不是权威
要创造真正平等的讨论环境，自然不可能是老板的一言堂，但Google做得似乎更进一步。在Peter刚刚进入Google的时候参加新人培训，其中一句话令他记忆犹新，并且时刻提醒自己作为行事准则：“经理需要为工程师提供制胜的资源，然后躲一边去。”Peter对此的理解是，要极力避免因管理而阻碍创新。在“带领”翻译团队工作时，Peter会在每季度初期和大家一起制定研发目标，然后他的工作就是调动一切方法，确保工程师们有足够的资源，并且尽量避免微观管理(micro-management)，比如说，尽量不开会;有疑问主动去找工程师问，而不是让工程师过来汇报或者写报告。虽然也会对工程师的设计方向提出一些意见和反向思维供他们参考，但一定不会一开始就否定。“总之，我不断提醒自己：‘我是来提供方便的，而不是来做领导的。’”Peter说。
Peter甚至还自称自己是整个团队中附加价值最小的那个人，希望大家觉得自己就是一个“跑腿的”。“我时常这样来形容翻译团队：经理负责造船，技术领导负责掌舵，工程师负责划桨。掌舵没有划桨的配合，也没有办法到达目标。划桨的人也可以影响船的方向。最无法影响方向的其实就是经理这个造船的人。那么我就应该做好后勤的工作：工程师们可能缺机器;可能需要跟另外一个团队去沟通;可能会缺人手……这些都由我负责去帮大家要：要人、要机器、要资源……但是我拿来以后，我就犯不着说自己来决定，要来的人需要做什么;机器该怎么用……团队中十多个那么聪明的人加起来，至少比我聪明十几倍，我这么做不是在浪费他们的脑力吗?”Peter一本正经地说。
