Scaling with Contractors and Employees - A Strategic Guide to Business Growth

Welcome to Building Better Developers, the Developer Noir Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season of Building Better Businesses. We are actually the Building Better Developers, Developer Noir Podcast. I am Rob Brodhead, one of the founders of Developer Noir and also a founder of RB Consulting, where we are what they call boutique consulting. We help you leverage technology and just do your business better. We get in there, we work with you to understand really how your business works. What is your secret sauce? What is the recipe that is needed for you to leverage technology, whether it's through simplification, automation, integration, innovation, whether you're buying stuff off the shelf or building something custom, or even having to build up a team or a culture within your organization to utilize and leverage technology. We're there every step of the way to help you do that, build a roadmap and let you just basically go on with, you know, take you, kick you out of the nest and you get to fly away and not like fall and go splat. Good things, bad things. Perfect day for it. It is again, one of those that is good and a bad thing is it snowed. I live in Nashville area where they don't deal with snow very well. Like you get like three flakes and they're like, boom, school is like closed for a week. I had people like the threat of snow had businesses closing down yesterday and it's not a bad snow. So that's a cool thing is like I woke up, it was a pretty white everywhere. The bad thing is it like it disrupts my schedule. I play ice hockey and they're canceling the ice hockey game tonight. How can you cancel a game on the ice because of snow? And yet that's what they do. So it's going to mess up my schedule, but it was sort of cool that I was able to like, I didn't have to commute in today. So I got a lot more work done. So it was a good thing there. I think we'll do that. And then I'll just go ahead and you know, a little ruminate about my good and bad stuff and pass it over to Michael to introduce himself. Thanks for everyone. My name is Michael Milash. I'm one of the co-founders of developer NUR, building better developers. I'm also the founder of Envision QA where we help businesses and clinicians really analyze their business, look at their processes, look at their software and help them figure out if the software is working for them or if they are working for the software. We essentially walk you through your processes, help you analyze what you're doing, streamline your processes, basically enhance the business experience so that you spend less time working on the business or working in the business and you can actually work with your customers, you know, work on the business. Or I have that backwards as always. Good and bad. Similar to Rob, it snowed. Unlike Rob, our roads didn't get better until about four o'clock this afternoon. So I couldn't even leave my driveway for most of the day because we actually got ice first, then snow. We had a nice little sheet of ice which made it fun walking up to the mailbox. It was nice, slippery, slidy. The good though is I have actually changed my routine over the last week. I am almost completely off of caffeine and I'm starting to feel a lot better, a lot less anxious. And if you've listened to some of the past podcasts, you can see why I had to start getting off of this. It's just if you take too many stimulants of any kind, it is a bad thing. That's my good and bad. Well hopefully this is not too stimulating for you guys and gals. We are going to talk this time about, basically it's building your business. We're going to really talk about employees and contractors. It's like at some point you have to, as a guy I worked for years ago, refer to it as you have to be able to scale yourself. If you're a developer, there's some point, and it may be from the entrepreneur side, it's something where you're maybe hiring somebody and whether it's an employee or whether it's a contract, outsourcing a couple things. Or even in a company where now you're moving up and you effectively have employees that are people that report up to you, that you have HR responsibilities and all that kind of stuff. This is a little different from, now a lot of times there will be early on in a career where somebody is a lead, a team lead or something like that, and they're more of a leader or a mentor or something like that, but they're not really managing that person. A lot of companies it's referred to as having HR responsibilities, the things where you're giving reviews and you're providing, you're giving input or possibly even giving them raises and talking about rates and stuff like that, all the things that we all care about. This is getting into more of that side where it's not just that you're being a mentor, but it is that you're now somewhat responsible for this person's career as well. You're not just building a better developer in yourself. Part of it is that you need to be building a better whatever that person is. This is where it can become, it really does change the game a little bit because it is not a simple thing. This is not just a developer issue. It's not a simple thing to take the things that we know how to do intrinsically, that we just do it automatically and tell somebody else how to do it. That's part of what we're usually going to need to do when we're bringing on employees. Is there something that we may luck out and it's like, hey, we're going to hire somebody to do accounting, we don't know accounting. Awesome. It's like, I'm going to hire somebody to mow my yard. I don't need to tell them how to mow your yard. They're going to mow the yard. When we bring them in to expand our team, usually we're going to have to tell them, what is this project? What are the requirements? We have to direct them in some way, form or fashion and say, hey, I need you to do X. This is the work I need you to do. Or for somebody I was talking to recently, that was like, this is one of the challenges. I worked with a guy and they had, we just had a blanket agreement of like, they're going to pay me money, which is awesome for me to some extent. But it was also like the understanding was they're going to pay me money and I'm going to have an equal and equivalent amount of work. And early on, that was great. They had tons of work. But then as the work started to fall down, the manager sort of come down and level the manager basically that was there suddenly had to take on, it was more work for him because he was now like, I got to make, find enough stuff to keep Rob busy enough. And he was still busy doing his stuff as well. And that's some of what we will run into because if you take a contractor on, if you take somebody that just is straight up hourly and there's no agreement to a minimum number of hours or anything, then if you've got five hours of work, you can five hours of work and they're done. If you got 40 hours of work, you get 40 hours and they're done. It's easy. If there is that expectation of like, I'm bringing on a contractor, but I need to provide them full time work or I'm bringing on an employee. So I am paying for them. I need them working all the time because that is how the, you know, the everything works out then we're now stepping into something a little different because we're not just talking about, there's other facets that I think we need to take into account and I'll toss it over to Michael to sort of get some of his on these as well. But I think one of the things is that you do have to look at developing that person because that's part of the value, not only to them, but to you, because if you can go, it's just like a professional sports team. If you can get a rookie that turns into be a super, super, superstar, and you had several years of that rookie developing into that where you were paying like, you know, the rookie prices, then, and maybe you even get a discount as they get into being the superstar. That's what you want to do in your business as well. You want to bring all these, you know, you don't have to bring all the rookies in, but you want to train people up so that, you know, from January, if they work from you, you know, all through the year from January 1 to December 31st, let's assume they're getting paid the same salary, you're getting more value out of them by the end of the year because you have helped them grow. So that's one of the things you want to do. You also want to be able to look at ways to scale yourself by pushing some of the stuff that you would do off to these people because now it's freeing you up to hopefully do, you know, build your business out and do some of these other things that are the things the company, your organization needs to do to thrive. But also it's going to allow them to stay busy and you get the most value out of them. I'll stop there and let Michael go because I don't want to take all our time up. So it's interesting. So before I get into the like hiring people, the first thing that came to my mind is you were kind of walking through like the leading versus managing, like the team leads versus a manager, the HR roles. It's a very interesting distinction because throughout our career, we kind of wear many hats, but as developers as you or even owners, as you slowly build your business or you slowly build your skill sets up and you move up within companies, you have to take on more responsibilities. So you become a leader or a team lead. And essentially you're helping to mentor people or you're helping to train people, helping people do their job and move the dial forward with managing and hiring people. It gets a little more complicated. The biggest distinction that I've run into is when I work for a company and we hired on contractors, the HR responsibility wasn't necessarily mine, but I found that I spent more time managing the behavior of the contractors in their communication with the manager because a lot of times the contractors did not know how to handle office politics when dealing with full-time employees or full-time managers. And that caused a lot of friction. And when you move into the role of being a business owner or a manager, you're actually hiring these people. You're actually looking for talent to fill in gaps. But a lot of the times for new managers, especially, is we wear a lot of hats. So by the time you worked your way up through a company or you worked your way up in the business, you have either bootstrapped most of the work yourself or you have come up with some policies or procedures to fill in the gaps to kind of segment your time. Well, when you hire an employee, you're going to hopefully carve out one of those segments and hand it off to the employee. The problem there initially will be that you don't want to let go. You are going to fight tooth and nail and I'm just going to do it. No, I can do it better. You have to as not just a manager, but as a leader, as a mentor, say, look, you're here for this position. Now the worst thing you could possibly do is hire that person, stick them at us and just have them read documentation. Well that is beneficial. That does not quickly integrate them within the company, within what it is you're doing. You're essentially giving them a pass to waste time. You're paying someone to just sit there and read through something that if you have them literally like shadow you, monitor what you're doing, or just jump into it and kind of, you know, fire to the wheels. You find out if they can one, do the job. Two, you find out, hey, do you understand this? You start to build that personality or co-relationship with your employee and you can figure out where their strengths and weaknesses are. Now the big key is if they do have a lot of weaknesses, take a moment or take like one on ones or even just little times to sit down with them and spend a little more of your knowledge. Make the knowledge you know. You have spent a lot of time doing this. You've learned this. Well, you can't expect your employee day one to just know what your company does, what your product does. Now they may know how to code, so yes, they can write code, but they don't know your application. They don't know your processes or procedures. So spend, it is expensive to you because you have so much going on. If you had to hire someone, it's because you've reached a maximum workload and you have to carve off time, but you still need to anticipate that you are going to have to spend more time upfront to prepare that employee to get them where they need to be. If you want them to be successful and if you really want your business to grow and not just hire monkeys to sit at the computer, typing keys and just follow procedures, you know, AI will eventually eliminate that. The key here is we want people that are experienced, that can do the job and help us help our business scale, help it grow and hopefully, you know, help us improve our customer relationships and improve our products. What do you think of that, Rob? There's a couple of things you touched on there. One of them, I think the early in that is one of the things you have to think about, and it's very similar to automation, is looking at where you can take something and you can peel that off and you cannot do it manually anymore. I think if you go at it with that kind of an attitude, I guess, of, hey, I'm automating this by giving this to this employee, then it's going to be, now it's a little bit different because automation, you're like, okay, it's going to just always do it the same way. Employee, you're lucky if they always do it the same way. There's going to be variations, but it is conceptually the same kind of thing. Like I'm taking something that I don't need to spend the time. It is not the best when we automate it. It's not the best use of my time to walk through these 400 steps to do this process. Can I do it? Yes. But not the best use of my time. Same thing with an employee. So even though you might be able to do the job that you're asking them to do faster or even better, you're looking at places where it is not, that doesn't bring enough value to the bottom line, basically. It's things like, yeah, I could go in and like, for example, let's say you've got some sort of a status report that's basically all you have, that all you're doing is you're taking your notes that you wrote down and you're writing it into an electronic system. You can do that and you'll be able to pull that across. But if you found somebody that you could give them the notes and they would enter in the system for you, then that's suddenly time that you get back. And it may only be five minutes or 10 minutes. But when you start looking at like developing stuff, there are things where it's like, hey, I can build one screen and here's all the logic around it. And there's 400 other screens to build. Well, you can go build, give those to somebody else to build those screens. Now they don't have to be identical and you really don't want them to be what you want. And this is where you want to not only build a better developer as yourself, but you also want your staff to be better developers, scrum masters, whatever the heck it is, you know, even accountants, office managers, you name it. You want your staff to get better because that's part of how you grow. You're not going to grow by having a bunch of people that are just the same person day in and day out. And they never change because then you always have to find new people. What you want to do is you want to grow people and grow them into the positions that your company needs to for itself to grow. And we'll talk more about that in a future episode, like maybe the next one when we talk about leadership. But I think this is something you need to keep in mind is that you're doing this. It is a it's an investment. As Michael said, it's going to cost you time and it's it can be frustrating. It'd be very daunting to sit there and go, OK, I know they need to explain this application that I've built over the last 10 years to somebody so they can start maintaining it. Well, first, you don't have to be perfect. They don't have to like you're not going to fall off the face of the earth, hopefully. And they're not going to have to just take it 100 percent from there. You're there to work with them. And the one other thing I want to do is like the sitting somebody down at a desk and just saying, OK, go read for a while. It is very useful, I found for myself and I think for a lot of people that I've worked with that I've brought in over the years, testing is actually a pretty good way to learn something. If you've got an application and you've got testing to do, it's actually really useful. You can take sometimes very senior developers and resources and say, OK, I need you to sit down and just like walk through, test this application for me here. Even if it's here's a script, walk through it. But usually it's like go test it. Don't give them much of a script and let them do it. And they're going to break it. They're going to give you all kinds of information back. And they're going to learn that application. The other thing is support it. If you have a support desk or something like that, it's a great way to bring people in because they're going to get questions. They're going to get to know your customers. They're going to understand the whys. They're going to understand the problems. They're going to understand the pain points. And suddenly you've got somebody that really what they're probably also invested. So maybe the first is they're invested because they know people. They've got these relationships with people that they've talked to on or through email or communicated with. So now they want to build a better product. They know what the pain points are. They're sort of like, you know, they're commiserating with them. And now you have a very driven person to build your your product or improve your service. Thoughts on that? Yeah, I have one additional thing to add to that. So one of the other things I've encountered with new hires or even new teams is essentially not scope creep, but basically we pivot too often. So one of the problems you have is you bring on a new team or a new employee, give them a test and give them some time to absorb it. Give them some time to understand it, to figure it out. Doesn't necessarily have to be a week or a month, but don't go into a situation where, OK, today, do this tomorrow. Do this. Oh, wait, every hour. Do this, do this. You're going to burn them out, confuse the hell out of them, frustrate them, and they're going to walk out. So please be very conscious of what tasks you do give the new hires so that they like Rob said, testing and support are great ways to figure out the application. The trick is, though, make sure you give them a workstation and an application that works. The other thing that's very frustrating is when I've been handed a project and the code won't even compile. So how the hell am I supposed to figure like I spent hours just looking at code and come to find out that someone forgot to include a file or someone accidentally deleted a file. And it's like, so I'm trying to work on something that's already broken. And you're telling me it works. So just be very cautious of what tasks you do assign a new hire and make sure that you're giving them something that is both meaningful, something that will help them learn the business, learn what it is that you're all about, what your product is and spend a little time with them. Don't just hire them and ignore them for a month. You want to build that relationship. You want to build, include them within your business culture. And the other thing is, make sure you hand off, make sure you give them the work and give them time to understand it. Don't fret over it and don't pull it back. Don't say I can do it better. I can do it faster. Let it go. One of the things Rob has taught me over the years is you have to let things go sometimes. And this is one of the greatest examples of one to do that is you bring someone on, you give them a task. Now I will say this, do not give them a mission critical task as their first task. You are just setting them up to fail. Or if they are a genius, great, maybe, but never, never give a new hire something that is mission critical, very high end deadline, or maybe even your most important client, something to do within a very short deadline. If it's over months, sure. But please be very conscious of what tasks you do give your new employees or your new hires and make sure you do spend the time with them to make sure that they understand what they're doing. I think that's very critical is that you want to realize that one of the things you need to do is you need to, when you're bringing somebody new in, whether they're contract or whatever they are, you need to make sure they succeed. Your goal should be that they succeed. So the early task should be, like Michael said, not critical, not the kind of stuff that's that you're expecting. Even if they are an expert, don't bring them in and just be like, cool, you're going to figure all this stuff out because that's not going to help. And you're going to have something that you think is an expert and you're suddenly going to think there are more on because they can't get it done. But it's not, it's because you didn't give them the opportunity to succeed, which is the other part of what Michael is leaning towards. It's like, patience. You have got to be patient and realize they're not going to pick it up immediately. They're not going to do it as fast as you, especially the first time they do it. And they're going to make mistakes because there's going to be things that they don't realize. And honestly, look back at it as if they make mistakes. It's probably because you made a mistake and did not communicate the details that you needed to beforehand. And that is something that one of the best and worst things I did is the first actual employee I had was a son, was one of my sons. And so he was more than happy to say, well, you didn't do this. You didn't do this. You didn't. And he was right. But it helped me as I was going through this stuff to be like, oh yeah, I handed this off, but I didn't do this and I didn't add this part and I didn't provide this piece. And part of it was because of where he was and what I was used to, but part of it was because I was not used to pulling that crap out of my head and sharing with somebody. It's one of those things you're like, well, everybody knows it. Well, you know what? Apparently not everybody, because this person does not, and you need to not, you know, it's not a personality flaw of theirs or that they're an idiot or something like that. It's they don't know it. Like we all have things we don't know. And you know how you fix that is you tell them, you let them know, and then they're going to be more successful the next time around. Before you do the challenge. Go ahead. When you do have new hires, depending upon your work culture, if you're scrum agile, whatever, or if you're just a small team, make sure you give time, especially the first week or two or within the first month, spend time in a safe space. Make sure that you can sit down with the employee and make sure that it is a calm, open conversation that like Rob said, his son was able to tell him what he was doing wrong. Set up one in ones or open meetings where people can bounce ideas of where things going good, where things going bad, essentially a formal or an informal retrospective, essentially in a one-on-one or maybe in a group setting, but give them a chance to give you feedback. Don't just assume they're not doing their job. Maybe they need something from you, but are afraid to ask. That is, I always hate this, the phrase safe space in a sense, because it's like it's loaded, but it's true. It's very much, you have to, I will say it, I guess, in more of the like the Gen X style of like people need to be, they can't be afraid to fail. You've got to allow the opportunity for failure because otherwise they're always going to be too scared to actually take any risks. And then you end up with not what you want. So really good point. The challenge this week is going to be whether you need to hire somebody or not, whether you need to bring somebody on or not, is look at what you do over the next few days. Look at what you do. What is your task list effectively? And what would it mean for you to be able to, what would be a piece that you could carve off and have somebody else do and do so in a way, preferably if it's something where it's like, this is not something that is where you bring the most value, something that is redundant or a little beneath you, if you want to call it that, or however you want to look at it, but basically something that this is not necessarily the best use of your time. And then maybe it would be useful to find somebody that didn't cost as much to you, to your company or anything else and have them do it. It's much less. We always talk about the four hour work week and doing like, you can offshore stuff and outsource stuff and all that kind of stuff. It's that same kind of thing. It's really is in that outsourcing mentality. Pick something that you would be able to, that you should essentially push off or that you could. And then just like spend a little time thinking about like, what would it look like to hand that off to somebody else? Maybe you run a little note cards, like, well, I got to tell them this, this and this, or I got to teach them that. Because I think doing that in itself, going through that exercise will help you, if you have to do it, it may also highlight something that you need to get rid of and get off your plate. And it may even just help you better understand what it is that you do, because now you're, it's always more educational for you to have to teach this to somebody else than it is for you to just like know it in your head. Just like I'm going to teach you right now, actually I'm not. You sure you know this? Send us an email. Shoot an email to info at developernor.com and let us know what is up. What do you like? What don't you like? What are some topics that you would like for us to cover? Whether it is in this season of how do we build better businesses? What are some things that we can do to make our businesses bigger, better, stronger? If you've got some suggestions or some questions related to that, we would love to hear it. You can also leave us comments at anywhere at developernor.com. We've got comment stuff everywhere. We've got a contact us form. You can hit us up at x at developernor. We have stuff out there. We are out on Facebook. We've got a developer Facebook page. There's eventually some other stuff we may do, but I'm not a socials guy, so at some point we'll get there. For now, let's go with those. But wherever, feel free to like just search for developernor. If you're listening to this 20 years from now, you may find us in the new like whatever the social site is. That being said, we're going to wrap this one up because probably gone a little longer. We need to, but hey, you got it for free. Hopefully, and I hope you got more out of this than just free. I hope you got a little bit of value out of this one. Go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the developer podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.