Matrix management is evil. Yeah, I said it. Maybe you don’t know what matrix management is, but chances are you’ve experienced the hellscape it creates. Maybe you’ve heard it called by other names, like dotted line reporting or consolidation of function. Maybe at the time you thought, “That sounds sensible,” but you were wrong. It’s not sensible—it’s evil and must end.
In my 40+ years in the software industry, I’ve survived numerous encounters with matrix management. Not once did it save effort, increase productivity, achieve higher quality, or reduce costs—the reasons management gave for matrixing. It had the opposite impact in every way every time. Within a few years, the groups involved would reorganize to remove the matrix and resolve the problems, only to have some fool suggest matrixing again once time healed the wounds and people forgot the pain. Never again.
“But what about cross-group collaboration? What about consolidating and growing expertise?” You can and should collaborate across groups without being matrixed. Each group must own its own products, components, and services that it then shares with other groups. As for expertise, communities of practice (such as mentoring circles, distribution lists, social groups, conventions, and talk series) exist to nurture and grow expertise. The experts don’t need to live together. Perhaps you’re confused about the nuances and unclear about the harm. Let’s talk about what matrix management is and isn’t, why people suggest it, the trouble it causes, and how to escape it before it takes you on a freight train to hell.
For more about other management dysfunctions, read Management malady, Beyond comparison—Dysfunctional teams, and Spontaneous combustion of rancid management.
Do you know what it is?
Matrix management is an organizational structure in which teams share responsibility for each deliverable. Groups are typically organized around expertise—for example, there may be a product management group, a security group, a React group, a .NET group, a content group, a design group, a reliability group, and a data group. To improve a product, component, or service, each group manager assigns one or more members to a virtual team (v-team), and the v-team produces the deliverable. Afterward, the v-team disbands, and its members are assigned to new v-teams. Only virtual teams produce deliverables, and in most cases, group managers are not directly involved in their staff’s projects. Many of you have been on v-teams that didn’t directly involve your management. Take a moment to let the implications sink in.
A simplified matrix org is formed when one group is shared by two orgs—the group reports directly to one manager and “dotted line” reports to another. A hybrid matrix org consists of some groups that are dedicated to specific products, components, and services and other groups that are shared across all products, components, and services. Regardless, engineers in matrix organizations work on projects overseen by multiple management chains.
Non-matrixed organizations look different. Teams typically aren’t virtual. Instead of organizing around expertise, groups all work on specific products, components, and services. Responsibility for group deliverables only runs through that group’s management chain. Cross-group collaboration is used to make those deliverables integrate smoothly and enable big customer scenarios. When tradeoffs and directions must be clarified, a single line of command acts. Sure, there are cross-group issues, but accountability and decision making are clear and consistent.
For more on cross-group collaboration, read We’re on the same team.
Let me tell you why you’re here
Why do fools keep suggesting a matrix organizational structure? Several perceived benefits accrue initially but reverse over time.
- Savings: Why pay for specialists on every team when you can consolidate them in one place?
- Flexibility: Specialists who are grouped together can swarm to where they’re needed.
- Alignment: Specialists are better aligned when they’re on the same team.
- Growth: Experts who are working together in one group can share effective practices and benefit from greater growth opportunities.
- Quality: Each specialized group understands its job and does it well.
These advantages sound great and do provide initial benefits, but they don’t last. Instead, failure ensues, productivity drops, costs rise, and quality suffers.
For more about Microsoft’s experiments with org structure, read Is your PUM a bum?, Are we functional?, and Are we functional (part deux)?
There’s something wrong with the world
What goes wrong with matrix management? There are two fundamental issues: scarcity of resources and disconnected management.
When you consolidate expertise (such as security), that one expert group must contribute to every deliverable. However, you can’t dedicate experts to a specific product, service, or component—that decreases savings and flexibility. Thus, the expert group will need to prioritize, leaving some deliverables compromised (literally, in the case of security). That scarcity of resources forces underserved people to work outside their areas of expertise (hurting flexibility, alignment, quality, and growth) and causes specialized work on deliverables to be delayed, ignored, or done poorly (hurting savings and quality).
When multiple management chains oversee the engineers working on deliverables, the managers become disconnected in two ways: from each other and from their staffs.
- Engineers in a matrixed org get one set of goals and priorities from their project managers and another, often conflicting, set of goals and priorities from their direct managers. Since their direct managers determine rewards, engineers usually defer to them (undermining alignment and quality). When tradeoffs or other issues arise, no one is clearly in charge (undermining savings, quality, alignment, and growth).
- In a matrixed org, direct managers aren’t familiar with much of their employees’ work. They depend on information from their employees and various project managers, which can be inconsistent and unreliable, resulting in erroneous rewards (losing unrewarded alignment, quality, and growth). To overcome this disconnect, direct managers often rely on deliverables done by their staff for their own team, which are typically internal tools and infrastructure, rather than deliverables for customers (affecting savings, alignment, flexibility, and quality).
Over time, all the intended benefits of matrix management become impediments instead.
For more on running effective rewards discussions, read Discussing rewards for people.
Bring freedom to our people
How do you avoid or escape the matrix hellhole? Have every group deliver its own products, components, and services, using cross-group collaboration to ensure everything integrates smoothly and delivers valuable customer experiences.
“But not everyone can be a security expert, technical writer, designer, or other specialized role!” That’s true. Every team can include engineers who are versed in these areas, but you do need specialists to help at key points in a project. So, form shared specialist teams (or hire external ones) that deliver their expertise as products, components, and services. They can schedule and manage their work like any other team. The groups they serve don’t manage them; those groups are their customers.
“But how do I grow and reward the wide variety of specialized skills on my team?” Every team needs engineers who are well-versed in security, design, documentation, testing, and other areas of expertise. As a manager, you can grow and reward them without consolidation and matrix management. Encourage them to join communities of practice, such as mentoring circles, distribution lists, and social groups, and attend conventions and talk series. Reward them for leading related efforts on your team and for mentoring their teammates.
“But at my small company, everyone has to contribute to everything!” That’s right. Small companies avoid the issues associated with specialized resources (no one is specialized) and disconnected management (managers also contribute to everything). However, as small companies grow, they can easily fall into the matrix management pit of despair.
“Are virtual teams useful for anything?” Sure, v-teams are useful for auxiliary activities, such as planning, coordination, alignment, learning, events of all sizes, and volunteer work. They’re also good for short-term investigations. Just don’t use v-teams for deliverables.
For more on becoming an expert, read Individual leadership.
A world where anything is possible
Matrix management is harmful and deceptive. It claims to save money, increase flexibility, create alignment, provide growth opportunities, and improve quality. Instead, it sets mountains of money on fire, constrains teams, fractures decision-making, provides dysfunctional rewards, reduces quality, and shatters accountability.
Fortunately, you can avoid and escape matrix management by having each group and team deliver its own products, components, and services. Use cross-group collaboration to ensure everything integrates smoothly and delivers delightful customer experiences. Encourage team members to join communities of practice to enhance their skills and leadership abilities. Avoid the pitfalls of matrix management as your small company grows. And only use v-teams for auxiliary activities and short-term investigations.
When you see something, say something. Does an org chart show a dotted line relationship? Sound the alarm. Are v-teams responsible for customer deliverables? Call the authorities. Do you report to multiple managers? Run for your life. Our business is in danger. Raise the concerns, point out the issues, and be the one to free us from the matrix.
Special thanks to Bob Zasio and Scott Cottrille for reviewing the first draft of this month’s column.
Want personalized coaching on this topic or any other challenge? Schedule a free, confidential call. I provide one-on-one career coaching with an emphasis on underrepresented, midcareer software professionals. Find out more at Ally for Onlys in Tech.
how do you do management for geographically distributed teams without matrixed managment? the reason for the matrix is not expertise consolidation but geographic alignment. The “project teams” are too small for direct reporting.
I talk about this issue in https://imwrightshardcode.com/2008/02/so-far-away-distributed-development/. In that column, I recommend having a remote team work on loosely coupled (fairly independent) products, components, and services that the remote team owns. It’s basically the same recommendation made in this column to avoid matrix management. If there aren’t enough remote folks to form a team, then each individual is a remote part of a team that has its own products, components, and services. No matrix.