There are no jobs for generalists

“How do I get a job as an enterprise-architect? Where do I go for that kind of job?”

This is an obvious necessary follow-up to the post ‘On learning enterprise-architecture‘, and it’s a kind of question I get asked all the time – such as by Pradeep in his comments here, or in a great Skype-conversation with another young enterprise-architect over this weekend.

Yet the short answer is: you don’t. Those jobs don’t exist.

Yep: there’s a problem here…

Defining the problem

Oh, fair enough, if we look at the recruiters’ job-listings, we’ll find plenty of roles that have the job-title of something like ‘Enterprise Architect’. But to quote Inigo Montoya in The Princess Bride:

You keep using that word. I do not think it means what you think it means.

…because if we look at the job-descriptions for those role-listings, it’s very, very rare that such roles have much to do with the literal ‘architecture of the enterprise’. Courtesy of some very intense but very unwise lobbying by the Open Group and others – who are only now starting to realise just how unwise that really was – most employers and recruiters still think that enterprise-architecture is something, uh, vaguely to do with IT, that they don’t much understand, and therefore obviously relates to some junior-ish role that might have something to do with code. Probably. Perhaps. Maybe?

So it’s not unusual to see role-descriptions that say ‘Siebel Enterprise Architect’, for example, or ‘.Net Enterprise Architect’, or specify a great long list of programming-languages as mandatory requirements. And whenever some recruiter calls me up about yet another role like that – “a perfect match for your skills!”, he says, excitedly, after a crude keyword-search in his system had returned my resume – my heart just sinks, because I know it’ll mean at least a half-hour phone-conversation trying to explain to the guy just what it is that enterprise-architects really do. And at the end of it he still won’t understand anyway. Oh well.

It’s usually no better even when we do manage to get past the recruiter-barrier. To quote Pradeep’s comment:

Most of the companies are looking for the Specialist and not generalist. … People get confused when they see different area/different role on your resume.All they want is years of experience in same role/same area.I had to create three resumes highlighting 1) PM skills 2) solution architect skills and 3) Information architect skills in order to sell myself.

A specialist’s value is usually in terms of their depth of experience; but for a generalist, their value is more in breadth, not depth. And the reality is that depressingly-few people in business actually understand the nature or importance of that distinction. I remember once going to an interview for an enterprise-architecture role with A Certain Well-Known Online Financial-Services Provider: one of the first questions in the interview – and very aggressively put, at that – was “Why have you worked in so many industries? That means you’re no good at any of them, doesn’t it?” So as far as I was concerned, the interview was already over at that point – because there was no point in going for a gig with a guy who so evidently didn’t get it, and seemingly had no interest in getting it, either. Sigh.

In short, the bleak reality is this: there are no jobs for generalists.

Yet if we think about that for more than just a moment or two, we should realise that’s as it should be. We don’t want a job as an enterprise-architect, we want employment as an enterprise-architect – and that’s not the same thing.

What we’d usually think of as ‘a job’ is actually an artefact of a Taylorist fantasy: people as interchangeable components in the ‘plug-‘n-play’ organisation-as-machine. Hence work described in terms of predefined packages of actions, capabilities and responsibilities – all defined as a neat, tidy, certain structure of little boxes reporting to and controlled by other little boxes, all the way up the Taylorist ladder.

It’s a paradigm that does fit quite well with how specialists work. But it doesn’t fit with how generalists work – and it doesn’t fit well with how real organisations work as a whole, either.

Any experienced architect should be able to say straight away where the ‘little boxes’ metaphor breaks down: 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 – which is exactly why the Taylorist fantasy so often fails in real-world practice.

So if we think of the specialists as those ‘boxes’, then the generalists are the ‘lines’ – the people who link between all of those specialist boxes.

Most people – perhaps 90% of employees, maybe more – are more comfortable with boxes: if nothing else, they always know where they are, always know where they fit within the overall scheme of things. Yet for the other ten percent or so, though – those like Pradeep who like change, who are comfortable with the inherent uncertainties of being ‘between’ – we still need some way to engage them, employ them in that work: because if we don’t, the enterprise will fragment and fail.

The catch is that we can only create predefined ‘job-descriptions’ for tasks that fit solely within boxes. For those other tasks – the ‘between’ tasks – often the only meaningful job-description is ‘work as directed’. Plus a fair bit of ‘make it up as you go along’, perhaps. In other words, almost the exact antithesis of Taylorism – yet also exactly the kind of work at which enterprise-architects and other generalists will excel. Yet it’s also not something that makes sense in a job-description: at first glance, it would seem that anyone could claim to do that work. Which is why we don’t see any job-adverts for that kind of work – other than at the most junior level, which is not where any competent enterprise-architect should sit.

In short, jobs are for specialists, and for the most part only for the specialists. There are no jobs for generalists: they’re… well, something else. Something ‘outside of the system’, so to speak – which is what we should expect, really.

Which, however, still leaves we generalists with a problem: just how do we get to worthwhile work?

Towards a practical solution

There are two parts to this: work within the system, and work around the edges. Although it’s useful to look at these as separate concerns, in practice we’ll need to do a mix of both, and often together at the same time. Which is where this can get tricky…

To work within the system, you need to make it at least look like you fit in with the standard assumptions: in other words, you’ll need to seem to be yet another specialist. Sort-of, anyway.

To get past the recruiter-barrier, you’ll need to build and maintain a small portfolio of specialist skills – because that’s the only way you’ll seem ’employable’. It’d be useful for the long-term if some of those skills fit within a TOGAF-style definition of ‘enterprise-architecture’, but it’s not actually essential: all you really need is something that will get you through the door. (What happens once you’re inside the door is what we’ll come back to in a moment.)

As a generalist, whenever a recruiter compares you to a ‘real’ specialist, you’ll always seem to come off second-best. So to enhance your credibility, it is worthwhile to gain explicit certification in appropriate skills at some level. In addition to obvious ‘EA’ examples, other good choices include any of the variants on Agile, service-management skills such as ITIL, and project-management skills such as PMBoK. There’s a practical trade-off here: many of the training-courses are expensive, and – to be blunt – some of the certification-schemes are little better than money-making scams. But as a minimum, I’d suggest TOGAF Foundation and Archimate Foundation, plus any choice of at least one certification from a domain that is not immediately associated with enterprise-architecture.

It’s important, too, to accept that recruiters will often place you in a more junior role – and at a lower pay-rate – than your skills and experience actually merit. That’s a direct consequence of developing your generalist skills: to a recruiter, they’re essentially invisible, hence you’re ‘obviously’ worth less than an equivalent specialist. It’s frustrating, humiliating, insulting – but unfortunately that’s often the only way to get yourself into a position where, later on, you will be able to break out of the box. Grit your teeth, bide your time, and just get on with the job for now: it’s just necessary tactics towards a broader strategy.

It’s wise to aim for roles in small- to medium-sized teams, especially those with mixed levels of skills and experience. This is valuable for two key reasons: a smaller team is more likely to expect members to do a broader variety, beyond and between the tasks specified in the nominal ‘job-description’; and you’re more likely to find mentors from whom you can learn, if only by example.

When you end a contract-role, or when an opportunity comes up elsewhere in the organisation, garner feedback and testimonials for your work – especially about anything you’ve done ‘above and beyond the call of duty’, because in the longer that’s what will most establish your credibility as a generalist, even to the specialists. Do also be careful to ensure that you leave well – that others know why you’re leaving, and that you’re not ‘abandoning’ or suchlike.

All of this is straightforward, of course. And that’s the whole point: you need to be able to demonstrate that you can ‘play the game’ before you’ll get a chance to break out of the game itself.

We set up that break-out by the way in which we work around the edges. Note that, especially in your earlier years for a career in enterprise-architecture, it’s likely you’ll only be able to do this from ‘inside’ a contract or full-time job – but remember that you need to be in an enterprise in order to get engaged in its architecture! 🙂

One key here is to make it plain, preferably from the very first job-interview, that you like variety, you like linking things together, you’re comfortable with the uncertain and so on. This important for three reasons: it reduces the risk of surprises when you do start to connect across the silos or whatever; it shows people that you’re willing to take on the uncertain, ‘risky’ stuff between the boxes, that specialists often feel uncomfortable about; and it marks you out as a ‘go-to’ person who can handle those ‘between’-tasks.

Linked to that, always be willing to take on something new – because the specialists often won’t. Often that also means taking on ‘low-status’ tasks that specialists sometimes think are ‘beneath their dignity’: for you, instead, approach everything with an attitude that there’s always something new to experience or to learn. To the generalist, everything is of value: I often describe myself as ‘an avid collector of useless information’, because at some point almost all of that ‘useless’ information has turned out to be useful somewhere…

There are explicit skills to go with working around the edge, such as systems-thinking, design-thinking, hybrid-thinking and suchlike. Find out about them; learn them; you’ll need them. Note, though, that whilst there’s usually an urgent need for such skills, there’s often an even more urgent ‘anti-want’ for them – because people either find them scary, or really dislike what they show about the inadequacies of the actual context in which they work. So whilst learning those skills, learn also how to hide them – if effect, to apply them by stealth, concealed with something else more mainstream or ‘ordinary’.

For your own protection, and credibility too, make sure that have an explicit minimum set of defined deliverables – and always ensure that that you do get those deliverables done, or doable, before you turn to anything else. The importance of this perhaps cannot be stressed enough: you want to work around the edges, sure, and you have an opportunity here to work around the edges, too, but in most business contexts you will only keep that privilege as long as you also still play the game by regular rules as well. If this seems unfair, remember that many people literally cannot see what generalists do: and if they can’t see what you do, then to their eyes you’re doing nothing. You have to do enough of what ‘makes sense’ in their terms in order to retain their trust.

Also crucial for trust is to cultivate an attitude of humility toward others. As a generalist, you’ll naturally learn a much broader range of domains than most others will – but that doesn’t mean that you know any more or any better than anyone else! It’s useful to learn to be willing to say “I don’t know”, an overt willingness to learn from others. Deliberate ‘low-status’-tactics of this type are often crucial for success in enterprise-architects and the like: it’s worthwhile doing a formal training-course on improv-theatre or some such to build your skills in this.

And likewise, learn the soft-skills of the trade: how to relate with people, how to communicate, negotiate, arbitrate, and above all how to listen. There’s a very good reason why it’s often said that “the soft stuff is the hard stuff” – but the ‘soft stuff’ is usually the key to making the ‘hard stuff’ work.

Then to link both ‘work within the system’ and ‘work around the edges’, often one of the most important career-moves is to aim to spend at least some time working within a recognised consultancy-firm. I don’t regard it as ‘the answer’ or ‘the pinnacle of one’s career’ – if you ask around, you’ll hear that some of the consultancies can be even more rigid in their rules and structures and career-paths than the most Taylorist of other organisations – but in terms of learning how to work as an ‘Outsider’, and the disciplines involved in doing so, it’s really worth doing. And it usually helps a lot in establishing your credibility beyond that point, too.

Finally, remember that there are two fundamentally-different types of role in enterprise-architecture and other generalist domains: the Insider versus the Outsider. The ‘insider’ provides best value by being deeply embedded within an organisation, building a network of contacts and collaborative-partners over many years; the ‘outsider’ helps the ‘insider’ keep in contact with broader world, bringing in new skills and techniques to build the organisation’s overall architecture or whatever. The choice is always yours, but essentially it’s about whether you prefer the stability of long-term employment or the ‘freedom’ of the outside contractor or consultant: choosing the right mode for you will make a lot of difference to your satisfaction over the longer term.

Anyway, hope this helps: over to you for comments and suggestions, as usual?

[[Update: 20Aug2012: Catherine Walker posted on Twitter a brilliant pairing of this post with an excellent article on ‘How To Write an Agile Job Ad‘ – how we should write a ‘job-description’ for a generalist. Strongly recommended! 🙂 ]]