Matrix Management - Part 1

Many believe that matrix management is the best organizational structure to use in managing the development of new services as well as new products. To understand how this perception arose and whether it is true for software development companies regardless of company size, part 1 of of our series on matrix management will look at the its definition and its general history of usage.

Matrix management thought leader David Gobeli defines matrix management, at its essence, as an organizational structure in which a traditional functional hierarchy is overlaid with some lateral or "sideways" structure of management responsibility or influence. Enterprises that develop new services and products often hire or contract functional specialists in engineering, marketing, product management, accounting, client services, operations and sales. These specialists are traditionally grouped by their function and form a team or department typically managed by an individual with some singular expertise in that functional specialty. Their grouping usually comes from frequently being in the same meetings, working on the same projects, receiving project responsibilities from the same manager, and having primary offices close to others of their specialty. Each functional group works on their portion of the new service or product being developed, and co-ordination is provided by the interaction of the functional managers or in combination with upper management.

Those not yet exposed to matrix management organization, or critics of matrix management, might wonder what could justify moving from silo simplicity to the complexity of a "sideways" overlay. Wouldn't sideways equate to "cross-grained"? Tom Peters wrote over 25 years ago In Search of Excellence that a hopelessly complicated organizational structure "reaches its ultimate expression in the formal matrix organization structure [which] regularly degenerates into anarchy and rapidly becomes bureaucratic and non-creative."

Before looking in detail over what types of lateral organization can be overlaid on a functional organization, it should be noted that another organizational structure that companies might use is a pure project organization. Every new product developed becomes a project which assembles a dedicated compliment of resources. This grouping brings the totality of all required specialties onto the project. There is no separation of the development tasks across functional team boundaries; teams are defined by the product they develop rather than the function they perform or corporate service they deliver. Clearly there is a logical continuum between functional management organization and pure project organization. Matrix management structures fall somewhere on this continuum.

In matrix management, the functional (usually conceptualized as "vertical") and project (usually conceptualized as "horizontal") orientations are integrated in one manner or another for the life of the product being developed. Team members report simultaneously to both their functional and project managers. The "when" of "who" team members report to defines one of three commonly seen forms of matrix management: functional matrix, balanced matrix, and project matrix. In the functional matrix, an individual oversees the project across all the functional areas, serving primarily to plan and co-ordinate while the functional managers are responsible for managing and delivering their specific portions of the new product. In a project matrix, a project manager is chartered to deliver the product while functional managers only serve up available specialists and offer advisory expertise. In the balanced matrix, an individual oversees the project. This individual and the functional managers equally and jointly manage the functional portions and arrive at project decisions.

So now that we know where matrix managers might sit on the organizational management food chain, we should ask why have matrix management at all? With two managers to report to, can the project even succeed, let alone flourish?

Two of the main advantages of matrix management are that resources are efficiently used as specialists can be shared between projects, and that projects are better integrated as there can be a thorough follow-up on all details related to developing the new product across all specialties. But there can be other advantages: communication and quality can be improved through frequent interaction between departments, while keeping specialists together for professional development as new development projects come and go.

Don't forget, however, that Tom Peters blasted matrix management. There are disadvantages beyond the obvious overhead of having double managers. Since matrix management deliberately overlays boundaries of authority to one degree or another, power struggles over direction and access to scarce resources can arise. Also, the counterpoint to increased communication and improved quality could be a decrease in market response and release time as multiple negotiations and shared agreements must be elicited. Team members also need specialized training to understand the motivation for matrix management and how to manage the stress of when and where to communicate and respond to different managers.

In our next blog in this series, we will discuss when (or even whether) software companies of various sizes and organizational maturity should introduce matrix management into their enterprise.