Insuperordination

In designing management-structures, why is it so often assumed that responsibility-relationships only go one way?

Our organisations often place enormous attention on insubordination, a refusal or failure to follow ‘orders from above’; yet why don’t they place the same level of attention on insuperordination, the refusal or failure to respect the the same relationships and responsibilities to those ‘below’?

For that matter, why do we still prop up the misplaced myths of ‘above’ and ‘below’ anyway? After all, in a service-oriented view of the enterprise, there is no hierarchy – they’re all just mutual peer-level service-relationships, no different in nature from any other. And does anyone benefit from those myths any more? – other than people who need to prop up arbitrary and unwarranted delusions about their own importance?

This came up for me today from three different directions:

I’ll happily give names to the good ‘bosses’ – Helen Mills at Australia Post, for example, or Graeme Burnett at DSTO. For the others, well, I’d best be a bit more circumspect, hadn’t I? 😐 – which is an interesting point in itself…

But there’s one of the latter that comes particularly to mind. It was on a large engineering-project a couple of decades or so ago; almost all of the team were contractors, some of them world-class level, because it was a genuinely innovative system that had to do things that had never been done before. To make it all work, and to hold the team together, we needed a manager at the same kind of skill-level. What they gave us instead was – to be blunt – an incompetent idiot, a classic civil-service time-server, eking out his last years before retirement. Not a good choice…

He was way, way out of his depth and his comfort-zone – a fact that became painfully obvious even before the first day was out. He had no experience or understanding of the inherent anarchy of innovation: as an ex-military-type, all he knew was command-and control. Which really, really, really didn’t work.

We limped on under his endless incompetence for a few months, until one day it all came to a head. At a particularly fraught team-meeting, every one of the contractors blew up at him, saying that he alone was the reason why the project was so far behind schedule; furious, he rushed out, accusing everyone of insubordination, and yelling – and I quote – that “I’ll have all of you frog-marched out of the establishment!”

At that point, the executive realised they needed to intervene, kinda urgently… The team explained to them that whilst, yes, they would perform best with a good manager, they would actually be better off with no manager at all than with this guy. And for once – hooray! – we actually had senior-management who had some real grasp of what was going on – and they agreed. So for the rest of the project, we ran as a self-organised team, without any manager at all.

In short, our incompetent manager had been fired for insuperordination – failing to deliver the required management-services to the level needed within that context.

Looking around at most management-structures, it’s clear that that needs to happen a lot more often…

And this, of course, is where it can get v-e-r-y tricky for enterprise-architects and the like. We can see what’s not working. We can see why it’s not working. We know exactly what to do to get it working again. And yet we’re supposed to pretend that the myths of management-hierarchy are somehow sacrosanct, that insubordination is real and punishable, but insuperordination and plain management-stupidity is not. We’re allowed – in fact required – to ‘fix’ anything and everything except that which is the blatant cause of the problems, namely those myopic myths of management, which we’re not allowed to challenge at all. Hmm… About time we started being honest this, don’t you think?

Implications for enterprise-architecture

Insuperordination isn’t just lack of leadership: it’s a structural failure of the management-model to support essential symmetries of responsibility in mutual service-relationships.

And as a structural flaw – one that has serious impacts on overall enterprise risk – it’s very much a concern for enterprise-architecture.

The key requirement here is to stop thinking in terms of hierarchies. If we take a service-oriented view, it’s clear that management-services have a very real function, as information-aggregators and resource-distributors, dealing with the trade-offs across a functional-silo.

Yet those types of services are not well-suited to managing end-to-end cross-silo process-flows: there needs to be a separate category of coordination-services that handles that task – a fact which immediately implies matrix-relationships of some kind.

And those matrix-relationships need to be peer-to-peer – which doesn’t fit at all with any Taylorist-style concept of top-down management-hierarchies.

In short, top-down ‘command-and-control’ hierarchy is an overlay on top of a tree-structure that arises naturally from aggregator/resource-distributor relationships. The tree-structure provides a genuine service; the hierarchy, all too often, a genuine disservice. Don’t conflate the two structures: they’re not the same.

The way to separate them is that the tree-structure could be viewed in any orientation: top-down, bottom-up, sideways-in, centre-out – it’s all the same. But the hierarchy is always described as top-down: it can’t be made to (seem to) make sense in any other way.

The top-down management-model is essentially a leftover remnant of a supposedly long-dead feudal past, in which position in that hierarchy denotes ‘rights’ to demand subservience on pain of punishment for ‘insubordination’. As a structure based entirely on ‘power-over‘ – with all the dysfunctionality that that implies – it can only be made to seem to work as long as there is no need to engage the ‘subordinates’ actually in the work: “check your brain in at the door” is how one colleague described it. But when the work does require that kind of personal engagement – as is becoming more and more common throughout almost every business context – then the overall system will either operate only at low efficiency, or even fail to operate all, if that ‘conventional’ command-and-control hierarchy is allowed to remain in place.

It’s an architectural choice. Command-and-control hierarchy will only work with low-agility: if we need to preserve command-and-control hierarchies, we will not be able to achieve high-agility in that context. If the organisation – or some part of the organisation – needs high-agility, we must define a structure in which that section of management is peer-based, as ‘just another service’ – and in which the responsibility-failures of insuperordination must be recognised as exactly symmetric with insubordination.

In any given context, we can choose one model, or the other: they don’t mix well, and we can’t have both in the same context – as even current military doctrine [PDF] now makes clear.

If we want our organisations to work, we need to stop pretending that insuperordination doesn’t exist – and instead acknowledge that it’s one of the most serious sources of organisational risk.

That’s the message that we need to give to our enterprise-architecture clients.

Challenging, yes – but it’s the only way that this is going to work.

Comments/suggestions, anyone?

2 Comments on “Insuperordination

  1. Tom. One of the things that makes fixing this even more difficult has to do with a common perception of the role and title of Enterprise Architect. As my colleague Tom van Sante has pointed out more than once, we suffer today from a vast number of different breeds of architect within any one discipline. IT is far and away the worst offender but one comes across it in other disciplines as well. The only discipline that doesn’t seem to suffer from the problem is building architecture, perhaps because they have a clear understanding of what architecture is.
    Why does everyone need to be an “architect”? Well it’s essentially a question of recognition. In IT it is hard, if not impossible, these days for an outstanding designer/programmer to gain proper recognition for their contribution. Apparently architects are more important and better paid, so they too want to be architects. Thus the emergence of a dazzling array of Architects.
    Back when there were fewer different architect titles in IT, we had Technical Architects. These were really important folks, who knew the difference between an implementation that looked pretty and one that worked – and kept working. One could argue that they should have been called engineers but let’s leave that aside. The meaning of such a title has eroded to the point that only people who feel very confident of themselves (and the recognition they receive) will still use it. The rest want to be called Enterprise Architects. Now I’m not saying these folks aren’t as capable of being an enterprise architect as I am but it’s not what their jobs are about. At most it’s part of EITA. That doesn’t make their contribution less important. It’s just not EA.
    So being an Enterprise Architect means being “important”. It often has a hierarchical relevance. You get to tell the other architects what to do. You even get to tell management what to do. It doesn’t follow they’ll listen but at least you get to talk to them. And that makes you important compared with the other shmos, which gives you something to defend.
    Several large companies I know have an Enterprise Architecture Manager, who doesn’t get to do any EA but just manages a team of EAs. Some of these folks may do a good job of enabling the EAs to get on and do their job, whilst not interfering in how they do it but it’s still, hierarchically speaking, a more senior position and therefore one with more credibility with higher (IT or Business) management.
    Now if all the folks with an EA title weren’t bothered about hierarchy, remuneration and recognition and if all the folks who didn’t have an EA (or any kid of architect) title were comfortable that their value was properly recognized, none of this would be a problem. But too often that’s not the case. So we get the situation where insuperodination can’t be tackled within the broader organization without first (or at least in parallel) dealing with it in EA. And I’ve seen it often enough to know it’s a real problem.
    You have to be very sure of yourself to withstand all this and even stronger to make a difference in the face of it. You may be that. I may be that too (on a good day) but in general it’s a tough position for an EA to be in.
    So what you’ve done I think, Tom, is to make the problem visible and therefore hard for people to ignore any more. That in itself is a major contribution. Now we need to see how we can take it further. I guess I’m therefore obliged to try to come up with some practical ideas to help that process. Watch this space?

  2. @Stuart Boardman – Many thanks. And yeah, ‘title-inflation’ is a huge problem, and one that’s all but crippling current EA (or just about any other form of business-related architecture, for that matter).

    One of its worst side-effects is that we have a sizeable number of people in the various architecture-disciplines who really don’t have an architect-mindset – and hence are non-competent for the role – but think that they are doing architecture, or that what they do is ‘architecture’, simply because they have ‘architect’ in their job-title. The result is that we not only have non-architects purporting to do architecture, but non-architecture purporting to be architecture. And when we toss into the mix the hierarchy-mess and its myths of ‘superiority’ and ‘do what I say because I’m more important than you so I’m always more right than you’, we have a perfect recipe for shambolic pseudo-architecture. As we see all too often…

    “You have to be very sure of yourself to withstand all this and even stronger to make a difference in the face of it. You may be that. I may be that too (on a good day) but in general it’s a tough position for an EA to be in.” – yes, exactly. And the main reason why I’m not an employee (and never have been) is that I’m not ‘very sure of myself’. That lack of certainty does (I think?) make me a better architect in the sense of getting a better grasp of the overall context, but perhaps not a better architect in the sense of getting real things to happen within the real-world that is the over-politicised, ego-ridden, shambolic mess of most large organisations… Which makes me useful as an architectural-toolmaker, perhaps, but probably not as the best ‘player’ in the joyous ‘games’ of middle-(muddle?)-management. Oh well.

    One way we could start, perhaps, is by illustrating insuperordination in IT-systems and code-level IT-services. If ‘subordinate’ services need coordination from their ‘superior’, and don’t get it, the overall system will fail. And there’s no point in blaming the ‘subordinates’, because that isn’t where the problem lies: the only way to make the system work is to challenge the insuperordination – the failure to deliver the required services.

    If we then extend the ‘everything is a service’ metaphor to other types of service-relationships such as management, the fact of insuperordination soon becomes visible. Whether anyone is willing to face that visibility is another question… but at least the risk/opportunity has been highlighted there, and is registered as an architectural / operational risk. And once it’s in the risk-register, it’s going to keep quietly nagging away until someone does find the courage to tackle it. “The inevitability of gradualness”, as my mother often puts it: when faced with something impossibly huge, keep niggling away until something finally happens… 🙂

    “I guess I’m therefore obliged to try to come up with some practical ideas to help that process. Watch this space?” – yup, I’s watchin’. Definitely watching. And more, I hope. 🙂 🙂 – let’s keep in touch on this?

Leave a Reply

Your email address will not be published. Required fields are marked *

*