How to Do Many Projects (Part 2): Matrix Management

In How to Do Many Projects (Part 1) I explained that it is good to have multi-functional teams, where each team includes a project manager. Here is part 2, which is about the merits of matrix management

Functional Managers
As in every other organization, in our company each employee has a (functional) manager. I prefer management to be arranged along functional lines. Therefore, a project manager has a manager who knows a lot about project management. A front-end developer has a manager who is herself fluent in CSS and HTML. And our software developers have development managers who are proficient at building code, delivering solutions and making nerdy jokes that no ordinary person understands.

I believe it is imperative that managers understand the work their employees do. There's little reason for software developers to work with a manager who cannot distinguish a bit from a byte. (I have blogged earlier about how to select a fine technical manager.) Similarly, project managers should be led by someone who understands agile principles, Scrum practices, and how to turn Notepad into a planning tool.

Important: a manager does not have to be better than the sum of his subordinates. It is only natural for his senior employees to exceed the manager's knowledge and expertise at some point, because management requires other (soft) skills, some of which the seniors might be lacking. However, the manager should be good enough to earn trust and respect, and to be able to coach and lead.

Note: For historical reasons our Development Managers are situated in the same teams as their own subordinates. This means there's a Development Manager available in each of our development teams. This works fine for now, but might be changed someday, as there is no practical need for it.

Matrix Management
It will be clear to some readers that we have organized ourselves as a matrix organization. Our project managers are primarily responsible for projects and the (short-term) goals of customers, while functional managers provide expertise and coaching. They deal with the (long-term) goals of our people.

There have been some negative reports about matrix management. It is said to significantly increase the number of meetings and communication overhead, and matrix management reportedly triggers numerous conflicts between project managers and functional managers.

But I think this is only true if you're stupid. Not if you're smart.

I strongly believe there are good and bad ways to implement matrix management. In organizations with stupid managers, where people actually desire organizing meetings and controlling people, matrix management is definately not going to help. It will simply double the amount of misery!

Matrix management does not solve the problem of having bad managers. It makes it worse.

Just think of this: Google applies matrix management too.

Google has good managers…

Good managers understand that there are times to discuss projects and there are times to discuss people, and these two don't have to take place at the same time by the same managers. In fact, separation of concerns is a good solution with any case of conflicting goals. I see no problem in a few healthy discussions between a project manager and a functional manager about some employee's priorities. (As long as they settle their differences with a cup of coffee instead of 200 pages of emails and documents.) Chances are their compromise will be far better for the employee than in those traditional cases, where project management and functional management are combined in the same person. This is usually someone who is not likely to be good at doing both.

Matrix management can scale much better than traditional hierarchies. Google has shown that its organization can remain relatively flat. Their (few) functional managers are able to manage many more people now that they don't have to manage all their projects as well. The pool of project managers is different from the pool of functional managers. That's why I believe that matrix management is a big help in doing many simultaneous projects.

to be continued…

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Do Many Projects with Few People (Part 1)
How to Handle Many Simultaneous Projects
How Not to Manage Your Country (or Project)

Related Posts
free book
“How to Change the World”
  • SteveJ

    “I see no problem in a few healthy discussions between a project manager and a functional manager about some employee’s priorities”
    See this sounds like a turf battle to me. I’d like to believe all the managers in the world are fair-minded, but it really only takes one “posessive” manager to ruin the whole bunch of decent ones. Of course I think it’s just as likely to see the same battles between project managers so perhaps the functional/project division is unimportant in this case. It obviously works for you, but could your success be more a reflection of your company’s people, ideals and cohesiveness than the particulars of the managing process?

  • Jurgen Appelo

    Steve: You might be right. This is what works for us, but it can depend on cultural factors.
    Still, I remain very skeptical about the idea of project managers also being functional managers.

  • BrettV

    Jurgen, two things you said got me thinking further about matrix management:
    “each team includes a project manager.”
    “our Development Managers are situated in the same teams as their own subordinates.”
    To me, this does *NOT* sound like a true matrix organisation which generally implies functional and project managers leading different subsets of people across different projects and functions, respectively. Consider drawing a grid (matrix) with functional columns and project rows and team members in each grid cell. Your situation sounds like there are only members on the diagonal (or a small subset of cells) rather than in most cells. That is your grid would look like a sparse matrix rather than a dense one []
    Since your development managers are managing roughly the same group of people as your project managers, I imagine they have much more common ground than in a matrix organisation, and therefore drastically fewer disagreements over resource allocation and priorities.
    In practice, I have seen true matrix management cause a lot of problems, for two key reasons:
    (1) most developers (and testers and analysts) each report to multiple project managers (i.e. for different projects). This always results in resource conflicts, task switching, artificial dependencies between projects due to limited resources. It also inhibits the formation of true “project teams” since most members are on multiple teams and move around frequently as projects start and finish and resource allocations change.
    (2) each project manager manages many projects, each with different (possibly overlapping) teams. Generally this results in project managers being spread too thin between their various teams, and not being available enough to actively remove impediments, manage risks and issues, etc. In this situation, I often see project managers’ role relegated to perfunctory status reporting and fire-fighting rather than proactive planning and prioritisation.
    I do not believe either of the above pitfalls is inherent in a matrix organisation, but in my experience matrix organisations are often liable to fall into one or both, particularly when managing a large number of small projects in the face of constant change, and when an explicit approach to actively prevent these in not in place (such as Agile).
    The only way a matrix organisation can work efficiently, in my opinion, is when (A) a developer/tester/analyst is on one and only one project team and (B) a project manager manages one and only one project team. Multiple projects can be assigned to each project manager, but with a single ring-fenced team the resource allocation problem is much less complex. Also this facilitates formation of true “teams” rather than just “groups working together”; turning groups into smoothly functioning high-performing teams takes time! [] Your model appears to have both (A) and (B) but not (1) and (2), which in my view is why it works so well for you.
    In my current organisation, we run many projects (200+ active projects across 13 programmes of work between half a dozen customers) across a technology department of 150 staff. Our matrix organisation gives the functional manager the power to make all resource assignments, while project management has all the power to make priority calls between projects. Because we run so many projects in this manner and have a historical culture of interchangeable workers, we are deep into both pitfalls (1) and (2) above. Suffice it to say this model causes a lot of churn in planning, customer commitments, and generally poor productivity and predictability.
    We are hoping to move our organisation to ring-fenced Scrum teams, where every developer is on only one project team, and every project manager works with only one project team. We have a huge amount of organisational momentum to overcome, so the transition will not be easy or quick…
    I agree with you that it’s a great idea to separate “people management” from “project management” but I do not think this requires a matrix organisation, and to me it appears you’ve accomplished this separation *without* moving to a true matrix organisation. I would advise you to think carefully before changing your model further in the matrix direction, and to avoid either of the pitfalls above (and keep attributes (A) and (B))!

  • Jurgen Appelo

    Brett, thanks for your comments. You are absolutely right, of course. However…
    I *did* point out that our development managers are included in our teams only for historical reasons. It serves no practical purpose. In fact, our testers, front-end developers and project managers already each have functional managers outside the project teams. We will move in the same direction with our software developers.
    We do indeed have (A) and (B), and we don’t have (1) and (2). I believe you are right in claiming this to be essential for a proper matrix management organization. Thanks for pointing that out!

How to Change the World - free Workout - free