Google的工程师们应该学着像公司创始人那样去思考和行动，只需要开发那些工作需要的产品和设备就可以了，简洁才是最重要的。复杂的系统既难学又难调试，更会增加维护工作的难度。要努力细化工作，使其变得有重点。
建立公司内部孵化器
马上行动！当一名员工向你递交辞呈，理由是他将加入另一家初创公司时，你应该立马回应他：“我先跟你说一下我们公司内部的初创公司孵化器。”
将聪明的人聚集在一起，让他们自由想象他们想开发的产品和设备，集思广益，就一定会出现令人惊喜的成果。事实上，我觉得每一个公司员工或者高层 都应该利用休假去公司的孵化器进行为期至少6个月的创业。可以让公司成员们轮流去，然后让他们把学到的东西带回公司。要在公司和每一个子公司所在地都至少 建立一个这样的孵化器。让公司成员们自由选择他们的工作伙伴一起去参加这6个月的创业，期间，人人平等，没有经理，没有公司例会，也没有无时无刻的监督。
要清楚地认识到，好的小创意是重要的。
这点非常重要，我一直以来反复听到的一个说法就是：如果你的想法不值十亿美元，那么就没必要浪费Google的时间。这个说法糟透了。这意味着，就算一个想法可能带来一年一百万的收益，也不如对广告和检索进行微调来得重要。
Google收购过的公司中，资产从5百万到5千万美元不等，这表示某种程度上，Google也对小公司给予了一定的重视。弄清楚这点非常重要。经常看到有人一面说着“收购才5千万美元的公司”的同时，另一方面又眼睁睁看着Google收购这些公司，这种感觉很不好。
消除“非公司产品不用”的行为
对于这点，我想说的是，不要逼迫别人一定要用Google的方式和产品来做事。有好几次我都看到一些“非Google”的设计系统因为没有采用 Google研发的Bigtable、GFS、Colossus、Spanner、MegaStore或其它任何一种内部系统而惨遭淘汰。
例如，Python语言遭到淘汰是因为他们网页运行速度缓慢。让工作团队自主采用他们想要的认为最有效的工具和语言来工作。不要针对他们所采用 的设备做出评价，要针对他们的最终产品做出评价。如果有人采用Oracle软件并基于运行在Sun Sparc 5上的一系列Perl CGI脚本开发了一个优秀的系统，那么你应当表扬他们，如果他们因为用户太多导致系统无法负荷，那就更应该因为这种成功而受到赞扬。
Google的工程师们被迫花费大量的时间优化公司的前端和后台基础设施，而在大多数情况下，这样的举动毫无益处，因为规模小的产品永远也用不 上这些重量级系统，反而时常会因为各种不必要的冗余开支，或者使用一些无法直接满足产品要求的运行不良的内部API而陷入困境。
建立多用途云供内部使用
比起Google内部的集群管理系统，Amazon EC2这一系统更适合进行重复和创新工作。EC2很可靠，让我们能够简单地开始、结束整个服务，而不仅仅是独立的过程。EC2包含长期运行的进程和开放的 源代码，用它来运行碎片MongoDB数据库实例简直不费吹灰之力。Google应该集中于研发出一款系统，能够在这个源代码完全开放的生态系统中运行。
承认20%时间是个谎言
事实上，在我整个职业生涯里，从没有见过哪个人能够高效地利用那20%的时间。是有些人在20%的时间里完成了某些产品的独家发布，我也见过一 些人充分利用20%的时间赢得内部提升，但是对于大多数的工程师而言，20%时间只是个神话我觉得这个想法很好，我们应该让它发挥作用。一周一天似乎不太 合理，因为一天的时间干不了什么事，也很难继续下去。每个月一周应该不错，但是这样做对你主要负责的项目而言不公平。我们需要在这点上有所改变，应该鼓励 工程师们花上大量时间发掘新的想法、寻找新的研究方向。真正开发内部工具和合作也许会是最好的答案，但我也不是很确定，也许我们应该就此放弃，给每个员工 提薪20%。等等，他们已经这样做了。
重复错误
工程师是从实践和犯错中学习的，如果制定系统设计规则，就会对他们的思路和产品造成不必要的束缚。如果内部人员对待事情时都抱有“Google 再也不会让Orkut上的错误再次发生”这样的想法的话，那就大错特错了。Orkut曾是个巨大的成功，造就了一段辉煌，而至今仍然如此。基础设施问题都 无所谓，甚至最近出现的一些问题，比如Wave等，都应该受到表扬，我们应该鼓励设计师们重复这样的错误。
Google规模的误区
你没听错，我就是这个意思。Google搜索产品需要大量的资源，别的产品其他几乎都不需要这么多资源，但是却被强制性按照Google规模运 行，尽管这样毫无必要。给予工程师思考和不落俗套地设计基础设施和系统方面的自由能够带来长远角度的更高效率。提供可靠的平台和数据中心能够减少冗余，提 高效率。既然一台机器就能轻易拥有64GB的内存、10TB的硬盘、八个CPU，那么如果推出的任何产品只需要用到两台这一级别的机器，那就太棒了。希望 工程师们能够打破常规，勇于犯错，敢于突破。
一个因负荷过度而崩溃的系统，即便很小，也是成功的。
如果系统一直浪费资源，并且只拥有少得可怜的用户，那么即便规模很大，也是失败的。
