矩阵组织意味着对传统层级式组织的修正。传统组织总是有很多的竖井和饼层，很多命令与控制级别。有些矩阵组织的成功似乎很简单，他们只是把原先简单的命令与控制复杂化。这就好像节食者问他的医生，他该在饭前还是饭后吃规定的食物。并不是每个人都能理解：矩阵应该窄一些、简单一些，能够代替传统性组织，而不是再往上面增加负担。很迷人，是不是？
巨型化随之而来的总是复杂化。大部分巨型化公司通过设计复杂的系统和结构来应付这种复杂化。一个传统的寿险公司转变成了七个维度的矩阵结构。有的组织单元要面对产品、地域、顾客(按类型分)、顾客(按字母顺序分)、功能、渠道和行业。因此，它雇用了更多的员工使自己能够把握、控制这种复杂化，而这就是错误之源。这种解决方法与员工的天性是不相符的，其矛盾显而易见。一方面，规模导致了复杂化，而用一套复杂的系统或结构作为对策是十分不合理的；另一方面，要想使一家公司正常运转，非常关键的一点就是要让实际做事的每个员工了解公司事务，而这意味着要使事务简单化。
◆令人头痛的矩阵结构
公司的规模一变大，就必然带来复杂性。而大多数公司对付复杂性所采取的手段都很类似，就是设计出复杂的制度和结构。矩阵是一个听起来似乎相当合理的理论，它具体是指一旦一家公司开始经营多种业务，它就不得不调整以前那种最简单的职能型结构，即财务、销售和生产，它的精力要分散到多个重点上，也就是矩阵的次元扩大。它能够依据生产类别来组织，也可以依据细分市场来组织，还可以依据自身的生产基地或销售网络的地理位置来组织。当然，财务、销售和生产这一套基本职能肯定还不能就此抛弃不要了。但是，如果公司想把以上所有这些都包容到它的正式组织结构中，那么至少就有一个四维矩阵，而这在逻辑上将会是一团乱麻。
矩阵结构……唔，我想，用程序设计来打比方会让人更明白些。我并不是一个程序设计专家，事实上，我对程序设计只了解那么一点点。但这并不影响我的叙述，因为我了解大多数程序设计系统的基本设计思想。我要说的正是这个东西。举个例子吧，管理信息系统。在设计一个管理信息系统时，是以模块化的思想来进行的。这种模块化的思想有几个基本原则，其中一条就是：一个子程序绝不能有一个以上的母程序。这条规则避免了模块与模块之间的混乱复杂，使程序的运行清楚可行。但这正好与矩阵结构相反。一个管理信息系统就如同一个公司，而功能模块组合则相当于公司的组织结构。当模块违反了基本规则，信息系统就无法正常运行。当组织结构变成了矩阵结构，公司的业务运营也将出现各种各样的问题。这种令人进退维谷的困境，是因为现实至少确实是那样复杂的。因此，如今进行大的组织设置时，矩阵结构仍然随处可见。当你开始把其他切合实际的组织方式（如项目中心等临时性措施）也添加进去时，这种矛盾会变得更复杂。那么，作为一位管理者，你怎么办呢？
首创矩阵结构的波音公司，是这样对矩阵结构进行管理的：公司员工分成两方面工作——有人属于计划小组，负责完成一些特殊任务；另一部分则属于技术部门，忙于确保该部门保持技术领先。员工一旦身处某一小组，就完全属于这个小组。
有些企业认为，尽管他们不能把所有可能的方面全都正式地考虑到矩阵里面去，但他们至少可以利用其中一些因素搞出一种正式的结构来。这种结构能给产品经理，同时也给工程、销售和生产等职能干部以同等的指挥各科室或部门的权力。
不过我们发现，就算这样，还是令人感到很糊涂的，人们搞不清楚该汇报什么和该向谁汇报。最为严重的问题是，为了名义上的“平衡”，每件事在某种程度上都与其他事物联系起来。企业变得麻痹、瘫痪，因为这套结构不但会使事情的轻重缓急搞不清楚，而且它还会自动地削弱缓急程序。实际上，这无异于对系统里的人下达这样的指示：“样样事情都重要，每件事都给予同样的关注。”这个信息只会使公司濒临瘫痪。那些出色的公司是怎样回避这种现象的呢？回答是：办法很多，但归根结底，都是保持基本的简单组织形式。大多数出色企业的基础，是一种相当稳定而不大变化的组织形式——也许就是产品分布式（这种形式能提供一个人人都能理解的基本检验标准，并且人们据此可以探讨与处理日常生活中的那些复杂问题）。价值观念的明确清楚，也是检验稳定与简单的基本标准中的一个重要部分。
在出色公司简单结构形式方面，惟一的关键性共同之处在于：班子精干，尤其在公司一级。组织形式简单了，办事所需要的人也就少了。出色的公司中，大都只在公司一级安排少量的人员，而且这些人往往要到现场去解决问题，而不是坐在办公室里搞搞校核检