Closing the Skills Intelligence Gap in the AI Era - with Cory Hymel of Andela

Welcome everyone to the Emerj AI in Business podcast. Today's guest is Cory Hymel, Head of Research at Andela. Andela connects global technologists with Fortune 500 companies to help them build high-performing engineering teams for the AI era. Cory discusses why most enterprises still source technical talent by job title, and why that approach badly undercounts what employees can actually do in the age of AI. He walks through how mapping skills instead of roles helps leaders see where real capability gaps sit, and why continuous assessment matters now that technical skills carry a half-life of just two to three years.

Today's episode is sponsored by Andela. Emerj works with a selected group of AI vendors to reach Fortune 500 decision makers through research, media, and direct access. If you want to be considered, download our media kit at Emerj dot com slash AD1. That's E-M-E-R-J dot com slash AD1. Now the conversation with Cory. Cory, welcome to the Emerj AI in Business podcast studio.

Of course, thank you for having me. I'm excited to be on.

Yeah, and I think we're going to have such an interesting conversation today. I'm gonna just hit the ground running. In preparation for this, I saw that the Stanford's latest AI index found that entry-level developer employment went down with nearly 20% from 2024, which was when it was at its peak, right? And that while agentic AI job postings are up with over 10,000% year over year, it's crazy. That is in the same labor market at the same time.

And then while we have that running, we also had the Lloyd's newest enterprise survey that puts talent readiness at just 20%, which is down from the year before. So these are all crazy stats, and I'm excited to ask you today, from your network and your seat, watching hundreds of thousands of technologists in real time. How big and how urgent is the gap between what companies think their technical teams can do and what they can really do?

Yeah, I mean, it's a really good question, and those stats are are rather, I would say, alarming from from our side. So, my background and I've studied for the past ten years the field of human-computer interaction and was with a specific focus on, like, how AI impacts developers. And it's very exciting to be have studied that because now AI is cool and it wasn't very, uh, that much long ago. We've kind of seen this coming and coming, and it's and it's happened before in the past.

You know, what we're seeing the trend play out today is that a lot of technical leaders, a lot of the C-suite, they're getting a lot of noise from the market, from the labs, from people pushing what should what they should be doing. Or what there's kind of like this FOMO fear of, like, your engineering team and all your developers should all be AI native, and Boris is out there telling everyone to be running 30 agents at a time, and you don't need this.

But when you get actual boots on the ground into true enterprise engineering, the story is much, much different. And the approach that we've seen a lot of organizations take is starting to kind of unfold itself. So, when AI kind of first, you know, hit the scene in 2020 and then kind of growing a little bit more, a lot of engineering, a lot of, like, businesses treated it as this kind of fire and forget technology. Give it out to your employees and boom, there's your 150% lift, uh, or just here, like, deploy it and you can start cutting jobs immediately.

And that obviously did not happen for various other reasons that I'll get into in a minute. Um, and then the next, you know, kind of wave was around, like, oh, well, let's start doing token maxing and then we'll kind of drive adoption and that'll get us our productivity stats. And that'll be the answer that lets us start cutting headcount in. We obviously saw that that was not quite the answer. And so, you know, what we're seeing from our angle and what I see very frequently with a lot of our customers is that they're starting to realize now that one, this technology is not this fire and forget.

That you actually need to do in, uh, you need to go in and actually enable your people to teach them the best practices of how to use it, when to use it, where to use it, and more importantly, a lot of times, of when not to use it. And that kind of story of having the C-suite or having business leaders get FOMO either from their peers or from their market and try to, like, push this technology down from the top is really not the answer.

And I think that the fascinating point is that there was some other recent research that had come out that showed that individuals are 2. 4 times more likely to adopt AI when they see a leader use it. They're 3. 6 times more likely to adopt when they see a peer use it, but they are 5. 6 times more likely to adopt when they see a cross-functional peer using it. So we're seeing AI come on board as kind of this grassroots movement, which I saw and many saw kind of come firsthand, like when BYOD and mobile came into the enterprise, and now that same kind of story is playing out here.

So those stats, while alarming, I'm not surprised at at all. And I think that they'll start to mellow out if leaders start to take the prescription and understanding that, you know, you need to invest around, like, training and adoption to really grow it from the grounds up. And it's not this top-down, just push.

So coming to this realization of enabling your team and thinking about training, where does that happen? Ha- Have you noticed that coming from a CIO specifically, or where does it surface within the organization? First?

Yeah, that's a that's a fascinating question, right? And it's, you know, I think a lot of enterprises and a lot of companies will check the box of saying that they've done learning and development. And I see that a lot at the CIO level. Like, look, yes, we're investing in upskilling. We offered out these blanket, generic courses to the enterprise and people should go be doing it. Or we give them 500 dollar a year stipend.

I checked the box, done. I'm there. We've seen that, that's still there, and that's kind of what they're doing right now. But what we've started to see is really more individuals reaching out, like individuals wanting to go in and wanting to go learn how to use this technology better. And it's and it's quite fascinating. Like, there's a ton of research out there on how, like, skill development and skill maturation happens within the workplace. And what we've seen playing out in real time is that individuals with emerging technologies or emerging kind of processes are ones that tend to kind of go outside the bounds of what's acceptable within their business or within their workforce.

And so a lot of the early adopters of AI that are using it very well in the development world are ones where the company said, Hey, we don't have any AI tools. And they said, You know what? I'll go get my own. I'll go pay for my own cloud code subscription. I'm gonna be the one that learns. I'm gonna proactively go learn how to do this. And that kind of bubbles up into team leaders, so that a team that might have two or three front end engineers and says, Hey, guys, this is amazing.

We need to go learn how to do this. We don't have maybe buy-in from the top, or we may don't, you know, people aren't shoving this down, but we are gonna be actively going o- out to find this education and learning. And you see that skill development happen pretty frequently in the research and pretty frequently in the world, in that those that are the strongest and earliest to adopt are ones that will circumvent the rules in order to get ahead in where they wanna be.

And the advice that I give to a lot of the C-suite when I talk to them pretty frequently is that AI is happening and adopting and probably going much better than you think. But it happens in pockets, and this learning happens in pockets. And as the stat that I mentioned before about the 5.6 times more likely to adopt if they see a cross-functional peer, really, when I talk to leaders, it's it's your job to identify when and where these pockets are happening and enable those and say, great, we found this great use case.

Look at, you know, I don't know, Jane and Tim from these, you know, from finance and from product. They found they had this issue and they used AI just to build this bridge. And like, use these as case studies to start promoting and driving learning from the ground up. And then you meet that from the top down and kind of begin to build this continuity of learning throughout the org.

So I think something that really gets our listeners to pay very close attention is when we bring up the idea of value and cost savings and things like that. And this feels like when you mentioned blanket training within or throughout the organization, that was the first thing that came to mind is if we're just going to force people to do the same short little course and just to to tick the box like you mentioned. We're sitting with stale skills.

So in terms of stale skills, what is the actual cost of that? And and that's thinking about hiring cost and project delay and things like that. It should cost us a lot more to not develop the skills of our employees. Is that the right way to think about it?

Yeah, of course, right. And that's and and the reason, I mean, uh, so I would even like give it a more concrete reason of why building a lifetime value of your workforce is more important beyond it just being like ethically the great thing to do. But, you know, when we're looking specifically in the in the development space right now, like the talent war is structurally unwinnable. Uh, if you look at what's going on in the market, Meta or Google buying Windsurf for 2 billion, only to get their top 20 engineers, or Meta paying AI engineer $3 million a year to come in, or them purchasing scale just to get the CEO and his, you know, little band of top

AI engineers. So is it this this idea of trying to play by the traditional talent game or a traditional workforce strategy game right now is just not possible. Not possible for most, I should say, I would say not possible for 98 of enterprises out there. And so it's okay. Well, if you can't win it by playing by the traditional rules, what is the next protocol? And that is definitely looking to invest in upskills the individuals that you have now.

Uh, but again, the traditional means of doing that, to your point, is great, let's go buy some Udemy courses, or maybe we offer out, you know, I don't know, Stanford's computer science class. But these are kind of just blanket attempting to do one size fits all, and that does not work. Like, I think everyone here has probably gone through, like, SOC 2 compliance and wanted to just fall out of their chair with how boring and lame it was.

And that's how a lot of engineers will see it if you just give them some blanket, hey, here's an intro to AI coding engineering. Very good, probably for a small percentage of them that have zero exposure. But again, those individuals that went outside the rules to start learning how to do this will be im- immediately turned off, start looking for additional jobs, they'll start, you know, building unrest and happiness. So, what we've seen as the correct method to go do this is to begin by doing methods of assessment to actually understand what the landscape of your current skill sets are.

And then based on that, be very prescriptive about what you teach and what you teach to who, because the days of just doing the blanket thing, like I mentioned, don't work. And now we actually have the capabilities to do very prescriptive, very on-demand, very custom, very tailored learning. So that you're able to not only drive engagement from these high-performing engineers, but you also give them the information that that they are needing to get those productivity and those ROI boosts that you are seeing in the market.

Yeah, and you just hit on the spot, um, that I'm probably most excited about for this conversation. That is capturing the skill set of our different, uh, team members and individuals. And it's no secret that most companies are still sorting people by job title. And if we think about it, that is never that's never actually been the right way to capture what someone can really do. Uh, you can have the most fanciest of titles or the the nicest looking certificate.

But something that you've spoken about before is building knowledge graphs and skills codification or taxonomy instead of just looking at resumes. Can you walk us through what changes when a company starts mapping capability instead of just a role? What does that let a la leaders see that they couldn't see before?

Yeah, of course. Yeah, it's a really good question, right? And when we talk about mapping skills and ontologies and skill taxonomies, what the goal is, is to be able to better pair work to workers. And the resume, the LinkedIn profile, it's like the best, worst thing that we have right now. And I understand why it's lasted this long because it's it's it's kind of easy to do. It's fast, maybe, like it's traditional, it's understood, it's institutional kind of pit, you know, pillar out there.

But really, it is the worst way to hire, and it is the worst way to try to mobilize your workforce against work, especially today in the AI kind of era. And so when we look at what an organization goes through as they start to move from job title into, like, skill capabilities, the first thing is that a lot of job titles are drastically under describing what the actual work is. We've got some research coming out now where we went through and analyzed, we scraped like 2 million jobs and analyzed down like almost 70,000 tech postings and then try to map those into skill taxonomies and understand what are the underlying skills being put under these traditional titles.

And what we found was that there's a lot of emerging roles that no one is really naming yet. And that's a problem. That's a big problem. Because as an organization, you might put out, Hey, I'm looking for a back end engineer. And then once they get on the job, you're expecting them to design agentic architecture and orchestration layers, which has nothing to do with traditional back end engineering. But based on your HR and hiring processes and recruiting pipeline, like this is just the easiest thing to do for us to get candidates.

But what you're doing is one, putting the individual in a place to fail, and you're also putting your company in a place to fail. Uh, so as companies begin to move from this idea of like job titles and job roles into this skills-based economy, is that you're able to break down what you can truly do into a much more finer grain understanding of what you have on the truck, kind of where the gaps are, and then where to, like I mentioned before, like prescriptively upskill or reskill, or potentially hire to fill those gaps.

And as you start breaking down work, you can start to look and see, maybe this person is better fit over here, or maybe these teams need to be aligned a little bit like this. And maybe this is what our hiring tech pipeline and strategy really should look like for Q3, rather than what we thought it did. And the longer term benefit, and this is the one that I'm most excited about, and one of the things that brought me to Andela, was that understanding and being able to match skills to work is really the foundation of blended human and synthetic labor.

And when AI is out now and what companies have tried to do, and I think we're beginning to learn that it's not the way that you do it, is to say, hey, we're gonna replace this role with an agent. And we've seen that catastrophically fail over and over and over. And the reason is is that it's not about replacing the role, it's about understanding what skills from that role can be replaced by AI. And so, you know, I look at it as a Venn diagram, and an agent has these skills, a human has these skills.

Where do they map in the middle? You probably want to, you know, allocate that middle lapping over to the agent because it's, you know, it's cheaper to run. And then now you free up the human to actually do bigger and better and more complex and more human centered tasks than what they were doing before. And but you can't do any of this idea of blended and synthetic labor until you start to really look at things at a skill, uh, at a granularity of skills.

And so we do it internally, it's very, very cool. We run it with like a, uh, so we, Andela has like a big network of individuals. We break everything down by skills. And what's so great is that, like, on the research side, as I'm doing projects or as I'm, like, needing to build things to support the studies that we run. Like, I can scoop in and say, Hey, here are the 15 skills that I'm looking for.

Scoop in and find that right person. And they're, you know, it drastically reduces interview time, drastically reduces onboarding time, drastically reduces the time that they're able to deliver the work, and then ultimately, like, improves overall satisfaction from not just from me, but also, you know, the individual that worked on it. So it's a it's a very, very powerful kind of mind melding thing once you get started on it.

I love it. It's giving control, find, like, I, uh, it it just sounds like it makes sense. Um, so I'm wondering, obviously, this data will only be as useful, uh, will only be useful if it is up to date. Um, so how often does the data need to be refreshed to stay useful?

Yeah, that's that's a great question. I mean, the perfect answer is always and continuously, which is something that we're that we're driving towards. I'm not gonna make the claim that, hey, today, Andela can assess, uh, you know, assess thing every, you know, consistently. And like, no, not true, can't do it yet, but we're getting there. But ideally, the way that we look at it now is that most enterprises have zero under, don't even have a baseline.

And you look at, you know, I was talking with someone earlier today and we were trying to like suss out this like hypothetical of like, how do you define what good is in an engineer? I was like, you know what? The funny part is, is that most engineers that are kind of like deep into their career, you know, whether they're 20 years in or 30 years in or even 15 years in, they've never they haven't been tested since college.

Like my I mean, I don't know about you, but, like, I haven't taken a test since college. And as an organization, it's like, how do you understand what this baseline of good is in your organization, but also what your baseline of good is to your peers, to your competitors, to the market at large? And so the way that we approach it is that so we always suggest starting with just an initial assessment. These go like really quick, and they're not meant to be like these, you know, it's not like a five hour SAT you gotta go sit down.

Most of them we've done in like 30 or 40 minutes, but we do have some special sauce in there on, like, how we're able to abstract how people perform in real world scenarios. And that just basically gives you as an enterprise a baseline, like, hey, here are the skills you have across these different teams, here's what's on the truck now. And with that, you can start to do a lot of, like, very, very cool things. You can start to look at maybe your project roadmaps and saying, hey, based on the skills, we can be more aggressive into maybe our AI strategy.

Cause turns out more people know how to do this than we thought they did. Or maybe this is gonna take much longer and we need to go, I don't know, hire some people in to get the acceleration that we're looking to based on the promises that we made to our board, to our customers, et cetera, et cetera. And then from there, how frequently you assess is is kind of up to you. There is there isn't really always, like, the perfect answer, but the like, the rule of thumb is that we also offer, uh, not to, like, sit here and plug Andela, but we also offer, like, learning and development courses based on how people perform on their assessment.

So we do typically say, hey, if you assess someone and you know that they need to go through some learning programs, assess them again afterwards just to make sure that that learning stuck. So that's like a general thumb in the air of how often to assess. But we see people do it quarterly, we see people do it twice a year, uh, we see people, some people just do it annually. So it's a lot about kind of what the appetite within your organization is to do it.

But the biggest thing is that we don't want the worst you can do is get like assessment fatigue, where it's like, oh my gosh, like, I've gotta do this again. And then people just get angry, which I to which I totally understand, totally understand.

Yeah, I was about to think about that, but um, I'm sure that you will get some pushback, especially in, uh, in the beginning stages of deploying this. But I guess when the first underdog comes out at the top, uh, um, of the skills ladder, if that is even a thing, they'll see that, okay, wait, this is actually working in our favor. Um, I'm actually getting used where I am useful. Is that the like the the culture that you've been seeing with this?

Yeah, a little bit. I mean, so the like the very interesting part, and I think this is this has been kind of a cool feeling. So we were talking to one of our customers the other day who's a large bank and I think he's a either director or VP level. And what was funny was is that he was almost nervous to roll out the assessments because he was worried that his team wouldn't be up to snuff and that they wouldn't be as high level as he would expect it, which would have reflected poorly on him from his managers above them.

And, you know, the thought process is totally valid, like 100 valid, like, I get that. But then, you know, the the bigger question to ask is, you know, what if you don't? Like, what if you continue to kind of operate with maybe the team that isn't right or isn't, you know, doesn't quite have the skills that you need. And now you start missing deadlines, you know, you start, then you start getting budget pullback and then you get your feet held to the fire.

But it's only six months from now when you could have gotten ahead of, like, that hiring and talent strategy now versus letting, you know, burning x amount of capital to only come up short. Uh, and that kind of resonated. And then, you know, on the other side, there's obviously we do see pushback at the individual level, like, hey, am I being tested because I'm gonna get let go, or am I not performing well? So we do anything and everything, whether that's through messaging, our platform, our setup, or how we work with our, uh, stakeholder counterparts, like, relieve a lot of those fears.

And I think that the big one too, is that when we do come out of it, a lot of individuals are pleasantly surprised with the findings that they get and use those to to either self-improve or sometimes they come back really good to ask for a raise, which I'm always super happy for people to do. We understand and we we work quite frequently with how to to make the whole thing seamless and smooth.

But I'm thinking also if you do get results that don't really reflect good on your team, it it gives you the opportunity to fix that and to identify the gaps in training and maybe upskill those individuals and empower them and enable them. So, uh, I I guess you can decide which angle you wanna see it from, but it can be used for good in that scenario as well. Uh, Cory, uh, we've talked about the scale of the problem and the tools that we can use to see it more clearly.

But if we have a leader listening to this, uh, and they haven't put any of this in place yet, where do they start on Monday morning? What's the first concrete step? And and then obviously, what comes after the first step?

Yeah, I mean, the 1st one, you know, uh, the 1st one. If I, uh, you know, if I'm a leader and I'm sitting there is the 1st thing to go would be either to your direct reports. Like, let's say that you're a C-suite, go to your direct VPs and say, hey, kind of like, what's what does our skill landscape look like right now? And most likely, you're probably just gonna get a list of like, hey, here's all the job titles that we have.

And it's like, this tells me a little bit of something, but I generally understand that we have 500 back end engineers. Are they AI fluent? Have they built AI systems before? Or, or, you know, are they working? Or do they have domain expertise? And we built assessments and for a big bank that wanted specifically engineers that had experience with mortgage-backed securities. So if you're sitting in some domain specific role, press your direct reports and your teams about these questions of what skills are truly, truly available within your org.

And not just I don't want role titles, I want skills. I wanna know what skills that we have because that's gonna give you a much, much clearer understanding of your visibility into the bucket and what's there. And then obviously, if you get bad answers, or if you don't get the right answers, or if they just get a vague list of job titles, reach out to us. This is the time, time to put the plug or not.

I don't wanna do that, cause I typically hate doing that. But really, that is the 1st step. Like, you know, we're we're more than happy to come in and like even offer up some free assessments if you wanna take a couple, just see what the data looks like. But really, we see people that push their team to say, what skills are in this thing? Or what skills are in your department? And not, I don't want just job titles, don't want resumes.

I need to know what these individuals are truly capable of, and that's a good place to begin.

I like that. I think to to wrap it up, I would tell the audience members that, you know, my key takeaways from doing the research on this, really going down the rabbit hole, is realizing that trusting resumes and certificates, it's it has never been a good idea. Um, uh, I can put anything on there, and I'm sure you can put anything on there, and I'm sure we have put things on there that we shouldn't have. So, uh, it's it's really comes down to capture the skills, ignore the titles and focus on the capabilities, uh, do the assessments, uh, at least then you know what the exact skills are and where the gaps would be.

Identify the needs, and I'm sure that you're gonna see a lower staff turn over. Um, and and that's just gonna help with projects going faster and just the general operations part of the business. Is that the right message? Is that what we want our audience to understand off of those conversations?

Yeah, 100. I think you nailed it on the head. And the best thing, you know, the best way that we look at it is that in the age of AI, the half life of skills is starting to compress even faster, meaning that individuals in your workforce need to up continuously upskill because skills now are phasing out with about two to three years. Uh, and if you don't kind of assess and invest and understand, then you're building talent debt just as fast as you build technical debt.

And when you have both of those together, the problem compounds and you get into a much more difficult position than you have probably ever been in.

Scary thoughts. Cory, it's been great having you in the studio. Thank you so much for sharing so much of your brain with us today. I'm very excited to see where this conversation

Of course, thank you for having me.

Wrapping up today's episode, let's look at the three key takeaways from our conversation with Cory. First, job titles routinely underdescribe the real skills within a technical workforce, leaving leaders with a distorted picture of what their teams can really do. Second, sustainable AI adoption tends to start in pockets among individual contributors and spreads only when leaders identify and amplify those early use cases, rather than mandating tools from the top down. And finally, technical skills now carry a half life of just two to three years.

So leaders who don't continuously assess and invest in their workforce are quietly building talent debt alongside their technical debt. Emerj works with a selected group of AI vendors to reach Fortune 500 decision makers through research, media, and direct access. If you want to be considered, download our media kit at Emerj dot com slash AD1. That's E-M-E-R-J dot com slash AD1. On behalf of the team at Emerj, we'll see you on the next episode.