Building a Skills-First Enterprise with Dr. Sandra Loughlin | Talent Draup

In this episode of our podcast, Talent Draup, Dr. Sandra Loughlin, Chief Learning Scientist at EPAM Systems and former professor at the University of Maryland, joins Vishnu Shankar, Chief Data Officer at Draup, to challenge one of the most persistent myths in the HR world, that training and learning are the same thing.
Sandra, who once described herself as a "training hater" in her LinkedIn bio, brings a systems-thinking lens to workforce development. With EPAM's 60,000+ person engineering workforce as her canvas, she unpacks how skills-first thinking, powered by clean data and smart organizational design, can move beyond buzzword status to become the company's actual operating model. From the numerator-denominator framework for measuring skill fit to the data mesh architecture that enables real-time talent decisions, this conversation is a masterclass in what a truly skills-based organization looks like in practice.

---

Quotes:

"Training is different versions of 'I'm gonna tell you something.' But that's not how learning works, it's never been true." - Dr. Sandra Loughlin
"The system itself is driving our learning culture - it's not just the people." - Dr. Sandra Loughlin
"You don't just ask 'what are the skills for this role?', you first ask 'what does this role do all day long?'" - Dr. Sandra Loughlin

---

#skillsbasedorganization #futureofwork #hrleaders #learninganddevelopment #talentintelligence #workforceplanning #skillsdevelopment #hrstrategy #hrinnovation #chieflearningofficer #learningculture #datadriven #hrtech #talentmanagement #draup #hrpodcast #epam #learningatwork #skillsgap #organizationaldesign

---

Moments You Can't Miss:
01:03 - Sandra's journey from professor to Chief Learning Scientist at EPAM
03:52 - Where training ends, and real learning begins
05:46 - Why AI skills demand a new approach to skill sensing
06:20 - EPAM's data-driven, business-owned skills governance model
10:40 - The numerator-denominator framework: baseline vs. actual skills
13:25 - How software engineers accidentally built the perfect skills-first org
17:14 - Why the operating model corrects for managers who don't understand learning
20:11 - The two secrets behind EPAM's skills-based model
25:49 - Why roles must be broken into tasks before defining skills
29:58 - The four buckets of skills and what lies beyond them

---

Key Takeaways:

- Training ≠ Learning: Real learning happens through reflection, practice, feedback, and stretch experiences, not just courses or content exposure.
- Start with tasks, not skills: The skills required for a role can only be identified by first mapping what that role actually does all day.
- Skills is a data problem: Without a unified data architecture connecting hiring, learning, staffing, and performance systems, skills-based decisions remain siloed and incomplete.
- Systems drive culture: The right organizational infrastructure reinforces how learning works, even when individual managers don't fully understand it.

---

More About EPAM:
EPAM Systems is a global software engineering and professional services firm of approximately 60,000–65,000 people. Known for its engineering-first culture, EPAM has built one of the most mature skills-based talent systems in the industry, connecting hiring, learning, staffing, and performance management through a unified data architecture. Its approach to workforce development is rooted in systems thinking, treating talent as a data problem long before it became an industry conversation.

More on Draup: 
Draup for Talent is a multidimensional labor and market data platform for HR teams that powers use cases across talent intelligence, skills architecture, and work redesign. It is trusted by more than 300 global enterprises, including 5 of the Fortune 10 and organizations such as Microsoft, Pep

Transcript

SPEAKER_00 0:00

Hello and uh welcome to Talent Drop, where we bring together minds shaping how talent, technology, and transformation are changing the future of work. I'm Vishnu Shankar from Drop, and today's conversation is about something every people leader is grappling with right now. How do you build a truly skills-first enterprise? Not just as a talking point, but as something that actually changes how you staff, develop, and deliver. My guest has been doing exactly that at EPAM Systems, a global software engineering firm of around 60,000, 65,000 people. Dr. Sandra Lachlan is EPAM's chief learning scientist. And she has a confession in her own LinkedIn bio. She calls herself a training hater. Coming from a chief learning scientist at this scale, that's either very brave or very important. I'm sure it's both. Sandra, welcome to Talent Drop. It's a privilege to have you here to start this off. Would be great to know a little bit more about the work you do at EPAM.

SPEAKER_01 1:03

Absolutely. And thank you. That's kind of a perfect introduction for me. It seems crazy. So at EPAM, I um so prior to coming to EPAM, I was a professor actually at the University of Maryland, uh, in the business school and the education school. And I got to know EPAM. Um, it's like a long story, but the reason that I came to EPAM was because of exactly what you said, which is the future of organizations and the future of talent is actually on skills and understanding the workforce and sensing what skills you need and being able and what you ski and what skills you have in the organization, being able to develop those people, um, motivate them to learn, um, put them into the right positions that make sense and deploy them to create business value. So it's a long story, but I came to EPAM because it's the only company that I have ever seen to date that is able to do that and do it exceptionally well, although imperfectly at scale. Um my job at EPAM is uh kind of unusual. I I um I try to make what we do internally better. And at the same time, it's already quite good. And so the other part of my job is helping clients start to get closer to that thing. So um it that relates to learning, to um data around people, to um building systems like um organizational systems, operating models, data systems that allow all of that to happen. So I have this like kind of unusual background and a very cool job. And I am so very, very excited that in the past few years, um, a lot of other organizations have realized that this kind of model can exist and are now working toward it.

SPEAKER_00 3:04

Perfect. Uh that's that's definitely something I would agree. Uh I was very curious when I saw your title. I was, you know, the next thing I did was find out how many chief learning scientists exist in the world. And I couldn't find a lot. I I think it didn't go beyond two pages. So that's a very unique role, a very unique vantage point you have uh looking at the internal log and also work get you also get to work with your customers uh you know externally. So you get you get that very unique vantage point. I just want to double down a little bit into that um training hit a bit, Sandra. Where does um uh training end and real learning begin? Uh and why does that distinction matter so much right now? I want to start off with that.

unknown 3:51

All right.

SPEAKER_01 3:52

So, Vishnu, we're gonna obviously be really good friends. Like I've loved all their questions so far. So this is gonna be great. That is an excellent question and one that very few people ask. There's this assumption um in how we talk about learning. I'm gonna transmit my knowledge to you. We talk about learners like sponges, they're gonna soak it up, right? There's this idea that if I just tell you stuff, like you have learned it. And that's what training is. Training is different versions of I'm gonna tell you something. I have content and you're going to like go through it. And that could be in a lecture, it could be in a video, it could be in whatever, right? But there's this inherent assumption that A, that's how learning works, and B, that learning will work because you do that. But in reality, as we all kind of know, like people can be exposed to content. They can actually engage with content, and then it doesn't stick, right? It doesn't actually change the structure in the head. And we also know, just people watching this podcast should know, that we learn most things not from any sort of formal training program. We don't learn, we learn from reflection and practice and feedback and talking to some people over here and screwing up and learning from it. Like there's most of the ways that people learn, and like meaning that they now in their head see the world a little bit differently than they did before. They have new skills that they didn't have before, happens not because of training. It can happen. I'm not saying training is bad, I don't really hate it, but I hate this association of training, therefore learning. And that is just a broken model that has never been true. And as a society, we need to get a lot better about what learning looks like and how to make it happen.

SPEAKER_00 5:46

And um, that's that's very interesting because and with AI coming in here, um skills are changing so fast. The skills that are relevant for every role is changing so fast, and which also becomes a big challenge for organizations and would be interesting to know how you decide which skills truly matter for your workforce at this point of time. How do you track this? How do you know what's relevant, what's just noise, and who owns that call at EPAM? How do you make these decisions?

SPEAKER_01 6:19

Um, so the business, in short. Now, to be clear, EPAM's business is uh professional services. So our product is talent. So this is a huge deal for us, and that's one of the reasons that we ended up having a system like this. Um, but every company has roles like this. It's not, to be very frank, right? There are some jobs, like they are changing, but if people aren't that great at them, like it's not awesome at scale, but it's not going to like shut down the company. And every company has certain roles that are, I think, are close to PL, right? Close like jobs where if these people don't stay abreast of the evolution in their field, the company will lose its edge and and it's an existential issue. So the way that we do this kind of sensing, I think of it, at EPAM, is we ask the business, the people who actually are responsible for those types of roles. I don't mean HR, I mean the cloud practice or the marketing team or whatever it is, whatever organizational like structure it is. We say to them all the time, um, what's happening? What, what are the skills that are like for these super important jobs? What are you seeing? And we have we have tools that allow us kind of kind of like drop, right, that allow us to get market signals of what are all of our competitors doing when they're hiring for certain jobs. But we also have tons of internal data from our customers on what our clients on what they're looking for. And also we just have experts who are just thought leaders in their space and are kind of looking and seeing this future. So we bring all of the data and people together on a periodic basis and we say, okay, here's all the mess that we're seeing. Like here's data, here's this, here's that, here's a perspective. Let's make a bet. What are the skills that we think for our business are going to be critical? And then we essentially change the goalposts. So the goalpost before that meeting was here. The goalpost after that meeting is here. Could be 10% different. That it just changes. And then the people organization says, all right, we're on it. And they then create learning programs. They hire differently, they will put new performance management metrics in place. They will um uh uh look to find um growth opportunities into those specific important roles from other places like within the company if we need them. So it is really a data-driven, human-owned governance process, essentially, um, that we engage in for the roles that matter, which is not every role, but a lot of them, um, on a periodic basis. And the periodicity, how often we do that, is dependent on a few different things. Like we can't constantly change it every week because you can't build a system around that. Um, but it's it's it's however often we need to do it. So for some roles that are changing really fast, that we have to stay close to them, it's every nine months. Sometimes it's every three years. It just depends. Um, and there's no set time frame for each job. It's kind of like when the data have changed enough, an alert goes out that's like stuff is changing, we've got to work on this, and then we do the thing.

SPEAKER_00 9:51

Right. And I'm guessing it's gonna be even more complex for a company like EPAM because your job architecture, your skills are again going to be largely influenced by your customers, the kind of work they uh um outsource to you, um, which becomes kind of tricky. There's gonna be customers who are at the bleeding edge, who are working on super futuristic stuff. There's many customers who are legacy still wanting you to get certain things which are which you don't want as part of your job architecture, skill architecture. It's gonna be a mix of all of these customers. How do you uh it's I'm guessing it's very unique to somebody like EPAM, uh, but how do you handle all of this? Uh just wanted to understand a little bit more about this.

SPEAKER_01 10:40

These are yeah, these are really good questions. Like I'm super impressed with your questions. Um uh the answer is okay, what we so you're right. There's always gonna be some clients that are like, I need your top 10%. Like, like we're just gonna do bleeding edge. And actually, EPAM does a lot of that work. So the vast majority of our work is not keep the lights on, like mooring maintenance stuff. That's just not our what we do. Um, so it is largely that. But even within that, there's still more and less like innovative, essentially. Um so we do not, so so we have two different things. We have two different um, I think of it as the denominator and a numerator. So the denominator is what is the expectation for the role? And then we have, you know, if we have a hundred people in that role, we have variability in the numerator of like the actual skills of the people that have that job. So you'll often, I mean, always you will have people whose denomin uh sorry, whose numerator exceeds the denominator, right? They have skills that are not required for their job, but they have them. Um, and so we like for those people, we want to put them on those client projects because they have a skills fit for the client project that exceeds the skills of other people in that same role. So we we it's very important, I think, the concept of the numerator and denominator to understand skills and how to sense them and deploy them. You need to constantly know what are the baseline skills that they're like the minimum expectation, if you will, for the job. But if you only assume that everybody has those skills, A, that's often not true. And B, you're missing some stuff. Uh, and so you have to have a really good infrastructure of a data perspective to get an accurate numerator so that you can flex people where they actually fit best.

SPEAKER_00 12:44

Right, right. I I I can't imagine what that's like. I and no wonder you have this role of chief learning scientist. Uh um, but switching gears a little bit, uh, Sandra, going back to how EPAM has been investing in skills strategically over a while, uh, what are some of these early decisions that have helped uh you know uh um help skills become something that leaders can actually use at EPAM, whether it is in surfing or delivery or performance uh across all of these things. You want to touch upon that a little bit?

SPEAKER_01 13:24

Yeah, happy to. And I will say, so keep in mind this whole skills thing for us started in 1993 when I was like in middle school. I had nothing to do with the foundation. I found this magical little unicorn um eight years ago, but what I'm talking about was built well before I got here. So EPAM was in a very so epam, a bunch of very, very um high-end, sophisticated software engineers. These are the founders of the company. And they um, of course, like your founder, like you're cheap, like you're not gonna buy all these systems. And I don't even know if the systems even existed back then. But these are people who think like software engineers. They're like, they think in terms of like denominator and numerator, like we're let's figure those things out so that we can like deploy them. Um, and they have a build it here mentality. Because again, like these are very high-end software engineers who build incredibly complex digital platforms for clients. They thought, well, we have bench time, let's just build our own digital platforms. And because they are also experts in data, they kind, and this was the prescient thing where a few people very early on realized this is a data problem. It's not a technology problem, this is a data and systems problem, a system meaning operational systems. And so they were like, let's build all of these little platforms to run our business and make sure they all talk to each other, they all feed into one data space. And then they began kind of doing doing this in order to solve very concrete business problems. And the first problem was staffing. We had to get the right people to the right clients at you at a certain size, like when you're small enough, first of all, everyone just figures figures it out. You just you just do it. But after a certain size, like you don't always know who you have in your organization and you don't want to mess up, right? Like give the wrong people to the client. And so they began building both like you know, they began building this organizational architecture from a from a from a process perspective, from a technology perspective, from a data perspective that they just built on over time. So the first use case was staffing, but then they're like, oh, we should hire based on this. Oh, you know what? This data is actually super useful for learning. Oh, what if people want to change careers? How can we use this? And so the system just evolved, not because, and this almost kills me to say it, not because there were some really good people, people at EPAM, like really good HR or LD or any of that. There was none of that. It was just a bunch of super smart software engineers who thought like software engineers about business problems and then designed the organization and all of the systems to solve them.

SPEAKER_00 16:29

Right, right. Uh that's that's very interesting. Um in this journey, and today when after you joined EPAM, uh Sandra and and in your journey with EPAM, um, have you come across and probably you you have come across uh scenarios where internal leaders, even well-intentioned ones, ones for that matter, most consistently oversimplifying what it takes to get people to learn something. Um going back to the training versus learning bit, but um, you know, how do you how are you handling such conversations? I I'm sure it comes up looking at your reaction.

SPEAKER_01 17:13

So yes. Well, okay. So okay. So the um well, first of all, in addition, like we we continue to make tons of mistakes. Like what I think I just described, like you had asked about mistakes, and I was like, yeah, it was a million mistakes. We keep making mistakes now. And and what's what I I'm a person who thinks in systems, right? And I know the uh the systems really drive companies, right? Um, we just had EPAM's investor day, and I talked a lot about this to all of our investors, um, about how training is not how learning works. But behind the scenes, as we were preparing for this, I had to keep telling certain people on our executive team, stop talking about training, because it's not actually what's working for us. Like remember, we have this whole system, and the whole system does this thing. So, what's fascinating about EPAM's systems is that the system itself is driving our learning culture. It's not just people, because it's still very possible at EPAM to be a person who thinks of training as like the answer to problems, even though the entire operating model of the organization says otherwise. Does that make sense? Like it what it means is that we have, because we have built these systems, I can be a manager who actually doesn't understand how learning works. And most of them don't, like most people don't understand them. But the system corrects for that. The system is what actually, like, I mean, like the tools that we have and our processes, I'm so I mean the system, is looking at a person's skill gaps, and it's feeding them content, but it's also feeding them all of these other I think of as real learning opportunities. Again, communities of practice, stretch assignments, um, being able to go to conferences, like uh reflection tools built into our training programs. Like the system itself reflects how learning really works, even though all the individuals in the systems don't understand it. Does that make sense? Was that like too nuanced?

SPEAKER_00 19:33

It it makes complete sense, Sandra. And and what it leads me, or or what I'm thinking right now is if these systems have to work so well, it also needs really good data in place. Um, yes. How are you ensuring and I've seen a lot of our customers, organizations struggle with internal data, they have messy data, they have no data. Right? So, how do you uh how do you go about ensuring you have reliable data for these systems to work? Um because I'm guessing that's that's where it all starts.

SPEAKER_01 20:09

So yeah. So I said that there were two secrets. The first secret is um driving a skills-based organization and learning in particular, but every aspect of it through skills-based performance management. That's secret number one. The secret number two is exactly what you said. This is a data problem. And it's a very complicated data problem. So I could talk for days. I will attempt to do this really succinctly, but there's a data um uh availability and access and into like just having all the data in one place problem, right? Having um missing data in, you know, getting out of the heads of people and in in in this one place, having all the different tools and systems talking to each other. Um, really the solution for that is um it's a mesh. It's a data mesh. So it's basically like you can think of it as a lake if you want, but it's just like all the data from all the systems, all the systems of record and work. So not just your ATS and your LMS, but also, you know, your um your project management systems, your staffing systems, your systems of work like Jira and GitHub and like all the different systems at EPAM feed into one place. There are no data silos. And that is the secret. If you can have all of your data in one place, and that place is not just an intel an intel, it's not like it's a reporting level. So it isn't like I just have all that data and I can go click buttons and figure out who knows what. If that data architecture is real time event driven. You can actually create automatic things to occur driven by skills. I'll give you an example. So at EPAM, well, in any company, like you hire somebody, you, and in the hiring process, you you learn about something about their skills, particularly if you have a really good, like skills-based ATS system. But in most companies, that information, if it lives anywhere, just goes to die in the ATS system because it can't actually connect to any other systems. And even if you had other skills systems, the skills are defined differently. So it's like it's like you can optimize for hiring, or if you do this for learning, you can optimize for learning, you can optimize for mobility, you can optimize here, but you can't optimize across the whole system. Here's how it's different at EPAM. At EPAM, when we hire somebody, we know that they're missing certain skills because we've assessed them. So we have a skills profile of the person, first of all, before they even get to that interview, just by sensing uh their presence in the world. And then we have a good skills profile of that person based on the entirety of the hiring process. Okay, so we have that here. While they're waiting to join the company, a couple of things are happening. One is that that information is going to our learning management system and it's pulling all the courses because that person's missing three skills. Like we know they're missing three skills. It's pulling the courses that they need to shore up those three skills. It is putting that automatically into the onboarding program for that person so that they have to go through coursework, not maybe informal, but actual coursework and certification. So it's coming from our certification system to say you can't actually function in this job if you are missing those three critical skills. At the same time, the high the manager is being alerted, hey, by the way, we're hiring this person that you really wanted. They're missing these three skills. On day one, you're going to get an automated email as part of your initial conversation of like, hey, welcome to EPAM, to remind them that they have to go through those courses. And also at the same time, um, the staffing system is going to block that person from being staffed to projects where those missing skills are critical. Even though that person has the job title that makes you think that they could do that job. That's just one example of thousands of what you can do when you have all the data in the right place, in the right architecture, and you are thinking about people in terms of their skills relative to skills that you need for their job. So numerator, denominator, or for a role. Again, numerator, denominator. And there's it gets so much more complicated than that. But I hope that that was kind of helpful in explaining why we why skills is a data problem and what companies can do about it.

SPEAKER_00 25:05

Right, right, absolutely. And it's fascinating to hear how things work and and how a bunch of software engineers, if they come together, um can have this systems first thinking, not just for the business, but also for the larger organization. Um, you know, I I think fascinating, really fascinating. Um, and and just one follow-up to that, Sandra, is do you also we we did talk about skills quite a bit, but what we are also hearing now is skills don't tell you the full picture. This is also you also need to unpack roles as tasks, workloads, and all of that. Is that also already in play? Um and and where does this lead if it's in practice for EPAM?

SPEAKER_01 25:49

Yes, as a great, I love talking about tasks. Okay, so first of all, um, again, denominator, numerator, they're very different. We have to think, we have to talk about them differently. So at the denominator, like how do you arrive at the skills for a role? Like you don't go there, you don't just say, what are the skills for this role? Right. You actually first say, what does this role do all day long? What are the tasks that this role is responsible for doing? And then you say, okay, well, what are the skills to do those tasks? That's how you arrive at the skills denominator. So it it at EPAM, it it starts with tasks and it and projects too. It's like, what is that person responsible for delivering? Like, what are the tasks? And then right, right. Um, okay. So, so there's other things in the denominator, right? Context is very important. So um, you know, let's again, we're professional services in engineering. Um optimally, we want like there are certain things, like you can do project management, for example. Project management is not a stall, a static thing. It's a it's there's different versions of it if you're doing experience design or innovation versus um uh construction versus software engineering. I think there's so even the tasks themselves, when they're the same tasks, can actually function differently in these different contexts. So and there's other um critical data elements as well, but just like to get a sense of like that's the kind of stuff that we think about. We think about what is the nature of the work in several different dimensions, and then we figure what are the skills to do it, and that kind of goes into the denominator. But for the numerator, you're right. Like skills is one element of individuals, but it's only one of like 25 that we track when we're looking at matching people to projects. We also look at what are they what so we have look at what are their current skills, what are the skills that they're working on, because we have evidence of that. We look at what what context have they worked in? Like if it's a if it's an experienced design um project management position, have they done that before? Like how much does that matter? We look at their availability, we look at whether they like projects like this, we look at their profile relative to the other people that we're putting together on that team to see if there are skill redundancies that we actually want to build in for the health of the team. Um, we'll look at location, we'll look what like we'll look at so many different attributes. But even, and now I'm gonna get like level another level of complexity here, even when we know skills, thinking about the kind of like what can a person do? There are things about people that I wouldn't call skills. We call them like characteristics or qualities. So it's like, who's a client whisperer? Who is just so good at talking to clients in any context? Like they're just amazing at it. Or who is it that you call when something is on fire? Who is it, who's a glue person? Who's going to be the one that's gonna like rally the team together and be the one to mention who's, you know, people's birthdays? Like the kinds so we we look at people in so many dimensions. Skills is one of them. Um, and increasingly we are looking at these qualities in addition to skills, plus, are you available? You know, do you are you in the right geography? Are you at the right price point? Like all of these different facets around people is what we build into the the numerator.

SPEAKER_00 29:32

Wow, okay. That's that's amazing to hear. And and um the fact that you're also factoring in, I'm not sure what to call it, soft skills, behavioral skills, uh personalities, characteristics, it could be all of them. Um very, very interesting.

SPEAKER_01 29:54

Well, sorry, on the skills thing though. Yeah, just I should say, like on the skills thing, um, for us, there are different kinds of skills. I I think of skills in four buckets. You have technical skills, very important, for especially for technology company, but you also have like professional skills. Like, are you are you a good teammate? Like, do you know how to manage up? Right? Like, do are you good with like the clients, right? Um, so there's like professional skills. Then there are skills that I think of as self-skills. Like, are you resilient? Are you reflective? Are you empathetic? Are you um like are you hungry? Like, are you motivated to to solve things, right? So there's those are all different kinds of skills. And then, very importantly, for every company, you have organization-specific skills. Do you know how to get things done in this company? Do you know our IP? Do you know our tools? Do you know our workflows? Do you know our business strategy? Um, and so like all of these different things kind of come together. And those are just skills, characteristics or qualities or whatever other word it is that you want to use, right? A lot of it is softer, but I wouldn't call it a skill because it's like a it's bigger than a skill. It's something that um, yeah, we just say it's qualities. And I and so I'm a data person, right? Like in theory, I think that let's say it's like client whisperer. I bet we could build some sort of data model of skills that would all collectively like cluster into this characteristic, but it's just inefficient for us to do that. The way that we can figure out much more efficiently, figure out who is a client whisperer is ask a bunch of people, hey, listen, if you had a client who was like you needed to have someone to come in and put out the fires, who is the one person that you know in the company who could do that? So we we get the the characteristics data very differently than we get some of the skills data.

SPEAKER_00 32:06

Got it, got it, got it, got it. That helps, that helps, that helps understand how things work over there. Um awesome. Uh that that kind of summarizes our discussion in a way, Sandra. I think my takeaways from you and from the discussion today are exactly those. Um definitely the nominator-denominator principle about how you look at um what you need. Um, the systems thinking, data first thinking, which I think is bare minimum for every organization in this new world. And of course, hate training, love learning. So uh Yes.

SPEAKER_01 32:46

Or at least or at least love learning and understand training. Don't you have to hate it, just don't love it so much.

SPEAKER_00 32:53

Awesome. It was great, great having you here, Sandra. Uh wonderful session with you. Um, thank you so much for joining us today.

SPEAKER_01 33:02

And thanks for all your awesome questions. It was a real pleasure to chat with you.