#181 From Enthusiast to Expert: A Conversation with Fractional CTO Brian Childress

0:00:02 - Mehmet
Hello and welcome back to a new episode of the CTO show with Mehmet. Today, I'm very pleased to have with me Brian. Brian, he's a fractional CTO this is how his title is and it's not the first time we talk about being a fractional CTO, but, as usual, I would love all the time that my guests introduce themselves. So, brian, thank you very much for being on the show today. Can you a little bit tell us about yourself and what you do? 

0:00:27 - Brian
Yeah, thank you for having me. My name is Brian Childress, I'm located in the United States and I work as a fractional CTO, so I have the opportunity to work with a number of different startups and scale-ups small businesses that are looking to grow their technology and use software to solve some problems for their customers. That's great. 

0:00:51 - Mehmet
Now, you know, maybe it's a bit traditional question, but what had led you to have, you know, this journey to become a fractional CTO? Because I was a tech professional and I'm still a tech professional. I kind of myself like that. So you know, back in the days we used to say, okay, I want to be the CTO of a company. But being fractional CTO means you are working with different companies at the same time. So what inspired you to choose this path? 

0:01:21 - Brian
Yeah, so my journey. I started as a software engineer. I typically worked in contracting organizations, so I've worked in healthcare and finance and transportation and worked my way up through the ranks as a individual contributor. One of the big areas that I saw an opportunity is around kind of technical leadership, so that combination between strong technical skills and leading the direction of the technology. So a lot of times we think about this around strategy and architecture and I like the fractional component to it because it allows me to work with a number of different organizations all at once and really a lot of my clients can vary across industries, so I get to bring a lot of the experience from one organization or industry into another and I found that my clients really benefit from that variety of skills and information that I'm gathering with a number of different engagements. 

0:02:30 - Mehmet
I see and I think, brian, you work with both startups and like full-fledged organizations as well, right? 

0:02:37 - Brian
I do, I do, yeah, so small medium businesses that have some technology component. What's interesting is I work with a lot of companies that already have strong technical leadership in place and they're looking for some additional direction or advice as they continue to grow or scale their offerings. 

0:02:57 - Mehmet
So, from a CTO perspective, I'm sure you would have different approach working with, for example, a startup, maybe with just like less than 10 people still, versus these big organizations where they might have, as you said, like big teams there. So what do you see? I mean, do you feel any challenges in startups more than the established organizations, or is it like the other way around? 

0:03:31 - Brian
I think a lot. Whether it's a startup or more of an established organization. I think the challenges tend to be the same. In a startup, we have the advantage of being able to pivot a little bit more quickly as soon as we identify an issue. I think that's maybe a key differentiator. But what I find in a lot of organizations is that there's really a need for some sort of direction. One of the big areas that I focus on with my clients is being able to tie the technology that we're building or implementing to a business need. A lot of times I see organizations we do see it a lot in startups, but we see it in larger organizations as well where we allow the technology to drive the solution instead of identifying what the solution, what the problem is, that we're solving first and then we start to establish the solution from there. And that's really where I focus a lot is making sure that we're solving a real business problem for the organization. We just happen to be using technology to solve that problem. 

0:04:36 - Mehmet
Do you think this is coming from the pressure of following some hypes or fear of missing out? Sometimes I'm talking here more about big organizations, because I used to be a consultant and I used to hear these stories about big budgets, that they were put on these big technologies, that in the first place maybe they didn't need them. So do you think this is the challenge there, one of the challenges? 

0:05:03 - Brian
I think it is and I think we have to be very careful with that. I've certainly been in projects that were very simple kind of internal applications and someone had heard somewhere on a podcast or read an article that Blockchain was the thing that was taking the world by storm. Someone in a leadership position comes in and says we need to add Blockchain to our application right now. In reality, the application would not be served by that. But without having a strong technical direction, it's easy to be distracted by a lot of those either new shiny components or the things that other large organizations are doing and really that may work great for that organization but it's not really serving our organization or our customers and we have to be able to identify that and ultimately push back from a technical perspective. 

0:06:02 - Mehmet
Yeah, this is something I used to face because I used to sit on the client side, I used to sit on a vendor side and, yeah, like sometimes these it's like tough conversations from time to time. Now, because I love more startups, to be very frank with you, no-transcript. Let's talk a little bit about startups and usually people they look for a CTO because they are not technical themselves, right. So what is the biggest challenge non-technical founders face other than like they don't have the know-how? What other challenges you can tell us about? 

0:06:41 - Brian
That's a fantastic question and something that I work with a lot of non-technical founders on every week. 

I think the biggest challenge there is understanding what they getting an understanding of what they don't know around the technology, and for a lot of non-technical founders they have the challenge of trying to find someone that can help them with solving the technology component. 

And what I find a lot of times happens is the best resource that they can find to serve that kind of CTO or technical counterpart for non-technical founders is just not experienced enough, because non-technical founders that may or may not have a good product or product market fit may not have time, money, resources to be able to bring in someone with a diverse set of experience that can make sure that they build a great foundation for the technology. 

And so they end up with folks that may or may not have a few years of experience developing software in an organization that doesn't have the same salary requirements as a fully fledged CTO or more senior technical leadership. And so they, the non-technical founders, tend to partner up with folks that might only have a couple years of experience developing software and they just aren't set up in a good place, and ultimately those are the clients that I end up working with a lot are folks that have built some sort of product, has a lot of shiny new technologies implemented but ultimately isn't working or isn't solving the right problem for the business. The non-technical founders very frustrated because they've spent all this time and money. They followed the leadership or the guidance that they were given, but it just wasn't great advice to start with, and I think that's one of the biggest challenges for non-technical founders is just finding somebody that can give good, solid direction as far as the technology goes. 

0:08:54 - Mehmet
And I think this what lead these startups to what is called technical debt, right, Brian Like? Because they figured out that they have built something no one needed and they tried to push to keep this technology because they have paid a lot of money on that right. 

0:09:09 - Brian
Right. Yeah, they've sunk a lot of costs into time and money and to developing something that they didn't need and really I think it's even bigger than technical debt. It's really something that's just not a product that anyone needed. So I work with a lot of my clients and making sure that we have good product market fit. We make sure that we're solving the right problem, that it's a problem that we can ultimately sell to customers before we start to write code. So really for me, writing code is one of the last steps in the process. First wanna make sure that we're solving the right problem. 

0:09:48 - Mehmet
Yeah, actually I keep repeating this on the show that guys you need to go, and every guest who, from both technical and business background, they kept repeating the same thing and we are trying to also enlighten anyone who's maybe listening or watching us today that guys, do some market research before actually building your first product and there are a lot of ways that you can go and validate your ideas. So, yeah, 100% on this. Now, brian, like, let's say, I'm a non-technical founder, I have an idea and then I decided that I need to build. Let's say, I validated also the idea somehow. I asked friends, I asked a couple of people, made some surveys, market research, whatever. Now, when it comes to start building the product, so what or who should I hire? Should I hire a freelancer? Should I hire a consultant? Should I hire a agency? Which direction should I go? 

0:10:47 - Brian
I'll give the classic answer of it depends. 

I think one of the biggest levers that we can pull as a non-technical founder getting started and building a product is really finding a good partner that can help provide a lot of the technical direction. 

So ultimately, that person may not be writing code day in and day out. 

That's not where they're going to be providing the most value. Really, what we're looking for is a partner that can help provide good technical direction. So this is doing things like deciding on a simple application architecture what are the components that we need to start solving the problem, maybe choosing some of the technologies that will be used. This is the person that's gonna be guiding the build versus buy conversations and making sure that we're choosing the right technologies and really someone that can help define the roadmap for what will be developed first and then what can be developed in subsequent iterations of the product. I think that's where I found a lot of founders are able to be most successful is by having someone that can come in and provide good technical direction. It's pretty easy for us to find developers anywhere in the world that are fantastic at building software. What lacks a lot of times is being able to define the problem and build the right solution in the right order, and I think that's where a good technical direction comes in. 

0:12:29 - Mehmet
Yeah, so does it depend on the budget that they have also as well? Because sometimes you know and I'm shocked and this is global, by the way, it's not only in the US, this happens here also as well, in Dubai and the Middle East in general I hear about, you know, these startups that they have spent hundreds of thousands of dollars on you know the first MVP not the product, the MVP and you know like later on they discovered that no one needed. So do you think also they should put this in mind when you know doing all this, like hiring an agency versus, you know, getting a freelancer or getting a blend of a consultant plus maybe someone part time? Like how it's important also to take the financials part and put it into the plan? 

0:13:22 - Brian
I think it's hugely important and, if I can go back and maybe correct my previous answer to your question, I think the first person to hire budget or no budget is probably a designer. I like to really start with sort of a clickable prototype. To start, fairly cheap to develop, gives a really good visual idea of what the product is doing, how it will operate, without actually diving into choosing specific technologies and starting to code anything. I like to start there. If we can then take that clickable prototype, we can use that to identify who is our customer segment. Let's make sure that we're solving the right problems for them. If we're not able to sell a clickable prototype, it's pretty I'm pretty confident that we won't be able to sell custom software either. So it's a lot cheaper for us to start with that clickable prototype and then go up from there. 

0:14:30 - Mehmet
Yeah, talking about clickable products, I mean design. What do you think of the no code tools that they are now spread across Like? Do you think are they good enough to build also a prototype, like a more realistic prototype, I would say? 

0:14:46 - Brian
I do. I do so that of most common business to business software, I think can be solved with the more popular low code or no code solutions. I think they're a great place to start. There's ways that we can leverage those tools to start to understand what is the final product going to look like. Some companies, some products may never graduate from a low code or no code solution to custom software, which is even better for them. They aren't paying the expense of developing custom software and then ultimately having to support that custom software. 

0:15:30 - Mehmet
Now I want to come to a topic which I think it's underrated. I speak with a lot of actually it's not only in startups, but I speak with a lot of startup founders and, let's say, small, medium businesses, and I find out that they are not taking care of their information security or cybersecurity. So, being in the field for a long time, brian, what do you say about the role of cybersecurity in startups and how people like yourself, fraction city O's can address this aspect, advising companies of taking better I would say cybersecurity plans? 

0:16:16 - Brian
I think it's hugely important in an area that I spend a lot of time researching and talking about. Cybersecurity is really important to an organization. Unfortunately, a single issue or vulnerability in an application can completely demolish a company, a business, and that's a real has a real negative impact on companies. So for me, I really like to focus on making security a foundational component. A lot of the organizations that I do work with tend to be in more regulated industries, like healthcare or finance, so those do have already more strict requirements, but I think security is very important Now from an application and software perspective, we have to get security right all the time. 

Unfortunately, nefarious actors or hackers, they only have to get it right once. So we have to make sure that security is a foundational component that we're always looking to as we're developing our solutions. Now it can vary in early stage startups it might not be as impactful or as important because we don't have as much data, as much valuable information that draws the attention of hackers or nefarious actors, but we're also not able to bolt on security later in the game. So we really have to make it a foundational component and really build it into not only the application but also the engineering culture as well. 

0:17:56 - Mehmet
Yeah, Now let's come to the famous topic, which is now very active. Actually, I was just playing before recording this episode. I was playing with the new ChagYPT code interpreter, the new feature that they have released. So how you see the impact of generative AI and AI in general on the role of the CTO first, and on the startup and what we both are, I would say, ambitious about technology in the future. 

0:18:34 - Brian
It's a great question and I know it comes up often. It's one that AI in general, I think is absolutely revolutionizing the way that we live and work. It's going to continue to be impactful and change the ways that we are able to generate and do the work that we do day in and day out. From a developer's perspective, I found it to be hugely beneficial to be able to ask a simple question and generate just really really helpful code that in even months prior, would have taken me hours to cobble together across a series of blog posts and Stack Overflow articles as well, and so it's really really helpful to have that power at our fingertips. From a CTO perspective, it's something that really kind of keeps me up at night, because of the capability that it has to be able to read the code that we have internally and inside any organization is really I kind of see it as a vulnerability. 

We're able to input our code into these systems. We don't know who has access to some of that data in the future. Another big concern that I have is around how much developers trust the code that's being generated, especially for the folks that only have maybe a few years of experience in the industry when they're generating code, they may be copying and pasting that code directly into the applications that we're developing. Now we saw the same kind of thing from Stack Overflow in the past. I think now we're just able to generate code even much more quickly, being able to take that code, input it right into our applications and then ship those applications into production and out to our customers. That does have me worried. For me, I look to our processes, to how can we not only build a culture around what code do we generate, how do we generate it, but also what is our review process and what do we accept into our code base. I think a lot of that comes down to the culture that we create within the engineering organization. 

0:20:54 - Mehmet
Yeah, I think. Regarding the code part, brian, I'm not sure if you would agree with me or not, but someone and I hear this a lot, someone I hear hey, these guys, they took an open source code and they just almost copied it. They just changed the UI and they built a full-fledged commercial product on top of that. So someone might argue that, as you said, we've been doing this for a long time. I mean, not me, I know programming but I'm not an expert. But I mean this is something that used to happen. But yeah, I believe the biggest concern is regarding the quality, because people might be more lazy to really review the code. And again back to the security part. We're not sure, is this code safe to use? Does it have any issues? Yeah, so big question marks, I would say. Now we gave some advice, let's say, to the non-technical founders. So now what advice you gave to CTOs and technical founders? 

0:22:02 - Brian
I think the advice I have towards technical founders or CTOs is really just keeping a close eye on how is AI impacting tools, the same way that even before AI really had this upsurge in the last few months. 

What are the tools, the languages, the frameworks that are really coming out and kind of taking the ecosystem by storm. It's really important for us to kind of keep abreast of those changes. Now we may not pull those new technologies into our organization In fact, I really guide a lot of organizations against pulling brand new technology into their production applications but I do think it's really important to kind of keep an eye on where the ecosystem is going Now. It's important for a few reasons. One is really around hiring. Most strong engineers are not really excited about joining an organization that isn't following and adopting new patterns and technologies in their organization. They don't want to be working on legacy technologies necessarily, and I think it's also important from a security perspective as well, just kind of keeping up on where the industry is going, how it's shifting and how they can continue to serve their customers and keeping everything secure and safe. 

0:23:24 - Mehmet
Yeah, brian, just out of curiosity, because, as you are working with several organizations, slash startups at the same time, so do you cap the number of customers you work with at a certain time? And the reason I'm asking you is because, from a traditional perspective, when someone is a CTO of a company, they are not thinking about how we can enhance the product, how we can do this and, of course, we have capacity. So do you limit yourself to a certain number of engagements and is there any hack you can share with someone else who's thinking to go to this path of being a fractional CTO, on how to do it, the best way to keep organized and not getting things like mixed up? 

0:24:13 - Brian
Yeah, organization and prioritization are really some of the things that I'm constantly refining and evaluating. The way I structure my business is. I have a couple different engagement tiers and really what that means is the amount of time that I spend with each organization. Some organizations I'll spend, you know, upwards of 10, 15 hours a week working with. Some organizations I may only meet with once a week, you know, for an hour long session, and so it really varies in between those kind of two ranges. Really, it depends on what the organization needs at that time. 

A lot of the organizations that I work with, like I say, already have strong technical leadership. They have engineers in-house that are building the product, but they're looking for advice and help and how can they architect their applications for scale, how can they improve processes to have better product development, getting better resiliency within their system, and so it really varies. I think my advice to anyone looking at a fractional CTO or similar type of consulting engagements is really how do you organize and how do you over-communicate to your customers and your clients? I think it's really important to over-communicate and answer any questions that your clients may have before they're actually able to ask the questions of you. It shows a great deal of preparedness and experience in the industry, understanding the problems that individual organizations have and then being able to really make sure that you're providing the best value to them. 

0:26:10 - Mehmet
As we are coming close to the end, brian, like if maybe today some young entrepreneurs are listening or watching us and they want to get into the start up world, right, so what piece of advice is? I know we make it too much advice today, but I'm keen because the experience that you have and the organization that you have worked with really it's something impressive and I want the audience to get as much as possible benefit from that. So what advice do you give to young entrepreneurs? Maybe someone who just finished college, someone who's thinking to start something new? What you can say to them? 

0:26:54 - Brian
I think my advice is to really focus on what problem that you're solving for your customer and make sure that you're able to get that solution out in front of the customer. Talk with as many people as possible to really understand the problems that they have. One of the challenges that I see with a lot of entrepreneurs is they think that they understand the problem and the solution and start building that solution before they really understand who their customer is and what their true pain points are. 

And so my advice is really just to get out there, talk to folks and start to sell your solution even before it's built, because if you are able to tap into and identify the problem before building anything, then you've really identified the problem and you're able to start building the right solution and you won't waste all the time and the money that we often hear about in a lot of failed organizations. I think we're seeing a big shift in the industry away from coming up with a buzzword type of solution and raising a lot of venture capital money. I think we're definitely shifting back towards creating solutions for customers that have real problems and building real businesses around those solutions, and I'm excited to see that shift. But I think it does require us to really take a look at the business component and making sure that we're solving the right problem. 

0:28:25 - Mehmet
Yeah, 100%. I agree with you, brian, on this regarding the threat I'm seeing. And guys, if you are watching or listening to us, focus on, as Brian said, about the solution. And a good way to dig down is to find who is your, as they call it, the ICP, identical Customer Profile, whether it's like if something led to finance okay, who is in the finance? Is it a bank? Is it an insurance company? 

And then go dig more, dig more and find out who would be interested. Is it the CFO of the company? Is it the HR? Is it like the IT? And then you keep doing this until you find who is your ultimate customer that would be happy to buy your solution because you solve for him a critical business problem. And I love this relationship you did, brian, because when I work as a consultant, the thing that we are always looking for what is the ultimate biggest problem the customer has that my solution can fit too, and this is where we can do the math. So, 100%. Now I have, of course, I will ask you at the end about where we can find you, but before we close, usually I have a question Is there anything, brian, that you wished I asked you and how you would answer? 

0:29:49 - Brian
I think the one thing that I maybe wish you had asked is for any aspiring consultants really, some of the things that they should be focusing on outside of the technology. My answer there is to really start to develop your own personal brand. That's something that I know is becoming more of the norm these days, but from a technologist's perspective, it's not something that we're familiar with doing. It's not something that feels comfortable to us, but it's something that I think is very valuable to really start to push ourselves and to learn how do we build a brand, how do we make sure that we have our own voice outside of the organizations that we're working with, that we can start to share and contribute into the larger community. I think it's really important to start to develop those skills. 

0:30:50 - Mehmet
Ultimately, I think you'll need them as you continue to progress in your career 100%, and because usually us people with technical background we think ourselves that we are introverts, believe it or not, we're not. Actually, we can talk very good, we can articulate things in a I'm not saying better way, but because of all the stack background that we have, we can get it out in front of people. And 100% I agree with Brian regarding building your own personal brand. It's becoming something more and more important. Unfortunately, maybe you would see it as a how should I be doing like anyone else? I believe that moving forward, this is the way to do it, because think about it, if you are, I don't know, maybe a Python developer, fully stack developer today, how you would differentiate yourself from hundreds of thousands, maybe millions, of someone who does the same thing as you. We need to have this unique thing, and this unique thing is your brand actually, brian, before it goes where people can find more about you and your service. 

0:32:03 - Brian
Yeah, I'm most active on LinkedIn, so please feel free to reach out on there, connect with me, send me a message on there. I connect with everyone and I'm happy to discuss any further. I do a lot of interactions there. 

0:32:19 - Mehmet
Okay, great, I will make sure to put your profile in the episode description. Well, thank you very much, brian. I really appreciate the time for you this morning. It was very insightful, it was like full of advice, like which is brilliant, I would say. And, as usually when I end the episode, I mentioned this again and again Guys, if you're watching or listening to us, send us your comments and feedbacks. 

I would love personally to hear about what you thought about this episode and the store in general. Also, if you are interested to be a guest, like Brian was a guest today, don't be shy, reach out to me and we will arrange for it. Time zones is not a difference. Brian is in the US. I have also the view people locally here. I have the view people in New Zealand, which is on the other part of the world. No issues, so I can arrange for that. And please like, show us your support, subscribe to the podcast or, if you are watching through YouTube, give us a subscribe also as well. Thank you very much and we will meet very soon again. Thank you, bye. 

Transcribed by https://podium.page?via=mehmet