Last year, I came across a couple of surveys about Middle Management that piqued my interest. The first said:

Middle managers emerge as a neglected, disillusioned and frustrated breed in research...a third say they are kept in the dark about company plans, almost two-thirds confess they are at a loss to understand their role   -- jobs.telegraph, "Middle Managers are left in the dark"

And if you read the underlying report you see  that an astonishing 48% of middle managers do not think that communicating with their team is a key part of their job;

The second said:

...under performing middle managers are costing British business £220 billion a year in lost productivity.  Over half (54 per cent) of senior managers felt that middle managers were uncommitted to strategic goals, and 62 per cent criticized lack of management and leadership skills. -- Hay Group,  "Alarming Performance Gap at Middle Management Level"

Whilst this is clearly a puff piece by Hay to sell all sorts of warm and fuzzy HR services, linking the two together, you can see why the senior managers and directors might hold those views.

Middle Management is possibly an endangered species these days, but does still seems to be hanging on in little niches,  according to these surveys, despite hating the job, and apparently failing in the eyes of their seniors, so you wonder why they stick it out?!

Wikipedia makes an amusingly naive attempt to define away the problem...

Middle management is a layer of management...whose primary job responsibility is to monitor activities of subordinates while reporting to upper management.  In pre-computer times [ "What? Jurassic, maybe?", dripping with sarcasm], middle management would collect information from junior management and reassemble it for senior management.  With the advent of inexpensive PCs ["har, har", choking on spittle]  this function has been taken over by e-business systems [paralysed with laughter, writhing on floor].  During the 1980s and 1990s thousands of middle managers were made redundant for this reason ["So simple?"]

...taking a Tom Peter's-like knife to the whole layer, thus:


...with the backbone provided by those amazing "inexpensive PCs" and fantabulous "e-business systems":  However, as a saving grace, the entry does at least refer to communication as a key job function.

I went through an epiphany on this topic some many years ago, when working as a development manager in a computer manufacturer.  I was sitting in a daily "War Room" session held during the torrid Beta trials of a piece of probably under-cooked software.  In the room were the luminaries of Technical and International Sales & Service divisions and assorted lackeys, acolytes, water carriers and coat holders.  In particular, on the Technical Division side was this management line:

• The Technical Director
• The Development Director
• The Development Manager (Me)
• The Project Manager

The Beta trials were displaying all the dysfunction of a classic "waterfall" software development project going to b*ggery, hampered also by a functionally aligned organisation, and all the attendant politics.  So we spent many a fractious morning in the cut and thrust of departmental politics, whilst attempting to alleviate the pain of the early Beta customers.  

Outside that bun fight, the job of a middle manager was supposed to be to "put yourself about", (be seen to) sniff out issues, especially the opposition's dirty laundry, and inform on the organisation to the Directors in your line, in short - a communication role, pure and simple in concept, hellish in reality.

The War Room was, however, one shining light in the risk management firmament - and something that still features many years later in Agile development methods (e.g, as the daily stand-up).  The concept is cribbed directly from military usage and is all about shortening communication lines to improve responsiveness and to win battles.  

And in this gladiatorial "circus", whose job was mainly about communication?  Well, mine.  

The fun started when discussing the approach to some issue and it came down to fixing some malfunctioning product feature, and the bullets starting heading my way.

It was a frustrating, no-win situation:

• I could, for example, just nod the question over to the Project Manager and be seen as weak, but then, why have a dog and bark myself?  
• I could have taken the role as Project Manager from the meetings to control the information flow, but that made a nonsense of the whole War Room, and would have been a recipe for being blamed for everything wrong with the project (which was woven into the very fabric);
• or other strategies which were all equally flawed, within the oxymoronic constraints of the project and the organisation, and most vitally, defied sanity and common sense!

Then, ding, the light went on!  This job is pointless!  

Moving back to the current day, elaborating on the analogy of "organisation as anatomy" , then you can start to think that there are, at the very simplest,  two types of job:

• useful, creative, purposeful roles that move stuff forward, onwards, upwards - like Muscle
• other roles that are like the connective tissues, insulation, piping for insanitary fluids and other ugly bits that get left on the side of the plate of life, yes, Gristle

Visually, then the pure Middle Management communication role has to be seen in this light:

 

I made my decision on this years ago, but for anybody who is still uncertain, I offer this handy little decision-making 2x2 matrix:

Middle Managers Career Game board		Want to be...
		Gristle	Muscle
Treated as..	Gristle	Stay	Move!
	Muscle	Retire	Enjoy

I have recently been reading "Plundering the Public Sector" by David Craig and Richard Brooks, and now halfway through have been getting more and more irritated with the adversarial tone of the book, and its tendency to shower blame everywhere in unequal amounts.

UK Public Sector projects are usually particularly large (Connecting for Health is quoted as being the largest civilian IT project ever), and inevitably have all the challenges you might expect, and more of them after that.

When discussing the risk profile of projects, I usually use a 2D chart that expresses the two primary dimensions of Work Complexity and Business/Organisational Complexity, a framework drawn from my experience of programme management in large organisations.

The usual chart looks like this:



The Work Complexity dimension registers risks like complex technology, logistical scale, dynamic market environment, whereas the Organisation/Business risk dimension registers such factors as poor communication across fragmented, stove-piped structures and populations, divided loyalties, parochial viewpoints and so on, that arise in any large organisation (driven in the main by human nature in all its forms).

However, for monster public sector projects, I would recast it like this:



The black area represents the terra incognita where overall risk is extermely high due to the sheer size and people complexity, and other factors which have rarely been experienced before.

Blame-shifting and adversarial attitude are not helpful in the context of programme management, especially when exercised with 20:20 hindsight.

However, agile development methods show the way things can be if they are done right. These methods are rooted in the early insights of people like Barry Boehm, a god of software engineering who brought us this...



and this...



Iterative risk managemnt approach embedded methods can also be applied to business projects as well as pure development.


Maybe the book will get better and more evenly balanced as I read further, and maybe even propose some solutions, but, for now, having incurred my ire, it has been relegated to the bottom of the pile in the throne room where [too much information - deleted]