Damien Filiatrault
Founder and CEO Scapable Path Follow

Welcome to the Use Case Podcast, episode 239. Today we’ll be talking to Damien from Scalable Path about the use case or business case for why his customers choose Scalable Path.

Scalable Path delivers vetted, remote software developers with the right skills to put your project on the path to success.

Give the show a listen and please let me know what you think. Thanks, William

Show length: 29 minutes

Checkr Forward SF22 Reshape the Hiring Industry

 

Enjoy the podcast?

Be sure to check out all our episodes and subscribe through your favorite platform. Of course, comments are always welcome. Thanks for tuning in to this episode of the Use Case Podcast!

Music: 00:02 Welcome to RecruitingDaily’s Use Case Podcast, a show dedicated to the storytelling that happens, or should happen, when practitioners purchase technology. Each episode is designed to inspire new ways and ideas to make your business better as we speak with the brightest minds in recruitment in HR tech, that’s what we do. Here’s your host, William Tincup.

William Tincup: 00:23 Ladies and gentlemen this is William Tincup and you are listening to the Use Case Podcast. Today we have Damien on from Scalable Path. You will be learning about the business case, or the use case, that his prospects and customers have used, or and use, to purchase Scalable Path. So without any further ado, let’s just jump into introductions. Damien, would you do us a favor and introduce both yourself and Scalable Path?

Damien: 00:50 Sure. Well, thanks for having me on.

William Tincup: 00:52 Sure.

Damien: 00:54 Well, I’ll start a little bit about Scalable Path. We’re a software staffing platform with over 24,000 developer profiles from around the world, and we’re kind of a hybrid between a talent marketplace, a staffing agency, and a recruiting firm. And our goal is to provide the best possible experience when hiring developers, designers, and project managers.

And I guess the story of Scalable Path started in a sense back in 2008 when I was living in India, in Goa, and managing a team of developers over there and I’d be up late at night on my laptop having meetings with people in San Francisco, where I’m from, and I’d get off my laptop at 11:00 PM or midnight and I’d think, “There’s got to be a better way to be doing this.” And when I finally came back to San Francisco, I started working with some developers in Argentina and I saw how well it worked, both from a time zone and cultural perspective. And so in 2010 I started Scalable Path. And since then we’ve placed over 500 developers, primarily in Latin America, with over 300 clients. So yeah, that’s a little bit about me and the company.

William Tincup: 02:20 I love that. And what’s great is the hybrid model, it’s flexible for folks. So if they’re looking, it’s really hard to find, as you well know, it’s very hard to find this talent, especially if you’re not looking globally. And so a couple questions and natural questions that the audience would probably have is one, how do you manage quality? What’s the process when a customer first engages with you? What’s what’s that look like first? So they find you on the web or someone refers you and what does that typical engagement look like?

Damien: 02:59 Yeah, so pretty straightforward and easy. So they go to our website at scalablepath.com. There’s a big orange higher now button. And when they click that, they get a questionnaire that asks them sort of the easier, more important questions about their needs, “How long are you looking to hire someone for? What kind of rates are you looking for? What kind of skills are you looking for?” We don’t try to overload them, we’re just trying to find out at a high level, whether we’re a good fit and right. We respond to that within 24 hours and if we figure out that, “Hey, I think we’re, we’re potentially aligned to be a fit to work together,” the next step is, and it’s not a lot of work, it probably takes 15 minutes of our time and 15 minutes of the client’s time, but it’s time very well spent just really thoroughly defining the job description.

So we take the answers that they provided on the questionnaire as a starting point, maybe they have an existing JD that they’ve been using somewhere else that they can give us and we put it into our platform. And then there’s some more specific questions that will ask to fill in our job description tool on our site to make it really thorough, we try to make it really appealing, we have a unique… Appealing to candidates, in particular. And we have a unique, I’ll call it like a skills matrix where we break down, “Okay, these are the top 10 skills,” it’s roughly 10 often, “That we’re looking for, that the client is looking for,” but also, “Okay, how important is this particular skill and what skill level does the candidate need to have?”

So we get really granular there so we can really see, “Okay, it’s not just we have those 10 skills, but maybe this one isn’t a must have, maybe this is a nice to have or a strongly preferred,” or “They don’t have to be an expert on this one, they just have to be familiar to succeed in this position.” And so really, the client experience, the hard part is just dialing that in with us, that job description, because once that gets finalized and polished, they’re kind of hands off. That’s where we take over and we go out, we reach out within our platform and beyond to see who’s interested and available. We do the vetting process, which I can go more deeply into, it’s two interviews, it’s a 30 minute screening interview and an hour long technical interview, typically.

And then, so the client is sort of outsourcing this part of their recruiting or HR process and they’re only getting back presented candidates who they know at least meet a baseline technical and other soft skill requirements, so the time that they need to invest is a lot less. And we have a team that does this all day long, it’s a team of software developers who do just this all day long. So they’re not taking time away from their own developers who don’t do this all day long and maybe don’t know how to do it as well, evaluating candidates. So really you just have to do a little bit of work up front to define your needs and then maybe a handful of interviews, but way less than you normally would need to, and you have a higher chance of success and in the end, so that’s a little 10 minute overview.

William Tincup: 07:20 I love it. Yeah, that’s great. So the job description itself, as I understand it, you’re focused on skills, skill level, ranking of said skills, the timetable of the project. And does that help you match, once you’ve kind of distilled that to its finest points, does that help you match against the folks that you already have in your community?

Damien: 07:45 Yeah. There’s a bunch of other fields as well in the job description form, “You’re looking for full-time or part-time? How many hours a day are you looking for? If you’re looking for full-time are you open to part-time? What geographic regions are you open to?” There’s a bunch of other… Well, that those are the big ones. It’s kind of hard verbally to sort of walk through it, it’s more of a visual thing. But once that is defined, yes, that skill matrix that I’ll call it, we can just push a button in our platform and it says, “Okay, rank all the 24,000 people in the platform, give them a score based on this skill matrix.” And that will have the platform suggest people.

So you’ll have a talent specialist that’s assigned to your position, and it is a human who’s managing the process behind the scenes, but they’re definitely empowered by our platform and they can have search results recommended to them and they can look at different profiles and say, “Ah yeah, I know this person, definitely I’m going to invite this person.” Or, “Actually, I’m definitely not going to… Even though the computer thought that this was a good candidate, I’m not going to invite that person because I can just tell that they’re not going to be a good fit.” So we do get a little help from technology, but we do really believe that technology isn’t able to do it as well as a human. And that’s a big difference between us and things like Upwork or even Turing, you’re not getting any help from a human and it’s not as great as an experience.

William Tincup: 09:47 With the folks that you have in your database, your skills change, right? Because they almost changed constantly, because people are taking on new projects and doing new things. So how do you keep up with the folks that you’re in your database? How do you kind of as they… And their desires, I guess. Some of it is, their learning Python or now they’ve done a year project in Python, but they hate it. So they have a ton of experience, great skills, but don’t really want to do anymore Python. So how do you keep up with both the skills and the passions or the interest?

Damien: 10:23 That’s a really good question. And it’s sort of two separate questions is, how do you keep up with the skills and how do you keep track of what they’re interested in. And we’ve talked about doing something where they tell us what they’re interested in and we haven’t implemented it yet. Right now, they sort of have a way to tell us… We have an interesting hierarchy of describing who you are. So we have three different levels. So at the top level, you categorize yourself, “I am a…” Either a developer, a designer, a project manager or something else, but those are the big groupings. And then based on what they choose there, we allow them to select, “Okay, these are my areas of expertise. I’m a developer and my areas of expertise are maybe JavaScript, Ruby and…” They can choose up to three. So you can’t say that you’re-

William Tincup: 11:43 Oh, interesting.

Damien: 11:46 You may have more than three areas of expertise, but you can only choose up to three. That’s how we prevent people from sort of saying they know everything. And our algorithm does sort of try to detect, the search algorithm kind of gives a little bit of a negative score in some way to people who rank themselves too highly across the board. But they sort of have to decide on those areas of expertise, what are they going to present themselves as? So in a way they can, if they know Python, because below the areas of expertise, we have the skills and there’s three or 400 skills that we track that are more granular, but there’s only about 15 or 20 areas of expertise.

And so they could say, “Yeah, I am a three out of five in Python,” but they don’t select Python as one of their areas of expertise, so that’ll give us a clue. So that was kind of a long winded answer to saying, we don’t really track them saying like, “I want to work on this,” or, “I don’t like that,” that comes out more in the, did they apply or not? They’re not interested, they won’t apply.

William Tincup: 13:01 So you mentioned technical interview, which obviously it brings up a quality discussion. So how do you manage, with all the folks that are in your database, how do you manage quality in the sense of, I know technical assessments and test and things like that, some are believers in that types of stuff and some aren’t as much. So where do you kind of lean on just, “Okay, we’ve got to manage quality because the client’s asking us for this, and our database we have that, but is it exactly what they want and what they need?” And so how do you manage, how do y’all think about quality?

Damien: 13:48 Well, we’re super transparent on what we know about candidates that we present. On one end of the spectrum, we might be able to say, “Wow, you’re looking for a React developer and here’s a candidate in Columbia named Carlos who has worked 15,000 hours on client projects through Scalable Path and I’ve personally spoken with and I can personally vouch for this individual.” That’s one end of the spectrum, where we just flat out know they’re good from experience. But I would say that’s tough to get most of the time and so most of the time you’re relying on your vetting process to tell you information about the quality of the developer.

And so our two steps are the screening interview where we’re going over English, communication skills, personality, we are getting a sense of, “What are they actually doing right now and are they trying to bite off more that they could chew by applying for this position? What’s their actual availability right now?” Because that is an issue out there in the freelance world, people overbooking themselves. And if they look good on paper, taking them at face value on their skills, are we going to recommend them for a technical interview based on those four things I mentioned in the screening interview.

And then as far as the technical interview, we really believe in a real world approach that really simulates what they’re going to be doing as closely as possible on the actual job. So just to contrast that with some of the things that have been done and are still done, I think less and less, in the industry, like having white boarding exercises, where you’re writing code outside of your development environment, people aren’t used to that, you never do that, right. It’s not a good predictor of whether someone’s going to be good at actually coding. Or solving some really tricky esoteric, algorithmic problem that is almost never going to come up. It might show that… It’s mainly an indicator that you’ve studied what kind of algorithmic questions might come up and got lucky, that you happened to study the one that got asked.

I was personally denied a position at Yahoo many years ago on what I thought was just a silly, silly, unrelated question to what I might be doing. So for example, if someone’s looking for a full stack Rails and React developer, we might say, “Okay, use your own development environment, let’s share your screen. You can use Google if you want, you can do everything you want or you normally do, and let’s build a backend API that you might build with the client. Then let’s expose that API and consume it with a Rest or consume it with a React application and then style it using CSS.” And we can see how they do a real world exercise and we record that interview and we share it with the client.

William Tincup: 17:40 Yeah. That’s collaboration at that point and they can see it in real world. With a lot of developers, they use GitHub and Stack Overflow to share, and other sites as well, but to share and also to get inspired, see something, look at something instead of having to reinvent the wheel. Are you and your clients all comfortable with them using those resources as they are?

Damien: 18:09 Well, using them in what sense?

William Tincup: 18:12 Well, like I say, in that scenario that you just put, if I could go to GitHub and find something that’s already been done, that does that, is that cheating?

Damien: 18:24 So yeah, GitHub or any sort of tutorial site or right or copying and pasting code. Yeah, the guys that are technical interviewers, definitely have preferences on what they see. If they do see that someone is relying to heavily on existing code, that can be a red flag. We want to see them sort of showing that they have familiar with the language or the framework that they’re using and that they don’t need to do that all the time. Yeah, you’re not going to remember every function or method or technique, and you may need to Google, but for the basic stuff, the obvious stuff, especially you know you’re being watched, you know as a savvy developer that you’ve got to show something, so…

William Tincup: 19:19 Other than how to find it on the web.

Damien: 19:21 Yeah. And the thing is, you’re not going to find the answer to the question that we’re asking you to do, it’ll be specific enough. But we definitely dock people for relying too much on external resources.

William Tincup: 19:39 Yeah. I think if they over index, if they do it once or twice, it shows that they know how to use it, they know it’s a shortcut, they know how to use a shortcut properly. But if they’re doing it too much, then the fear is, and probably rightfully so, is that they’re all about shortcuts and they might not know the language or be able to solve the problem as it is. So that’s great. What’s y’all’s philosophy on conversions in terms of staffing firms find themselves in a situation where they fall in love with Miguel, they do a project, they’re just like, “Oh my gosh, we love him and we got six other projects that he could just crush it on.” How do they work with you on a going forward basis?

Damien: 20:28 Well, we definitely like to keep engaging with developers who are on a client project and get released. And so at the end of a client engagement we’ll get feedback from the client on how the client thought they performed, we’ll do an offboarding interview with the freelancer to see how they thought it went, are they looking for something else right now? And if they are-

William Tincup: 21:02 Sorry to interrupt, Damien, but you just unlocked something, I just wanted to ask you about it really quickly while you’re there. Because you’re getting information from both parties on their experience, are they rating each other? Is there a way-

Damien: 21:17 No, we don’t have that mechanism right now.

William Tincup: 21:18 Okay.

Damien: 21:24 Our internal talent team ranks people and they rank themselves as well. A lot of the things in their profile are self scored that we can then sort of confirm or modify if in our evaluations we think that their skill level is different in a certain facet. But on our interviews, we have a structured ranking system on certain facets of their capabilities. But going back to engaging, or you used the word converting. As you mentioned, it’s hard to find good developers and so if you find someone who does a great job on a project, we really want to keep them engaged, so we do really try. We’ll sometimes even put them on an internal project if we don’t have a client project at that time, we might say, “Hey, we’re working on this. We’ll keep you engaged until we can get you on another client project.” But sometimes it’s just timing doesn’t work and so we can’t guarantee that if we’re in a economic contraction when bunch of clients are starting to sort of cut costs at the same time, we might not be able to keep everyone that’s being released from projects engaged.

William Tincup: 23:08 And what if the client wants to hire them full time?

Damien: 23:12 Yeah. It’s not something that we are promoting.

William Tincup: 23:20 Of course, you don’t want to be a development firm in the sense of double-A or triple-A to the major leagues, that’s not the model, but…

Damien: 23:32 I think with-

William Tincup: 23:33 It’s inevitable that it would happen, right? You’re-

Damien: 23:36 It comes up. I think that, as many of our can appreciate, that one of the things that makes a business stable is having recurring revenue. And so we’re trying not to be in a model where you’re at zero again every month. You could place 10 developers one month and next month you get unlucky and you have zero. And how do you keep a talented team of developers and all different kinds of people on your team steadily employed and working on this if you don’t have any sort of steady income? So I think that our model allows us to have a really, really great platform and team to do a really good job at what we do. But it’s something that if it’s a must for our clients, we can talk about it, but it’s not something that we really seek to do or love doing.

William Tincup: 24:57 Right. Trust me, it’s a question that a lot of RPO staffing, a lot of folks get. They have a model of keeping that talent and putting that talent back out and working and keeping them engaged, especially great talent, keeping them engaged. And it’s just I’ve seen it a couple different times and people have different models. I’ve seen some conversions where it’s, “Yeah you pay 50% and you can hire the.” It’s built into the contract, “If you really love them, great, pay for the privilege,” which, again, doesn’t get you the recurring revenue, but it also gets you to a way that both parties are happy. So take us into some success stories, without names of course, just something that you’ve loved. You built this business from the ground up, you saw the problem and built the business, and you’ve placed a bunch of people on projects. What’s your favorite or even your most recent bit where you’re like, “We’re doing good work here”?

Damien: 26:07 Yeah. So we have a startup in the FinTech space. And there’s a lot of reasons I like what happened with this client. The first thing is that the now CTO of this client of ours was a developer in our network that we placed on another FinTech startup. So he worked there for a couple years and then he left that engagement where we had placed him and he was now in charge of building his own team. And he said, “Hey, I’ve seen how the sausage is made. I trust this company. I’m going to go to them and say, ‘Hey, I need to build a team.'”

And over the past, I don’t know, I’d say eight months or so, I think we’ve placed like 17 or 18 individuals and they’re building squads. When you have that many people, agile can break down teams of that size, you can’t have scrum teams with 17 people, it’s unwieldy and so they have, I think, three or four different squads of five or six people with four developers and a designer and then a project manager on each squad, focusing on different areas of their business. And they’re building it out with a Python back end and a React front end, so lots of Python and React developers and designers and project managers and it’s gone really well. They appreciate that… It’s been pretty turnkey for them, they have a really lean team internally and they don’t have to hire an HR team or recruiters or anything. They just tell us what they need and they get an invoice at the end of the month for the hours that people are working. And there’s a lot of trust in their relationship and I think it’s worked well on both sides.

William Tincup: 28:30 I think you could almost be paid no higher of a compliment when someone that you’ve placed then comes back and then hires you to then place other people. I can’t imagine something better than that. So Damien, thank you so much for coming on the podcast and explaining Scalable Path.

Damien: 28:49 Thanks so much for having me.

William Tincup: 28:50 Absolutely. And thanks for everyone listening to the Use Case Podcast until next time.

Music: 28:56 You’ve been listening to RecruitingDaily’s Use Case Podcast, be sure to subscribe on your platform and hit us up at recruitingdaily.com

The Use Case Podcast

Authors
William Tincup

William is the President & Editor-at-Large of RecruitingDaily. At the intersection of HR and technology, he’s a writer, speaker, advisor, consultant, investor, storyteller & teacher. He's been writing about HR and Recruiting related issues for longer than he cares to disclose. William serves on the Board of Advisors / Board of Directors for 20+ HR technology startups. William is a graduate of the University of Alabama at Birmingham with a BA in Art History. He also earned an MA in American Indian Studies from the University of Arizona and an MBA from Case Western Reserve University.


Discussion

Please log in to post comments.

Login