Google新任CEO拉里•佩奇宣称希望使Google恢复创业初期的面貌。为此，一名曾在Google工作过五年的员工Slacy发表了一篇博 文向拉里献计献策。Slacy称，Google应让工程师可以专心进行编程和设计，而不是处理一些琐事。公司的集群管理系统严重影响工作效 率，必须立即废弃。另外，Google应放低姿态，虚心像外界学习，重视一些小的好创意。为了防止其他初创公司挖角，Google应建立内部初创企业孵化 器，帮助员工自 主创业。
以下为原文翻译：
2005到2010年间，我在Google工作，见证了公司经历的种种变化和员工队伍的不断壮大。最重要的是，我亲眼看着曾视工程师为激情四溢 的破坏者和创新者的Google逐渐变为奉“Google方式”为最高准则、容不下新锐想法的公司。因此，我认为拉里如果想把创立之初的感觉带回 Google，就应做出下列举动：
让工程师们各尽其用，其他的一切都不用他们操心。
这大概是最重要的一点。在Google，工程和产品设计以外的事占用了工程师们太多的时间。他们应专注于创造优秀的创新产品，这一点高于其他一切。以下简单总结了我离开Google时对工程方面的所有不满：
编译及修改其他人开发的代码。这是Google C++开发者们面临的严重问题。他们花费大量时间编译（及修改）别人的代码以使自己的项目得以进行。这一切应该到此为止了。应停止分发源代码使不同团队之 间相互依赖，并让Bigtable、GFS、Stubby、Chubby等团队把在交付二进制文件和头文件时把格式整理规范点。
对低于拍字节的产品实现机器资源请求。只需要免费提供这些资源，监控使用情况，一旦超过了很高的上限就开始收费。这有什么难的呢？
LCE和SRE方面的阻挠。拥有LC（发布合作）和SR（网站稳定性）团队的支持是很好的，但当他们说“除非……否则你不能发布程序”这样的话，你就知道他们已不是帮助，而是障碍。
会议。事实上，人们被大量的“状态更新”和“组内汇报”等会议搞的焦头烂额。“周四不开会”的公司是不好的，那“除了周四都不开会”怎么样呢？也许这样能使工程师团队更加高效地工作。
每周琐事，工作表现等等。我一直惊讶于每周的额外工作量。也许这些事听起来很重要，但工程师的工作应该是编程和设计。
工作表现、面谈和冗长的面谈反馈。坐在一起讨论候选者情况的老办法其实有效率的多。公司应保证每个工程师都参与面谈过程，这样才能将压力分散。别让内部招 募人员挑选工程师做面谈官，因为他们各有偏爱而且没有适当激励。应限制一周最多一个面谈。可制定一个简单的体系，制定简单的规则禁止“我不能做这个面谈” 或“我觉得这个简历很糟，不想浪费时间和这个候选人谈”这类行为
不鼓励使用开源软件。开源领域正发生着很多创新：在使用简便性和专注于产品方面，和Hadoop、MongoDB、Redis、Cassandra、 memcached、Ruby on Rails、Django、Tornado（网页框架）等许多其他产品相比，Google的基础设施显得很差。Google不鼓励工程师们用这些系统，甚 至即使他们想用除了Bigtable/Spanner和GFS/Colossus以外的产品都会被指责。
废弃集群管理系统
确实需要这样做。这是个徒有其表的批量任务预定系统，让新式的数据中心看起来像古董大型机。初创公司用的是专用的机器和资源，把它们给最好的工 程师们，他们能够很好地利用这些机器。Teragoogle小组的事例就很好的证明了这一点。应开始打造更好的基于虚拟机的系统，工程师自己可以拥有并管 理设备映像，包括操作系统和代码依赖性（Dependency）等等。如果需要添加结构，可以用现有的开源软件包或者内部开发新的系统并开放它们的源代 码。建立不使用旧系统，每个工程师都能使用的新型“非标准”数据中心。
集群管理系统不允许在本地长期存储，因为任务随时可能被终止或转移。为了长期储存，必须使用Bigtable和/或Colossus运行服务，这实际上排除了其他所有外部数据库系统（MySQL等等）。这是一个过时、过度约束的工作分配模型。
转变为基于团队的分布式源代码控制
团队应管理它们自己的源代码，只提供基于Git的虚拟主机。团队之间交付的产品应是发布二进制文件而非源代码。应该废除团队间的文件生成类的依赖性。
反思那个“大量多余且不可靠的硬件”的咒语
对于灵活的初创公司来说，推出一项简单的服务必须使用全世界的众多数据中心或几乎每周关闭数据中心进行维修都将是不可接受的。初创公司需要专注 于产品开发，而不是流程和基础设施。一个持久运行的亚马逊EC2实例比每周都要维护的集群中的100个批量预定任务更有价值。停止这样做吧。
消除NIH综合症
Google有很严重的NIH（非原创）综合症。替代解决方案（Hadoop、MongoDB、Redis、Cassandra、MySQL、 RabbitMQ等）都被视为技术上落后、低级的工程系统。Google应放弃高高在上的心态，看看外面发生了什么。Twitter等高度可扩展服务都建 立在几乎完全开源的基础上，并且它们都运行得很有效。开源解决方案有Google基础设施所缺乏的对产品的专注，能为工程设计提供帮助。首先专注于产品， 并使用任何可用的解决办法才是在新领域试验的灵活办法。
此外，消除NIH综合症后，Google需要在产品环境中包容这些开源系统。亚马逊和RackSpace已确立了可靠的虚拟主机解决方案，使建立在这些平台上的服务变得便携、高效且灵活。
始终铭记：明确具体的目标往往比宽泛空洞的大目标更为灵活和重要。
Google以擅长建立大型基础设施来解决一些重大问题而出名，比如用于文件存储的GFS和Colossus，用于结构化数据存储的Bigtable、Blobstore和Spanner，以及用于文档存储和检索的Caffeine。
然而，当新的要求或问题出现时，公司往往要根据新项目的需求把它们细分到上述设备系统中的某一具体类项，如果归类错误就会被指责。此外，当现存 设备的功能无法满足新项目的需求时，要求改进或增强设备性能的呼声淹没在噪声中。这意味着，这些庞大的体统由于缺乏灵活性，从而也削弱了一些小团队的工作 能力。
