Fractional CTO, Moonlighting, Side Hustles

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are getting into an interview. This episode, we're going to be speaking with Brian Childress and we're going to talk about some pretty cool things like a fractional CTO and how he went from basically just an entry level programmer and worked his way up into that role. We're going to talk a lot about moonlighting, side hustles, things like that. So I think this is one of those that if you're wondering where you can go with your career or if you're sort of stopped a little bit and you're wondering like, how can I kickstart this thing back into gear and into motion? This is going to be a great episode for you. So let's dive into our conversation with Brian. Well, hello and today we're going to speak with somebody new. We're going to be speaking with Brian Childress and we're going to talk about a lot of things, but basically it's about a career in IT. It's talking about the things that we do where we, you know, we've got our day job, but we've got that little side hustle. We've got some sort of night job, whatever it is that we're building along the way because at some point we probably want to work for ourselves. And Brian is somebody I think very much, you'll find out very much like us, done some of the same things. And we're going to talk about contracting and offshore versus onshore and some of those kinds of things that are out there that are, you know, the kind of topics that come up over and over again. So before I get too far, Brian, welcome to the show. And if you'd like to give us a little introduction. Yeah, Rob, it's great to be here. Thank you. My name is Brian Childress. I'm located in Virginia in the United States and I work as a fractional CTO. So I'm a software engineer, software architect by trade and training. I've been in the industry for well over a decade now and have been working both full and had a side hustle off and on throughout my entire development career. So I guess what let's start at the big stuff is sort of is where what drove you into the fractional CTO area? And I guess just for, I think everybody knows, but just to be, you know, give us a brief definition of what a fractional CTO does. I don't know if the industry has agreed upon a definition there, but I'll tell you mine. So as a fractional CTO, I have the opportunity to work with a number of different teams, whether they're startups, scale ups or small businesses that have a software solution that they are looking to put together. So a lot of the groups that I work with already have something in place. They may already have a team and a product developed. And I come in to help them to scale, to get the train back on the tracks, if you will, or turn the ship around. A lot of the work I do is very much collaborative. I work across a number of different industries. And really, it's an opportunity for me to bring years and years of expertise in working in both small and large organizations, small and large projects, bringing all of that expertise to an organization where they don't need to necessarily hire someone in a full time CTO role or someone in that kind of technical leadership role. Very well done. Yeah, the industry, I agree, may not agree on what that is or what the definition is, but I think that's an excellent definition. And it's actually, I see it as a very good sales pitch basically for a fractional. Because you're really in any of those roles, but particularly in a technical world, it's very easy to get to a point where you're advanced enough that you have skills that are, you have a particular set of skills and they're really not, they don't scale down as well. You don't want to spend for a high level developer and have them writing CSS code or HTML or something like that. There's just an issue with that because it just doesn't, you don't get the bang for your buck for it. And I think that's a lot of us see that as we grow as a developer and go into that. That area where the first year to the second year to the third year, we get multiplier of productivity. A guy that's been a regal that's been around maybe five or 10 years can easily be two or three times as productive as somebody that's just starting out. That's just sort of the nature of the beast. And so as part of that is coming into an organization as the, essentially as the CTO, even though it may not be a full-time role, how much of your, how often do you find yourself doing things like the, like sort of building out the team or having what, because a lot of people think if you're a CTO, you've got a whole organization underneath you. How often is it you're actually helping them build an organization versus you are the organization, you're the chief cook and bottle washer when you walk into these? I think most of the engagements that I come into, I tend to be, you know, tend to need to build out the organization. Honestly, a lot of the projects and the clients that I work with already have an organization, but it's just not going in the right direction. So a lot of what I'm doing is better aligning the engineering efforts to the business goals. And really a lot of that means just dialing back on engineering efforts that no longer make sense, right? We were building in the wrong way. We had the wrong architecture. Something along those lines. So bringing that technical expertise in just to make sure that it aligns well with the business. So usually I come in when there's a more of a problem that needs to be solved. But I've certainly come in where I needed to bring on a team, you know, whether they were, you know, full-time or part-time contract type hires. I've certainly done that as well. Now, how did you, I guess we'll back up now a little bit. Hopefully everybody now has a good understanding of a fractional CTO and some of your roles and some of the things you do. How did you go from sort of starting out, you know, because everybody, you know, you start as this entry-level person, you know, slinging some code around or however it is into this role. And a little bit of it is the, you know, talk a little bit about the technology side and the job side of it is like where you saw your skills, you know, leading you in that direction. But also maybe how the, because you mentioned several, you know, you've got a lot of projects, a lot of experiences, how those maybe helped groom you for this position. I think for me, it's been really valuable throughout my career to have an opportunity to work in a number of different projects, in a number of different industries, and really kind of see what works and what doesn't work across those teams. You know, I've worked in finance, I've worked in healthcare. So I'm very familiar with highly regulated industries where we're dealing with a lot of sensitive information. I'm familiar with working with startups that have zero to no money and are trying to build something versus a Fortune 50 organization. And how do they build for scale for the customers that they have? And I think seeing different projects across that full spectrum has been really, really helpful in being able to come into an organization as a fractional CTO and really be able to bring a really well-built out toolbox to solve the problems that a particular organization has. I never want to come in and have a prescribed set of solutions. I really want to understand the problems that folks have and then come in and make the best suggestion based on the information and resources that we have. That makes a lot of sense. For somebody that... So you also did mention that you talked about having you sort of had some moonlighting and some other things that you worked as a freelancer and as a consultant. And I'm assuming that even as while you were an employee. So how did you... Was that an intentional? Were you going out and you were trying to build that broad experience set? Or is that one of the things that sort of happened because that's just the nature of the business you were getting? It was very much intentional. I would say a couple of years into my career, after I had hit some of those typical plateaus that we see, I started to get a little bored with the day job. We weren't using the latest and greatest technologies. I wasn't getting to drive projects in the way that I thought they would be best served. So I started to get into freelancing. And so on the nights and weekends, I would pick up small projects. And way back when I started, it was a lot of WordPress websites for dentists and that sort of thing. And from that, I learned a lot. There's a lot that I took from that that I still use today in my career. But it was very much intentional as a way to get exposure to more projects, more technologies, more problems that need to be solved with technology. And I think having both moonlit and worked full-time, sometimes at the same time, has really, I think, propelled my career in many ways where I haven't seen peers with the same number of years of experience in the industry, may not have had the same level of growth. Now, the interesting thing, that's actually a question I don't think I've ever asked that we haven't really talked about on this before, is when you were doing these little projects, and particularly like you mentioned, like a WordPress site for a dentist, I envision that, which is why I'm going to ask this question. I envision that as one of the things where they're like, hey, I need a site. I need a website set up. I need a presence on the web because everybody's got a presence on a web. I need somebody to put something up that I can do something with it. So I don't have to call a technology person every time I want to change the hours of business. So within those, as I say, it's not quite a turnkey solution, but it is sort of a full featured solution because it's finding a hosting and doing all that kind of stuff. How much do you see that those projects, those soup to nuts kinds of projects that you picked up really helped you advance to the point, like you said, where you're ahead of a lot of people that are, you know, have spent in the same number of years, but it's that type of work that you did that really helped advance you? I think it really played a big part. And I would say it's not necessarily from a technology perspective. I love to say that technology is the easiest part of what we do. I can Google my way to a solution. But the skills that those projects really taught me was understanding my customers, understanding that this is a non-technical person that wants to be able to make simple updates to a website that they own and they're in control of. So that encouraged me to really understand their needs, their abilities, and choose a technology that best fit their particular situation. It helped me deal with contracting and setting up bank accounts and all the things required on the business side. It helped me learn the hard lessons of not getting paid for the work that I did, you know, which clients are going to be great to work with and which ones are just going to be really, really challenging. It really helped to teach me a lot of those skills. Now, certainly I picked up new technologies. I would jump into projects where another freelancer may have started the project and then completely left it. And I would need to jump in and get up to speed on a new technology I wasn't familiar with. And those are certainly fun engineering problems. But I think largely a lot of the skills that I've taken from that time is really how do I interact with other people? How do I interact with clients to help deliver a great product? You brought up something that again will vary a little bit from our primary focus here, I guess, is the idea of customers doing work where you don't get paid. I think that's one of the things that a lot of the entrepreneurial type shows and those kinds of things, tutorials and all that out there, they don't really talk about the... Sometimes it's not going to go well. You can go out, you can get a customer and you can have a great project and they can be a reference and you can grow and all that kind of stuff. But then there's... And I think whoever you are, however you do it, you're not going to be able to avoid sometimes. It's just those customers that are just... They're a pain for lack of a better term. And I'm wondering if you've gotten, especially now as you've grown over the years, are there... And particularly in... It's interesting because now you have different, I'm going to say tiers of customers. It's different doing a website for a doctor versus being a fractional CTO for a large company. Are there maybe a couple of, we'll say like red flags or something that you see now that where you're talking to a customer where you're like, I don't think this is going to be a good position to get into or maybe some that you learned early on that helped protect you after the first couple of times of running into that. Yeah, I wish I could say that I learned all those lessons early on. I think I'm even probably last year, I was still learning some of those lessons, the hard and very expensive way. I think the one thing that I didn't do early on that I eventually learned was to really honestly trust my gut and whatever I'm feeling, if it just does not feel right, then there's a reason behind that. And we may not be able to clearly identify it. It might not be a red flag jumping out on the screen in an email that's sent, but it's just something that doesn't feel right. And so I've learned since then that if, even if I feel like I need the money or would love to take on the project because it's a cool thing that I want to build, if the interaction between me and the client just doesn't feel right, then it's time for me to back away and really, really examine that because it's likely that there's some sort of underlying issue that's going to crop up in the future. Things like communication are really, really important. So even before we start on a project, what does it look like for the client or potential client to engage? How do they ask questions? How do they answer questions? How do they interact with their own team members or other folks on their team? When are they sending emails? How fast are they expecting a response from you? All of those things can kind of play into what is it going to be like working with this person for three, four, five months into the project. All of those things do seem to kind of show themselves pretty early on. We just have to be cognizant of it and really pay attention to what we see. You've mentioned several times communication, which I think is a key part of being successful in either actually as a consultant, but also even as you get into your career, because there's just, there's going to be those situations you have to communicate. Even if you're all on the same team, theoretically working for the same company, there can be communication issues that rise up. I've found a lot of times that's a challenge that technical people have stepping into that side hustle, moonlighting type of world, is that they have a project and it's like, oh, this is great. I want to go do this. And they talk to the person and then silence. Then they're just like, okay, I'm going to go do it. And then they're going to come back to the customer in four weeks. And it's like, hey, here's a project. And then they wonder why customers are complaining and things like that. Was that something that you had to sort of learn? Was that how to get that communication and to make it clear and maybe to, in some cases, it almost feel like over communicate because of that technical background that, like I said, a lot of people, it's just, it's not our first thing. It's more like, hey, we're going to go and get the work done. We're not going to sit there and tell you as we're going through it. Oh, absolutely. And yeah, as a technologist, it's a really frustrating thing to feel like we have to provide a status update or something along those lines. But it really is a powerful tool if we learn how to leverage it. One of the things that took me a while to figure out was that we all receive information in different ways and at different times. So we had to continually kind of reiterate the same message over and over and over. We may change the way we present the information. It may be in a short snippet versus a long email. It may be over video versus in writing. I think we just have to put the information out there and do our best. Even if the client, they may not be communicating to the same level. We can control how well we communicate as consultants, as freelancers. And I think that really speaks to how professional we are in the way we interact and the way we communicate. Again, technology is the easiest part. It's all about how do we interact with others and how do we communicate ultimately the value that we're delivering. Now, as you've grown in your career-wise, I guess we will say grown in that position from a, just to label something sort of like that, you have a staff developer up to a CTO. How have you seen the need for communication change? I think the further up in your career you go, the more you need to be able to communicate with different stakeholders. Typically, they tend to be less technical stakeholders. Early on in our careers as individual contributors, it's likely we're only interacting with other members of our team who are also technical. As we continue to grow up, we're going to be interacting with other folks on other teams and product owners, other stakeholders that may not have the same technical background that we do. So we have to change the way that we communicate. I think finding different ways that we can effectively communicate, too. Some people receive information really well in writing. Some people really prefer to kind of hear it in a one-on-one call. So just really identifying who your audience is and delivering the message that can be best received by them is a really powerful tool. Now, one of the things you mentioned, you've done a lot of, worked a lot of startups and with founders and things like that. And particularly from your role, this is where I think a lot of times you're coming in and they've got a product, they've got an idea, but they need you because they need a technologist. That's not their strength. So where is the... And so you're coming in and solving their problems. What is sort of the common or the typical challenges that the non-technical founders, solopreneurs in that face that you're able to step in and help them with? I think for me, the biggest area that I like to focus is understanding what is it that we're trying to build. And really that's based on the problem that we're trying to solve. I think unfortunately, a lot of non-technical folks, non-technical founders really struggle with understanding the different ways that we can leverage technology to solve their business problem. And I think as technologists, it's our job and our role to really and our responsibility to help in guiding them in choosing the right technology for their particular problem. So thinking about an example, a lot of times a non-technical founder may come to me and say, hey, Brian, I need an app. And that's kind of what they have. It's like, okay, fantastic. What kind of app? How many users do you think you're going to have? What's your target audience? And so really for me, instead of jumping into solving the problem or coming up with a particular technological solution, I take a step back and really focus in on what is the business problem? What is it that they're trying to do? Do they really need an app? Do we really need to go down the route of a month-long custom development project, or is it something that can be solved in another way? So I think that's really where I like to serve most of my non-technical partners, is really just identifying what problem is it that we're solving, and then we'll figure out the right technology after we know that. Another area is that, as you talked about earlier, as you come into these, you've been in situations where you've helped organizations, companies, founders build out a team. Sometimes they've got a team, sometimes you've got to build it out. And so sometimes you've got to make adjustments to the team. So what are some considerations, if somebody comes to you or is thinking about talking to you, what are some considerations they should have in building a team? What are some of the things you should think about, particularly when you think of the options, whether it's a, do I hire consultants? Do I hire employees? Do I go with an agency? Do I do offshore, onshore? Sort of that, with all of those choices, I think it's confusing to most people. It's like, okay, I've got too many choices. What do I do? Or do they just, they'll throw a dart and see where it lands on the board, basically. I think most of my engagements, I come in after that dart has been thrown and they hired an offshore agency and things didn't go well, or they hired a freelancer and they completely skipped town and left with all the code and their money. So I think it's, again, it comes down to what is the business problem and what are we trying to solve? And then I'll build a team around that. So there's two typical ways that I try and approach that particular problem is once I understand their business problem, is there a core component to that that requires a subject matter expert in a particular technology that we need to first identify? So let's say that the product that we're building has a very, very strong ML focus, and we need to have a machine learning subject matter expert on the team right away. So I want to find that particular person and treat them almost like a nucleus, and then I'll build the team out around them with a series of generalists that are able to support the work, but may not have the same level of expertise. And then counter to that, if what we're building is another crud type business application, then it's fairly common that we'll find some really talented senior full stack developers that are more generalists and able to get us off the ground. They're the folks that can wear many hats and get the project moving along. And then as the product evolves and grows, as the team grows, then we'll start to add in more specialists where we need to. But largely, most of the time, I typically focus on more senior experienced talent that can bring in the right technologies, the right engineering practices. And then for me, from a leadership perspective, that's where I have, I keep a close eye on what is it that we're building, how are we building it, what technologies are we choosing, what code looks like that's coming into the code base, and really understanding that, just to make sure that we continue to stay in line with where I think we need to be from an engineering perspective. I think from contractor versus full-time, really, it's that a common answer of it depends on things like where is the business in its maturity? How much funding do we have? Do we think we have enough work for someone to be brought on full-time? Maybe not. Maybe we only need somebody with a certain area of expertise for a short period of time, then we might look at a contracting route. But really, I like to kind of take a really close look at what we're building first and then build the team based on that. And we will pause right there. We'll be back, second episode. Now, remember that we have alternated our schedule a little bit now, so we'll have a one-on-one kind of podcast episode, and then we'll have an interview. So, this will be a week from now. You'll get part two. Hopefully, that isn't too long. But again, it gives you some time to sort of maybe think about some of the things that Brian brought up and maybe where you can apply that to your career, your services, your products, and how you maybe you can find a way to branch out to some of these other places. But we will continue next week. Until then, 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 Develop-a-Nor 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. Hi, this is Rob from Building Better Developers, the Develop-a-Nor podcast. We're excited to be on Alexa now. You can enable us by simply saying, Alexa, enable Building Better Developers, and we will be there, ready for you every time you want to listen to your now favorite podcast. Whether we are your favorite podcast or not, we would love to hear from you. So please leave a review on Amazon.