Matrix Management

Organizations tend to swing between FunctionalManagement? (you report to someone who used to have a job like yours) and ProjectManagement (you report to someone who is coordinating your efforts with those of other folks not like you). The styles have complementary strengths and weaknesses. MatrixManagement freezes the pendulum in the middle by having you report to two managers at once.

Too Many Chiefs & Not Enough Braves AntiPattern.

Yet another idea that--like CMM certification, alcohol prohibition, or job-cost accounting--attacks the symptom instead of the problem, contains no system of checks or balances, and is therefore very easy to go very wrong.

who is coordinating your efforts with those of other folks not like you). The two From the XpMailingList:

: I don't think I would enjoy working in a Matrix organized company. It seems like it would be very difficult to build cohesive teams. For those of you in companies like that, is it more or less difficult to introduce XP? My guess is that it would be more difficult, but that's just a hunch.

xxxxxxx

A lot fo the challenges in the matrix come from the fact that people dont have the skills to make it work. They are concerned about influence without authority and accountability without control. But what is the alternative; if we have to constantly fall back on old fashioned authority and control and can't cope with ambiguity and change then we are probably not very good mamagers.

Some resources, videos and articles on the amtrix are at www.global-integration.com

There are problems with matrix management that cause me to run - as quickly as possible - for the door when I'm threatened with it. I think that XP is untenable in that environment unless its [MM's] basic human problems can be solved.

Matrix management is an attempt to get "maximum efficiency" from people. It is a manifestation of the mistaken belief that an hour someone isn't working is an hour wasted. The idea goes something like this: If I have two projects, each needing 60 hours a week of human time, it would be wasteful to have two people working on each project. Each project would have 80 hours of labor available, using 60 and "wasting" 20 (a total of 40 wasted hours... a whole person!). So what does matrix management do? Get 3 people into a pool (120 hours a week of labor), and then have the whole pool split its time between the projects. Obviously more efficient. This is a simplistic example, but that's the essence of matrix management.

It would work great if only:

People had no "setup time," and could switch from one task to another without incurring any penalty.
There were no dependencies between people that could cause one team member to wait for another team member to become available.
Lost labor was more costly than slipped schedules or bad quality.
It was possible to fairly apportion your time between the projects you are assigned to without encountering infighting or bureaucratic entanglements.

Unfortunately, none of these conditions is true. As a result, my memories of matrix management are of spoiled productivity, overtime, stress, and intense unhappiness. Perhaps it actually works in some places. It did not where I worked, and I have trouble imagining how to solve the human problems it causes.

Do not worry about how to practice XP in such an environment. Instead, run away as swiftly as your feet will carry you.

Sincerely,

WayneConrad

Of course no companies out there have any political or personality conflicts. But for the rare ones that do, MM can ripple even the most minor of problems out through the matrix and cause amazing collateral damage. Including the loss of sensitive types like Wayne.

Sensitive? Maybe. Slow, certainly. It took me a decade of being subject to some remarkably pathological behaviors to realize how many of them were a direct result of MatrixManagement. A decade (sigh). -- WayneConrad

Some companies (which obviously don't practice ExtremeProgramming) have trouble sharing information between employees, let alone teams. The rippling of information (including "minor problems") "out through the matrix" is often cited by MatrixManager?s as a good thing.

Another "feature" of MatrixManagement is to create 2 orthogonal management structures. Plus 2 management support structures, including secretaries, timekeepers, accountants, SixSigma / CMM chart collectors, etc.

If badly applied, this doubles the number of managers.

Where do the new managers (and support people) come from? From the ranks of the employees. So the number of managers doubles, while the number of workers goes down.

Another problem that MatrixManagement causes is that the manager responsible for your day-to-day work is not the one responsible for your performance review - leading to (best case) incomplete and unclear reviews, or (worst case) complete hash of reviews because the reviewing mgr thinks you've done nothing for him/her all year.

I work at an organization that seems to have embraced the Matrix Management structure. My experience (and sentiments) are not nearly as harsh as Wayne's, though I still have some reservations.

We have about 70 people in the organization and build engineering-heavy web sites. Around 20 are engineers (4 team leads), 4 project managers, 4 project coordinators (~~ Tracker ExtremeRoles), 5 gfx types, a few writers, 5 systems/server types, and assorted executives and administrative types.

Anyone in the organization doing client services is in the matrix. Sales drops off the landed client, and we go to work collecting stories (aka requirements) and doing work. Since we're an engineering-heavy company, the teams are co-lead by the Project Manager and one of the engineers designated a Lead Engineer for that particular client. We have one person who does nothing but manage, hire, fire, review, give-raises-to, shuffle around, and set some semblance of standards for the engineering organization. He's nice, and essential in that he replaces approximately weekly meetings to hash out common technical and staffing problem. Probably not worth what he's being paid.

So far, the Matrix organization has worked reasonably well. I don't feel torn between who does what, and there is a fairly clear distinction between the two axes.

We do put in efforts to make sure that people aren't being overloaded, and that their responsibilities are clear, mainly by asking oneself "who should be responsible for...". Rational.

-- SteveVanEgmond

MatrixManager?s claim that the 2 management structures provide 2 different paths for career growth:

Through "line management". (One of the management structures is meant to organize the customers of the work to be produced.)
Through a "technical ladder". (One of the management structures organizes the various labor "pools". The labor pools are based on the employees' technical fields.)

The problem is that the "technical ladder" (supposedly for ever-improving technical ability) becomes confused with just another management ladder, where promotion is based on the ability to handle ever-larger numbers of subordinates. The two abilities are not the same.

If badly applied, the company loses a way of rewarding people with excellent technical abilities.

Here's another of the many ways to apply it badly: Matrix Micro Management

From the XpMailingList:

I work in what began as a functional structure (client developers, server developers, engine developers), which was re-organized into matrix style with product assignments.

Over time, the functional link has deteriorated drastically, so we now think primarily in terms of the product team that we are on.

My product team had 2 client developers, 2 server developers, and 1 engine developer (me). About 2 and half months ago, we expanded to 2 engine developers (Another product team completed their product, was disbanded, and members dispersed to other product teams). This was the same time I started finding out about XP.

Experimental results:

Positive:

Satish and I can pair relatively easily. We implemented the CppUnit in a variation of the engine build, and pushed ourselves for pairing and unit-testing and test-first. Our courage was definitely higher, and I'm convinced our resulting code is better than either of us could accomplish alone. The courage aspect has most to do with refactoring for cleaner code. Much of the initial effort was frustrating, (working at one desk or the other - corner screens - missed e-mail and missed phone calls, and just not feeling like we were both simultaneously, actively engaged). For myself and Satish, this is no longer true. We made room arrangements that eased the keyboard / screen sharing; and reached a point where we can move rapidly as a pair. (We also have a timer for when we feel like enforcing keyboard rotation). Test First approach takes constant reminding, as does top down design (design down from desired results) as opposed to our usual design up from code we have in place. Essentially, the hard part is converting from a "do it as quick as possible" mentality based on existing product knowledge, to a "long term - easy to understand, code designed to fit the requirement, and tested" mentality.

Negative:

I believe it took myself and Satish two months to reach the state where we can be effective.
Culture: Our company, in general, consists of programmers who desire solo work behind closed doors. The general view is that the only 'productive' time is one's solo time at the start of the day, before other people arrive, or at the end of the day, after other people have departed. Most have a pre-conceived notion that they are better than others and that pairing will just introduce arguments, disrupt necessary 'flow' concentration, and slow them down. Management fears loss of hard-to-find talent and productivity loss if engineers are "forced" to do things (pair programming, test first) that they don't want to do.
Extended trial: Since the engine pair does develop better code, we tried extending this cross-function (1 engine (me) with 1 client person), and cross product (2 engine people). Both of these trials failed [as defined by a 9 working day trial].

My experiment failed in that we were unable to put a CppUnit into our client framework. This included getting help from infra-structure gurus. I found it frustrating to fail at getting a simple dialog box up.

Satish's failed in that he wound up primarily alone while his partner was sucked into their own product work (originally planned as a quarter of each day). His partner found that the pairing was distracting and disjointed. She needs to concentrate on a single task per day, and has primary responsibility on a different product team. I don't think either of our partners found it easy to be away from their keyboards.

Conclusion: I'm still convinced that when paired with a peer, my peer and I will produce better code. Whether the improvement is worth the investment/hassle is not clear.

-- JimMead

At my last place-of-employment, they put in a system where I had _three_ managers (though two of them were the same person). These managers were:

my "career manager". In theory, he was a support person to me. His job was to manage any HR-related issues that cropped up for me. He was also supposed to co-ordinate little things like my performance and salary reviews (this required co-ordination, because of all the various managers I had). Regardless of how my career progressed, this person was meant to stay the same. Why they needed a manager in the R&D department for that when it seems like what I really needed was a dedicated HR person, I don't know.
my "team manager". In theory, separate to the career manager. In practice, it seemed like everyone had these two roles merged. The major point of the team manager was to be the FunctionalManager? outlined above. He didn't give me work, but he shopped me out to project managers. He was also responsible for getting the "team" together once a week to pass down various news tidbits from higher up in the management chain.
my "project manager"(s). The head of the project(s) I was working on at the time. We had a rule that we couldn't be tasked to more than one project as a full-time resource, but we often had projects we were assigned to in support roles (for example, as the only remaining former developer of one product, I was assigned to back up the support staff for that product, in addition to my regular duties). Only the project manager(s) were allowed to assign us work.

For the year or so I was there while they had this system, it seemed to work okay, but it looked like a lot of extra overhead. I don't know what it would have been like once the split between the "team manager" and the "career manager" became more official. (Oh, our managers didn't have support staff of their own... only a shared departmental secretary).

MatrixManagement can work.

It works better with larger organizations that run simultaneous large projects.

In our organization (large engineering contractor) every body has a home department that manages their discipline. This covers the day to day people management as well as providing a technical group that defines the processes and practices that the discipline must follow.

People are allocated from the department to one or more projects. Some people are dedicated to one project whilst other people, who tend to be specialists in their field, work on more than one project.

Some departments (HR, Finance, IT) that are seen as supporting the business do not allocate people to projects and their work is very much as would be found in a functional based organization.

The IT department tries to use matrix management for IT projects and many of the issues raised above do occur. This is exacerbated by the fact that the IT people are expected to support existing applications as well as develop and implement new ones. The only way round this is to identify support as its own project and allocate resource against it. However as Support is very ad-hoc a severe problem can cause immense problems with the schedules of real IT Projects.