Yet more on ‘No jobs for generalists’ [3b]

Why is it so hard for enterprise-architects and other generalists to get employment as generalists – despite the evident very real need for such skills in the workplace? And what part do current business-paradigms play in this problem?

[[This post has been split into six parts, in line with the chapter-headings:

  • Part 3a: ‘An incomplete science’ – about Taylorist notions of ‘scientific management’
  • Part 3b: ‘Management as a service’ – a service-oriented view of the role of management
  • Part 3c: The impact of the ‘owners’ ‘ – about how and where financial-investors come into the picture
  • Part 3d: ‘A question of fitness’ – exploring the use of ‘fitness landscapes’ to guide selection of appropriate architectures
  • Part 3e: ‘A question of value’ – how we could describe the business-value of generalists
  • Part 3f: ‘No jobs for generalists?’ – a brief(ish) summary of the whole series

Previous: Part 3a: ‘An incomplete science ‘]]

Management as a service

In Taylorism, management is a class of activity that is fundamentally and qualitatively separate and distinct from any other type of work, and, because it provides overall control of ‘the machine’, must inherently be assigned higher priority than any other type of activity. Managers are always ‘above‘ the respective workers; are important; managers are the people who matter; ‘job-promotion’ is always a move towards higher-management, and so on; these are the kinds of messages we hear every day in business.

Yet from a service-oriented perspective – such as in Viable System Model [VSM], or Enterprise Canvas – there’s no real backing for any of these claims at all: everything is a service, hence, by definition, management is ‘just another service’. This has huge implications for organisational-design, both functionally and structurally, and, of course, politically – a point of which we again need to be wary. There are a fair few articles here on this, including:

When we review the Taylorist concept of management through a service-oriented lens, what we find is that it describes an overly-simplistic subset of the services needed for system-viability:

  • assign resources to ‘child’-services – the ‘boxes’ of functionality under that management’s ‘control’
  • aggregate performance-information from all ‘child-services’

…yet bundled together with one very odd twist:

  • issue orders to child-services, whilst explicitly forbidding any feedback about or contextual adaptation of those orders

To quote from the ‘Insuperordination’ post:

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 resource-allocation and performance-aggregation make sense enough in service-oriented terms; yet in most real-world contexts that final command-and-control twist makes no sense at all. It forces the system to run ‘open-loop‘, which is only suitable for “well-defined systems where the relationship between input and the resultant state can be modeled by a mathematical formula” that do occur with some IT-systems but often do not occur at business-scale; and it explicitly blocks real-time self-adaptation, which forces decision-making further and further away from real-time. Worse, if the management-structure is designed as a strict tree-hierarchy, partitioned into silos and sub-silos, there is then no means of dealing with cross-silo issues other than by traversing all the way to the top of the tree and all the way back down again – presenting the kind of all-but-impassable performance-bottleneck that’s also a typical outcome of micromanagement.

There’s also yet another twist that arises from Taylorism’s dependence on the linear-paradigm’s primacy on analysis. As we saw in the previous post in this series, the Market-Cycle shows that we need to loop from future (purpose, relationship, attention) to present (transaction) to past (completion and performance), linking back to the original purpose as the new future. The catch here is that all analysis is actually past-oriented: the data that it uses for its analysis must already exist. So whilst what we should have, for viability, is something like this, with management-type functions – particularly direction-services – linked cleanly to the Market-Cycle:

What we end up with instead, with the past-first orientation of analysis, is something more like this, where the cycle is being driven back-to-front, and the structure overall upside-down:

Which itself then tends to fall all too easily into the ‘quick-profit failure-cycle’:

Hence, too, those classic past-oriented strategy-errors such as thinking that ‘Last year +10%’ is a viable strategy…

And although Taylorism is, as we can see, enough of a problem already, it’s often made even worse by the equally-scrambled relationships between management and ‘owners’. Reality is that we won’t be able to disentangle the ‘no-jobs-for-generalists’ problem unless we also address that architectural challenge as well…

[[Next: Part 3c: ‘The impact of the ‘owners’ ‘]]
Posted in Business, Enterprise architecture Tagged with: , , , , , , , , ,

Leave a Reply

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