Finishing off the exploitation of this particular line of thought – and the film reference that goes with it (sorry) with some of the slurry at the end.
Bad things come to those who wait.
The worst challenges of Matrix Management are logical progressions of the concept, and probably inadvertent, but they are common enough to be something to watch out for.
In the kind of change Wolf Bear are involved with, the primary activity of most of the individual contributors on a given project or programme is one requiring focus, attention, and thought. It might be cabling a server rack well, or it might be writing code, or identifying what felt wrong about a particular functional test, or making a good consistent set of icons for navigation around an app, or a dozen other things that require attention.
Matrix management is sometimes used to slice people’s time too thinly to properly concentrate on what they are delivering.
The focus required can take quite a lot of time to muster, to reach full effect. This is often referred to as “getting in the zone”. For a lot of coders (for example) it’s a necessity to have a long run up at solving particularly challenging problems, and that doesn’t make them a bad coder – often quite the opposite. Understanding and getting into the context of a particular project or activity isn’t something that just happens, at least for most people. Context shifting comes at an intellectual, energetic, and motivational cost, and it harms the concentration and reduces output.
With matrix management, some organisations think they can spread people out ever more thinly, and receive the same results. A cariacature of a project manager often repeated is: “A project manager is someone who thinks that if producing a baby takes a woman nine months, putting 8 extra women on the job should produce the baby in a single month.” Many organisations behave as if they believe that they can equally split a person across 4, 6, or even (the worst I’ve seen) 16 different projects and still receive the same attention, quality, and output.
I notice that in every large organisation I’ve seen adopt this kind of approach they have been careful to avoid doing it to flagship projects (programmes, etc.). Any time you see a behaviour consciously avoided for flagship projects, you know that the organisation knows it harms delivery, and they choose that compromise for the less important things either because it’s how it’s always done (intellectual apathy), or because it’s a compromise they are willing to make.
The results at the negative end of the spectrum include some that are pretty obvious – slower completion, lower quality, increased rework – but they also include some less obvious results: the consequences of forcing people to work in a way which they know they are less good at destroys motivation, lines them up for the kind of performance review which drives them to leave (and sometimes leave permanent employment entirely), and even if their performance review doesn’t suffer, the constant drudgery of producing something less good than what you know you could if you were just given the chance is debilitating. This is the illusion of efficiency – it feels cheaper to split people across projects – over effectiveness. It is often better to focus on doing a few things well and quickly than doing many things at the same time, but taking longer to finish anything. There are scholarly articles in the canon of psychology exploding the myth of multitasking on an individual level, but organisations as well only have so much focus too – but that’s for another article. True efficiency is a result of comparing the total inputs with the total outputs, but the perception of efficiency is not always as well thought out.
In short: careful with focus; it is fragile, and if it’s too dilute, it harms progress dramatically.
There’s a consequence from matrix management on the (leadership of the) team from whom the matrix resource is drawn. Very few people become leaders of teams because they are thrilled by utilisation spreadsheets. (I would like to think it is none, but a variation on Rule 34 probably applies). If you take their team away on a regular basis and largely divorce them from what the team are doing, what do you expect their response will be?
The team leader might stay. All organisations have a degree of turnover in staff, but the fastest to leave are seldom the ones you want to leave. A team leader who knows he has little to do with the way his team work may not take the care and attention a motivated one would in recruitment of replacements. This snowballs rapidly: if people work in a team where they know the manager no longer cares, they also lose their interest. That fuels a drop in engagement, which in turn often increases staff turnover, and the problem accelerates.
As a change leader, this can rob you of the tools you need to deliver change – effective, engaged contributors. The short term solution is to bypass the more irritating consequences of matrix management and, especially on large, demanding changes, adopt resources wholesale. Longer term, the changes needed to resolve this issue are more pervasive, and harder to achieve.
This is the disconnect is what lies at the heart of my problem with matrix management: the disconnect between the host organisation and the change vehicle. It is the underlying cause of most of the problems I’ve laid out here, and it is hard to resolve systemically. Recognising the organisation’s true priorities and focusing on those is an organisational approach with a lot of merit; but it’s hard to get the different competing areas within a big organisation to be patient while other areas get their changes carried out.
This is mostly a problem with waterfall organisations. Agile’s resourcing is for another time.