‘No jobs for generalists’ – a summary

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?

At first glance they’ll no doubt seem fairly straightforward questions: yet of necessity they spawned a whole stream of very long posts here – which I hope have been useful to some folks? Anyway, time to summarise and wrap this up.

No jobs for generalists?

Way back in the distant past (i.e. about two weeks ago… 🙂 ) we started with a question from Pradeep about how to learn enterprise-architecture. One of the core themes that came up that first post, ‘On learning enterprise-architecture‘, was that enterprise-architecture is a generalist-discipline: by its nature it requires us to straddle and bridge between multiple domains.

The next catch was around how get employment in enterprise-architecture – and in particular, employment in true whole-of-enterprise architecture, rather than solely in specific sub-domains of IT. What we discover in practice is that most forms of recruitment for employment fail to recognise that employment is not necessarily in the form of ‘a job’; and also that almost all ‘jobs’ are defined in terms of a ‘job-description’ in terms of specific skills, responsibilities and deliverables – in other words, specialist, not generalist. So whilst there might well be employment for generalists, it’s usually specified in a form that makes no sense as a generalist. Hence the mildly-exaggerated yet all-too-often all-too-accurate summary that there are no jobs for generalists: the need for such employment may be there, but for recruitment-purposes there’s no apparent way to describe it.

In ‘There are no jobs for generalists‘, we then wandered through various tactics on how to navigate through this dilemma. To work within the system, we need to make it at least look like we seem to be just another specialist:

• to get past the recruiter-barrier, we’ll need to build and maintain a small portfolio of specialist skills , so as to seem ‘employable’
• it is worthwhile to gain explicit certification in appropriate skills at some level
• we need to accept that recruiters will often place us in a more junior role – and at a lower pay-rate – than our skills and experience actually merit
• aim for roles in small- to medium-sized teams
• when ending work-role or contract-role, we need to remember to garner feedback and testimonials for our work

We need to be able to demonstrate that we can ‘play the game’ before we’ll get a chance to break out of the game itself. We then set up that break-out by working around the edges:

• we need to make it clear to our employers that we do like and prefer variety, and tasks the cover the ‘between’-spaces
• we need to demonstrate that we’re always willing to take on something new
• we develop the skills to go with working around the edge, such as systems-thinking, design-thinking, hybrid-thinking and suchlike – and learn how apply these ‘by stealth’
• we ensure that we have an explicit minimum set of defined deliverables – and always get those deliverables done, or doable, before turning to anything else
• we cultivate an attitude of humility toward others – for example, we learn to be willing to say “I don’t know”
• we learn the soft-skills of the trade – how to relate with people, how to communicate, negotiate, arbitrate, and above all how to listen
• we develop our own strategies and tactics to cope with the personal challenges of the work – such as the inevitability of chronic self-doubt
• over time, we also need to choose between the two distinct types of employment-roles for generalists – Insider employee or Outsider consultant

In ‘More on ‘No jobs for generalists’‘ we explored some of the implications of ‘no jobs for generalists’:

• we looked at questions around the identity of enterprise-architecture – what it does, what  business-problem it sets out to resolve
• we looked at the ‘EA job-title problem‘ – that most current so-called ‘EA’ roles in job-adverts relate solely to some aspect of detail-level IT
• we asked about who are the real architects of the enterprise – and the role of CEO and others
• we briefly explored the organisational role of EA, as a steward of  the holistic or systemic view of the enterprise – awareness of the whole as whole
• we pondered whether EA is a ‘new’ discipline: – the short answer is that isn’t, but it systematises the discipline in ways that often weren’t available before EA
• we explored why the job-description problem is such a challenge for generalists – for example, why conventional tactics such as resumes make little sense in practice

In practice, it seems that, to get anywhere on these challenges, we first have to re-educate the HR/recruitment industry:

• we need to challenge role-specification mistakes such as ‘the Implausible Guru’, ‘the Random Wishlist’ and muddled mixtures of strategic-, tactical- and operational-layer responsibilities
• we need to advise recruiters on how specify roles not just in terms of specialism ‘boxes’, but also inter-box relationships, the depth of specialism needed in each domain, and the attitudes or approaches needed within the overall role and culture – because new skills are easier to learn than new attitudes

In ‘Yet more on ‘No jobs for generalists’ [part 1]‘ we started to explore some of the underlying assumptions that give us so much trouble. We began by comparing three different paradigms:

• a linear paradigm (or ‘digital paradigm’) asserts that everything is connected by strict patterns of cause-and-effect – everything is a distinct, separate ‘box’, in a distinct, nested structure of ‘boxes’, each to be worked on by a specialist in everything to do with that one type of box
• a flow paradigm (or ‘analogue paradigm’) asserts that everything is in flux and flow always undergoing change – there is no certainty, there are no boxes, no states, no components, no rules, no boundaries, and nothing to divide
• a systemic paradigm asserts that both linear and flow paradigms are true, that neither paradigm can be true on its own, and hence requires a synthesis of both ‘boxes’ and ‘lines’ within a broader systemic scope, changing in line with ‘variety-weather’

Most people – perhaps as much as 80% – will bias naturally towards some variant of the linear-paradigm. In essence, Taylorism is the direct outcome of the linear-paradigm applied to business at large scale. In terms of impacts on recruitment:

• Taylorism assumes that every activity can be broken into predefinable tasks, with the capabilities for those tasks definable as a specialist ‘job-description’, and everything defined in terms of objects or ‘resources’ – hence people as ‘human resources‘, interchangeable units of capability
• there are no generalists in Taylorism – every box is complete in itself, and all the boxes fit together with ‘scientific’ precision
• the general notion of a ‘job’ is almost entirely an artefact of Taylorism.
• a direct corollary is that since Taylorism has almost no concept of a generalist, there are no ‘jobs’ for generalists.

By contrast, in a flow model of business asserts that everyone is a generalist:

• a true flow-model ‘job-description’ would consist solely of ‘work as directed, if you feel like it, and make it up as you go along’
• however, a flow-model notion of a ‘job’ does not scale – and is often inherently inefficient and/or ineffective at scale

In a systemic model of business:

• we still have a somewhat-Taylorist notion of ‘jobs’ in boxes, but the boundaries of the boxes are somewhat ‘squishy’ – the ‘squishiness’ is needed in order to allow for movement, for flex, for limited change
• we need explicit specialists and their in-the-box skills and capabilities in order to get things done – the ability to deal with the fine-detail that applies at the actual moment of action
• we need explicit generalists, to link things together
• these are emphases, not necessarily distinct roles – each person may be (and usually will be) some mix of specialist and generalist

We will always need human skill to work with inherent-uncertainty:

• skill is the human mechanism via which we adapt our ‘rules’ to cope with complexity and inherent-uncertainty
• no system of automation can ever be complete within itself – it will always require human skill to support it
• the more we automate, the more we put at risk the means via we which we cope with the inherent limitations of that automation
• every ‘job’ will include some distinct mix of specialist and generalist – never just specialism alone
• every ‘job’ must describe how it will support the learning that will make that ‘job’ viable in real-world practice

There are also significant implications for business-education:

• skills cannot be taught: they can only be learnt – training is about pushing rules in, education is about bringing skills out
• skills are personal – they arise and reside  only within that person
• to create some kind of ‘skills-transfer’, the task of education is to provide conditions under which skills can be learnt
• it takes time to learn new skills – see the Sidewise post ‘10, 100, 1000, 10000‘
• abstract cross-context meta-skills are as important as context-specific specialist skills
• continuous-education must be an explicit employer-responsibility – not something to somehow handball to everyone else
• continuous skills-education needs to be part of every job-description – and also every employment-contract
• in a knowledge-economy, the ‘means of production’ reside primarily in individuals’ skills and knowledge
• an enterprise gains access to people’s skills and knowledge through its relationships with those people – the relationship is the asset, not person-as-asset

In ‘Yet more on ‘No jobs for generalists’ [part 2]‘ we explored a bit more about the context for generalism, in terms of structures and interdependencies between services. On the respective roles themselves:

• specialists focus more on content – the actual ‘doing’ of work
• generalists focus more on context – the ways in which different aspects of work link together

That much should be obvious if we look at work and ‘jobs’ from a systemic view. However:

• most people do not think in terms of systems, but in terms of linear ‘transactions’ and linear outcomes
• in effect, most non-’market-transaction’ work becomes ‘invisible’
• major problems arise because of the ‘non-visibility’

To avoid getting trapped in the politics of work, we need a more architectural approach to what’s going on, which we can summarise in two parts:

• use Market Model and Market-Cycle to describe the scope and context of work
• use Enterprise Canvas to describe the interdependencies of work in that scope and context

In Market-Model and Market-Cycle:

• an organisation employs a person in a job for the purpose of creating and delivering value towards the aims of the enterprise(s) with which the organisation is associated
• value is added to and moved around the overall shared-enterprise within the context of a market, and beyond
• the visible transactions in the market take place between the organisation and its suppliers and customers
• other non-visible transactions and interactions may take place anywhere within the organisation, its ‘supply-chain’, market or extended-enterprise
• the Market Cycle shows that the availability of a transaction depends on the customer’s attention, which depends on relationship with the customer, which depends on trust, or reputation as proxy for trust
• in the linear view, ‘non-visible’ interactions are separate from the transaction – i.e. an undesirable ‘cost’ or ‘overhead’
• in the systemic view, ‘non-visible’ interactions are integral to the transaction – i.e. transaction-profit depends on the entire set of interactions

Much the same applies as we unravel the interactions at the far side of the transaction, where we need to complete:

• the tasks (process) of the service itself
• the overall transaction (for example, the organisation is paid)
• satisfaction of customer-attention (customers feel that they have been heard)
• renewal of customer-respect (respect of customer, and by customer)
• renewal of overall mutual-trust

In terms of ‘completeness’:

• a systemic view accepts the necessity of all of these interaction-types, with balance between timescales and time-horizons of strategy, tactics and operations
• the linear-view focusses only on a subset of the service-cycle – the segment that it identifies as ‘the market’, centred solely around the visible-transactions
• if ‘performance’ is measured primarily in terms of completion from the organisation’s perspective, the usual result is the ‘quick-profit failure-cycle’ – leading directly to the loss of viability of the business in the longer term
• if we want to prevent business-failure, every ‘job’ must be able to ensure the ‘completeness’ of the respective service-cycle
• we need to be able to describe the interdependencies of each ‘job’ in a way that ensures the viability not only of the ‘job’, but of the entire enterprise within which that ‘job’ would exist

To model service-interdependencies with Enterprise Canvas, we assert that:

• everything in the enterprise is, delivers or represents a service.
• every service exists to add value to the enterprise
• every service sits at an intersection between ‘horizontal’ flow of value around the enterprise, and service to the values and principles that express the aims and purpose of the overall shared-enterprise

Since everything in the enterprise ‘is’ a service, we can can model everything in essentially the same way:

• we describe the content of the service – what it uses, what it does, how it does it, and so on – in terms of assets, functions, capabilities, locations, events and decisions
• in essence, a service consists of bringing together a set of functions with a set of capabilities
• with machines or machine-like IT-systems we bundle function and capability together – Taylorism explicitly describes every ‘job’ in this way, as a distinct ‘unit of production’
• with people, the capability resides in the person, and is then matched up with a function to deliver the service

In short:

• a machine or IT-system usually implies a one-to-one correspondence between capability and function
• a real-person usually implies a many-to-many correspondence between capability and function

Or, to put it another way:

• we buy machines for their functions, and the respective in-built capability to deliver that explicit functionality
• we hire real-people for their capabilities, and their ability to apply those capabilities to any required functions
• if we use only one subset of each person’s capabilities, by assigning each person solely to a single Taylorist-style ‘job-description’, we’re not likely to be using that person’s capabilities at best effectiveness
• we need to hire for capabilities, not ‘functions’

Enterprise Canvas also gives us a means to map out the interdependencies that underpin any viable business – every service must also link to support-services that:

• direct and link it to the larger strategic, tactical and operational plan
• coordinate it with other services
• keep it on track to enterprise-values

Although Taylorism would bundle all of these other services under the management-banner, it’s essential that we respect the differences:

• direction-services do align quite well with Taylorist assumptions
• coordination-services operate primarily between the Taylorist silos
• validation-services must often be separate and distinct from management – sometimes as mandated by law
• by definition, many of the tasks in the coordination-services and validation-services are generalist, not specialist: they link between, not deliver ‘within’
• the classic Taylorist ‘org-chart’ view of the enterprise is a dangerously incomplete view of what needs to happen within a viable enterprise
• all of this applies to every service, at every level of granularity

Enterprise Canvas summarises all of the key interdependencies, service-relationships and subsidiary-services that every service would need to identify – and, in turn, every ‘job’ that would implement that service:

• all of those support-services need to exist somewhere, and likewise the interfaces and the like through which the respective service can access them

I’d intended the post ‘Yet more on ‘No jobs for generalists’ [part 3]‘ to be a brief-ish summary on where and why Taylorism is a poor fit for many present-day business-needs, and what that implies. Unfortunately the post turned out to be so huge that I had to split it into six subsidiary-posts, in line with its chapter-headings.

In Part 3a: ‘An incomplete science’ we explored the core Taylorist notions of ‘scientific management’:

• ‘Taylorism’ is the linear-paradigm as applied to business-design, as in ‘scientific management’, business-process re-engineering, Six Sigma and suchlike
• its mindset is still predominant in much present-day management thinking, education and practice

Its key assumptions include:

• everything is connected by strict identifiable cause/effect relationships
• all relationships are linear and ‘reversible’ – cause can always be inferred from effect
• everything is reducible to identifiable algorithms with identifiable parameters
• all parameters are separate and independent from each other, other than through the algorithm
• the only relevant system-effects in algorithms are feedback-loops and delay-loops
• given reliable execution, all outcomes of an algorithm are exactly predictable and repeatable
• all functionality follows strict combinatorial logic
• all production-units are exactly interchangeable
• appropriate system-design will inherently yield control over the system

When applied as ‘scientific management’, it also asserts:

• every production-unit requires an external manager as controller
• every production-unit requires external analysis to adjust the unit’s algorithm(s)
• control and analysis of production is always external to that production-unit – Taylorism explicitly rejects the concept of ‘craft’, that decisions take place within within the work itself
• the sole function of a production-unit is to execute its predefined algorithm(s)
• the internal operations of all production-units should be ‘de-skilled’ wherever practicable
• hierarchies of functional-decomposition imply matching hierarchies of management and external-consultants
• capability to deliver the functionality of each production-unit is pre-specified in a requirements-document and/or ‘job-description’

In Taylorism, the core metaphor of the organisation is as a machine:

• the sole function of workers/automation is to execute the processes of ‘the machine’, in accordance with the ‘job-description’ – in this sense, a ‘job-description’ is a specification for an externally-controlled, non-autonomous ‘doing-unit’
• the sole function of analysts, ‘time-and-motion men‘ and other ‘external consultants’ is analysis and reconfiguration of ‘the machine’, from a viewpoint outside of that of the respective production-unit in ‘the machine’
• the primary function of management is control of ‘the machine’
• analysts, managers, management are indispensable to ‘the machine’, because without them, there would no means to control ‘the machine’.
• human workers are dispensable, and should replaced by automation wherever practicable – the Taylorist ideal is a fully-automated factory where the only human roles are for analyst-managers

In practice, Taylorist does not fit well with any context where any of the following apply:

• any non-linearity or inherent-uncertainty in parameters, algorithms, feedback-loops and suchlike – such as in wicked-problems and kurtosis-risks
• any non-transitivity or network-effects – where performance-results from outputs cannot be used directly to identify required changes in inputs
• any context undergoing ‘Black Swan‘ disruption or other step-change
• any context where the parameters of the context themselves are inherently uncertain – such as in ‘stormy’ variety-weather
• any context where the rate of change or the level of uniqueness outpaces the ability of external-analysis to adapt its response to those changes
• any context for which linear analysis is inherently unsuitable

Note also that:

• Taylorism has no built-in means to handle inherent-ambiguity or inherent-uniqueness
• its only option is to ‘escalate’ up the management/analyst hierarchy-tree, resulting directly in the Taylorist trap – a ‘death-spiral’ that leads inexorably towards ‘analysis-paralysis’.
• its over-focus on automation also feeds another ‘death-spiral’ that makes it all but impossible to learn the skills needed to design and operate that automation

In Part 3b: ‘Management as a service’ we contrasted the Taylorist centrality of management with a more service-oriented view:

• in Taylorism, management is a class of activity that is fundamentally and qualitatively separate and distinct from any other type of work – it provides overall control of ‘the machine’, and hence must inherently be assigned higher priority than any other type of activity
• in a service-oriented perspective, everything is a service, hence, by definition, management is ‘just another service’

From a service-oriented perspective, the Taylorist concept of management 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’
• issue orders to child-services, whilst explicitly forbidding any feedback about or contextual adaptation of those orders

The latter is an arbitrary overlay on top of a service which will usually cause the service-interfaces to fail:

• it forces the system to run ‘open-loop‘, which is only suitable for some types of IT-systems but not occur at business-scale
• and it explicitly blocks real-time self-adaptation, which forces decision-making further and further away from real-time
• it blocks any 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 – creating a potentially-impassable performance-bottleneck
• it forces a past-oriented rather than future-oriented view of business-operations – which tends to fall automatically into the ‘quick-profit failure-cycle’, driven by past-oriented strategy-errors such as ‘Last year +10%’:

The next subsection, Part 3c: ‘The impact of the ‘owners”, explores how and where financial-investors come into the service-oriented picture. If we follow the Taylorist logic of organisation-as-machine:

• not only does the mindless machine require a controller-manager to control it, but it also needs an owner to give that control its direction and purpose
• the owners are the controllers of the controllers
• most current law and custom assert that the financial-investors in an organisation are the ‘owners’ of that organisation, and thus have exclusive right to set the direction and purpose for that organisation
• hence, in a commercial context, organisation as ‘machine-for-making-money’, on behalf of the owners

Yet from a service-oriented perspective, this Taylorist view of the organisation and its owners makes very little sense, because:

• money itself is one of the least-successful and least-reliable motivators for enterprise
• the motivators that do work well, such as autonomy, mastery, and purpose, are all explicitly blocked in Taylorism – autonomy is forbidden, skill (mastery) is designed-out wherever practicable, and purpose comes solely from the outside.)
• in any case, owners and managers alike are ‘just another service’, with no inherent priority over any other service

• symbiote (primary-investor) – committed to the aims of the enterprise
• parasite (beneficiary-investor) – interested primarily or solely in returns to self
• grazer (market-investor) – invests in the market, not the organisation
• predator (attack-investor) – invests for the purpose of gains from destruction
• scavenger (derivative-investor) – invests solely to ‘game’ disruption within the market

Implications from this include:

• all these investor/beneficiary types do play a part within the overall business-market
• however, to an individual organisation, any type of investor other than a symbiote is likely to be bad news.
• to enterprise-architects, the needs of the organisation must come first
• any structures we develop must prioritise and support the symbiote-investor relationship above all other types of investor
• our architectures must support the needs of the symbiote-investor – resilient, responsive, self-adaptable, purposeful, with good long-term returns
• Taylorism similar linear-paradigm models give us the exact opposite – brittle, non-responsive, slow-to-change purposeless ‘machines’, inherently prone to failure-cycles caused by short-termism and a built-in inability to ‘connect the dots’.
• Taylorism and its related management-models and market-structures prioritise the needs of the respective investor-types in the exact opposite order to what our organisations need

From a design-perspective, in terms of re-prioritising the investor/beneficiary structures and their impacts:

• we can’t do anything about the politics or the law – other than document how and why it doesn’t work
• we probably can’t do much about management-structures – other than document how and why they don’t work, too
• we probably can’t do much about the linear-paradigm itself – other than describe its inherent flaws and challenge its various manifestations such as IT-centrism
• what we can do is make it clear why and where our architectures need their generalists – and help others describe what it is that those generalists need to do, so that our organisations’ recruiters can find the people that we need for those roles

That’s what all of this long series of posts has been about: finding the right people to fit a very real yet all-too-often unacknowledged business-need.

In Part 3d: ‘A question of fitness’, we linked to the concept of ‘fitness for purpose’, exploring the use of ‘fitness landscapes’ to guide selection of appropriate architectures. The practical problem we face is that:

• in relation to current business-realities, most of those deeply-held linear-paradigm beliefs simply do not work ‘as advertised’
• many of those deeply-entrenched vested-interests are actively damaging the viability not just of individual organisations but of the entire business-ecosystem in which all of our organisations operate
• if something in the enterprise doesn’t work, it is our professional responsibility as enterprise-architects to reduce and resolve the respective risks to our organisations
• yet even to talk about this – let alone publicly do anything about it, in terms of architecture-designs – will often seem tantamount to career-suicide, or worse.
• So what can we do here that would sidestep those dangers? – and actually achieve viable, verifiable, sustainable results for our client-organisations?

In business, we talk about ‘fitness for purpose’: but how do we describe what ‘fitness’ is? If possible, how would we measure it? How could we compare different ideas, different models, different designs or implementations, in terms of their ‘fitness’? One of the best options for this, that will also help to keep emotion out of the picture, is to model each context as a fitness-landscape. We explored here how to use the SCAN frame as a base for context-space mapping:

In SCAN:

• the vertical axis is ‘time-available until decision/action’
• the horizontal axis is a spectrum of modality from fully-predictable to inherently-uncertain
• the key boundary on that horizontal axis – the position of the red dividing-line – is the Inverse-Einstein Test: where doing the same thing either always leads to the same results (left/blue), or may lead to different results (right/red)

Using this as the base-map for a fitness-landscape

• the linear-paradigm asserts that everything is ultimately subject to explicit, certain, predictable control
• Taylorism and other linear-paradigm models will only succeed – have strong ‘fitness’ – where the context is always predictable
• such models won’t – can’t – have high fitness for anything inherently-ambiguous or inherently-uncertain, over on the far side of the Inverse-Einstein Test
• hence wherever we hit anything in business that is not inherently predictable and controllable, Taylorism is not going to be a good fit for that business need
• if everything in that business-context is built around Taylorism, and/or if Taylorism is the only choice we’re allowed, then by definition we will have business-problems there that we will not be able to solve…
• whenever the workers in a Taylorist model hit anything uncertain, where reality shifts over to the far side of the SCAN frame, the decision must be ‘escalated’ to a ‘higher’ level -but that ‘higher’ level usually lacks the contextual knowledge needed to solve the problem
• even if the knowledge can be found from other than at the point of action, it all takes time – hence a response that may be too slow to keep pace with the real-time action.
• unlike humans, automation has no means to cope with anything on the far side of the Inverse-Einstein Test – which means that as soon as does hit against something that it doesn’t know how to control, it’s stuck: it can’t make any decision at all
• system-designers typically add more and more and more ‘business-rules’ to the system, to try to plan for every possible eventuality
• yet because Murphy’s Law is the only true law in town, there’ll always be yet another ‘something-that-doesn’t-fit’
• hence any system that attempts to rely exclusively on linear-paradigm automation is guaranteed to fail at some point in any real-world context

A SCAN-based fitness-landscape would include:

• predictable versus ambiguous
• real-time versus time-available-for-experiment
• business-need mapped to the respective areas of the frame
• the dynamics of the context, such as its variety-weather – the variety of the variety in that context

A single model is a point-solution within the overall fitness-landscape. By mapping Taylorism and all other management- or design-techniques in terms of degree of fitness at each point, we can derive:

• where and where not to use the respective models
• the extent of potential reliability or risk if we do use those models for that business-need
• and thence, a context-sensitive management-architecture which selects appropriate techniques according to their respective fitness to the dynamics of the business-context

Note that at times we might have a ‘fitness-landscape’ that’s as turbulent as a stormy ocean. What the fitness-landscapes show us is that:

• whilst classic Taylorist models do work, there are fewer and fewer contexts at present where they would fit well
• even those contexts where they do fit might cease to be so at any moment.
• clearly we do need available alternatives that can cope well with this type of turbulence – alternatives that are more resilient, more adaptable, more self-adaptable too
• all of those alternatives depend on a much more explicit role for generalists who can help to take up the strain, and who can make and remake the changing connections that keep the enterprise on track to its aims even in the stormiest of variety-weather.

In other words, generalists such as whole-scope enterprise-architects. Who need employment as generalists. Which is where we started on all of this exploration.

In Part 3e: ‘A question of value’,  we then explored how we could describe the business-value of generalists:

one of our core problems here is that Taylorism assumes a direct, linear, causal connection between work and final value

a typical Taylorist work-role is a ‘box’, a ‘cog in the machine’ that carries out a specified item of specialist work with a specified outcome and specified end-value

generalists’ work sits between the boxes – the bits of glue and string and duct-tape that take up the slack in ‘the machine’ and make it possible for ‘the machine’ to work amidst the uncertainties of the real-world

generalists’ work contributes to the value of the end-product via at least two other work-roles, maybe more – hence there is no obvious direct connection to end-value via the usual mechanisms of price and the like.

Taylorism is likely to purport that generalists should never be needed – there’s often a huge ‘anti-want’ for generalists

The reality is that, by definition, generalists’ work has a non-linear connection to value – which is inherently going to be problematic given that the predominant paradigm assumes that value-connections are always linear. (The post explored a couple of examples on this.) Some practical issues that arise from this:

• the ‘deniability’ of non-linear connections is sometimes a bit too useful in a Taylorist-dominated world…
• especially for ‘far-distance’ generalists, our work often isn’t valued at all – in a monetary sense, at least.
• often generalists will end up either being forced to do some kind of specialist-work, or else just have to accept that we will not be paid for what we do
• this is both a direct and inevitable outcome of the inadequacies of Taylorism – from which everyone loses

It is possible to get employment as a explicit generalist, yet:

• that isn’t the same as ‘a job’ in the usual Taylorist sense
• at the kind of level that enterprise-architects should typically work, the difference in value-as-pay is often very real – often 30% less, or worse, for equivalent skills/experience levels
• even in a somewhat-more-realistic concept of ‘value’, as generalists we’re forced to choose between accepting a permanent and significantly-lower valuation of our worth, or change to do less-satisfying specialist-work that is of less value to the organisation yet actually costs that organisation more
• in short, that overall Taylorist-driven model for valuation of work just does not work.

A worked-example of an explicit generalist role for front-line work showed the following implications in terms of what the organisation actually values, and for what characteristics it will pay a generalist significantly less than the respective specialist:

• multi-task roles are worth less than single-task roles
• customer-relations are of relatively low worth to the organisation
• soft-skills and adaptability are of relatively low worth to the organisation
• a focus on the overall customer-experience (customer-perspective, ‘outside-in‘) is of lower worth than on the product itself (organisation-perspective, ‘inside-out’)
• roles that must be aware of broad-scope values-issues are of lower worth than specialist roles that may purport to be ‘value-free’
• dealing with low-level implementation-detail is of lower worth than abstract-oriented roles that may dismiss such details as being Somebody Else’s Problem
• willingness to do whatever is needed has a lower worth than sticking strictly to the ‘job-description’
• systemic knowledge has lower worth than domain-centric knowledge
• roles in slower-paced, more-predictable environments have higher worth for the organisation
• indifference and rigidity have higher worth for the organisation

What’s even more scary is that those themes are what Taylorism inherently does assume and assert:

• single roles
• robotic non-relations
• product-orientation
• ‘value-free’ indifference
• rigidity
• certainty of ‘control’
• minimal to no variation
• glacial pace of change

– none of which are good survival-traits in most present-day business contexts: which might explain why so many organisations are in so much trouble these days?

Clearly we need a much better balance here, and much stronger respect and support for generalist roles.

There definitely do need to be explicit jobs for generalists, properly described in terms of how generalists actually work – and not trying to force them into a pseudo-’specialist’ mould that simply does not make sense.

—

All of which at last brings this summary, and this series of posts, to The End (for now, anyway…). A sigh of relief, perhaps? 🙂

Over to you, anyway, for your comments/suggestions and suchlike.