The Ksense Technology Podcast

Kelson:
Nobody would call up their handyman to have them build a house.

Calvin: And then by the time you've maximized the improvements you can make, a new technology then arrives that makes those old improvements obsolete.

David: It's like trying to beat a Pokemon game with only the Pokemon that you caught in your hometown. Welcome, everybody. I'm here with Kelsen and Calvin from KSense Technology Group. Kelsen is the CEO and Calvin's the COO. And together they run a really successful software team that provides business tools and software for all kinds of organizations. So today I'm really excited to talk about the pros and cons of outsourcing, outsourcing your software development projects versus hiring your own internal team to complete those projects. So my first question for you guys is what are the primary differences between outsourcing and in-house development?

Kelson: I think we should start by outlining exactly what each of those things mean, right? What does it mean to outsource and what does it mean to in-house development? Like, what does that mean? Outsourcing is where you find an agency or somebody who's already developed a team of experts and you pay them for your needs. In-house development is where you find all of the team members individually, you bring them into your office or work remote with them, and you are in charge of managing them on a day-to-day basis. And I think the biggest difference between the two, or one of the biggest differences, I should say, is the amount of effort that it takes. With outsourcing, a lot of times you're talking with one or two individuals, whereas an in-house team, the workload is substantial. You need to hire people. You need to set them up in your HR payroll. You need to onboard them into all of your systems. And then you need to train them, upskill them, micromanage them, and everything that you would expect with an employee. Whereas outsourcing, really, you don't have to worry about that. And so I think that is a pretty good contrast between the two. That doesn't mean that one is inherently better than the other, but there is definitely a big difference in workload.

Calvin: Yeah. With every team or with every software project, somebody is going to need to know how to figure out the process that these developers need to go through the requirements, you know, how to organize their work, how to make sure everyone knows what they're supposed to be doing and that the product is getting designed, built, tested, deployed, all that stuff. So whether you have an in-house or an out or an outsourced team, Someone is going to need to do that, which means you're going to need high level expertise somewhere. So to get that from an outsourced team, if you hire an agency, for example, maybe that agency has, you know, CTO level, like really high level people who've designed a system for building web apps. If you hire someone on Upwork, maybe they're a senior engineer that's been working for 15 years on web apps, and so they know what they're doing by themselves. And if you hire an in-house team, maybe you hire a project manager, and then a DevOps person, and then you hire developers themselves. And so between all those people that you hire, you are able to have the skill sets you need. Um, but with the in-house team, the business is responsible for setting up those systems. You know, somebody is going to need to figure out exactly how that team needs to run. It's a whole, you can think of it as a whole kind of department, you know, like some, if it's a one man department, it's still a department. That one guy needs to know everything. It needs to, he needs to know how to deploy, how to do DevOps work, how to do web development, and also how to understand what requirements you need for your features and to translate those into code. and to make sure that those work for stakeholders. So yeah, there's pros and cons and it depends on your individual situation. Either way, there's no getting out of the fact that someone's going to need to know what they're doing and someone's going to need to have a high level view on the project and how it's going to be built.

Kelson: Yeah, and I think there's a pretty big misconception when it comes to building software. A lot of times people think that they can just get one guy. And that might work for a really small module that somebody's building, but larger applications or applications that need to be really durable and reliable and efficient, it just doesn't work. You know, nobody would call up their handyman to have them build a house, right? You need an architect, you need the specialty of how to lay the foundation. You have all these different guys and you see it when you go and look at a construction site, how many different individuals there are, how many different hard hats we have of specialties. And the same thing is especially true in development. I've been writing my own code and been a lead engineer for quite a while, and I don't know half of the stuff that my DevOps team does. When it comes time to deploy the application and keep it up, I'm very inexperienced in all of those technologies and things that are required. And I could go on and on about the gaps of my knowledge. And so, you know, it's important to realize that building reliable and good software, whether you decide to outsource or build an in-house team, you're going to need a team of experts in order to do it the right way. And so that's just something that is really important to keep in the back of your mind through the rest of this conversation.

Calvin: If you're going to hire one person, the closest you're going to get is basically hiring a CTO and then letting that person go and build a team, or maybe they can outsource what they need to outsource. But those people that are able to do that, obviously they're going to be very expensive employees because they have those skill sets. You know, anyone who can bring an app to market and knows everything there is to know about building a software project and managing a team, they're going to be kind of the top of the food chain in terms of like people who you might be able to hire for that.

David: Yeah, makes sense. And so, you know, the question, what are the differences between outsourcing or hiring your own team? I'm hearing, you know, pros and cons. You know, it could be more expensive to hire your own team. It could be more expensive to outsource. Uh, how do those costs compare between outsourcing versus having your own in-house team?

Calvin: Well, uh, let's break it down by function. Like what does, what are all the different things a team needs to do? And for each of those skill sets, it's going to cost something, right? You're going to have to get an expert that knows how to do that thing. So one of the things that people often overlook is basically business analysis or planning. Uh, and that kind of ties hand in hand with UX UI design, basically understanding the business's problem at a deep level, and then understanding how to translate that problem into requirements. and into some language, whether it be user stories, tasks, whatnot, that developers can take and build a software, build an app with, right? So that's one part of it. Then the next part is obviously writing the code, right? You sit down and actually have to write the code. You have to initialize the app. You have to set up all the pages and all the functions and everything like that. That's the bulk of the development work. But then developers will be completely lost most of the time when it gets to actually deploying that app, actually working with Amazon Web Services, actually hosting the app. So that's a whole nother chunk. That's actually a separate job description called DevOps. And so those are, I'd say the main three things. So the question is, okay, how much does each of those cost? And I'd say out of those three things, the least expensive one, it might be surprising actually, but the least expensive one is probably writing the code. Um, that's the easiest one to find as someone who can write the code. Now, if they're, whether they're going to do it really, really well is another question. I mean, you're going to get what you pay for, but you can find people who can write code. So if you are trying to think about, okay, how much is it going to cost me to build an app? You got to know, okay, where am I going to find. the, all three of those pieces and how much am I going to pay for those? If you have someone on your team who can do the first part, who can do the business analysis and who can plan the features and, and, uh, who can look at the result and test the app and say, actually, this UI isn't great. Let's redo that. Let's redesign this. Um, then you just took one third of the cost out of the equation that you can have someone in your, on your team do. So that's in, that is in-house development. If you have a business analyst on your team, you're running partly an in-house development process, right? So that's where it comes down to, okay, which of these pieces are we going to outsource and which of these pieces can someone on our team do to make the project go well?

Kelson: I think that when you ask how do the costs compare between the two, it's not exactly apples to apples. Because there's a lot of distinction when it comes to caliber, right? You could have an in-house team that you hire and every one of the engineers is from MIT versus a offshore development company. And the, the in-house team's always going to be more expensive, or you can flip it on your head on its head. Right. And you can make an in-house team and hire all the offshore guys. remote and, and then your outsource could be a team of highly skilled people. And so it's difficult to compare the costs directly. And it's very difficult to know which one's going to be cheaper. Um, and so really if you compare the, the caliber, the, the level of talent, that's a good way to start the comparison, but there's also, Differences in costs when it comes to hiring, like the time it takes to hire the entire team. You're also paying payroll taxes that you wouldn't on the outsource team. But there's different benefits that come along sometimes with having the in-house development team. I'd say, especially in the situation where you have a really good lead who knows how to run a team. But yeah, it's difficult, I'd say, to directly compare the costs. And so what I think you would need to do is you would need to evaluate an outsource team, evaluate their costs directly. And then also evaluate what it would cost to do the in-house team, calculating in everything from employee turnover and all of that into your calculations, and then compare those two. And that's how you would be able to compare it. Otherwise, it's incredibly difficult.

Calvin: Yeah. And also not all costs are straightforward in terms of a dollar amount. Like if you're going to build an in-house team, you're going to be putting out job posts, right? You're going to be conducting interviews. You're going to be doing, you know, designing an interview process to try to narrow down the 600 candidates that you get to 10 candidates that you actually want to interview. Then, um, that when you bring them on, you're going to be training them. Uh, so they understand your process. Um, you're going, if you're going to be doing the business analysis, yourself you're going to be spending a lot more time trying to do design thinking and design work right so there's all these costs and a lot of them are also time related like how much time do you have maybe your coo is at the level where they can lead a software team but do they have time to do that and how much is their time worth that's also a factor when thinking about costs like If you're just looking at total dollars spent in-house versus outsourcing, sometimes if, if you just need to hire one person or something, it might say, it might seem like, okay, it's actually a lot cheaper to do this, uh, versus an agent, a full service agency. But if you factor in your time and you factor in, uh, the cost of learning, like if you're going to run an in-house team, you're going to go through a learning curve as a business. Like there's a lot of different things you're gonna have to build systems. Like you're gonna. have to basically learn how to, like really it's learning how to run an entire business, like an entire software development production line. So what's the cost of that learning? How, how much trial and error are you going to go through to figure out how to run that team effectively and get the good result from them? Right? So there's a lot of different costs that you may not consider up front.

Kelson: That's right. And if your COO has to spend all of their time managing this new software team, then it might be worth it to just bite the bullet, spend a little bit more money on the outsource team so that your COO can focus on, on what he's best at. Right.

David: Great. So that makes sense. So we're, we're getting a clearer comparison now. Um, I want to ask again, pros and cons and this time around risks. What are the risks that are associated with hiring an outside agency and what are the risks of hiring your own internal team?

Calvin: So the risks of hiring, let's just say anybody that's not in your company, like there's separate risks depending on who you hire from the outside too. So just taking your company first, like if you're going to hire an employee, the risks associated with that are going to be number one, can you find someone who's good? Do you have an interview process that is going to allow you, if you don't have a technical background in development, how are you going to evaluate candidates to see if they know what they're talking about and if they know how to write good code, right? So can you find someone who's good? you know, how long is that process going to take? You might be risking your time, you know, training and, uh, upfront investment, hiring an employee is a very expensive upfront investment. You know, like you're risking the money now to try and, and invest in an asset basically, right. An employee who you're going to need to train, you're going to need to have systems in place for them and you're going to need to, to organize their work. So that's really the risk of hiring internal also sometimes, uh, with employees. and with internal teams in general there can be a risk of sort of like of the metrics not being quite right to encourage results so let's say like if you have a team who sort of you know they're they're getting stuff done they're working on stuff but it's like there's no incentive to really produce massive results right now. Like they, maybe there's, it's more of a bureaucratic situation where, okay, as long as the monthly reports look good, everything's good, but we, we ended up not making very much progress. Right. Like there's, there's basically a whole nother side of it where you have to figure out, okay, how do we make sure that our internal teams are being efficient with their time and getting stuff done like effectively. Right. So that's another risk for an internal team. Now for the external teams, like there's a few different types. I mean, you could hire a freelancer. Um, you could hire an agency. Uh, you could hire a team of freelancers, right? So, or you could go through a staffing company that specializes in doing like near shore, uh, staffing. They get software development students out of the universities in, in Brazil. And you know, they, they, you let you hire those people, right? So there's various levels of cost and there's various levels of risk. So if you pay one of the top staffing companies to get you near shore developers, they are going to charge you a lot more money. So the risk is you're paying more money for a, for a higher quality developer. The benefit is that if you don't like that developer, they'll switch out, they'll switch it out for you. Um, and get you another developer, right? And no, no extra costs. So like, The risk there is more in how much money you're going to burn through before you find somebody good. Same with a freelancer. Your risk is that, again, how do you know they're good? How do you know they know what they're doing? If you're not technical yourself, how do you know how to evaluate an individual developer? So then you look at an agency. Okay. Well, the agency takes on that risk. They're the ones that hire the developers. They're the ones that have the processes in place. They're answerable to you. They have to provide results for you. Uh, and they have to have a system to do that. So with the agency, the risk you're taking is. Is that your, maybe your incentives don't quite align with their incentives, right? So the agency is incentivized to make as much money as possible. They're incentivized to. have a factory that produces software for their clients and they're incentivized to keep their clients satisfied. However, maybe the agency is hiring lower, like they're hiring some junior developers and so they're going to put some of those people on your project because, you know, they have to put them on someone's project. So how do you know that that agency is putting their best people on your project? Or how do you know that the agency is providing the very best service that they can for you? So your risk there is like, how do you know we're not just getting put in a box that works really well for this agency and works well for their business model, but doesn't really work the best for us getting the best return on our investment? So there's sort of a risk with that. So I hope that makes sense. That's kind of how I think about the risk. between the different options.

Kelson: Yeah, I don't know how much you touched on the quality risk as well, because I've seen a lot of difference in quality when it comes to outsourcing versus in-house development. I think one of the major benefits, and it's not always the case, but sometimes it's the case where if you have an in-house development team, and you have the correct oversight in place, a lot of times you'll end up with better quality just because the incentive for the employees there is kind of the long-term benefit of the organization, right? An employee goes into work and they set things up the right way. And the only reason for that is because a lot of the outsourced agencies, or even freelancers, it's kind of a one and done thing for them a lot of times. You go to them with your project, they'll scope the whole thing out, they'll give you a dollar amount for the whole project. And then from there, their incentive is set up to where they want to build it as quickly and cheaply as possible. That's why I think when you're doing the evaluation, you need to find an agency. If you're considering looking for an agency, you need to find one that is aligned with the long-term success of your organization. And flat rate prices for the whole project are not that. They're not, it's not, that's not set up in a way that aligns well. And that's why here at KSense, we, we don't do it that way. We do one sprint at a time. A sprint is a short amount of development work, just a couple of weeks. And then we deliver the software to you where you can look at it, make sure it aligns with your vision. And then we rinse and repeat over and over and over again. And So instead of having one price for the whole project, and instead of trying to build it as quickly as possible, we're trying to set it up the best way. And so when you're looking for an agency, look for one where they're charging for time and resources, as opposed to project or value-based pricing, because the value will align a lot more heavily there for you. As far as in-house development goes, if you are a solo leader, like you don't have an executive team. And if you don't, especially if you don't have any experts in development, if you don't understand the development process, do not set up an in-house team. I've never seen it go well, and it's not going to go well for you.

Calvin: If you think about it from an eight, like let's take two agencies as an example, uh, and look at their incentives and how those align with your incentives. If you have an agency, who's giving you, they're saying, okay, yeah, we're going to build your entire app for this price, this fixed price. It's like, they're not going to be able to stay in business. unless they can guarantee themselves that they're not going to be doing free work, right? If they're promising you a price, they need to make sure that the cost of development that they have to pay for, for the developers and for the infrastructure and everything else, is less than the price they quoted you. And because software development is inherently It's inherently not possible to really predict how long things take because it's engineering work because it's basically you're building something that hasn't necessarily been built exactly that way before. So you have to basically do design engineering work and then you have to keep changing the product over and over again to align and to fit it to that specific company's process and make sure they really like using it and everything. The only way they can really do that is they're going to double or triple the price and they're thinking, well, the chances are we're actually going to make more money by doubling or tripling the price because it may take one and a half times what we think it's going to take or two times what we think it's going to take. But we can pretty confidently say that if we triple the price, we'll be making a good profit margin. You may think that if they do that, they probably, okay. They probably know for a fact, that's not going to be more than triple, right? Like they they've probably at least figured that out. No, actually they may either be unexperienced or they may have, they may have some other reasons for this, but it's very possible that it will end up taking longer. And then they'll, they maybe just dump the project at that point, because basically once it gets to the point where they're no longer making money, where they've capped out. the price they gave you, either they're going to dump you as a client or they're going to come back to you and say, we need more money. In either case, they're incentivized to cut corners to make sure that like, from your perspective, you don't know how good, like the code quality doesn't necessarily matter to like, you can't see it, right. It matters, but you can't see it as a business owner. So like it's, it makes total sense for them. Cut, cut, cut quality, cut costs. And that way we can give you more, we can give you double the results in a month than you would get otherwise. And then it looks a lot better for you. But then in a year, going back and working on that code again is going to cost you twice as much because they cut quality, they cut corners, because they were trying to hit a certain deadline or a certain price that they promised you. That's the incentives that an agency like that might have. And as you can see, it might not be great for you if that's what they're doing. So take a different agency that takes this approach. It says, you know, we know that it's not possible to predict how long software projects are going to take. In fact, we know that software projects are never finished because is Facebook finished right now? Like they were invented in like what, 2007 or something. They still have hundreds or thousands of developers right as we speak coding, writing code for Facebook. It's never finished, right? Because you can always improve something. And then by the time you've maximized the improvements you can make, A new technology then arrives that makes those old improvements obsolete. So you're going in a cycle. It's kind of like the highway system. Like you're never going to not have any construction on the highway because by the time they finish that, the entire highway, you know, making it nice and new, the very first part they were working on is now crumbling again. So they got to redo it. Right. So it's like a software projects never finished. So what if an agency decided instead, what we're going to do is we're going to. Really just treat this like that. We're going to be with this client for 10 years. You know, this is, we're basically going to be partners with this client. We're going to be working with them for the foreseeable future. So what we're going to do is we are going to maximize quality. We're going to make sure the code base is as good as possible because we're the ones that are going to be working on it for 10 years. And we want to make sure that we maximize the value we can deliver. We're just going to charge an hourly price because then that's completely fair for every time we do work. We charge the same amount for it. We're not jacking up the price. We're not cutting the price in half. Um, so that we're doing free work. We're just charging a nice standard rate and we're basically acting as a partner to that company for the longterm. And that's really the incentive structure that you want to look for with an agency, which will reduce your risk. Uh, if you're looking at hiring an agency for a project like this.

Kelson: One massive risk that a lot of business owners don't realize when it comes to outsourcing is if you decide to hire nearshore or offshore, there is no legal contract that says that they have to keep your data secure. So if you are going to go with an agency, make sure you go with one where you are able to sign a confidentiality agreement with them to where they can't use your data. This is your user's login, your website visitors, your financial data, all the data that goes into your apps. They can leak it. They can do whatever they want with it. And there's no legal recourse for you.

David: I mean, I guess that makes sense, right? Like if they're in another country, it's going to be really hard to pursue any sort of legal action. Yeah. Good luck. OK, so that makes sense. We're getting a clear picture of kind of the risks that are associated with either option. Let's let's talk about quality. That's kind of associated with risks. But how does the quality of work compare? You mentioned that when you're outsourcing, a lot of times you deal with quality issues. How do you avoid that when you're outsourcing? Or is it just always the case that if you outsource, the quality is going to suffer?

Calvin: Quality is a system that is built into the development process. Quality is built in. So the way that you can reduce the risk of low quality is make sure that whoever's working on your development process is building in the safeguards and the standard operating procedures to make sure that that quality is just part of the process. The way to prevent bad quality is not to go back after the fact and comb through the app and find all the bugs. That's like the worst way to do it. Um, even though testing is good, you know, it's a good last resort, but really the way to get good quality is to build it into the process from the start. So if you're doing it, if you're outsourcing, it's difficult to try and police the quality. If you, if no one in your organization has the expertise to look at code and determine quality. So one thing you might be able to do if you're going to outsource, is you could hire someone to, um, to check the quality separately as someone who's writing the code. That way you have, you know, this person that's you hired for the, to check the quality, maybe you hire a tester, like a technical tester that can actually write tests and can actually go through the code base. Like that person, they're fully incentivized to do nothing but, but improve the quality. Right. So you can rely on that. And then that other team that's doing the coding, you know, they're, they're going to be held in check by that person you hire. Uh, or if you hire an agency, you got to make sure that you understand what their process is, because it's the same with agency, right? Like an agency can have a really bad process. because they don't care about quality because they're not really, depending on what their business model is, they might be looking to burn through projects. They might make all their money in the first year and then kind of let the project die off and get another one in. So in order to understand the quality, you really got to interrogate the process and say, okay, what is your process for quality? How do we know What the quality is going to be. Can you show us what you do to improve quality and what are your, like, if you understand their business model and their pricing model, you get a better idea of what their incentives are. Like, are they trying to be your partner for 10 years or are they trying to turn and burn, you know? So that's how I think about quality.

Kelson: And one misconception that we might add is that just by looking at the finished product doesn't tell you what the quality of the work is. You can have a very, very poorly built application that does all it needs to do. And every time there's been a bug, somebody has gone in there with duct tape and they fixed it. And so after so many iterations of that, it's a dumpster fire of an application. Nobody wants to touch it. because every time somebody touches it, it breaks, but it works. And so if you try to evaluate the quality just based on what you're able to see in the user interface, that's not the whole picture. You need to take a look at the code, say, what's the code hygiene look like? What does the testing process look like? Is this modular? What versions of the technology are we on? Do we have all of the security patches in place? There's a whole bunch of different questions that need to be asked, not just looking at the final product.

Calvin: If you've ever hired an agency or a developer and that agency or developer has delivered low quality on a regular basis, You're likely going to feel it because you're going to think to yourself, how is it possible that this app is this broken this often? Like you're basically going to tell them to fix something. They're going to go fix it. And then the next week, that same thing is going to break again because there's no good process for. Like the app gets complex, right? It's very, very complex. You change one thing over here. It can affect 10 things over here. It's not going to be something that. is super difficult to see. I mean, it is possible to have nothing break on the front end and still have really low quality. And in that case, the biggest downside, you may be wondering, well, what does it matter then? Well, the biggest downside is when anyone goes to try to add a new feature to that app, it's going to triple the amount of time that takes and increase the likelihood that adding a new feature breaks the app, right? So that's why quality actually matters, even though it doesn't affect you. But I think you'll be able to tell often after a few months of development, especially if really the thing also you need to know is that it's very, very hard to tell if you don't have your people, your users in the app using it. Like the worst thing is when you spend a year having someone build an app and then when it finally comes time to deliver it, that's when you, that's when you actually see the Um, you know, the, that the quality is really bad because that's the first time you've had someone in there to use it. Right. So I would recommend have people in the app as early as humanly possible using it, actually using it. Right. And that, that also ties into how the app is built and designed design the app so that you can use that app from the first month. So that you're building an, a module that you can start using. And then, you know, once people are using that module, it's a minimum viable product. then add another piece and another piece and another piece, but use it from the beginning. And that will really help with quality.

Kelson: Yeah, there's kind of a couple different camps when it comes to development methodologies that I just want to very quickly touch on. So you have Waterfall over here in one bucket, and then you have Agile in the other over here, right? Waterfall is the approach where you plan the whole thing out, you have a massive amount of documentation on how every little thing's gonna work, you have all the mockups, and then you spend months and months and you build it, and the stakeholders don't have access to it until it's all done. This is how most government sites are built. In the other camp, Agile, you have small cycles of development, which we call sprints, where one small module's worked on, completed, and delivered to you on a very frequent basis, and different agencies are gonna have different amounts of turnaround. Ours is about two to three weeks until we have working software in your hands. And so what we do is we plan out just that cycle. We plan the whole thing out, we document it, all that, right? But not the whole app. then we deliver it to you after the development's complete and you're able to look at it and say, this looks good, but this right here, it doesn't look quite right. Or you could say, this looks great, but I had an idea or my business is changing directions or whatever it might be and we need to change for whatever reason. You know, I woke up this morning and I had a really good idea on how this could be better. And boom, we can add that right into the next sprint planning. And you can have that in your hands in just a couple of weeks, those new ideas that you had. And you see the difference when you go and look at the quality of a government web application. know, if you've ever tried to buy health insurance online, you can see how buggy and broken and non intuitive it is versus something that goes through an agile process like Facebook, where every little tiny thing has been thought about and iterated on over and over and over again until they found the best possible solutions. And so agile is really the very best for the quality of your application. And so when you're vetting either in-house or outsource, make sure really make sure that they're following an agile methodology because waterfall just it's just a nightmare. It really is. Yeah.

David: So tell me about communication. Sounds like there's, um, you know, some, it'll really depend on the situation, right? We talked about earlier, you might be able to hire a couple of people internally, or you might need a whole team. I imagine that affects communication as well. Tell me about the pros and cons of communication and collaboration. If you're hiring an outsourced team or hiring your own team.

Calvin: Well, this is maybe one of the main reasons that a lot of people are attracted to the idea of hiring a team, because you're like, man, I could have people in my office and I could talk to them every day and I could fully control how things are going. I could check in with them every anytime I want. They'll be, you know, they'll be available nine to five. Right. So that is a great benefit of having somebody internally. You know, it's, there's no doubt about it that a contractor or an agency, you know, their attention is divided between multiple clients and it's sometimes difficult to have them be responsive immediately when you need them. One way to, to improve that is to see if you can get into the right channels. You know, email is pretty slow, pretty slow way of communicating. Um, so, you know, we like to bring people into Slack. Um, some people use Microsoft teams, some people, um, you know, maybe you have the phone number of your project manager or something. Um, but it's good to have a, I like, I really like Slack because it's just real time. You create a channel that's dedicated for the project and it's like, anyone can just send a message and everyone lives in Slack, at least at our organization. So it's like, you can communicate really quickly. Another thing is to make sure there's a good cadence of communication. Like oftentimes it really helps a project if there's a weekly call, a weekly meeting, because every week, you know, things are going to move forward because you get to talk face to face, you know, so regular communication on a project and making sure that people are on the same page on a regular basis is really good, really good practice.

Kelson: And I think when you are vetting an agency, not only should you do what Calvin says and see if you can get into those more real-time channels where you can communicate with them over the phone whenever you want or you're in their Slack, but you should also make sure that they speak English if that is your first language. And the reason I say that is because there's already so much miscommunication when we're communicating English to English. I couldn't tell you the number of times that I've gone on a call with somebody in my organization, and we've talked about the project requirements for there to be some level of misinterpretation or misunderstanding. And I've only seen this problem grow exponentially when you're communicating with somebody where English is not their first language. They have to translate your requirements to their native language. whatever that might be. I've never seen a project go really well when people speak different languages. It's just incredibly difficult, even English to English, to collaborate and prevent miscommunications. And the last thing that I might mention is when we're communicating about project requirements, the best way to do it is over a call. Like, it's good to have a note of some sort so that the developer or whoever on the team can remember what is expected of them. But really, you know, the best way to avoid miscommunications is to get on a call with them and discuss the requirements, you know, person to person really. When you're hiring an in-house team, right, let's say that's the direction that you decide to go in. You're making a really big mistake if you hire all of your team members in your same city and have them come into an office. Like, could you imagine if the NBA decided for each team that you could only bring on team members from your own city? Like, I mean, I'm here in Salt Lake City. Imagine if the Jazz could only recruit from Salt Lake City. I'll tell you, there's not a lot of tall people here, like not NBA level tall here in Salt Lake City. So it's really important to either move your team members to your city if you're going to have them working on site, or to work remote, you get a much larger talent pool that you wouldn't otherwise.

Calvin: Maybe if you happen to live in in like the San Francisco Bay Area, that might be an exception. But yeah, right.

David: Otherwise, right off of MIT campus or in New York, maybe one of those, you know, tech hubs. It's got a lot of talent right there. But yeah, that makes sense.

Kelson: But I would even say those people are missing out as well, because the downside there is you're paying all San Francisco salaries. which are a little bit more expensive. And and you could get the same talent remote from, you know, Nebraska or some lower cost state and pay a little bit lower of a salary.

David: It's like trying to beat a Pokemon game with only the Pokemon that you caught in your hometown. Yeah.

Calvin: Yeah. Having a whole talent pool, like the whole nationwide talent pool is really nice because, um, yeah, when you put out a job posting, like as people also want to work remote a lot of the time. So, um, you know, remote is not for every organization, but like it is, it does come with some benefits for sure.

David: Awesome. Well, thank you guys really appreciate you joining me today. you