Why Hiring Cheap Developers Will Cost You More

If you need to hire a senior tech person or any real expert, here's a truth that I've learned over 20 years. You get what you pay for. And when it comes to software development, a bad hire isn't just expensive. They can destroy your product. They can create technical debt you'll have to pay off for years to come. They can waste months, maybe even years of your life. That's why today I'm answering today's Q and a Wednesday question from Gustav how to make a high level tech hire. I'm going to show you step by step how we exactly did it with our software company, Webinar Ninja, and how we made each hire along the way. First, we have to establish that hiring technical talent is not like hiring for customer support or admin. If you're hiring the wrong person in a technical position, they can break your app. They can slow down your product. They can make the wrong architectural choices that can cost you thousands, if not hundreds of thousands of dollars down the line. They can cost you months of delays. They can make your life a living hell. How do I? Well, I made a hire that cost our company nearly half a million dollars. And worst of all, you won't know they're doing it until it's too late. That's why you want quality, not bargains. Don't try to find the diamond in the rough. It doesn't exist. A senior engineer who costs more per hour will actually save you money because they finish it in a fraction of the time and make better decisions for your company now and for the long run. Here's exactly what I do. The same method I've been using for years, I've been using Upwork for over 20 years. Yes, they're a sponsor of the podcast, but I've been using them way before they became a sponsor. And this is not a sponsored episode. But if you want to save some money, go to upwork.com save now. Once you're on Upwork, this is what I recommend you do. Don't sort by best match. Don't sort by most recent. Don't sort by price low to high. Sort price high to low. I look for the most expensive engineers who match the skill set I need for the project. Why? Because expensive engineers are usually the best in the game. We're talking about senior developers, CTOs. We're talking about people who are bored in their corporate job and want to have a little bit of fun on the weekend with a startup project like yours. These are people that who can do in 10 hours while others take 60 hours to do. I've witnessed this myself over and over and over. These people don't take side projects for the money. They do it for fun, for creativity, for a challenge. Right? They haven't been challenged mainly in a bit because they've been in a high level job managing, you know, hundreds of people in the department. Yes, they might cost 150, 200, maybe even $300 an hour, but if you save 40 hours of work, you just saved thousands. And I'm telling you, I've tried both ways. I've tried to find the diamond and rough. I've tried to find the person that's fifty and sixty and a hundred dollars an hour and they take two, three, four, five times as long. And therefore I'm paying more money and I'm losing out on the opportunity cost because the faster they can get out what I need to get out, the more money I can make with my customers. So trust me with this, go with somebody expensive, that's senior, that's experienced real quick. If these episodes help you in any way, hit subscribe. It helps us keep bringing you practical business insights three times a week for free. Thanks. When we started building Webinar Ninja, I didn't have a full engineering team at the start. I needed experts for certain areas to build the foundation of the software. I needed somebody to be able to set up my infrastructure, like server infrastructure on Amazon web Services. I needed somebody to help me scale my product so I can serve hundreds and thousands of customers. I needed somebody who's focused on front end design and implementation. I need somebody who can take complex features and build them out quickly. I needed somebody to be able to optimize database so that I'm not spending a fortune every single month in, you know, usage of database on the servers. I found senior developers on Upwork who worked for companies like Amazon, Salesforce, IBM, Yahoo. They built major features in a weekend, they diagnosed bugs in minutes and unblocked my customer support team with a nagging problem. And literally in a couple of hours, they optimize our infrastructure in a single afternoon. Which that alone saved me thousands of dollars a year. And I wasn't paying for time, I was paying for talent, people that know how to solve real problems. A senior engineer might cost more per hour, but they cost far less per project because you guessed it, it takes them less hours to complete the project. My next tip is to look for communication skills because skills without communication skills is basically useless. So don't do what many people do where they only evaluate skills. Senior Tech people must be able to communicate clearly back to you what they understand, what you want so that there is no wasted time and energy. You need somebody who can really understand your product vision, can translate it into code and explain their decisions so that you understand how your product's being built. They also need to be good enough communicators to build a document what they're building so they have proper documentation for your business and for your company, because one day you might get acquired and that's going to be super valuable. So my advice is don't interview two or three people, speak to five to 10 people and find out who's got the best combination of technical skills and communication skills. So you might be saying, omar, what do you mean by communication skills? What should I be looking for in this interview? Well, you want somebody who listens. You want somebody who asks smart, clarifying questions, somebody who can repeat back what you said so they can confirm they understand what you're saying and what you want. You want somebody that understands the customers you're serving. You want somebody that understands the product. You want somebody who can explain technical trade offs. Because when you're building out software, there will be trade offs where like, hey, I can build this fast, but it might be a little bit slow or I can really take my time and make it a super fast experience. And of course, you don't want somebody who's going to talk down to you. You, you want this to be an enjoyable experience. And often I found when you deal with very talented senior people, it's a lot of fun. So when you're having these interviews, if you feel like the communication is bad, that's a sign the whole relationship is doomed. You shouldn't start this relationship, but if the communication is great, it might be the beginning of a brilliant relationship that's going to serve both of you for a long time. The next step is once you have agreed to work with them, you need to set them up for success. This is on you. Most founders try to hire a senior engineer and they hand them some vague instruction like, I need the app to be faster or I want to add a calendar feature. I want to improve the ux. No, that's a recipe for disaster. If you're going to hire a senior person, a senior engineer, you got to give them as much context as possible. You must tell them what the business does in the first place. What do you do? Who do you serve? Who's your audience? Okay, what are your metrics? What are your goals? What's the purpose of the feature you want them to build, what are the trade offs that you care about, what's important to you and the experience for the customer? What's the timeline, how much time do they have to pull this off? And what are your non negotiables? And by the way, you can't have a million non negotiables, right? These need to be one or two. For example, if speed matters more than the ui, then you need to tell them that if, for example, you have a really bad bug that's costing you hundreds or maybe even thousands of dollars, then you need to tell them, hey, I need a fast fix to this. But because they can fix it and solve the problem and kind of put a band aid solution and then later do the deep work, they need to fix it permanently. But they need to know that this is urgent. If scaling matters more than rapid release every day, then they need to know that. Because I found that when you're building software, there's often a lot of trade offs, like I mentioned, but there's often a lot of decisions that need to be made by the engineer on what to work on. First, second, third. It's so important for you to communicate this because they need to know your priorities to make the right decisions. Their talent really depends on the clarity of your leadership. So as much as possible, be clear. Give them as much context as possible so that they have the full picture. There is one more step that many people forget. While you're interviewing them, they're interviewing you. Remember, these people already have great jobs, great careers, great incomes, comfortable lives. They they don't need your job, you need to sell them on the project, the mission, the impact that your product will make on the world. You need to tell them things like why this product matters, who it helps, why building it is an exciting project, why it's going to be fun, and what they will get out of this whole experience. What is it going to be like to work on this project? How will their actual expertise and work be used in the marketplace and help other people? I found that great engineers love meaningful work. Show them that you're building something worth building. One of the things I used to tell people when I was having this conversation is that I can guarantee you're going to do the best work of your life on this project. And after we worked with each other for a bit, I would ask them, was that true? And they always say yes, because I want to make sure that we're building something that really allows them to feel that they're being creative, that they're adding value to the world, but also something that's just fun and exciting in the world. So let me give you some action steps. The first thing is you never want to commit long term. At the beginning of the relationship, start with one clearly defined project. So, for example, when you're having the conversation with the engineer, tell them specifically, I want this feature that does XYZ to be built. I want this infrastructure to be set up so I can save X amount of money. I want this bug to be fixed. Ask them how many hours is going to take to do this project. If they say 20 hours and they cost $200 an hour, then you know that the project is going to be $4,000. Now, you know the budget, you know the expectations, you know the outcome. You can work together on this one project. And if it goes well, you can have a project too. If it doesn't go so well, at least you got a feature built out and you can move on. No drama, no sunk costs, no hiring disaster, no HR nightmare, no legalities. And what's great about a place like upwork is that upwork kind of secures your IP and also becomes the person that pays them and makes sure everything's on the up and up. Legally, most people think that hiring a senior engineer is expensive. The truth that I found is not hiring a senior engineer is a whole lot more expensive. A cheap engineer can cost you months, if not years of work. A senior engineer can save you an entire project, an entire product. You're not paying for hours. You're paying for speed, for clarity, for experience, for accuracy, for sanity. Somebody that gets it right. A great engineer doesn't just build what you want. They build what you should want because they have the understanding to technically what you should build. If this episode helped you share it with another founder who might be struggling with a tech hire, you'll do them a huge favor. And you'll also be spreading the good word of the $100 MBA show. And if you want to continue to go deep with me, you want to join our weekly newsletter. Just go to 100- MBA-NET Newsletter to get zero hype insights every single week. That takes five minutes to consume. Before I go, I want to leave you with this. You don't need a full time CTO to get started. You don't need a 10 person engineering team. You don't need to break the bank. You don't need this and that, right? You need one thing. You need that first right person doing the right work. Spend the time to find them. Interview as many candidates as it takes. Give them as much context as possible so that they know what they're building and they're inspired to build it. Start with a project and let the relationship evolve naturally. Hiring tech talent doesn't require guesswork. It's strategy. The strategy I shared with you today. The strategy I learned the hard way so that you don't have to. Thanks so much for tuning in and I'll check you in the next one.