Rebalancing top-down management-architectures

One of the points that came up in the previous posts on the management-architecture theme is that most management-structures are top-down, which doesn’t fit well with the ‘everything is just another service’ nature of most service-architectures – especially at a whole-of-enterprise scope. Yet if so, how can we create a better balance in the overall management-architecture? What can we do about that, in an enterprise-architecture sense?

Quite a lot, as it happens. There are a fair few models that are explicitly designed to tackle this rebalance problem, and plenty of practical real-world tactics, too. In this post I’ll summarise the mechanisms that support this in Stafford Beer’s Viable System Model; a real example from the 1960s that uses some of the same principles as in the VSM; and two more recent examples, one from an engineering research-laboratory, the other from current Army doctrine and practice.

(Not too long this time, I hope?)

Viable System Model

Stafford Beer’s Viable System Model [VSM] was first developed back in the early 1970s. It’s well-established, well-proven, and applicable to any size of organisation – including the management of the economy of an entire country. At first glance, though, it looks like a straightforward Taylorist-style hierarchy, with the system-3/4/5 cluster as ‘the management’, and system-1 as ‘the workers’, each connecting in their own ways to the ‘cloud’ of the real-world:

Unfortunately this early diagram from the Wikipedia site, based on Beer’s original notes, is actually more than a bit misleading, because some of the most fundamental concepts of the model are not obvious, or not shown at all.

The first key point is that the model is fractal: the pattern repeats in a ‘self-similar’ way at every level. In that sense, everything is actually a ‘system-1’: whatever it looks like, whatever ‘system’-label it might have, it delivers some kind of service. Conversely, every ‘system’ or service contains within itself, in some form or other, the whole of this pattern: hence a ‘system-1’ delivery-service also contains its own element of ‘system-5’, ‘Decisions to maintain identity’ and purpose – in other words, more like Deming than Taylor.

Next, ‘system-2’, the set of services for inter-service coordination and ‘Tactical planning’, is not bundled into the ‘management’-cluster; and neither is ‘system-3*’, ‘Audit’ (which I usually expand to what I call ‘validation-services’). In effect, they’re orthogonal both to the ‘system-3/4/5’ management-cluster, and to each other:

If we try to hold to a strict Taylorist model of management, we would either have to subsume all of these functions into ‘management’ – where they really don’t work, because they need to be independent of management, even by law in some ‘system-3*’ cases – or else we’re likely to find ourselves with lots of fights and arguments from ‘system-3’ middle-managers about ‘insubordination’ by ‘system-2’ and ‘system-3*’.

To make this work, we need a structure that acknowledges the semi-autonomy of ‘system-2’ – particularly for cross-silo coordination and cross-domain change-programmes. It also must acknowledge the even greater autonomy of ‘system-3*’ – which does link strongly with the management-services, but usually at least one more levels ‘above’ its nominal level. In the inter-service relationships in Enterprise Canvas, this expands out a bit as the full set of services in the overall ‘Guidance’ cluster, where ‘system-3/4/5’ are the direction-services, ‘system-2’ the coordination-services, and an expanded ‘system-3*’ as the validation-services:

Yet there’s one more element in the VSM model that appears briefly in that VSM diagram earlier above, yet isn’t properly explained: a link that Beer describes as an algedonic connection. (It isn’t separately documented in Enterprise Canvas because in effect it’s just another type of inter-service connection.) The term literally means ‘pain/pleasure’, but the point is that it allows an ‘any-to-any’ connection that may bypass the ‘official-channels’ of the entire management-hierarchy, linking right from ‘bottom’ to ‘top’ if necessary. It’s typically reserved for emergencies, but it needs to be present if the overall system is to be viable.

That’s the core of the theory, anyway: let’s see how it works in practice.

Management on an aircraft-carrier

I came across this example more than forty years ago, in an article in Scientific American in the senior-school library, and it was one of the things that first got me started me thinking about enterprise-architectures.

The article was about management-structures in high-stress environments: the aircraft-carrier was one of four examples discussed. (Another was electricity power-distribution, but I can’t remember the other two.) The key point was that they all had much the same type of organisational structure, which we might describe as ‘hierarchy/flat’. Each environment maintained a very strict hierarchy, with defined ranks and roles, each with their own explicitly-defined responsibilities and reporting-relationships – so at first glance, the naval ranks on the aircraft carrier might seem little different in structure from those back in the dark days of Sir Cloudesley Shovell. Unlike in Sir Cloudesley’s time, though, the management-structures also supported ‘any-to-any’ links: even the lowest of ‘erks’ on the aircraft-carrier had not only the authority but the duty to go over the heads of their immediate officers and talk direct to the admiral if necessary – and the admiral and everyone else had an explicit duty to listen, too. In general, ‘any-to-any’ communication was reserved for emergencies only, and the ‘erk’ would need to be able to give fair reason to have bypassed ‘official channels’: but there are so many unexpected and unpredictable things that can go wrong on an aircraft-carrier that that option definitely needed to be in place – with official support and sanction.

(Another type of algedonic link common in many present-day organisations is an ‘open email-address’ for the CEO and other executives, that employees can write to, and expect an in-person answer.)

And whilst the Taylorist-style system of ‘ranks’ was strictly enforced, there were also explicit rules and rituals that emphasised that everyone was also equal. One example was that everyone – the admiral included – had to do their turn at the tedious task of ‘FOD’, or ‘foreign-object detection’: everyone in a line, shoulder-to-shoulder across the full width of the flight-deck, walking slowly along the whole length of the ship, to search for loose bolts or bits of wire that could puncture a tyre or end up in an aircraft-engine. Another example was that everyone, right down to the newest recruit, would each have their own birthday-cake baked for them by the ship’s cooks: the personal element of this was deemed so essential for morale that the admirals forcefully overruled an attempt by the Navy’s bean-counters to save money by getting the cakes pre-baked on-shore.

So that’s a ‘hierarchy/flat’ management-structure, designed to balance the need for clear command with the need to manage a wide range of largely-unpredictable emergencies. In the aircraft-carrier example it pre-dates VSM by a decade or two, but it should be clear, I think, that the same overall principles do apply.

Engineers and fitters in a research-laboratory

During one part of my aptly-named ‘career’, I worked for some years as a contract software-developer at an engineering research-lab. During that time I got to know well the fitters and toolmakers who constructed all of the test-rigs and other equipment used in the engineering experiments. I gained a lot of respect for their skills, and so did most other people at the lab – though for some of them that happened only after an interestingly subtle ‘teaching-ritual’…

Each year, the lab took on a new crop of graduate engineers. And each year, at the end of summer, they would arrive with their shiny new degree-certificates, certain that as now-qualified engineers they knew everything that there was to know about engineering. Unfortunately, almost all of them would assume that, solely because they’d had formal academic and analytic training, by definition they must know much more about engineering than any of the lowly ‘workers’ in the toolroom. Some of those new graduates were quite startlingly arrogant at first: in classic Taylorist tradition, they would give orders, and demand that others should follow those orders to the letter.

In reality, though, there are other kinds of knowledge than the purely academic: and if those new graduates were to become of any practical value as engineers, they needed to understand and respect that other knowledge. So each year, with the agreement of the lab’s senior management, the toolroom foreman would order a strange ‘work-to-rule’: the fitters were instructed to create equipment exactly as specified – even if it didn’t make sense.

The results of the work-to-rule were, often, uh, interesting… One new graduate delivered a design for a rotating component that specified a zero tolerance on both sides – which couldn’t be built on any equipment in the toolshop, and even if it could, it wouldn’t be able to rotate. Another graduate came in with a design whose components could all be made – but couldn’t be assembled, because there was no clearance to get in to tighten the bolts.

In most cases the new graduates immediately blamed the fitters for all of the problems: after all, the world should conform to our designs, shouldn’t it? The foreman would take each of the complainants aside and, uh, gently introduce them to the other side of engineering, about how to make things work in the Real World – about which the fitters knew a lot more than the new graduates did. If the graduates didn’t listen, or didn’t stop blaming everyone else… well, they soon found that it wasn’t just the foreman, the senior management were serious about this too – so serious about it that some of the graduates were politely requested by HR to find another job elsewhere.

The practical point was that the new engineers soon learnt that theory only goes so far: they needed the help and hands-on experience of the fitters in order to come up with designs that would actually work as intended. In a matter of months at most, we would see the new engineers working closely with the toolroom crew, in most cases developing strong mutual respect. Theory needs realism, and hands-on knowledge needs the support of a solid frame of theory – because in the real world, neither works well enough on its own. Overall, this was a deliberate process intended to create an appropriate balance between the two.

Officer-training in the Army

My niece’s husband is a career-soldier who’s now seen front-line service in a fair few conflict-zones. He’s now in his mid-30s, but by choice he’s still a sergeant: he’s been offered promotion, and even went on a officer-selection course at one stage, but he turned it down because, as he said, they seemed more concerned about which knife to use at a formal dinner than a knife he might have to use in combat. But he’s a good leader of ‘grunts’, and a very good trainer: and the army won’t let those skills to waste. So he now has a new job: teaching officer-cadets about the realities of the battlefield.

One of the first realities is that, despite what those officers might believe about themselves after leaving training-college, they’ll know almost nothing about the real world of the army under real-life conditions. What little they do know is often just enough to put everyone in real danger: a new lieutenant with those shiny new pips on his shoulders and an urgent need to prove himself will be a real risk to his platoon, especially out on armed patrol in unfriendly territory. That first year or so as an officer is, in essence, the first real part of his training: and it’s the troops under his nominal ‘command’ that are his trainers. And if our bright young lieutenant doesn’t get it that his job is to support them – not the other way round – then he’ll soon be pulled back to a desk-job for the rest of his life in the army – preferably before he gets anyone killed…

There’s a strong myth that the military is a rigid Taylorist-style tree-structure: generals give commands to colonels who give commands to captains, and on down to the ‘private soldier’ who must follow without question the orders of everyone else, and can never answer back. It’s true there’s still a strong element of that: but it’s there for the same reason as the ranks on the aircraft-carrier, because in a crisis – and the whole point of an army is that it does deal with crises – everyone will need to know their roles and responsibilities, and what to do to keep things on track. But the blunt fact is that rigid top-down command doesn’t work: that was the lethal lesson of the Charge of the Light Brigade. And in the complexities of current combat in counter-insurgency and the like, where every action or inaction by any soldier can have political as well as military consequences, there’s a real need to get a better balance between the aims of top-down strategy and the realities coming back up moment-by-moment from ‘the sharp end’.

Hence my nephew-in-law’s task, getting young officers ready for that reality. And hence, too, some radical revisions of military field-doctrine – such as the US Army’s ‘FM 5-0 Operations Process’ manual, using a much more fluid ‘design-thinking’ approach centred on ‘Commander’s Intent’ rather than explicit point-by-point command.

In effect, what we see now in many military command-structures is less like the old Victorian ‘command and control’, but something much more like a value-network or service-network in a service-oriented whole-enterprise architecture – the Services as literal services.

Summary

All of these are real cases where the organisation’s management, and management-structures, created a context in which top-down Taylorist theory could meet with Deming-style bottom-up practice, and together reach a mutual balance that would best serve the needs of the overall enterprise.

Yes, in each case, the hierarchy of ranks is still there: but that structure is there  for a valid reason, rather than solely as an expression of someone’s over-inflated ego… 🙂 An important difference – and an important lesson that many businesses could also usefully learn?