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! 🙂 ]]

16 Comments on “There are no jobs for generalists

  1. Very well written and explained, Tom. I can validate every step you discussed.

    Especially 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.

    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.

    Sad…because now, more than ever, companies need generalists to be flexible enough to work between the boxes and around the edges to focus on rethinking strategy and their role in the holistic view of an enterprise.

  2. Hi Tom,

    great article yet again. It made me realize that I should be more thankful for the job I have, because:
    – I am not expected to be a specialist in a particular field
    – I am basically free to define what EA is all about (and while working with/around those who think they know what it is pursue my long term goals)
    – I am free to do it in basically any way I want
    – I am also quite well paid under current circumstances and definitely not considered in a junior role

    Thanks for that, as you well know, I also do have my weaker times of… say frustration:) I’ll read this again when it comes next time.

    I was also thinking 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:)


  3. Thanks Tom for another beautiful post. Title of the post is attention grabbing and as usual content illuminating

    “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”.
    Is CEO the real chief enterprise architect( And his team of direct reports are Enterprise architects)?
    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.
    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?

    • Hi Pradeep,

      @”So how does EA creates its “own unique place” without “being redundant” – well, our view from bwin (put together with Gerold Kathan and Nenad Antic) was that enterprise architect is everybody who actually defines the architecture (in fact it’s everybody’s business), and we are facilitators of the discussion, having tools/skills for visualising problem areas, progress, target, let it be architecture, business model, gaps etc. At the end it was however pretty much about all other skills but architecture:) Have a look here:


  4. Excellent article.

    I really like the analogy with the boxes and lines, and for me EA is all about managing (and reducing) complexity of an (business) entity’s way of workin and creating value. Of course, in the end, some of these tasks will be undertaken by IT solutions, but again, the focus is to manage complexity, so you as a business entity can stay agile and flexible to meet tomorrow’s demands.

    You do that by defining the right granularity which makes sense to the BUSINESS side of the boxes, and to understand the constraints and characteristics of the glue (lines) between the boxes.

    So by defining the value to be created, and defining when you are successful, it’s just to throw yourself at the “box-and-lines” tasks 😉

    That’s how I see my job. -Magnus

    • Hi Magnus – Yes, great points, and yes, ‘boxes and lines’ is a particularly valuable metaphor for enterprise-architects, both in the IT-oriented context and beyond.

      I’ll admit I’m a bit concerned, though, that you may be missing the key point here: that this is about how EAs get employment, as EAs, rather more than about what EAs do?

      For example, “You do that by defining the right granularity which makes sense to the BUSINESS side of the boxes, and to understand the constraints and characteristics of the glue (lines) between the boxes” – yes, exactly. Yet the point we’re exploring here is a recursion of that: describing to people who think only in terms of boxes, the ‘constraints and characteristics’ and suchlike of the work-roles that take on the tasks of ‘the glue (lines) between the boxes’, in ways that make ‘business sense’ to those people.

      This is a recursion of the same principles that applies all too painfully to our own ‘jobs’ – not just to the work that we do. That distinction is extremely important in practice – especially if we actually want to get paid for our work! 🙂

      • Hi,

        agree, and my tools to do this practical work is to use the Business Motivation model (BMM) + Osterwalder canvas to define, ALIGN, structure, and FOLLOW-UP on the Vision, Goals, Objectives, Mission, strategies and tactics, biz rules and influencers.

        With these tools we can then sharpen our business message (and mission) and detail our Value propositions, link them to our strategies (long and short term) and then we are more ready to)start to define the starting point for the EA work, and consequencly to actually practice EA as we teach, as that we have been talkiong about (processes, inforamtion, systems (roles), rules, events ). -Magnus

  5. Excellent post, Tom. Thank you.

    What you have described with “EA specialists” is rampant in the architecture world, and sadly, I find it is propagated largely by people who call themselves architects, with HR/Talent staff following their lead. Frequently these are senior technologists, or application specialists, looking for a way to distinguish themselves from less capable peers.

    I have found the pinnacle of this occurs in my chosen (and still emergent) domain of business architecture. What should truly be about the design of the business (from the business model through strategy, goals, processes, information, org and functional structures, and the enabling IT capabilities, in house or external) is often relegated to a poorly understood sideline of the IT architecture group, typically masquerading as Enterprise Architecture.

    A broad experience base – theoretical and applied – gained from real experience in multiple organizations and industries is undervalued, except within consulting. I believe that this is because it is hard to measure the value of this experience, and so easier to discount it. Of course, for consulting organizations, a generalist is valuable because they can be deployed across a wider variety of engagements.

    The counter point is that a history of success in a wide variety of situations (industries, companies, roles) demonstrates adaptability, social and emotional intelligence, curiosity, learning ability and the psychological make-up needed to tackle uncertainty and risk – namely the most sought after skills for leading in the dynamic and volatile business environment that most organizations face today. In my opinion, these are the most valuable employees a company can have.

    When I am advising and mentoring people on their careers, I recommend that they think about their personal development on two dimensions – generalist skills that will apply to any position or role, such as above mentioned soft skills, systems thinking, or productive behaviors / habits; and hard skills, where the objective is to develop specialist level understanding in a concept of technology. The key is to understand that all technologies are, by their nature, transient and temporary. If your value is based on technical prowess and you are not learning new skills, you are a rotting vegetable, that is, depreciating in value.

    One way to think about this is to reflect on your personal learning curve – if you have plateaued, then you are not gaining experience, you are only repeating it. Do you have 10 years experience, or two years experience repeated five times?

    • @Chris – great points – thanks! What we’ve seen here with EAs and (in both your and my experience) BAs has also happened in the past to business-analysts: they started out as broad-scope generalists and ended up being forced into a narrow sub-specialism of IT. Infuriating… 😐

      I’m not sure that even the consulting organisations – especially the large ones – are that keen on broad-spectrum generalist experience. They may claim to promote that, and it does carry a huge price-premium at the top levels; but the reality is that narrow-function specialism is much easier to sell because of its definable and pre-measurable outcomes. In practice, what I’ve seen large-consultancies do far too often is promote something as if it’s a high-value/high-premium/high-price cross-function generalist (‘system integrator’, for example) but actually deliver it as Taylorised cut-and-slice package implemented by low-cost/low-experience juniors, with nothing to link it all together. Very profitable, but it doesn’t work, and to my mind it’s barely one step clear of outright fraud. Oh well.

      On “the most valuable employees that a company can have”, yes, strongly agree: it’s a very strong benefit for the company. The catch for the employee, though, is that because there’s (almost) no mechanism to describe generalist skills on a resume or suchlike, in practice those skills are not easy to present to another prospective employer – making it difficult (or at least more risky than it need be) to change jobs.

      On “Do you have 10 years experience, or two years experience repeated five times?” – very, very good point. Thanks.

  6. As a career-long generalist who has always been employed, I don’t agree that there are “no” jobs for generalists, but I definitely agree with the theme presented here.

    Something I would add to the practical solutions: a genuine interest in the domain you’re working in, and a visible passion for supporting your team & organization’s performance. I think I’ve been successful as a generalist because I’ve chosen to work in domains I’m genuinely interested in, and where I can be committed to high performance and success. In my experience that is much more important to staying happy as a generalist as working within the system.

    That said, I was once told by an executive I really respect that I could make 30% more if I would specialize. Alas, I would be bored to tears if I had to specialize at that level. I feel like I’m making a much greater contribution as a generalist, so I stick with what makes me happy.

    • @Jeff – strongly agree with all of that, and many thanks, especially for the “I could make 30% more” example – as you’ll have seen, I used that in a later post in the series.

      On “I don’t agree that there are ‘no’ jobs for generalists”, we do actually agree here. My point is not that there is neither need nor employment for generalists – because clearly there is, and both (though not enough of either than must of us here would like). What I am saying is that the current recruitment-mechanisms – particularly resumes and ‘job-descriptions’ – do not adequately support or reflect what generalists do or how they work: hence – unlike for specialists – there’s little to no means to describe a generalist role in order to gain employment in that type of role. In that sense, it’s not that there’s no employment for generalists, but almost no ‘jobs’ for generalists – which is not the same.

  7. Companies need generalists for all of the reasons listed in the piece and in subsequent comments but, they don’t know they need them until they need them. For example, in IT, leadership traits are routinely filtered out of the job candidate pool in favor of raw technical skills. The result is often a scramble to find someone to play the role of technical lead, not just a Program Manager who keeps an eye on the schedule and budget. The specialists, who are happy playing the role of cogs in the machine, run from these opportunities. Ultimately, the most socially adept of the geeks loses and gets stuck with the role. Some thrive, most become the proverbial “fish out of water” and underperform. Generalists have a hard time getting hired but often become key contributors in their organizations.

  8. Dear Mr. Graves,

    Thank you for writing this article, I have thought for the longest time, that I was not following the “accepted” patch because I was unfocused and yet when I took on the specific role, I could do it and more. I like thinking outside of the boundaries of the specified position and why I love “real” enterprise architecture.

    Thank you,
    Rahul K. Razdan

Leave a Reply

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