EPISODE 1721

[INTRO]

[0:00:00] ANNOUNCER: Damien Filiatrault is the founder and CEO of Scalable Path, a software staffing agency that matches companies and startups with vetted remote software developers. The company was founded in 2010 and since then has worked on hundreds of client projects and has built a freelance network with 35,000 remote developers in 177 countries.

Damian joins the podcast to talk about software engineering management, the state of the software engineering job market, the challenge of hiring engineers, measuring productivity, and more.

This episode is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[EPISODE]

[0:00:48] SF: Damien, welcome to the show.

[0:00:50] DF: Thanks for having me, Sean. 

[0:00:51] SF: Yes. I'm excited to talk to you. So, you're the CEO and founder of Scalable Path. So, can you give me a little bit of backstory on the company, like why did you start it? What are the problems you're trying to solve, and what are you doing there?

[0:01:04] DF: Well, I can kind of walk you through the story of how I got there. When I first went to school, I was a geography major, and that wasn't really - taking my career the way I wanted to go. So, I went and got a computer science degree. When that was done, I started working at a digital agency in San Francisco. While I was there, I kind of worked my way up to managing a software development team in that company. The company was also starting to work with some people in India, like a company in India to do some development. I said, "Hey, that sounds cool. I want to go over to India and help manage that."

So, I did that for six months, and that was a really cool experience. But I came back and I actually tried working with some developers in Latin America, and that just worked super well. So, I was seeing how well that worked and I was kind of reaching a little bit of a ceiling at that company, and also, getting a little frustrated with like, "Wow, this company is charging $200 an hour and paying us less than half that. This isn't really great for clients either."

So, in 2010, I started Scalable Path to provide more value for companies and connect them with developers in Latin America. Yes, since then, I could go on and on, but that's essentially how I started the company and why I started the company.

[0:02:36] SF: Yes. You're focusing on tech there's in hiring. I think there has been a big change in the last couple of years in terms of the market dynamics with sort of the downturn in the market. I think the 2020 to 2022, there was a period where it was kind of candy on this market in many ways and then it's kind of flipped as the market is tightened up. I'm curious to see what are your thoughts on that and are you seeing things start to turn around in terms of the market tend to ramp up on hiring?

[0:03:08] DF: I'm definitely seeing what you're seeing. Yes, COVID was oddly a boom for us and for the market in general. I don't know whether it's driven by just macroeconomics, interest rates, and how all that affects capital. A lot of our clients are startups and I know they're having a lot harder time getting funding and it all trickles down. I would say, maybe, we're seeing a very small upturn, but it's still nothing like it was in 2020, 2021.

[0:03:41] SF: So, a lot of your clients are startups. I was a startup founder once upon a time. I did a lot of hiring there, both personally hiring, just completely managing it myself to also working with third-party agencies and stuff. What are some of the things that technology companies typically struggle with when it comes to hiring engineers?

[0:04:00] DF: Yes. I think things that come to mind are like, it's nobody's job to do hiring. Everyone's busy, so it takes time away from what they want and need to be working on to go out and figure out, okay, what's our hiring process going to be? Where are we going to find people? How are we going to interview people? Then, even if they do sort of have an HR department or they have a recruiter or someone working for them, those people are not typically engineers. So, they're not really able to do that technical vetting that you want.
Even if you're an engineer yourself, you might be a great engineer, but you might not be great at interviewing or you might not be great at coming up with a test that's really going to correlate with success in a job. Just the fact that hiring isn't something that startups are tooled to do necessarily, so they can lead to some challenges.

[0:05:09] SF: Yes. I feel like there's a tendency to try to copy what like big techs doing from a hiring perspective, without fully maybe understanding even why the things are there, which is also a challenge where you're sort of creating systems and processes based on maybe a company that's completely different, really, from what you're dealing with, and like what their hiring pipeline looks like, and then trying to apply that to your use case. It might be the wrong fit. It might be the wrong thing to do.

[0:05:37] DF: It might even be the wrong fit for those companies that you're copying. Who knows if they even should be doing that, like, pitting people through five interviews and doing random, super esoteric, like algorithmic coding exercises to test super niche things. It might not even be relevant.

[0:06:00] SF: Yes. I'm curious, given that, like, what is Scalable Path doing essentially that's different than maybe what some of these other people are doing? What systems processes do you have in place to help that candidates and how does that compare to maybe some of the standard things that we might see?

[0:06:15] DF: Yes, first of all, I would say, I would call our approach a very human approach. We do things a little old school, frankly. We like to talk to people, have humans vetting them. There's also a trend in some of our big competitors in our space to just automate everything and have AI do it. Not only does that not do as good of a job, but it kind of can alienate candidates and make them feel like cattle.

Our process is basically, we will invite people to apply for a position. They fill out a detailed application, maybe 10 or 15 questions, very specific to that job. Then, a human will review those applications and say there's a hundred people that apply, we might invite 20 to do a 30-minute screening interview. On that screening call, we'll be just vetting their personality, their communication skills, what's their actual availability, what's their sort of life story. If that looks good, we'll invite them to a live technical coding exercise and that's typically 60 minutes, can go up to 90 minutes in some cases where we'll do a real-world coding problem. If they're going to be a full stack developer, we'll ask them to build a feature using that exact tech stack, right in front of us, on their laptop. They can use any of the things they use in their normal job. They can use AI if they want. They can use Google. They use their IDE. We talk with them through what decisions they made on the exercise, and we record all this. If they pass that, we end up presenting the candidate to the client and sharing the recording of their technical coding exercise.

[0:08:16] SF: Then, at that point, does the client do their own screen process? This is like a pre-screen?

[0:08:22] DF: Yes. That's the standard. I mean typically where the part of that interview, each interview gets more and more deep, right? So, in a client interview, the client can just come into that knowing like, "Okay. I know this person knows how to code in our tech stack. Then, maybe I can just skip to some deeper questions." Like, "Hey, we're having this problem. How would you solve this?" It's more conversational at that level and you can get into a deeper level because you know you don't have to verify, like, "Hey, do you know how to code in Python or the basics?" Some clients will say, "Look, I trust you guys. I watched the video. I just want to move forward." But that's pretty rare, usually, and we want them to interview. We want to make sure that they get along with the person. We want them to interview them typically.

[0:09:16] SF: Are you focused on certain types of engineering roles or this is the full spectrum?

[0:09:20] DF: I mean, we'll typically take on any kind of role that's related to digital product development. But that said, if you look at the distribution of what typically gets hired through us, full-stack web developers. It's like web, mobile, more recently, more ML stuff because that's where the VC money is still flowing.

But yes, we'll do designers. We'll do more random niche. If you need like embedded Linux person, we'll go out there and we'll try to find you someone great, but it's a lot of like JavaScript developers, a lot of typical web and mobile stuff is very common.

[0:10:07] SF: Then in terms of the people on your side that are part of the vetting process, they're interviewing them, are those full-time employees on your end that have these skill sets? How does that sort of alignment of having enough knowledge to be able to interview someone appropriately?

[0:10:22] DF: Yes. It's a good question, because I think we kind of take pride in the fact that like our core talent team, as we call them, all have a background in coding. Or like one of our guys who's a talent specialist who does like the screening interviews was a QA engineer. But someone that we've all got a background in software development. We're not like coming at this as like recruiters trying to find developers. We're more like a group of developers that had no experience in recruiting and staffing and who just kind of figured out how we thought it would be the best to go about this. I think that the candidates can sense that, and I think we can do a lot better job, just sort of getting a sense of who's going to be a good candidate and who's not because of that experience.

[0:11:14] SF: Okay. So, I want to start to transition a little bit to talk about, sort of, there's the hiring part of it, the interview process. But then I go and I land my candidate and there's a lot that happens after that. I need to figure out how to ramp people, their productivity, how I monitor performance, and then also how do I ultimately make sure that people are successful and improve their productivity and their performance.

So, I guess like from a performance and productivity perspective, how should businesses be thinking about measuring performance? Because we need to measure performance in some capacity to know, are these people doing their jobs correctly? Especially, if maybe I'm not a technical founder, but I have technical people under me because we have a technical product. But I'm more on maybe the sales side or something like that.

[0:12:01] DF: Yes. I mean, the big picture, I think it's easy to get pulled into this rabbit hole of measuring and even potentially monitoring. We can talk about how to measure productivity and metrics and things like that, but I think it's important to say off the bat, the most important thing you can do, I think, in my opinion, is first of all, get good people, and then just focus on how can you make them as productive as possible. Sort of like the analogy that I can think of and it might be silly is like, you're a gardener, you want to grow some tomatoes, and are you better off trying to measure the pH of the soil and measure what nutrients are missing, and how many gallons of water you're giving them? Or is it better to just put a bunch of good soil and fertilizer on there, give them plenty of water, it's going to work out.

You can focus more on the more positive, proactive things that you can do to just make sure that these developers thrive in your organization as opposed to this more of like, maybe it can be portrayed as negative like measuring, monitoring, blaming, these things. I agree, it's like, I think you should. There's a place for measurement, but I want to just stress that it's, in my opinion, sort of a secondary thing that can maybe be used to validate our gut feelings that we get from just doing things that are more qualitative and more straightforward like communication, right?

Sometimes I talk with clients who say, "Look, I want a developer who's just super independent. I don't have time to manage them." I think there is a place for that. Longer in an organization, you have a rapport with someone after you've hired, maybe they can be really independent. But really taking the time, one of these things that you can improve your productivity with is just having great communication.

I do believe in daily scrums. They don't have to happen every day. But once you have a really good communication with your dev team, then you're getting information as a manager. When you have information and you're really in there with your team, then you'll just sort of have a gut feeling about how are things going. What needs to be improved? What obstacles need to be removed? That is the most important thing you can have other than these little measurement tools which we can get into.

So, I just wanted to set that stage and say like keeping it high level, just having good communication with your team and trying to make them as productive as possible is the number one goal.

[0:15:00] SF: Yes. I mean, I think there's something to be said about, if you focus on hiring quality people, and you're always going to have hits and misses with that regardless of how much time you spend on that vetting process. But if you can hire really good people and then sort of give them an environment for them to be successful, then you hopefully get the best of those people, essentially, because they're being set up for success where they like coming to work. And if they like solving problems and challenges, they'll be motivated by that more than you cracking the whip and stuff like that.

[0:15:33] DF: Totally.

[0:15:34] SF: The other thing, I think, especially with startups, we can sometimes get a little overly focused on certain KPIs and North Star metrics and all these types of things where if you're a small company, you're 10 people, you're a 100 people, like it's generally pretty transparent, I think, whether people are being productive or not. Are they contributing in a way that's having impact? That's the beauty of the startup is, regardless of what level you're hired into, you have the potential essentially to have company-level impact. But also, that transparency goes two ways. People can see the great work that you're doing and they can also see when you're not contributing essentially at that level.

[0:16:09] DF: I totally agree.

[0:16:10] SF: In terms of measurements, there's different extremes, obviously. We can have everyone have monitoring tools on them and shut down chat. I've heard a company's doing things like that. But there's that extreme, but the other thing is we tend to optimize, I think, the things that we measure and we have to be careful about what those measurements are as a result of it. But if I'm a person within a company and I don't really know the expectations of what I should be doing, then that can also lead to problems in this alignment where I might think, "Oh, my God. I'm doing a great job. I'm putting a ton of work in." But if they're misaligned with the expectations, then that's also a problem.

I guess that goes back to your sort of, what you're saying around communication and making sure that people feel supported and there's a two-way communication. So, would you say from a productivity standpoint and even from like a measurement standpoint, the thing that you should be focusing on is how many of those communication touchpoints you have. Do you have visibility into what everybody's doing work-wise based on their qualitative feedback about what they're contributing?

[0:17:14] DF: I do think communication is huge and I can't say that enough. Going into the earlier part of your question about like the one end of the spectrum, monitoring tools. I just want to get it out there and say like I really don't think that you can monitor anything you want, but I really don't think that anyone should be monitoring silly things like keyboard activity or screenshotting people's screens or any of that silly stuff. It's going to weird most developers out, even though the market may have shifted a little bit, more to a hirer's market. But people still have a choice where they want to work and they don't want to work in a big brother-type environment.

What I think is totally fair to measure is like things that correlate with what their actual job is. If your job is to add new features to our application, then maybe it is a fair metric to say like, "How many story points did you accomplish in this month?" No metric is going to be perfect, and there's flaws in that because that story didn't get estimated correctly, or you changed the requirements midway through the task, and that slowed me down. I don't think these metrics should be used frequently, honestly.

I see these detailed metrics as something that are looked at with a grain of salt, maybe in certain problem situations, they can be really useful. We have a tool internally that we just created that makes it really quick and easy to correlate someone's git activity with their hours. Do I think that that's a good way to measure someone's productivity? No, I do not. But it's really convenient if a client says to me, like, "Hey, I'm having some doubts about Marco's work output over the past three weeks. I don't feel like I'm getting much out of him." We can quickly look and be like, "All right, well, it looks like, yes, Marco still logged about eight hours a day, and like, his commit frequency went way down, and his insertions went down."

We could see like, "Okay, there might be a problem here. But I don't think you should ever just look at those metrics and judge someone." It's just, they can be wildly off. Someone just happened to get a task that required including a new library in the app and they're going to get 10,000 insertions on one day. It doesn't make sense. But I think that having metrics like story points in a month that were, okay, maybe you had a slow day or a slow week, no one's perfect. But if you look over time and you see, okay, this is what you did in a month and you can check that over the course of a year, that's your job. I don't think anyone can argue with that.

Other more small metrics can help be useful more to catch problems. Maybe early on with the developer who's trying to just game the system. They're saying, "Yes, I have plenty of time," but they're really trying to take two or three jobs at once and just work the system and they're not really working. Okay, you could catch that.

[0:20:37] SF: Yes. I mean, I think that it's important to probably combine qualitative with the quantitative feedback. You can use these metrics to get a pulse on what people are contributing, especially over time, if you're looking at it on a week-by-week basis. You're going to have that wall of small numbers, variance, where maybe something just took an inordinately large amount of time compared to the original estimate, because of unforeseen factors or something like that. But that should average out over time, but you also need to take into account, dig into the details and find out from those people what's actually happening through conversation and don't just take the metrics, essentially, as the peer review of what their performance is like.

How much do you think things like peer-reviewing also should play a factor in this?

[0:21:21] DF: Well, you mean like peer review of like, as far as performance or like code reviews?

[0:21:27] SF: Of performance. 

[0:21:30] DF: To be honest, I hadn't really thought much about that. Seems like it could, on one hand be an interesting thing. On the other hand, it could lead to a little, if that was a known practice on a team, it could lead to a little distrust or a little bit of anxiety. Like, "Oh, I'm going to be sort of judged by my peers." I don't know what that would do to a team morale. I haven't been on a team where we've done that. Have you?

[0:21:57] SF: Yes, at Google, that was standard practice during performance reviews. You have essentially peers review you and then your manager reviews you as well, and you also review your managers and peers, essentially. But I do think that in some ways on paper, it seems like a good idea because it's like, well, if this person is respected by their peers, like clearly that's like a good thing, right? They're basically evaluated on different types of both qualitative and quantitative measurements.

But I think the challenge there is you select your peers. So, presumably, you're going to select peers that are probably going to give you a decent review.

[0:22:30] DF: You got to choose who reviewed you?

[0:22:32] SF: Yes.

[0:22:32] DF: Okay.

[0:22:33] SF: Exactly. So, there's a certain amount of like gamification there. Then, I also think that most people in that position don't necessarily want to be mean to somebody and give them the true response. Whereas like a manager, you're taking on, like part of your job is to take on the responsibilities sometimes making hard decisions and also giving hard feedback at times. But it's like, "I'm your friend on the team. Do I really want to be put in that position?" Where I'm like, "Oh, Damien's a nice guy, but his code quality is terrible."

[0:23:04] DF: I haven't done that, no. 

[0:23:08] SF: What about, one of the other things that's happened a lot in the last couple of years is more and more companies have gone distributed. They're either fully remote. Maybe they're hybrid. Some of the big tech companies are trying to pull people back into the office. What are your thoughts on that in terms of developer productivity and also hiring?

[0:23:24] DF: It's actually been like 14 years since I worked in a traditional physical office since I started this company. But thinking back to then, even when I was managing a team of five developers, and even then, I don't really think being in the office helped me judge their performance. We were still kind of all just at our desk or in our cube. And even when we would meet, someone could be like 50 feet away from me and I would still like get on a Zoom with them with the client.

So, I'm not sure that I think it changes much. I think it might - this more distributed remote world, which I'm a huge fan of, might actually help us just focus more on what is actually important, which I said before, which is like, what is your job and what really matters, which is how much value you're producing for the company and how do we measure that? Okay. Well, one of the best metrics I can come up with is how many features or story points you've delivered in a month.

When you're remote, you're forced to let some of these, maybe, or not even beneficial ways of evaluating people that go away. We might have judged someone before on like, "Okay, when did you get into the office and when did you leave?" Or, "How much do I see you typing at your desk or how much do I just like hanging out with you?" How much would that influence me as a manager and wanting to keep you on the team or whatever? Some of these things that might be lazy ways of evaluation that we could get sucked into more easily in an office environment. We don't have the benefit of those easy human cues. So, we're forced to be more rigorous maybe in how we're evaluating people. So, I think you should probably follow those more rigorous techniques, even if you are in the office.

[0:25:33] SF: Yes. I mean, there's certain advantages of remote. You can ignore them, but ideally, it forces you to be a little bit more thoughtful about how maybe you measure, but also how you communicate. If you're doing remote properly, you should really focus on probably doing like a lot of in-communication where you're able to do asynchronous rather than - because you can't rely on going and sort of tapping someone on the shoulder to have a conversation with them.

But what about culturally? A big part of performance is also how good I feel about a company. If I'm really - just things become transactional, because I'm interacting with people want to resume, I may be being just working through my KanbanFlow or whatever, Sprint, my tickets. What's the difference between working for company A versus company B? It becomes your little bit of a mercenary if you don't have that connected tissue to the company. How should remote companies think about that kind of stuff?

[0:26:29] DF: Well, I said before, you should just hire good people and then do whatever you can to help make them productive. I'll go to the next step now and say my opinion on what I think the thing you should focus on is to help make people productive. Because there's a lot of stuff out there, as we all know, on how to make a team more productive, like agile techniques, project management, software. There's all kinds of stuff out there. But one thing that's not talked about much, which I think is kind of a fun way to look at it too, is just try to optimize the developer happiness. A lot of other things will just flow from that.

There's some basic stuff like, okay, pay them well. Don't overwork them. It's not sustainable. Then you get into culture, company culture. There's some things in company culture that work just as well in person versus remote. Those are really important things. Do you have a culture that's about trust and collaboration and compassion? That doesn't matter if you're in the office or not. Or are you like a command and control, like militaristic kind of organization? I vote for the former. I think you're going to get happier people who want to be there and more productivity because of that.

There are some things that are a little bit harder that we all know, like team building. Getting people to like connect and get to know each other. You have to make an extra effort remote. We do some just silly things like once a year we'll do like a virtual escape room or get everyone on a Zoom and play Wheel of Fortune or just Pictionary. It's dorky and it's weird, but people like it and I think it's worthwhile. So, you can make an effort to have a culture and get people together and do some team building remotely.

One of the most important things I think about making developers happy, and I think you actually said something about this before. If an engineer loves solving problems, just let them do that. One thing we haven't really gotten into is like with monitoring and performance monitoring. There's all these like frameworks, like there's the DORA framework, there's the SPACE framework, the DevEx framework, there's something called CALMS. There's all these things you can read about and dive into and they're interesting.

But I can't remember which one of them I was reading about, but there's a concept of like the developers inner loop and their outer loop. Are you familiar with this?

[0:29:18] SF: No, I haven't heard of that.

[0:29:20] DF: The inner loop is stuff that they like to do and they need to do, like architecting what they're going to do and thinking about that. Then, coding the solution and then debugging it. Just really core stuff, like deploying. Actually, deploy is actually kind of an outer loop thing. Outer loop is everything that's like, sometimes you need to do, but sometimes you do too much of it and it takes too much time and you need to get that off of their plate, like unnecessary meetings, like really slow deploys, or really slow test suites, or like really slow feedback cycles from code reviews, or just all this kind of stuff that developers just gets in their way of doing the stuff that they want to be doing and that they actually like. That's really important.

So, the more we can just focus on getting them doing the stuff they like, and we'll naturally make our team more efficient. I'll just say it again, communication, because it's not just communication like, "Hey, let's have a daily scrum," or as you said, like really well-defined tasks. If you just tell a developer like, "Oh yes, I want this," and just give one sentence, that can be frustrating. Really define what it is this feature is going to be that they're going to be working on.

But also, one of these frameworks I mentioned DevEx is short for developer experience is like the core of what they're saying is like, "Talk to your developers." One thing that we do that comes out of this whole framework you may have heard of called EOS. It's called the entrepreneurial operating system. It's just a bunch of business best practices. You do a quarterly or biannual, just check in. How are you doing? Do you like your job? What's annoying you? What do you like? Talking to them and asking them, and then in DevEx, they'll do surveys where they survey the Dev team. What's making your job more difficult? And just really asking them. Then, you're going to get it like, "Okay, how can we optimize their happiness?" One thing we haven't really said is when you're measuring performance, you're not just measuring the individual, but you're measuring the team. Because what you really want is a highly functional team, and that's what's going to deliver value for your company. You do want to look at individuals, but you also want to look at the team as a whole.

A lot of those frameworks that I mentioned, DORA, SPACE, DevEx, they're about optimizing your team and how all the different people interact and how that interacts with your DevOps processes. Yes, that's a whole other thing. That's a whole other topic that we could dig into if we want.

[0:32:05] SF: Yes. I like the idea of this sort of inner or outer rims framework. You're talking this kind of almost like, it's like the Maslow's Hierarchy of needs but for like developers. You could almost come up with, if your focal point is we're going to optimize for developer happiness, then a lot of it would be, like, let's figure out how do we reduce the time spent in the outer band and increase the inner circle, and see essentially what impact that on productivity and happiness. I do think it's really important to essentially ask for feedback in an anonymous way, take a pulse on how you're doing either as a functional area, or as a company, and get people's feedback. How can we improve? What are you happy - basically, like CSAT that you would do for your customers, but for your employees. Because if you're not really doing that with intention, you're not going to make those improvements.

Just like in office world, certain things are easy to become reliant on and you have to work harder for certain things. In remote, it's also that way, but some of those things are kind of in reverse where team building is harder to do in a remote world. You have to be a little bit more intentional about it. But it doesn't mean that's impossible to do it, and you just have to be thinking about that stuff upfront and make it important to your company.

[0:33:22] DF: I agree.

[0:33:24] SF: One thing I've thought a little bit about is do you think there's opportunities to introduce like some form of gamification into improving developer productivity? Because if you look at sales teams, there is a tremendous amount of tooling and effort that goes into both, they're tracking a lot of activity, calls, emails, all this type of stuff, which I don't think necessarily would translate that well to engineers. I mean, there is a certain act. We know commits, lines written, codes written, features shipped, all that kind of stuff. But there's a lot, especially in SER organizations around sort of keeping people motivated, gamification, competing against each other, but in a friendly way. Do you think that there's opportunities within engineering organizations to do something similar?

[0:34:11] DF: Potentially, yes. I'm trying to think about it here as you were talking about it. You'd want to be real careful about code quality, I think, because I don't think we actually stopped into really define what we mean by developer productivity. I was thinking about it a bit. One thing I've said multiple times in this talk is like, how many features is someone delivering over a period of time? But then code quality is huge too. It's like, you could deliver 10 features, but if 5 of those had bugs and need to come back and, that's also super important, right? Then, how people are collaborating with each other and interacting, I think, is a big part of team productivity.

But you'd have to be really careful, I think, if you were just saying, "Okay, who can get the most story points this month." I think you'd have to factor in code quality. That'd be an interesting thing. You could make some - you'd have a metrics that handle both. It wasn't just about how much you can put out there, but it also, after that, like, okay, you might get docked for bugs. But yes, I think it could work.

[0:35:28] SF: I mean, it's kind of like a singular metric is not going to work. If you are looking at lines of code written or something like that, well, all right, well, I know how to gamify this. You can create some really poorly written code that -

[0:35:42] DF: I mean, terrible.

[0:35:45] SF: Or the joke we used to make at Google sometimes was around, because so much was focused on impact, from quarter to quarter, it's like you could implement one feature, but intentionally implement it in an unoptimized way and then come back to the next quarter and be like, "Oh, look. I fixed this code. I improved performance, a hundred X and stuff." But basically, do it by design. People will come up with all kinds of creative ways of gamifying metrics if you put those things in there. I think that also goes back to some of the things we were talking about earlier where you can't rely on these solely. You have to also look at it qualitatively.

[0:36:19] DF: It's totally secondary. It's got to be qualitative first. In order to be qualitative and get this sort of Zen gut feeling about your team that's accurate, you have to have - you can't just be a distant manager or a distant participant. You really have to get into it and be talking to people and seeing the day to day. That takes work. I think a lot of product owners and entrepreneurs don't know and want or have the time to really do that. That is the hard part of it, to get into it and stay with it. But if you do, I think you'll usually be right in your gut feelings. Who's doing a good job? Who's not? What part of our development process is the bottleneck that needs to be improved? You probably won't need metrics. You'll just know, but you'll have to put in the time.

[0:37:22] SF: Yes. Definitely. Well said. As we look beyond where we are today, how do you think tech hiring might change engineering hire in the next five years? Or is there going to be a change at all?

[0:37:34] DF: I mean, the first thing that comes to mind is AI. I think for us as a company right now, we don't think it can do as good of a job for the actual decision-making. Who should get presented to a client or who should get hired? I'm not comfortable leaving that up to an algorithm or AI. I think a lot more people are going to be using that. It's such a buzzword. It's hard to know what people are really using AI for. But one thing that we are looking at and we haven't implemented yet is just maybe earlier on in the process. Right now, people apply and then we do a screening interview. I think you could implement maybe AI earlier in the process of the hiring pipeline, if you will, in the sourcing and the initial screenings. You could save some time and money potentially using AI there, but I definitely don't think we're there yet with making decisions. Because I don't know if an AI and detect BS yet, as well as a human.

[0:38:50] SF: Could it generate?

[0:38:52] DF: Yes. I'm not putting anything past AI. I mean, I'm very open to where this goes because maybe it will. I don't know, it is a little bit sad, I guess, just the loss of personal touch that this could mean long term, and I think we're still trying to hold on to it, because I think I personally enjoy actually talking to a client and really like using my experience and our framework to like define what they need. I think that's the most important thing in the whole process is like the job description. It's like the requirements document for software is like - the job description is the requirements document for the hiring process and you really got to nail that and get that right.

I think sometimes people are just like, "Oh, yes. We'll just write up a JD. Copy that other one we had. And there's all this sort of fluff in there, like team player of working in a fast-paced environment, all this stuff that just doesn't mean anything in there," and just writing a really good job description and people trying to do that with AI now. You're going to end up with crap. I think that having a human involved in that, having a human involved with talking to candidates, it's going to make people feel valued, and I think that's going to make a better experience for both the clients and developers. But yes, that's what I think might change. You'll see more of that in the market and I think that we're going to probably continue to buck that trend and keep it more human.

[0:40:38] SF: Damien, it's been fantastic having you on the show. Thanks for coming by. I enjoyed the conversation.

[0:40:43] DF: Thank you.

[0:40:44] SF: Cheers.

[END]