How often have you read a job description including language something like “Must be comfortable operating in a matrix-management structure”? This denotes that team members report to multiple bosses, and in a software development context often means each team member has their “functional” boss and their “project” boss. Typically, one of those relationships is considered “solid-line” and the other “dotted line”, but to be sure both managers exert some level of authority over the team members.
Since the 1970’s, countless articles and papers have been published about the concept of matrix management, and like most things in our society the reviews are mixed. I recently came across a paper from 1994 citing matrix management as one key reason for the downfall of Digital Equipment Corporation, at one time the second leading supplier of computer systems in the world. A May 1978 article from Harvard Business Review decries the “pathologies” of matrix structures, while another article from McKinsey as recently as 2016 extolls the virtues of this approach. After reading many such articles, and reflecting on my own personal experience over thirty years, my conclusion is that done well a matrix structure can be incredibly powerful, but done badly it can mean the death of an organization.
A Typical IT Project-Oriented Matrix
Most clients I’ve worked with in the Tech industry are very familiar with matrix organizations and use them routinely to execute large projects and programs. The typical structure follows functional silos as the primary or “solid-line” axis, while cross-functional project teams are temporarily formed by cutting across these functional boundaries, and assembling team members from each silo.
This functional silo orientation matches very well the typical phases of a waterfall project, which I suppose is why it has been so popular over the decades. It does however lead us toward the problems cited in numerous articles:
Lean-Agile Suggests We Pivot the Matrix
The bottom line for any Agile organization is the delivery of value. Therefore Lean-Agile practitioners recommend creating long-lived, cross-functional teams aligned to value streams, rather than forming and dispersing teams as projects come and go. If your teams align to products or the value streams those products support, they will be together long enough to bond, to adapt lean-agile practices to their unique needs, to learn from multiple project experiences together, and to have a chance of performing at a high level.
But what do we lose if we pivot the matrix? Will architects become less effective over time because they’re not interacting as often with other architects? Will developers become bored and de-motivated if they work on the same product(s) for years? Will resource utilization suffer because we’re no longer juggling developer assignments from sprint to sprint?
Such risks are easily mitigated, and far outweighed by the advantages of product-team orientation. Cross-team collaboration can be fostered by adopting a CoE or “Chapter” model, as it’s referred to at Spotify, to encourage interaction and knowledge sharing between team members performing similar functions on different teams. Management can provide team members opportunities to migrate across teams periodically, to allow for individual growth and combat “ennui”. Finally, management must take a Systems Thinking view of the development organization, and strive to optimize for total throughput of value rather than sub-optimizing for resource cost or utilization.
Improving Engagement & Clarity of Purpose
The McKinsey study mentioned earlier makes clear one advantage of a matrix organization – employees operating in a matrixed structure expressed a higher degree of engagement and collaboration than those who were non-matrixed. Alignment to a product or set of products gives all team members a greater clarity of purpose, which is a key driver of engagement and motivation:
”higher levels of the ownership mentality predict higher levels of collaboration, organizational commitment, and corporate citizenship”
Delivering products that delight our customers is a mission most professionals can embrace enthusiastically. Particularly when bolstered by regular contact with and feedback from those customers, this purpose can drive tremendous results from teams that are aligned around products, and have full collective accountability for their outcomes. By contrast, those teams in which the “solid line” follows functional silos never have more than partial control or accountability for the actual results they deliver.
Making the Change
First and foremost, management education in Lean-Agile principles and practices is crucial to making the case for change. Middle management must be engaged and actively participating in defining the new structure, and how roles, accountabilities and rewards will pivot. Managers may themselves need development plans, to ensure they are well-equipped to oversee product-oriented teams, rather than the functional teams they now lead. How well will your Software QA Manager function, once she becomes responsible for all aspects of certain products? Will she need training on other functional best practices herself? Addressing this risk openly and in an environment of safety will help everyone envision a different future, and reduce change resistance.
These managers must be further empowered and encouraged to take a broad view of the organization, its goals and its value-delivery process. They must be trained on Lean budgeting and portfolio management so they can envision the future in a matrix principally aligned around value-streams and products, rather than functions. Then they must be challenged by leadership to make it so. Without doubt, inertia will fight against this change in most organizations, so manifest leadership commitment will be crucial to sustain it.