More on ‘No jobs for generalists’

Wow… My previous post ‘There are no jobs for generalists‘ certainly touched a nerve: it’s been my most popular post for months, with so far (barely a day later) well over 1,000 reads, and some 35 ReTweets so far on Twitter. To give just one example of overall sentiment, from Michael Nacos:

and just like that, you read about your predicament in a blog post: “no jobs for generalists” buff.ly/PkDVoV #careers #life

In short, an all-too-common predicament, it seems…

A lot has come up from this, so it’s worth doing a revisit here to pick up on some of the themes that came up from that post, on the Twitterstream and in the comments to the post.

First, though, a quick recap on the post itself:

• One of the common questions I receive is around ‘How do I get a job in enterprise-architecture?’, or in some other generalist discipline.
• For historical reasons, the usual notion of a ‘job’ is a predefined package of actions, capabilities and responsibilities – a ‘little-boxes’ view that only fits well with a specialism-oriented definition of work.
• By contrast, the work of generalists tends to take place in the spaces between the ‘little-boxes’ – the ‘lines’ that connect and coordinate between the ‘boxes’.
• A ‘box’-oriented view of work has no means to describe the work that takes place between the boxes. (That doesn’t mean that the work doesn’t exist, or that there is no need for work-roles to carry out that work, but rather that the ‘box-oriented’ view has no means to describe what happens there.)
• Hence, in practice, there are no jobs for generalists – or, to be more precise, almost no apparent jobs, in the conventional sense of ‘a job’.
• Given that problem, if we want to work as generalists, we’ll need some other means to find employment in that work.

The rest of the post explored various strategies and tactics on how to do this.

So, to the responses. First, the Twitterstream (or rather, a somewhat-simplified version), which I’ll let speak for itself:

• MartinHowitt: EA by stealth? Love it. Really useful post, thx Tom. Do I really have to go work in a consultancy? They’re so *cheap* 🙂
• tetradian: “Do I really have to go work in a consultancy? They’re so *cheap* 🙂 ” – grin indeed 🙂 (and no, you don’t. 🙂 🙂 )
• ChBrain: “[…] no jobs for generalists […] #entarch” reminds me of @scottwambler Generalizing Specialists: http://tinyurl.com/32dpeg
• MartinHowitt: @tetradian you nailed it ALL except for that! I hope in the new world time spent with socents will have the same CV enhancing effect 🙂
• tetradian: “I hope in the new world time spent with socents will have the same CV enhancing effect 🙂 ” – strongly agree.
• thoughttrans: Did you REALLY have to get my blood boiling before my morning coffee!?! LOL
• tetradian: “blood boiling…” – sorry… 🙁 🙂 (great comments on that post, btw – many thanks!)
• scottwambler: Generalists and specialists are two different extremes.  Extremes are often problematic.
• tetradian: “Generalists and specialists are two different extremes. Extremes are often problematic.” >true
• leodesousa: we guide our staff to aspire to higher roles by blending the two extremes – http://leodesousa.ca/2010/02/enterprise-architects-what-attributes-do-you-look-for/ #entarch
• ChBrain: @scottwambler sometimes it helps to explain if one concept is put to the extreme. But who is a real full specialist in #EntArch
• ChBrain: @leodesousa @scottwambler Thank you for sharing. I like to set the two extremes to start a thinking process in people. Tough.
• leodesousa: glad you liked my post. Do you have any feedback? Always looking for ways to improve my approach #people
• walidkoleilat: The insider reminds me of solution architects and outsiders reminds me of enterprise architects
• ChBrain: @walidkoleilat Its two sides of the same for me: I currently work as holistic #EntArch and project focussed Solution Architect.

(I’d strongly recommend the articles at both of those links, by the way – though note that ‘generalist’ here is probably closer in meaning to Leo de Sousa’s ‘Strategic Practitioner’ than his ‘Generalist’.)

Anyway, on to the comments, and the questions and challenges that arose there.

In his comment to that previous post, Pradeep again came up with another whole stream of questions that each need some response. The first starts with a quote from the post itself:

“in a viable architecture, we need to pay attention not just to the ‘boxes’, but to the ‘lines’ that link between them. Without some kind of metaphoric glue to hold the boxes together, the whole thing falls apart”

Now it raise the question in my mind where this lead us to? Does EA has its own identity? Will there be any roles like Enterprise architect ever? Most of the people who talks about EA does not even have “title of EA”.

One part of this is the identity of enterprise-architecture: what does it do? Does it even exist? Is there a real business-problem that such as discipline would resolve? Probably the classic response to that is Len Fehskens’ Open Group blog-post ‘Enterprise-architecture’s quest for its identity‘: I’d recommend that as essential reading here, not least because it explains key distinctions between different categories of architecture/generalist roles.

Another part of this is the ‘EA job-title problem‘. Courtesy of some extremely unwise lobbying by IT-oriented folks such as the Open Group and the big IT-consultancies, the term ‘enterprise-architect’ now seems generally understood by recruiters to mean ‘anything that’s a bit blurry that’s sort-of IT’. The ‘IT’ part seems to be central in this interpretation. The catch here, as Len explains, is that enterprise IT-architecture (EITA) is only a subset of the actual scope of EA, but the IT bit is the only part that recruiters understand. So the moment we talk about ‘enterprise-architecture’, recruiters assume we mean some style of detail-layer IT. Which means we’re stuck: the only term that actually describes what we do – ‘the architecture of the enterprise’ – has been hijacked to mean something else in a different domain entirely (and entirely different pay-grade, too). So we’re forced to use another label – almost any other label – even though it doesn’t properly describe what we do. This is yet another reason why this whole problem is so darn infuriating…

Pradeep’s next question addresses who are the architects of the enterprise?

Is CEO the real chief enterprise architect( And his team of direct reports are Enterprise architects)?

Yes, and sort-of-yes, is the short answer; the longer answer is a bit more nuanced, of course. 🙂 See Chris Potts’ sort-of-novel recrEAtion for the best explanation of this point. Chris’s view there is essentially an ‘inside-out‘ perspective, where the organisation ‘is’ the enterprise; I tend to prefer an ‘outside-in’ view, where ‘organisation’ and ‘enterprise’ are not the same; but since I argue that an EA creates an architecture about an enterprise, but for an organisation, Chris’s view is probably the one that makes most practical sense here.

Next, Pradeep asks about the organisational role of EA:

if so fundamental question “Why do I need EA?” “What is that Gap it fills?” Why another term(EA)? We do have people/Dept who already works on Org structure, Purpose,business model,strategy,alignment,planning,execution,change management etc. All this was being done even before EA came into picture.

Yes, exactly true: the catch, in most organisations, is that it’s all done in separate boxes – as indicated by all those separate titles, in fact. The problem, as Deming and many others pointed out decades ago, is that the organisation becomes fragmented, disjointed, because there’s nothing to link between all those boxes and create something that acts as a single unified entity. And because of that fragmentation, most optimisation applies only to a single ‘box’, often at the expense at of everything else.

So the gap that EA fills – in conjunction and collaboration with other cross-functional generalist-disciplines – is the holistic or systemic view, in the Deming sense: awareness of the whole as whole, linking from strategy to execution and back again, linking every resource and action and event back to business-purpose, and so on. The catch is that almost everything that it does is between the ‘boxes’, and hence all but invisible to those who see the world only in terms of discrete boxes – as is the case with most current approaches to HR and, thence, to recruiting. Which is one of the core reasons why we have such difficulty getting work…

And Pradeep asks whether EA is a ‘new’ discipline:

So how does EA creates its “own unique place” without “being redundant”
Are we just trying to create new decipline(for the sake of it)in which we can place anything to broaden its scope?

No, and no, is the short answer: it’s not a new discipline, and it does have a very clear scope of action. As in Pradeep’s job-titles list above, there are plenty of people doing bits of the EA role – in fact it’s actually everyone’s responsibility. The only ‘new’ thing that the formal discipline of EA brings to the party is an explicit and systematic approach to coordination and guidance of all of these disparate, otherwise-implicit ‘wholeness-responsibilities’.

And whilst the overall scope of interest for EA is – and must be – literally everything that the organisation is and does, and its relations and interactions with its entire business-ecosystem, the scope of action for EA is much more limited. For example, it’s primarily about decision-support, not decision-making: in general, we advise about whole-of-context concerns, and help others to communicate with each other – but we don’t try to tell specialists how to do their job, because they’re a lot better at it than we are! There are a couple of older posts here that might be useful on this: Making sense of architecture roles, and Enterprise-architect as generalist.

On the job-description problem – that everything is geared towards specialist-style ‘boxes’ – Pradeep suggested one possible tactic, in a comment to an earlier post:

I had to create three resumes highlighting 1) PM skills 2) solution architect skills and 3) Information architect skills in order to sell myself.

I’ve done much the same as this myself in the past: I think I used to maintain four different resumes for wildly different business-domains. The problem is that not only is it ridiculously time-consuming, but it also ends up confusing everybody – especially the recruiters, who couldn’t understand why ‘my’ resume could turn up several times in a single keyword-search.

And what on earth do we put in those resumes? My current ‘official’ resume is already something like 15 pages long, and even most of that only relates to conventional contract-type work I’ve done in the past decade or so. It doesn’t include most of my real work, which looks more like this:

• Client: [someone]
• From: [some day], 9:30am
• To: [the same day], 11:30am
• Responsibilities: urgent review of client’s overall business strategy, as a ‘demonstrator’-task with a view to obtaining longer-term contract-work on enterprise-architecture
• Client outcomes: identified fundamental flaws in client’s strategy, and devised agreed appropriate alternate strategies to reduce risk, leading to savings and cost-avoidance of anywhere up to $1billion (as described in revised strategy formally published two weeks later)
• Own outcomes: nothing – no payment (it was classed as a consultant-interview) and no paid-work (“Thank you, we’ll keep in touch” – which they didn’t)

(That was a real example, by the way: I’ve hidden the dates and the client-name, but otherwise that was pretty much it. 🙁 )

I’ll admit I’m a fairly extreme case: in addition to the usual cross-function generalism, my real specialism is metaframeworks (frameworks to build frameworks) and metamethodologies (methodologies to build methods to build methodologies to build methods) – which is very, very necessary work in the overall scheme of things, and someone has to do it. Yet it’s kinda abstruse by most people’s standards… so there ain’t no ‘jobs’ advertised for that kind of work. And no-one seems willing to pay for it in any case, because they assume it’s just trivial ‘background glue-stuff’ that ‘sorta just kinda existed anyway’ – not realising that it didn’t exist until I (and others like me) had done the hard work to create it. Sigh…

And in any case, my greatest business-value usually comes from a throwaway connection that I make somewhere almost at random somewhen in a conversation someplace, to which someone else says “I hadn’t thought of it that way…” – and then, as a specialist, goes on to implement that idea. That ‘I hadn’t thought of it that way’ response happens somewhere in most of the conversations that I have with people – and it should, because that’s a key part of my work is really about. Yet in several cases, those people have literally made millions from that respective idea: but because there’s no way to trace it back to the very real work that I’ve done in the past to create the conditions for that confluence of ideas, I get nothing from it. (It’s not a conspiracy or anything like that, it’s just the way that things [don’t] work.) Which makes life kinda hard… 🙁

So what do we do, when the fundamental Taylorist-type model of ‘human resources’ in predefined ‘boxes’ that’s used in most recruitment not only fails to value what we do between those boxes, but for the most part can’t even see that type of work to recognise that it exists? Seems we’re stuck with the ridiculous situation that before we can get anywhere with this, we first have to re-educate the HR/recruitment industry. For example, as Ondrej Galik asked:

how would you write a job offer if you were hiring an enterprise architect (who does not need to go through what you have just described)? It might be a new template then:)

A couple of clues come up in Pat Ferdinandi‘s comment – for example, the sad search for the Implausible Guru:

From the non-IT side (meaning business side), you will need an MBA in the states and come from first working at a large consulting agency as a management consultant before you can work as a generalist. Even then, you need a specific industry under your belt.

Or there’s the Random Wishlist:

…in the world of IT. Not only do you need to be a business analyst but a business analyst who knows SQL and knowledge of derivatives…for example.

Note there too the random mix of layers, as so often occurs in these ‘wishlists’: strategic/big-picture (‘business-analyst’), tactical/domain-specific (‘knowledge of [financial]-derivatives’) and operational/implementation (‘knows SQL’).

Both of these are really classic signs that they’re struggling with a ‘between-the-boxes’ problem, and trying to find some way to dress it up as a ‘super-specialist’ instead. And since they believe that the best person for every job is some kind of depth-specialist, they’ll search for the deepest specialist who can somehow be crowbarred into all of those boxes at once – not realising that the real need is less about the boxes than the links between those boxes. So we – and, if possible, they – need to understand that that search-approach is, by definition, the wrong way to go about finding the right person for the task.

The right way has three parts to it.

The first part is to identify not only the specialism-boxes, but also the inter-box relationships needed between specialism-boxes. This becomes mandatory in every case where the recruiter – or recruiter’s client – specifies more than one specialism and/or more than one layer within a single ‘job-description’ – in other words, a ‘job’ that indicates any form of implicit cross-functional generalism.

The second part is to clarify exactly the depth of specialism actually needed within each of the domains denoted in the wishlist. For example, we could summarise depth as follows:

• minimal: the domain needs to be considered as relevant, but not much more than that
• black-box: the domain needs to be known only in terms of its exposed interfaces, without requiring any knowledge of its internal operation
• white-box: some knowledge of the domain’s internals, sufficient for concerns such as cross-domain trade-offs, probability and direction of change, failure scenarios and risks, disaster-recovery scenarios and options, etc
• full-depth: full knowledge and experience of the domain, to an identifiable level of skill (e.g. Trainee, Apprentice, Journeyman, Master)

Linked to that, the original client needs to identify who in the organisation already has depth-skill in the respective domain – because a generalist will usually need to rely on that person to do the actual implementation. If there’s no such specialist in the organisation, they probably need to recruit them – which is usually a separate concern from recruiting a ‘between-the-boxes’ generalist.

The third part relates to a fundamental point that is too often forgotten by recruiters, or especially by their clients: skills are easier to learn than attitudes. A true generalist has a very specific type of attitude or approach, focussed more on connections between things than on the things themselves – and although there are real skills involved in this, it is more a matter of attitude rather than skill. (This is a key reason why framing enterprise IT-architecture [EITA] ‘as’ enterprise-architecture [EA] is such a problematic issue: many EITAs are actually IT domain-specialists with interest only in how things connect across that one domain – and don’t have the mindset or attitudes that would enable them to link across all domains in a domain-agnostic way, as full-scope EA requires.) This is also where clarifying the actual required level of skill comes into play: if it’s only minimal, black-box or even white-box level, a good generalist should be able to pick that up very quickly – enough to converse meaningfully with the specialists who do do the final implementation, anyway. In most cases, the real priority is the attitude – and the ‘fit’ with the client-organisation’s own culture – rather than the skills-level as such.

Ironically, the quest for the Implausible-Guru ‘super-generalist’ will often select someone who’s least suited for a true generalist role. It’s often forgotten that an MBA degree is a Master of Business Administration – which almost invariably places the focus on Taylorist-type boxes, not whole-of-system integration. In the States especially, the business-schools prioritise monetary-profit over everything else, whereas an EA or suchlike generalist role must necessarily focus more on the complex relationships between money, price and value from which that monetary profit will actually arise. The large consulting-companies are good at churning out multi-domain specialists, but they’re often not good at linking across anything more than those specific domains – and, like the EITA folks, often have anti-generalist attitudes anyway. And especially for EA and related whole-context disciplines, an over-focus on having ‘a specific industry under your belt’ belies the reality that the most valuable innovations usually come from outside of one’s own industry. In short, not only is the Implausible Guru, well, implausible, but it’s not even a good idea anyway. Oh well.

So where does all of this place us? Perhaps not that much further on, I suspect – certainly in terms of the painful reality that there are still almost no jobs for generalists. But what it has brought up is the following:

• we have a clearer idea of why there are no apparent jobs for generalists
• we have some idea of how go about re-educating the HR/recruitment industry about the real roles of generalists, and the equally real need for jobs that implement those roles
• we need some mechanism or template to describe jobs for generalists
• we have a three-part structure to define or describe at least some of the content for that template

So that’s a start, at least. Yet what else do we need to do? How can we more clearly establish our value within the greater scheme of things – and prove that value, too?

Over to you for your ideas and suggestions, folks? 🙂