1/ Organization design is changing.
As I discuss in the podcast, the way we organize our companies into functional groups is a historic artifact. It goes back to the days of industrial businesses (and slavery, to be honest) where we had “management” and “labor.” Today as most work is “service-oriented” and people add value in every role, almost every job is a “hybrid job.”
What this means is that the traditional “organize to scale and segment work” idea has to go away. As I discuss in the podcast, the Apple Genius Bar is a good example of this. It’s not a functionally specialized team, it’s a cross-functional team of hybrid-trained experts.
Consider the problem of customer support, which every company faces. There are typically four parts to this problem: bug fixes (we called it “break fix” at IBM), service (a call for help), consulting (help us implement your solution), and education (teach me how to use, customize, and integrate your offering). Should these be in four different groups?
Probably not. As telcos and many software companies have learned, these four groups each interact with product management, engineering, sales, and presales support. So why would you segment them into small teams? It all depends, of course, on the size and geographic organization of your company, and then on one big issue: where the skills reside.
In other words, as the podcast explains (and in our upcoming JBA course), org design is not about “who leads what” and “what are the spans of control” anymore. Now it’s a serious and strategic discussion about what skills are adjacent to each other, and therefore what clusters or “tribes” belong together.
In HR, for example, we found 14 “tribes” in our research, and our full-stack HR development model helps build these hybrid skills. There’s a lot more to think about on this topic, so stay tuned for our big JBA course in Org Design coming later this year.
2/ Skills are different from capabilities.
As I’ve written about many times, you won’t become a better company by letting every employee “upskill themselves” on anything they want. Yes, it certainly is important, but you as a business leader want to “push” people in the strategic direction you want to go. This is the essence of building what we call capability models.
As I discuss in the podcast, “business capabilities” are things any business person would understand, while “skills” may be technical domains. In HR, for example, “Building An Employment Brand” is a business capability, but as you can tell it requires many complex skills.
So what we’ve learned (and what we advise) is that companies should sit down every year and discuss the business capabilities that drive success. This can be done at a company level (as Autodesk and Allstate have done, for example), or in a functional area (as Cisco does in sales, for example). It’s a business-driven process and over time you’ll get better at it. A large healthcare company I interviewed told me they do it every year and the CEO and top functional leaders look forward to the process each year.
3/ The three business reasons to embark on skills taxonomy projects.
The third finding to discuss is “why are you building a skills taxonomy?” The obvious reason is that we need it to assess, develop, and upskill our people. But that’s not good enough. These are massively complex projects and they always run into job architecture issues (more on that below), so I’d suggest you have three big business cases.
First, it may be a performance improvement issue. “We need to improve our sales productivity, so let’s figure out who’s doing what and where we can upskill our team.” Second, it may be a bigger talent strategy. “We want to improve career management, talent mobility, or recruiting effectiveness and we need to know what skills people need in each job.” Third, it may be a business transformation or risk project. “We’re moving into electric vehicles (or digital products and services) and we just don’t know enough about this new adjacent area as a company.
If you don’t attach your work to one of these business strategies you may end up with an architectural project that never ends. And you’ll have a hard time getting business leaders to help. Telcos, for example, are doing this to get ready for 5G. Energy companies are doing this to prepare for electrification and solar energy. Insurance companies are learning about new risk areas and the use of AI. But you have to decide “why” you’re doing a skills project, otherwise it just feels like overhead.
4/ Job Architecture is part of this work.
As you listen to the podcast and think about how your company is organized, you immediately run into the issue of the job architecture. Most companies have dozens of “job families” and they are cataloged in the HRMS in a hierarchical way. At the leaf of the tree are the job descriptions, which are often filled with details about each job and role.
Well, this is all difficult to manage. In the new world of work, where everyone is in a more hybrid role and we play more than one role at a time, we need a more flexible, simplified architecture. As I describe in the podcast, Epic, the software company, has only seven job families. Other companies (like Yelp, for example) have only one type of engineer. The purpose is not to over-simplify what people need to do – it’s to generalize the architecture so the company can be more flexible.
We have a sound methodology for doing this, and we’re happy to help you think it through. But if you try to create a skills model for every job in your company you’ll be embarking on a project that never ends. In our Global HR Capability Project, for example, we use the tribes to help cluster skills, and we found only five “types of jobs” in HR. Yes there are hundreds of job titles, but ultimately all HR professionals do one of five things. And that has helped us make our skills architecture simple and easy to use.
5/ Carefully examine how skills cluster.
One of the important disciplines in skills management is figuring out how the skills themselves cluster. Skills, like jobs, are hierarchical. A skill in C++ is part of skills in software languages which are part of skills in software engineering. But did you know that object-oriented programming skills cluster together with skills in design thinking and technologies like Cobol?
These kinds of “adjacencies” are well known to academic and universities (they are always finding ways to collaborate between disciplines), but harder to see in business. You can identify these adjacencies by using external skills data and looking at job descriptions in detail. And that lets you decide which Capability Academies to build.
The example I point out in the podcast is the strange but proven practice that CyberSecurity specialists have a lot of skills in common with financial auditors. The skill of investigation, pattern matching, and digging into detail are all related to both jobs. So if you know about these adjacencies you can better build a talent mobility or career framework for your company.
6/ Skills are very dynamic: always becoming obsolete and new ones emerging.
Every domain of business has a set of skills that are “diminishing in value” and some that are “increasing in value.” And every year there are thousands of new technologies, science, tools, and business practices being invented. If you’re an expert on Oracle 6 database backups, for example, you’re probably not finding that much work to do. So you, as an Oracle DBA, have been upskilling yourself ever since.
The same is true in every single job. So your job as the “skills architect” or taxonomy designer is to create a system that lets you constantly update your skills models as the market changes. That’s why this is not a project to be “outsourced” to a consultant. You want to build an ongoing process to see and integrate the “skills of the future” on a regular basis. And this means building a SkillsTech architecture that can scale.
7/ Complex internal and external data is needed.
In today’s highly connected world, it’s not enough to just “develop and categorize” the skills you have. It’s also very valuable to see what skills are “in the market” around you. Thanks to vendors like Eightfold, Censia, EMSI-Burning Glass, SkyHive, and others you can get access to trending skills collected directly from job postings. So you can get near real-time data on emerging skills – by location, industry, and job level.
8/ The vendor market is confusing.
Finally, let me conclude with one thought. The vendor market is not as clean as you think. All of the learning, recruiting, and core HR systems are building skills engines, but many of these are what I call “raw software.” They are good at indexing information and categorizing skills they “infer” from your job descriptions, postings, and learning programs.
What they aren’t very good at (yet) is using AI to integrate skills data with job experience, industry data, and the myriad of other things that impact your talent intelligence system. As we describe in our talent intelligence research, you will ultimately want to integrate a lot of different types of data.
If you’re a big company, you’re likely to do this yourself. But for most of us, we’ll use a new breed of vendors, and we see some pretty significant changes taking place in the market. While most HR people think they’re buying “HR Technology” from their HRMS, learning, or recruiting vendor, you need to think a bit broader. We need vendor solutions that are both “tech” and “data,” because that’s what the market needs.
This is an exciting new world.
Let me conclude with one more thing. This is not a “project” you do to clean up your job architecture or competency system. This is a whole new business capability. Organizations in the future will be much more dynamic and intelligent at their core.
Think about your job, skills, and organization team as a part of strategic planning, not just a team of specialists in HR or L&D. How you define your skills, jobs, and organization in the future will be one of the most important things you do.