The 2016 enterprise skills debate - specialist or generalist?

Jon Reed Profile picture for user jreed December 29, 2015
With the robots nipping at our heels, the pesky specialist-versus-generalist debate takes on new urgency. Here's my latest thinking.

For as long as I've been writing about the enterprise, there's been a skills debate about generalists-versus-specialists.


The debate matters now more than ever - we can now add robotics and process automation to the list of white collar job threats. Our livelihoods depend on our negotiating position against both humans and machines. Over-generalize your skills, and you wind up classified as non-essential. Choose the wrong specialization, and you are either obsolete or clutching a legacy skill set.

In the past, I advised all enterprise professionals to specialize:

  • Specialization is how we stand out and brand ourselves (e.g. "she's the best Workday payroll person I know, or "he's the best predictive analytics dude on the market").
  • Specialization lends itself to mastery. The relentless pursuit of mastery is how we excel in our careers. The push towards mastery also brings intrinsic rewards: we are pushed to confront our imperfections and stretch towards the greatness of a black belt.

There are dangers. Your specialization can become too narrow too quickly. And if your specialization is technology, you run the risk of failing to pursue the broader discipline that contextualizes your speciality. Example: almost no one wants to talk to a call center configuration specialist. A customer engagement expert who can also configure customer-facing products is far more appealing. Yes, how your skills are  described could be a factor. The point is that technical tunnel vision doesn't lend itself well to helping companies manage change.

Put specialization in an industry context

That's the first tweak to my specialization advice:

  1. For most tech/biz professionals, your software specialization should combine a cutting edge and a core set of skills.
  2. You should always approach your specialization in broader industry terms, rather than a narrow product focus.

Cutting edge skills help you stand out from the pack, but you risk getting too far in front of customers. Or: you risk pursuing a skill that doesn't ever pan out in terms of widespread adoption. Putting your cutting edge skill in the context of a broader core is how you hedge against the risk over over-specializing. Granted, your software specialization is usually focused on one product, so you ARE making a product bet here. You could potentially move from being a Workday to SuccessFactors consultant or vice versa, but those changes are harder than we'd like. Unless you're at a higher management level, you'll need to pick a product and stick with it.

But: your product focus should stem from a discipline, and sometimes a vertical (retail, banking, etc). Continuing with the HR example, a Workday or SuccessFactors consultant should think of themselves. first and foremost. as an HR/HCM expert. That means studying global staffing trends, new approaches to talent and recruitment, on-demand/talent marketplaces, and so on. Example two: a Salesforce or Oracle CRM consultant should think of their work in the framework of customer engagement, digital/inbound marketing, and so on. A good litmus test: could you give a conference talk on your area of focus without EVER mentioning the product you specialize in?

The same goes for technical professionals, who are dealing with a devops convergence. Developers might have a Java skills base but also be savvy with Ruby and/or Python etc. Systems admins/DBAs might have a deep expertise in Oracle or SQL Server, but should be expanding into NoSQL, Hadoop, etc. The bigger picture might be understanding analytics trends - actually deriving value or decision support from the data. For developers, the bigger picture might include a go-to-market grasp that include agile/design thinking, UX design and/or working with diverse teams.

So far, the "specialization" advice holds up. "Generalists" without a hands-on focus can succeed large companies, but I still don't like their chances. They tend to wind up as "project managers" which is not the most portable skill set. Even the best consulting managers I know have a specialization, such as leading analytics/big data initiatives. Small companies carry the opposite risk: you can end up being asked to wear multiple hats, so you awkwardly try to maintain multiple specializations.

Specialization needs a "soft skills" wrapper

Here's where we got off track with this debate.

It is no longer enough to be a tech or software specialist. Those software specializations need to be wrapped in so-called "soft skills," which in turn are often wrapped in an industry specalization (e.g. media, telecomm, oil and gas).

"Soft skills" seem fuzzy at first. But they are anything but soft. Soft skills are about bridging gaps with business and IT and speak a common language of outcomes and results. You now need an iterative ability on software projects. That means working alongside business users - and even customers and suppliers outside the enterprise. We can talk about happy phrases like lean, agile, and design thinking, and all three have things to offer. It's really about building things that matter and solving problems - not just delivering specs with your head buried in a cubicle.

Today, we are all consultants. Whether we are full time employees or contractors, it's our ability to work in teams and advise on big picture issues that reinforces our value. Bad news - that doesn't let us off the hook for our specialization. We still need to master a focused skill. But then we need to wrap that specialization to make it easy for clients/employers to insert us into project teams. Divas and ninjas are an endangered species on enterprise projects. Rate mercenaries have already gone the way of the dodo bird.

Example: You are a NoSQL expert. If you can also advise on the pros and cons of different NoSQL databases and integrating with SQL systems, you're far more valuable than someone who is an expert on MongoDB's scripting language but can't advise on NoSQL issues outside that narrow context. If you've worked on diverse open source NoSQL projects, so much the better!  Granted, some employers don't give a shit about your opinion. Those employers are the ones you move on from. And:  the ability to play "advisor" also comes with knowing when to advise, and when to shut up and do the needful.

The ideal enterprise skills combo

Now we can define the modern enterprise skill set:

  • specialist (usually in a software area, that combines "core" and "edge")
  • wrapped in a proper mix of "soft skills"
  • (probably) wrapped in an vertical specialization (utilities, discrete manufacturing, etc)
  • dedicated to the consulting approach of advising. not just doing, and pursuing outcomes, not just deadlines.

If you find my soft skills definitions vague, I wrote an entire article on that. And in the business process expert piece, I updated my definitions of a proper BPXer. Originally an SAP term. I've appropriated BPX to mean a tech-biz pro whose skills bridge the IT/biz gap. Examples of such skills include:

  • knowledge of user experience design
  • SaaS delivery know-how and value proposition (elasticity, multi-tenancy, resource pooling, deployment models, etc)
  • agile/interative software delivery approaches
  • experience with embedded analytics and visual reporting tools
  • expertise in collaborative tools/workflow
  • vertical industry know-how, including the configuration of cloud-based templates and guided configuration techniques

Update: So in a sense, this view resolves the specialist-versus-generalist debate by letting the soft skills combo be the "general" abilities that can move with you - even if you need to shift or change specializations. But it's telling that most "general" abilities don't do a lot for your marketability until they are tied into a focus (example: analytics expert specializing in Apache Spark). There aren't many opening on for "future of work" pundits (general know-how), but there are gobs for cloud HCM pros across a range of products. Aspire to fuse the two.

I haven't really explained the "edge" and "core" aspect of specialization. Spark might be a good example of the edge. Hadoop is now mature enough that for some Spark specialists, Hadoop might be a core. Can you have multiple specializations? Sure. Vinnie Mirchandani wrote a potent book called The New Polymath that looks at how technologies compound. The same could be applied to individuals, so it's up to us to figure out the unique flavors - and how many specializations we can maintain.

It's time for a five year skills plan

That list of BPX type skills above is not even the full list, so we better get busy. An aggressive skills development plan is a big part of our career strategy. Thus the timing of this article. Before the new year, set out a five year skills plan. Break it down into one year chunks, until you have your marching orders for next year.

Figure out what skills you'll be exposed to on the job, and which ones you'll need to pick up on your own time, or perhaps in classes sponsored by your employer. There's never been a better chance to expand your skills online - the only thing that stands in your way is Netflix.

And yeah - I practice what I preach. Every December, I break down my skills, identify the gaps, and prioritize my improvements. Tough choices may be needed; you won't be able to push ahead in all areas. At the moment, I'm working through a big data/analytics course from the Teaching Company. I'm also studying a bunch of info on enterprise buying trends. The robots are going to have a hard time catching me - until they figure out how to take audio classes. Then I might be screwed.

I'd be interested to hear any tips or tactics you utilize, and whether this framework makes sense. As I said on Twitter, it's not possible to provide a one article template for all careers. Take what you can use - and good luck out there.

Final update, 12/31/2015:  A vigorous Twitter debate brought out some nuances, and convinced me you probably need a separate article for higher level managers. As you advance into executive roles, you start to move away from hands-on specializations. Example: you might manage an HCM practice that combines Oracle, Workday, SuccessFactors and Cornerstone. Our an analytics practice that is tool-agnostic.

That doesn't mean you've left specializations behind. A "service delivery manager" is an unappealing, generic skill set. An "analytics delivery manager specializing in media and communications" has more teeth, and offers more value to customers. For the manager, the core skill might be service delivery. he specialization would be things like analytics, or HCM, informed by an industry or regional focus.

I received an email I will try to add that emphasized as a soft skill the importance of customer-facing skills and roles, and, bottom line, the ability to listen. I agree, and I'd add to listening the ability to pull from those conversations accurate requirements - issues that customers can't always articulate unless you are listening hard and really know your shit.

Finally, the passionate pursuit of mastery should not eclipse constant experimentation and self-critique. Adaption and course corrections - even those that move us far from home - are now par for the course.

Update: tweaked conclusion and added clarification to end of soft skills section on 12/30/2015.

Disclosure: Workday, Salesforce and SAP are diginomica premier partners. Back when I was just a lad, I recorded some paid podcasts for the SAP BPX community. I believe those have been scrubbed from the planet by now.

A grey colored placeholder image