Why the early attempts at skills-based organizations failed ... and what you can learn from them

Almost every large company is looking to become a skills-based organization. This is, in part, due to the after-effects of the pandemic (remote & hybrid work, the "Great Resignation," and increased competition) but also because employees are demanding more meaningful experiences.  

Fewer individuals remain at one company for extended periods of time (5-10 or more years). This isn’t because they don’t want to, but simply because employers are not enabling growth and upward mobility at a rate that satisfies the demand from individuals for more fulfilling careers.

To address this challenge, most large companies are transitioning from an emphasis on jobs to an emphasis on skills. The over-arching theme here is to not judge individuals solely on the positions they’ve held in the past, but to focus instead on the more granular ‘DNA’ of the role at the skill level and to enable more internal mobility.

The benefits are numerous. Skills-based organizations, according to Deloitte, outperform their peers, are more innovative, retain high performers at a higher rate, and are nearly 80 percent more likely to provide a positive working environment.

But the transition from jobs to skills isn’t quite as straightforward as many had hoped.

Over the last five years many organizations have purchased skills-based solutions (such as talent marketplaces) that at first glance appeared to be the “silver bullet.” Talent marketplaces in particular have fantastic user interfaces that are fun for employees and deliver significant value to employees by matching them to jobs, gigs, and mentors.

But the results from these early forays into using skills-based technology were not always successful, or at least weren’t driving the enterprise-wide transformation many leaders had hoped for. There are three reasons for this:

Data Interoperability: Almost all HR technologies (e.g. HR systems, talent marketplaces, learning systems and platforms, applicant tracking systems, candidate relationship management systems) use skills in different formats, or taxonomies, which makes moving data into and out of these platforms impossible. This leads us nicely onto the next point below.

User Experience: The majority of these HR technology providers want employees and a large user base to be “on their platform.” For customers, this means asking employees and managers to jump between lots of technologies to do certain tasks such as apply for new roles, search for gigs/mentors, or identify and execute exciting new learning opportunities.  

Because of the data interoperability issues referenced earlier, this means you cannot ask employees to take an action in one platform (e.g. update a skills profile in your learning experience platform) and have it reflected seamlessly in your HRIS and talent marketplace. This lack of connectivity creates bottlenecks, duplication, negatively impacts the employee experience, and ultimately decreases the return on investment for organizations.  

Job Architecture: The effort to take a career framework and make it “skills first” can be hugely onerous. I speak to large banks and insurers all the time who say this process took them 18-24 months or more, and it is still not quite working. Traditional methods used for building career frameworks, such as interviewing hiring managers and engaging large consultancies, are expensive and involve largely manual processes. This might be sustainable for career framework development, with a refresh every 3-5 years, but it is not suitable for skills which have a shorter half-life than jobs and will need to be updated on a more regular basis.

This last element, job architecture, is a necessary foundation when working toward becoming a skills-based organization. How can you match employees or candidates to exciting new roles if you have not accurately and comprehensively defined the skills for those same roles? How can you close skill gaps through learning if the gap hasn’t been adequately understood?

To help articulate some of these challenges and address them in more detail, I’ll discuss several of these key elements and SkyHive’s point of view in separate blogs over the coming weeks.

I’ll start with job architecture and the key steps required to become a skills-based-organization. I’ll then touch upon the Human Capital Operating System^TM (what it is, what it means), managing skills taxonomies (yes, plural), before ending on gathering a skills inventory and how this will impact workforce planning.

‍

Paul Scott is an Enterprise Account Executive at SkyHive. Contact him at paul.scott@skyhive.io.