Why Matrix Groups don't work

First hand experience and some simple thinking.

I just went through another night of CompanyX/HeavyMatrix had 10 people work from 11pm to 5am moving 2 servers 10 feet. It was an amazing effort that the typical person could have completed within 30 minutes, including a 10 minute pat-on-the-back. The 10 people were from 6 different matrix'd groups - and it just happened that the one person needed wasn't present because 'his group' was not requested via proper channels. SOP for CompanyX.

Let's think about programming for a bit. In programming you have concepts of highly coupled and complete function concepts. Highly coupled relates to different functions/procedures that rely heavily on each other via mass info being passed back and forth and each having to know the other's operating behavior to work properly (something object oriented approaches addresses). Complete function is the same idea - a function should perform a simple/complete/unique operation so as to reduce complexity and cross procedure/function communication. This was an area in programming highly focused on, because it's a known that, HEAVY COMMUNICATION BETWEEN FUNCTIONS INCREASES RISK OF FAILURE. Basic programming understanding that is not yet understood in most corporate environments. Usually each individual function does not fail because of it's internal processing, it fails because of the communication received/sent. Same is true with groups.

Basically, the more the cross team communication, the higher the risk of failure - failure in this case is defined as miss-communication. It's the links between the groups/teams that cause the majority of issues:

• Communication from Users to IT
• Communication from IT to Production
• Communication from Management to Staff
• Communication from developers to QA
• Communication from Analysts to developers
• ETC.

Agile/XP methodologies (mostly focused on development) address this by having complete teams in a single room. Probably one of two (the other being Test Driven Development) MAJOR benefits of Agile/XP. Typical response to having 'complete teams' ie Project focused instead of discipline (QA, DB, etc.) focused. The typical response to complete teams is 'How can we afford to have a team made up of customers, developers, QA, etc. - there might be some slack time - who will mentor the developers.....' The real question is 'If the project is worth it, how can you not do the most important thing to ensure it's success'. The excessive communication required with matrix groups is well documented and known to be exponential.


Development teams like functions in code should be de-coupled and complete - a development team should be a self contained team that can perform a simple/complete/unique project. This is the key to success and addresses the Highly Likely/Highly Impact'ful Risk of miss-communication.