At every company in the world, you will find some good managers and you will find some bad managers. You will find smart employees and you will find dumb employees. You will find some people who are incredibly nice, and you will find some real psychopaths. The proportions might vary, but all of those groups will be represented no matter where you go. There is no escaping that.
As a result, when I see management problems at a company, my conclusion is always that the problem is structural. Sure, one employee might behave like a jerk, or some manager might be unreasonable, but the job of managing a company is about creating structures that work in spite of that fact. There will always be someone behaving poorly, there will always be an idiot in the room, and there will always be a manager trying to inflict harm on others for the sheer pleasure of it. In a good company with a good process and a coherent organizational structure, the “bad apples” are isolated and cause little harm. In a bad company with a flawed process and an incoherent organizational structure, the rot from the bad apples spreads. When looking at a particular problem or fight at a company, it therefore pays to focus less on the isolated incident, and focus more on the question of what is wrong with the process or structure that allowed the problem to occur.
That brings us to the matrix organization. If you have never worked in a matrix organization, the basic idea is that each person in the company reports to multiple leaders. It does not take much work to see how that can cause problems. Having worked in a matrix organization for years, and managing a team of managers who operate within a matrix, I have opinions on how to make a matrix work (or at least, how to make a matrix vaguely tolerable).
The Basics of a Matrix
As explained above, in a matrix organization each person reports to multiple leaders. There are a lot of ways of achieving that, but usually this takes the form of having a project with a project leader that is allocated “resources” (i.e. people) from functional departments. For example, a developer might be a part of a mobile app project and work on a team with other developers as well as marketing and sales people, and report to the head of the mobile app project, while also reporting to someone in the tech department.
Proponents of matrix organizations argue that this increases cooperation and better distributes information, resulting in a more agile organization and better decision making. Ironically, just about every article I found online on the topic also mentions cooperation as a challenge in a matrix. I read this as saying that a matrix that is properly implemented will increase cooperation, but a poorly implemented matrix will hinder cooperation.
Who Decides What
So, how do we make a matrix work in practice to increase, rather than harm, cooperation?
Let’s return to the example of a developer joining the mobile app project. The mobile app project has a project leader; that leader has commercial responsibility for the entire mobile app project, and the developer has a reporting line to him or her. The developer also has a reporting line into the tech department, say to the head of tech in the company. Now, imagine a question comes up about the technology that should be used for the mobile app. For example, should the project use an app development platform like Expo or not?
Who should get to decide that question? You could argue that it ultimately is the decision of the head of tech, and that he or she would work with the developers in the project to decide. After all, this is a tech question. You could equally argue that it is ultimately the decision of the project lead, as that person has full commercial responsibility, and arguably that choice would have serious financial consequences. Or maybe the right answer is to say that the head of tech and the project lead should “decide together”. After all, this is about cooperation.
The wrong answer is the last one, i.e. the “decide together” option. Failing to allocate responsibility to one party or the other actually hinders cooperation, because it creates an opportunity for conflict. For any matter that is left to “deciding together”, neither party has to actually cooperate. If the head of tech and the project lead cannot agree, then the matter gets escalated and a decision is made at a higher level. Leaving matters to a “collective decision” therefore makes cooperation optional; there is always an “opt out” available in escalation.
In contrast, if the head of tech is forced to accept the decisions that are rightfully made by the project leader, and the project leader is forced to accept the decisions that are rightfully made by the head of tech, then the two will be forced to cooperate to ensure that they are aligned. If they fail to do so, then the project will fail, and both will look bad. The key to cooperation is therefore to ensure that decision making responsibility is properly allocated at the start.
To return to the example, which person should get to decide on whether to use an app development platform depends on the specifics of the organization. What matters is that the choice is ultimately the responsibility of one of the two leaders, not both together.
Courage in Leadership
Allocating decision making responsibility at the outset encourages cooperation because it makes it impossible to “opt out” through escalation and conflict. However, what happens if the head of tech (in the example above) is consistently making bad tech decisions and therefore hurting the business? How does the company detect and handle that?
To answer that question, I want to highlight the matrix I run on my own team. On my team, I have three product managers, as well as three tech leads and a design lead. The three tech leads and design lead can be thought of as functional leaders, whereas the product managers can be considered project leaders. For any new feature, the developers are allocated from the tech lead or design lead to the product team led by a product manager; in that way, each developer has two reporting lines.
So what happens if one of the tech leads is not making good decisions or managing properly? Well, that is my job to identify and correct for. I do not need my product managers trying to overrule the weak tech lead; I want my product managers to manage the product. I am there to manage the tech leads. That is my job. I can fill that role because I know what I expect of my tech leads and product managers, and I know what it looks like to succeed and fail in those roles.
However, if I did not feel comfortable leading the tech leads, the “decide together” approach might be more appealing to me. After all, I could make the tech leads my product managers’ problems, and therefore avoid taking that responsibility myself. In turn, I simply would have to make ad hoc decisions for each issue that escalates. Of course, in doing so I would have a team that is constantly fighting (and failing to cooperate), but I would just have to say that is their fault. Every time they say they are having problems, I could throw my arms up in the air and say, “Your job is to figure it out and work together!” And like that, I could absolve myself of any real responsibility.
When viewed from that perspective, the “decide together” model is really a sign of insecure management at the top. Top management chooses not to manage, and instead places the obligation on everyone below them to “figure it out together”. What is left is a matrix organization that leads to conflict, not cooperation.