在对Patrick Copeland的采访的第二部分，我们主要讨论了管理一个全球开发团队的挑战；食物刺激对程序员的作用；好的测试工程师和超nb测试工程师之间的区别；以及为何某些公司始终无法提供靠谱的软件。
问：管理一个跨越一打以上国家的团队有什么挑战？在这样的团队中管理人员、流程、产品有什么样的困难？还有，你一般几点睡觉？
答：“确保对人员的掌控”<谈到这个时他脸上挂着邪恶的微笑>不是Google的解决方案。实际上，我们的团队结构在业界是非典型的。首先，我们是扁平化架构，即使是Google新雇员，和最高管理层之间的层级也只有几步而已。还有就是公司内的那些半自治人员和团队。在这个非典型体系中，让管理者控制一切显然不太合适。与之相反，我更愿意让nb的人组成团队然后让他们自己管理自己。我的重心会放在帮助团队提高效率上。大体上来说，我们评价Google管理者的指标就是他们让聪明人完成任务的能力。而且我们认为，大部分人一旦拥有超过15个下属，就会陷入混乱，投入到真正的管理上的时间就会减少。
确保我们向同一方向努力的神器是——OKRs，这个东东是董事会成员John Doerr在2000年带入Google的。John强调由公司级目标派生部门目标的重要性；与之对应的，每个员工的OKRs应该支持团队和整个公司范围的目标。在2000年第一季度，我们发布了第一个公司级别的OKRs，其中包括“每秒800万次搜索”以及“为公司寻找CEO”。自那时起，我们已经取得了长足的进步。
问：我们注意到Google给雇员提供了大量独特友好的工作环境。对于你们的工程师，这些手段是否依然有效呢？或者（如同我们在uTest做的那样）你们正准备把工程师拷在桌子上，然后他们每写一行代码你们扔一个小食品以示奖励？不开玩笑了，真正的问题是，如何保证开放的环境下工程师依然可以做出出色的软件？
答：我们有开放的文化，工程师有足够的自由去探索他们感兴趣的领域。我们有一个“20%时间段”，在这些时间中我们鼓励工程师去探索他们主要业务之外的领域。
（好的）文化会衍生出好的产品吗？我们这么认为，但是这二者之间的关系很难判定。有些人会倾向于使用那些“产品化度量”：代码行数、签入次数等等。我们（非正式的）阻止这种做法，因为类似这种度量会造成一些不可预知的问题：例如人们会使用一些“技巧”，以在系统中获得“所谓的成功”。（除了带给最终客户的创新）我们衡量绩效的最重要方式是每季度一次的同事评审。这种系统会强化你对团队工作的认识，确保你在同事中拥有影响力，并建筑尊重。这种评判是主观的，可能看上去很难操作，但是对于塑造个体价值功效显著。
另外，扔食物在我们那里必然没效果，因为在Google员工可以免费享用各种美食。
问：好测试工程师和卓越的测试工程师之间有什么区别？
答：好的测试工程师是可以训练出来的。基础的要求有：计算机基础知识，对于应用领域的认识，对于客户用例的强力理解，客户角度的视野，对于度量的把握以及对开发流程的关注。
卓越的测试工程师则意味着传说中的10%，他们非常罕见和稀有。不是每一个人都可以成为卓越的人。从个人经验角度看，卓越的开发工程师并不一定能成为卓越的测试工程师，但是卓越的测试工程师（拥有很强的设计能力）则可以成为卓越的开发者。这与一种心态和激情有关。从超过100次面试得来的经验看，我认为，卓越来自于：1）一种发现问题的特殊潜质；2）被潜质指引去测试和发现问题的激情。换句话说，他们喜欢测试并且善于测试。他们也常常感觉到测试中的挑战，大于等于开发中的挑战，并为之感到特爽。一个大牛测试工程师，他们有测试的基因，正确的态度，他们总是很容易的找到一份工作。他们就像金子一样的宝贵。
问：您认为，导致我们无法在带着（交付日期，优先级，竞争）镣铐下制作出高质量的产品的最大原因是什么？换句话说，为什么不是每一家公司每一次都可以发布世界级的产品？
答：我经历的每个产品都有不同的故事。每个故事的情节那就是有一句说一句了。某些产品我们几乎可以掌控全部（例如技术选择）。而另外一些产品中我们只能控制一部分。有些因素则完全不受我们的掌控（例如竞争对手想咋整）。
有些公司试图开发一些规范的流程。这些看上去冠冕堂皇的流程都说自己可以：提高效率，消灭不确定性，维护质量，如此等等。这些重口味开发流程在造大灰机的时候灰常有用——这也确实被一些nb飞机制造商证明了。不过在程序猿们看来，这种流程可能过于繁杂，会破坏他们创造软件的心情。相反的，木有流程的流程则可能导致你的开发无法被复制。你需要在大流程和没留成之间做出平衡。
让我们把灰机制造和软件开发过程放在一起比一比。在飞行条件具备和飞行员有经验的情况下，制造灰机的核心就剩下了平衡必要条件：超重或推力不足在一些情况下就会导致灾难。同样的，对于团队，产品和流程这些虚拟因素也是如此。例如，在项目后期猛招工程师是没法提供升力的。再比如，采用一套新流程可能会给团队带来一时的新推力，但是也可能在中长期破坏团队的创新能力。
敏捷开发的流行说明程序猿们需要更好的平衡和创造性。我们的软件质量也确实提升并且过程可控了，我们必须鼓励创新。我们需要鼓励那些给客户带来价值的或者是解决了困难问题的奇思妙想。话句话说，我们要保持团队在天上自由的灰啊灰。