古老的博弈——系统部门VS.应用部门
1992年，在微软高级管理层的变动中，最引人注目的便是公司将系统和应用部门正式地整合在一起。在过去，各项目组都直接向盖茨进行汇报，而现在它们则划归迈克·梅普尔斯统一管理。由于这两个部门之间长期排斥对方，但是它们之间的战略依赖性又变得越来越高，因此将它们整合在一起很有意义。应用部门只有深入了解Windows如何运行才能写出好的应用软件，从而对Windows与一些技术（如OLE）的演进施加关键影响力；另一方面，如果以微软为首的应用软件制造商不再编写应用软件，那么新的操作系统，如Windows NT，就绝不可能在市场上占据一席之地。问题在于，历史上微软的系统与应用部门从未和睦相处过。虽然系统软件往往更难开发与测试，但系统部门的员工（尤其是Windows 3.1和Windows 95的开发者）与在应用软件部门工作的同僚相比，管理却更为松散懈怠。
梅普尔斯曾经成功地使应用部门管理更为规范，做到以质量为本。他对系统部门也进行了相同改革，这一行动一直延续到1995年。虽然他的举措赢得了一部分经理的支持，如戴夫·卡特勒（在加入微软前在DEC工作），但遗憾的是，他最终没有完全获得成功。他总结教训时说，他将重点放在用户问题与产品进程上，但由于受两个基本因素的影响，这种作法更适用于应用软件部门而非系统软件部门。首先，操作系统必须能够在各种不同类型的硬件上正常运行，而对各种不同硬件进行测试需要“冗长及大规模的beta测试”（指从用户的角度对初级产品版本进行测试），以便让用户能够使用机器与应用配置的不同组合来测试系统产品。但这种测试的进程难于预测。其二，梅普尔斯发现操作系统项目一般需要更多的员工，其组件也与许多不同产品相互关联，这使得项目管理非常“笨重”，他说：“应用软件部门效率较高的一个原因是他们能够以小组形式工作，这一优势使得交流更为便利，依赖性也较少。但系统软件部门的队伍庞大，相互依赖性强，因此这两个部门的工作过程截然不同。坦诚地说，应用软件部门的小伙子比系统软件部门的小伙子更易享受到工作过程的驱动，这并不是我的主观臆断，而是事实。”
这便导致了在系统软件部门内部经常会出现一些混乱局面，这种状况甚至波及到了形象极佳的Windows 95项目。不过Windows NT却是一个例外，正如梅普尔斯所说的：“哪怕是在系统软件部门内部，各产品开发过程之间的差异也很大。Windows NT组的主管戴夫·卡特勒管理得就非常严格，他们专门准备了一本工作簿并记载该项目的所有事项……这是一种非常严格的开发程序。而Windows组与DOS组却与之相反，他们更像一帮持枪的乌合之众，毫无章法可言。他们常满不在乎地说：‘让我们开始编程吧，看看会出什么结果’。”不过梅普尔斯认为所有的系统软件组都必须集中更多的精力以减少产品缺陷，并提高完成日期的预测准确率。
虽然两个部门泾渭分明，两者间的界限也正在逐渐弱化，但两方的经理们都认为系统软件部门比应用软件部门问题更多。克里斯·彼得斯在成为Office副总裁之前，是MS-DOS 2.0和Windows 1.0（还包括不同版本的Excel和Word）的开发人员。他曾强调公司在编写说明书和项目管理方面缺乏有效的控制：“你会发现系统软件部门比应用软件部门更加缺乏组织性……我从不认为他们拥有合适的说明书……他们会说，我们在这项目中采用的是里程碑式的技术，但当你询问他们在项目中总共有多少个里程碑时，他们便会无言以对。”Windows NT的高级产品经理理查德·巴斯同意克里斯的上述看法，他说：“当我在1990年刚加入到微软时，就发现应用软件部门和系统软件部门在管理方法上存在着巨大的鸿沟。事实上，从系统软件部门来看，我们一直都时刻关注着应用软件部门，并认为他们管理有方，在他们那里开发过程能得到更为有效的控制。”
史蒂夫·鲍尔默独特的管理风格，是系统软件部门特殊文化氛围形成的一个重要原因。多年以来，他更偏向于营造相对宽松的环境，不设独立的测试组，给予程序经理和开发人员很多创新的自由空间，甚至还允许在开发末期对产品进行改动。MS-DOS与Windows的前任测试主管戴夫·马里茨（现在已离开微软），曾经这样评价他的老上司史蒂夫·鲍尔默：“他十分精明，不过在他下面做事很困难，因为他总是那么随意……他绝不是那种做事井井有条的人，这也导致了他无法控制系统软件部门。”Office组的高级程序经理迈克·康特，指出了系统软件部门形成独特文化的另一个原由：
我认为他们现在仍在进行着许多观念的转变，其中之一即从面向OEM转变为面向最终用户……从一定程度上来说，这正是微软的历史和文化。史蒂夫·鲍尔默是系统软件部门的最高权威。他不是那种有官僚做派、有板有眼的人，正因为如此，规范化并没有影响到系统软件部门。另一个原因就在于他们倾向由技术来主导一切，开发人员拥有更多的发言权。但缺乏严格组织的开发人员却很不理性，如果依着他们的性子去做，那就可能无法顾及市场需求、用户支持或其他的一应原则。所以系统软件部门一直没有出现好转。尽管应用软件部门曾经一度也如同美国西部大开发一样毫无章法，但迈克·梅普尔斯却将它治理得井井有条，相比之下，系统部门却从没经历过这样的约束。不过以上的观点来自于应用软件部门的一位员工，所以你可以对此持怀疑态度。尽管史蒂夫·鲍尔默已经离开了系统软件部门，但他在公司内具有很高的威望，因此他仍然保持着强大的影响力，除此之外，盖茨更是对他言听计从……但迈克却是一位善打持久战的人物，他不会初来乍到就发号施令：“好吧，让我们打破一切陈规，按我的方式开始干吧。”他的做法与之正好相反，我想他会潜移默化地改变身边的事物。
微软的员工大都赞同康特的这一观点，并将这一观点归结到为何系统和应用两个部门有诸多不同的原因之中。人们甚至还提出了一种地域上的差异解释：应用软件部门坐落在整个微软园区内更具现代风格的北部地区，一条大路把“宏伟豪华的棕色大厦与南部郊区”分隔开来（戴夫·马里茨如是说）。尽管应用软件部门的条件相对更为优越，但盖茨仍然将他的办公室与系统软件部门设在一处。产品的不同技术特性也成为了导致差异性的重要的一环，不过由于操作系统中用户界面和功能变得越来越重要，这种差别已在逐渐缩小。产品开发主管克里斯·威廉姆斯认为系统软件部门的员工在取得更多的实践经验后会逐步改变他们的立场，他说：
系统软件部门的员工始终认为一个产品在成熟之前不应进入市场，因此他们采用了截然不同的软件开发方法……我想你必须切身经历过三、四个项目周期，就能数次体会到糟糕的管理过程所带来的痛苦……而一旦考虑到那些在系统软件部门工作的员工，他们的的开发周期……比应用软件部门的要长两倍。刚从Windows NT组离开的家伙跑到我这儿来抱怨：“我们再也干不了！”至于那些在Chicago（即Windows 95项目）组工作的同仁，我估计等产品推出以后也会有一部分跑到我这抱怨相同的话……这便是这两个部门的本质区别。我认为另一个重大区别就在于，在系统软件部门内负责具体项目的人都是那些曾经获得过成功的人。毫无疑问，Windows 3.1是一个相当成功的项目，人们正是用老式的方法成功地创造了这个软件。既然它并没有遭受失败，你怎么能指望他们尝试着进行改变呢？
