Logo

Software Developers Journey Podcast

#286 Brian Childress from geospatial data to fractional CTO

Resources

Highlights

Embarking on a career change can often feel like standing at the precipice of a daunting mountain trail. It requires the courage to take that first step and the tenacity to climb to new heights. Brian's story serves as a shining example of how it is possible to pivot from one passion to another, transforming from an outdoor guide into a software engineering maven and a fractional Chief Technology Officer (CTO).

Brian's tale is not one of overnight success but of a calculated journey that began with his love for the outdoors. His pivot into technology started in graduate school, where programming became a tool for his studies in Geographic Information Systems (GIS). This initial exposure to coding sparked a curiosity that grew into a rewarding career in the tech industry. His story breaks the stereotype that tech experts are only those who have been tinkering with computers since childhood. It reminds us that it is never too late to discover or pursue a new passion, particularly one that intersects with technology.

As we peel back the layers of Brian's professional transformation, we uncover the strategies that enabled his successful transition. He emphasizes the importance of sharing knowledge in scalable ways, such as through blogging, podcasting, or videos. This approach not only efficiently disseminates information but also positions one as an authority in the field. Brian also sheds light on the invaluable experience gained through moonlighting and freelancing, which allowed him to hone his skills without the immediate pressure of a full-time role.

Networking played a pivotal role in Brian's ascent. His proactive engagement in the startup community through meetups was crucial in forging connections that propelled his career forward. He offers practical advice for making an impression in such settings, advocating for strategic interactions that can open doors to new opportunities.

The episode takes a deeper dive into the evolution of Brian's career as he progresses from a junior role to a senior position in tech. He stresses the importance of focusing on maintainability, collaboration, and solving business problems sustainably. He shares insights into the art of convincing stakeholders about the importance of code quality by aligning technical discussions with business interests.

In his current role as a fractional CTO, Brian brings a wealth of expertise to organizations that might not require or afford a full-time executive. He lays down strong foundations in software architecture, engineering best practices, and team growth strategies. His approach is both dynamic and strategic, focusing on scalability and security while ensuring that he positions the organization for success even after his departure.

Finally, Brian's leadership playbook, which he describes as an evolving collection of ideas and processes, is a resource he generously shares with other professionals. He remains hands-on with coding to some degree, balancing technical prowess with leadership and business acumen. Brian extends an open invitation for further discussion, signaling his commitment to mentorship and his eagerness to tackle projects in diverse sectors such as healthcare, education, and cybersecurity.

Brian's journey is not merely a chronicle of personal achievement but a roadmap for those hungry for transformation. His experiences offer a blueprint for professionals seeking to navigate the rapid currents of career change and make an impact in the tech industry. This podcast episode stands as a testament to the power of resilience, adaptability, and strategic planning in forging a path to success in the ever-evolving world of technology.

Enjoyed the Podcast?

If you did, make sure to subscribe and share it with your friends!

Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.

Become a supporter of the show. Head over to Patreon or on Buzzsprout.

Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.

Thank you for tuning in!

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Tim Bourguignon: 0:00
So how do you help yourself to not say yes right away?

Brian Childress:

0:07
So one of the things I do like to do, if it's something like a mentorship or someone's asking for information, I, I try and I take an engineering approach and like how can I solve this in a way that scales? And so is it a blog post that I can write, or a video I can record, or a you know, a podcast, just like this that I can record and share with them as a way to not only answer their question but also potentially answer it for someone that doesn't know they want to ask the question yet. So that's really been something I've tried to focus on more and more is how can I scale the information that you know from one on one To one to many?

Tim Bourguignon:

0:47
hello and welcome to developers journey, the podcast bringing you the making of stories of successful software Developers to help you on your upcoming journey. I'm a host team. Oh yeah, all in this episode I receive Brian children's. Brian is a husband, father, technologist and avid adventurer. As a technological advisor with a strong background in software engineering, cloud computing and cyber security, he is Experienced in helping CTOs and CEOs make the right technical decisions for their organizations and the rest we're gonna hear today, brian, a warm welcome David.

Brian Childress:

1:24
Tim, thanks for having me. It's great to be here, but my pleasure, my pleasure.

Tim Bourguignon:

1:28
But before we come to your story, I want to thank the terrific listeners who support the show. Every month you are keeping the Dev journey lights up. If you would like to join this fine crew and help me spend more time on Finding phenomenal guests than editing audio tracks, please go to our website dev journey info and click on the support me on patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey Journey. Thank you, and now back to today's guest, brian. As you know, the show exists to help listeners understand what your story look like and imagine how to shape their own future. So, as as usual in the show, let's go back to your beginnings. Where would you place the start of your dev journey?

Brian Childress:

2:16
Let's see. I remember taking some very rudimentary programming classes in high school, but really I think for me my programming journey started in graduate school. Honestly, I Was not the kid Programming on my family's computer at eight years old. That just it wasn't me. So I really didn't get into computers until I went back to to graduate school and from there really really found my passion and have continued to grow and evolve in software engineering since then.

Tim Bourguignon:

2:51
For the non-us listeners, grad school is the equivalent of college, is something like this so post my bachelor's degree.

Brian Childress:

2:59
So this is working more towards like a master's or something along those lines.

Tim Bourguignon:

3:03
Yep okay, how did? How did you come to to discovering or rediscovering a computer programming at that point in time?

Brian Childress:

3:12
So my undergraduate degree, my bachelor's degree was in something kind of so far removed from software engineering and computer science. It kind of wasn't even funny. Actually started my professional career as an outdoor guide, so I would take people white water rafting and mountain biking and rock climbing and that sort of thing and really, really enjoyed that work, but found, you know a little bit of time into that that I wasn't completely fulfilled. It wasn't really kind of, you know, is intellectually challenging, didn't really kind of do the things that I was looking for to do, and so I at that point I went back to graduate school. I went back to college To learn a geographic information systems. I felt like that was a good kind of blend between the things that I found interesting and my, my passion for outdoors and outdoor venture, and that's what got me into programming. At that point we were learning Python, was the primary language that we use in GIS and was, you know, building some small data analysis programs and working in various systems, and you know that that was kind of, I would say, the beginning of what's led me to where I am today.

Tim Bourguignon:

4:29
So very much as a tool first for doing something else, for doing GIS analysis or whatever you do, and then it evolved into a subject matter in itself.

Brian Childress:

4:42
Absolutely.

Tim Bourguignon:

4:43
Yep, it's exactly right. Do you remember when, when the this this, this u-turn happened?

Brian Childress:

4:51
I was a ski bum, so I was living in a small town in Colorado, I Was a painter during the day and that allowed me to live and ski and do those sorts of things, and you know that I had a great time. Right, I was in my early 20s and, you know, from there went and did some Outdoor guiding. I had already been doing it, you know, kind of all throughout college but found, you know, I want something different, right, I just I want a different challenge. And it was at that point that I decided, hey, let me look at Going back to school for something To continue to, you know, grow and expand my skills and maybe find something that I'm even more passionate about. And that's where I kind of stumbled into GIS as a. I had no idea what it was when I even started looking into it. It just kind of brought together a few different interests of mine and then from there I just continued to evolve and After graduate school, got out into into the workforce developing software.

Tim Bourguignon:

5:56
Okay, so you didn't. Didn't work as the GIS expert, but what would you do as a GIS graduate?

Brian Childress:

6:04
I did for about four months. Okay, I worked as a contractor for the transportation department and so, basically, for GIS, it's it's, you know, putting information and Tying it to points on the globe, right. So it's the same technology that makes our GPS units work. And you know Strava and all of those types of apps. It's all based on GIS technology. And so, you know, working for the transportation department, I it was not nearly as glamorous, right. I was basically putting together and analyzing large amounts of data that had been collected on our highway systems and bridges and culverts that run them underneath roads, and Signs that are on the side of the roads and that sort of thing. And so, you know, it was, it was good, you know, to kind of get out there and practice a lot of the things that I had been learning in school, but it wasn't, you know, it wasn't exciting, it wasn't the thing that I was really looking for, and and in a prior job that I had had, you know, one of the so I worked three jobs to put myself through Graduate school and one of those jobs I had worked with a company who was doing they were contractors for Medicare and Medicaid and they had an opportunity to come on as an application developer with their group. So they had an internal software platform that they had built and they offered to bring me on and I jumped at the opportunity. I thought it was be a great way to kind of learn and you know, I I think I kind of missed being a junior developer and kind of going through those Climbing the ranks. I kind of skipped right over some of those steps and was thrown right into the deep end and you know, I think I've continued to To to go forward from there.

Tim Bourguignon:

8:00
Is that your way of learning or of Going at problems with with air quotes, jumping the cold water, going to the end and and see what happens?

Brian Childress:

8:11
I Think it is Maybe not intentionally, it just that seems to be the way it happens. But yeah, I kind of just you go for it and figure some things out along the way and get some skin to knees and that sort of thing. But yeah, I would say it's probably been a theme throughout my career is to kind of take that approach.

Tim Bourguignon:

8:34
All right, fair enough. How did you go being I assume and correct me if I'm wrong kind of a sole developer during your studies, working on your data analysis and tools, but probably At least it was for me without all the best practices of software engineering? I'm really doing coding, I would say, but, but not Crafting software for the long term, with, with the legacy in mind, etc. And jumping into this new world of application development and discovering all this. Assume all the. Do you Discover that beforehand? How did that transition?

Brian Childress:

9:11
work, not. Yeah, I very much learned that on the job, and a lot of that was just what I thought was right, because I didn't necessarily always have a team that I could rely on. I didn't have a great software mentors that I could lean on that had years of experience, and could you tell me about all the ways that this could go wrong? I can just Follow my gut and, thankfully, made some decent decisions most of the time. Yeah, I didn't really. I didn't have a lot of that mentorship early on, and so I saw it out in other ways. I tried and I think early in my career is when I started to. Not only I was working full time as an application developer, but I started freelancing and moonlighting and doing development projects on my own, and I think I tribute a lot of my success to that hard work Doing freelancing and moonlighting to learn a lot of those things, and it was just another way that I could make those mistakes and then I learned from them.

Tim Bourguignon:

10:16
That's the deep end of the pool again yeah, right going from freelance projects as the not junior but still beginner in your career. That's ballsy. How did you find those projects? How did you manage to get in there with probably not so much experience to show for?

Brian Childress:

10:42
I don't know charm and charisma. I mean some of the early projects you know I was finding on I don't know if you're familiar with it, but like craigslist dot com. So I mean this is many years ago. You know I was creating websites for wedding venues and insurance companies and that sort of thing. It wasn't wasn't necessarily software engineering, right, I was kind of largely putting together wordpress websites. But you know I had met some people at meet ups really good friend he and I still collaborate today Met a meet up group just randomly, you know still user group, and he and I have collaborated and worked on things and so he and I would Kind of bump through that together, you know. But I just always looked for opportunities to kind of learn and found a you know a lot of the things that I was learning on my own in those early days I'm continuing to use today. So it was really really beneficial. I probably didn't know what I didn't know at that point. Maybe that was an advantage because I didn't let it hold me back that I didn't know those things.

Tim Bourguignon:

11:59
Yeah, the benefit of being young and still naive. You mentioned. You mentioned meet ups. See, you discovered meet up really early on in your career.

Brian Childress:

12:12
I did. I did, you know. I was just ravenous because I didn't. I wasn't collaborating with a lot of people in my day to day work, especially not from a software perspective, and so is ravenous for more information and to be around folks that were doing it. And it was kind of at that time where start ups were a really, really sexy thing, like everybody wanted to be in start ups, you know, because we were hearing about the explosion of google's popularity and all the you know, the free food and the you know slides and all of those kinds of cool things that was coming out around that time, and so there was just a lot of draw towards it. I had one of my college roommates what is a founder in a start up and you know, I mean it was like three guys in a small bedroom apartment in san francisco like developing software that ended up Growing and growing, like it was just a very exciting thing, and so I wanted to find a way to break into that, and meet ups were a way to do that, and at the time I was living in denver and there's a huge start up population there, and so I was able to attend a meet up every night if I wanted, to Different user groups. It was just a very popular thing and you know, from that, made a lot of great connections, learned a lot, you know. It also kind of pushed me out of my shell. I'm not naturally, you know, kind of extroverted, or, and so it really kind of pushed me to go and meet other people and learn from them and see what I can share and maybe help them in some way.

Tim Bourguignon:

13:49
I'm gonna be piggyback on that. How would you Behave, going into a meet up? First meet up you come in the city. You haven't been to that meet up yet and the first time you show up, how would you be able to start making connections, feel at ease, just just feel like somebody who's a who's a welcome there.

Brian Childress:

14:13
You know it wasn't easy for me. You know I tend to be kind of more reserved, held back, I'll be the ones kind of sitting in the back corner of the room kind of seeing what others are doing, you know. But I found for me the way that I kind of broke through some of that was I would sit like in a spot like up towards the front, like a couple rows back, kind of a few seats in, basically in a spot where Someone was almost forced to sit next to me and then when we're sitting next to each other, like most of the meetups where there was a presentation and then some networking and we have pizza and beer afterwards, and so by having somebody sit next to me, then you know it was just more of a one on one conversation that I could kind of break through that. You know that anxiety or that fear and we can start to talk about things. And because we were at the same user group, it was largely based around specific technology or you know a topic that was really interesting. I could then use that as my opening. You know, hey, tim, what would you know interest to about JavaScript or something along those lines?

Tim Bourguignon:

15:31
That's. That's a good one. I've heard a couple others and how to, how to break in there at one. One was to sit as well in the front, but mostly to attract the eyes of the person speaking. When you're speaking, you're quite often searching for somebody who's really attentive and and then you focus on that person. It's your, your persona, for the audience, and I found it personally Call me to be that person for the, for the speaker, and then it was easier to talk to the speaker afterwards and break the ice and you've been looking at me for an hour now, so let's chat and that felt easier, at least to me, and I've heard that from a couple persons as well that eat, help them break that high in that ice and that's great.

Brian Childress:

16:17
I mean I do the same thing. Now that I'm doing a conference speaking, I do the same exact thing. I'll pick out a couple people in the room and they're my anchors. No one else exists in the room.

Tim Bourguignon:

16:31
That's the secret. It really really helps, really helps. And the other one I've heard is to go to someone and ask them for referral. Asking them maybe you know who I could talk to about react. I'm passionate about react. Maybe it's not a react meetup, I'm passionate, but react. You know someone here who I should talk to and it's a great way to to have this person, to have this person answer you and help you without cornering her or him into having to talk to you. If they, if they don't want to talk to you, they can just say, well, talk to Bob of their he's, he's knowledgeable about that, and there you go. And if they, if it's their topic, then they can start talking to you. And these two combines of sitting in the front and using this, this diversion technique, is really helped me personally in many conferences. To come there and know no one and start talking from the get go. That's really really helpful.

Brian Childress:

17:27
Nice, I like that a lot. I mean, I have to borrow that, yes.

Tim Bourguignon:

17:32
Okay, so you are in that journey, started your first gigs, or at least your first job, doing God knows how many gigs on the side as a freelancer and learning during meetups. Did you sleep at that time?

Brian Childress:

17:47
Not much. Thankfully, in graduate school I was also introduced to coffee, so I've been a an avid consumer.

Tim Bourguignon:

17:57
sense yeah so how long does a lifestyle work out? Do you have to change something at some point?

Brian Childress:

18:09
Um, I don't know, I think I'm just, I have a personality that naturally just I want to have a lot of different things going on, you know, and so I found it ebbs and flows a little bit. I kind of get to the brink of burnout or maybe actually burn out, and then I have to take a little bit of a break. But I like, a lot of things interest me and so I try and, yeah, we explore a lot of different things.

Tim Bourguignon:

18:39
Do you have to actively Restrain yourself from from going in one or the other direction just because you know it's gonna be too much?

Brian Childress:

18:48
Now I do, I absolutely do. Earlier on, I think In those early days you're just looking for anything, especially around technology, like which technologies do I enjoy, which ones do I not? What problems do I like to solve, what industries are interesting? And now I feel like I've Got a better idea of those things and so I try to Restrain myself a bit more. But it's still hard to say no with somebody comes and says, hey, can you help out with this thing or do you mind mentoring me? It's, it's really hard to say no.

Tim Bourguignon:

19:24
How do you Help yourself to not say yes right away?

Brian Childress:

19:30
I. So one of the things I do like to do, if it's something like a mentorship or someone's asking for information, I I try and I take an engineering approach like how can I solve this In a way that scales? And so is it a blog post that I can write, or a video I can record, or a you know, a podcast, just like this that I can Record and share with them as a way to not only answer their question but also potentially answer it for someone that Doesn't know they want to ask the question yet. So that's really been something I've tried to focus on more and more is how can I scale the information that you know from one on one to one to many?

Tim Bourguignon:

20:11
Okay, and and so you've been writing blog posts, publishing videos, etc. Creating your own content for that or Partly for that partly for that, partly for myself.

Brian Childress:

20:23
To you know, my, my blog is taking a bit of a hit of the past year, to just Life, it's gotten busy. But I originally started that for me. I wanted a place to be able to reference information and so I started it there. And you know I found just having a blog, a public Space on the internet, has been hugely beneficial. I mean, it helped me to get jobs and bypass technical sections of interviews and it's been really, really helpful.

Tim Bourguignon:

20:58
And there's not quite anything like googling for something and finding one of your own blog posts.

Brian Childress:

21:04
I wish I could tell you how many times that's happened, that I've appeared on the first page of Google and oh yeah, I wrote about this a year ago. I've already figured this out.

Tim Bourguignon:

21:15
And for God, I love it. Which is awesome just write about it. You immerse yourself enough into the subject matter to really be able to write about it and then forget about it entirely and really discover it later.

Brian Childress:

21:33
It's just like high school, right we studied enough to pass the test, and then we immediately forgot everything. I just have a resource.

Tim Bourguignon:

21:42
You mentioned. I'm jumping back a bit. You mentioned you skipped junior dumb, I'm not sure that the word, but now it is and you jumped both feet first into a more senior role. And how did that evolve afterwards? Is there some more graduation of senior? Is your different flavors of seniority? What kind of thoughts does that trigger?

Brian Childress:

22:09
I think for me, yeah, there were various areas of senior that I focused on, so it became less about creating something that worked and more focused on creating something that's maintainable, that I can collaborate with a larger team on. That continues to kind of focus on solving a business problem. So it still wasn't as like heavy technology focused, it was just more how do we solve this problem, do it in a more maintainable way, because you know a lot of the things that I was doing earlier on it wasn't as important, it wasn't, they weren't as long lived projects and that sort of thing. But as I continued to progress in my career, I found that that was actually important, and so then I became the person that really, really focused on you know, quality and craftsmanship in the software and took a lot of pride in that, and so you know now Working with a number of different clients, that's something that I really really focus on, because I found it hugely valuable for me, for the teams that I worked on and now, you know, for my clients as they continue to grow and scale. It's something that I still like to focus on.

Tim Bourguignon:

23:25
How do you approach selling is not the right word, but but convincing somebody? They have a software which is working and now is the time to start focusing on more quality, more craftsmanship, more sustainability and more effort for the long term. How to approach this discussion with them?

Brian Childress:

23:47
So I think it's important to know our audience and who are we talking to, and so I always like to understand what are the things that drive that particular person. If it's the business owner, they may not care about the code quality as long as it works. So I can talk about, well, what happens if it doesn't work, or what happens when we need to expand it to onboard a new customer that's going to bring additional Revit, new into the business, and if we don't focus on the quality and the craftsmanship and the maintainability now it's going to be very difficult for us to bring in that new customer, which is then either going to delay them coming on board or potentially we could lose them as a customer altogether. And so really kind of focusing on what is that particular person interested in and then tying in the technology and software from there.

Tim Bourguignon:

24:42
Hmm, yeah, that's a very, very important advice Really knowing your audience and tailoring your arguments for that. Obviously, if you start talking with them about principles, solid principles, etc. It's not going to connect. No, they usually are. So in the in the Bible I read at the beginning, you kind of hinted as now you would be doing some kind of consulting job. Is this how you would describe it?

Brian Childress:

25:15
Yeah, yeah. So you know I'm doing the kind of freelancing in the moonlighting for a number of years, so I mean call it consulting, and so now I'm full time, fractional, cto and technical advisor. So I consult with a number of different startups and small media and businesses that are developing custom software, typically in the B2B space, and helping them to. You know, I like to say that I help get turn around struggling software projects and help them to scale, and so that's that's what I do.

Tim Bourguignon:

25:50
Okay, so fractional CTO would be kind of a sidekick offer CTO learning the ropes, or how would you describe the fractional CTO?

Brian Childress:

25:59
So the way I operate is you know, I bring years of you know, expertise and you know lessons learned and mistakes made to organizations that may not need or may not be able to afford a full time CTO and oftentimes, they don't need a full time CTO. A lot of organizations are probably just looking for a really strong lead developer and they call them the CTO, and so what I'm doing is helping them to. You know, I bring a strong background in software architecture and scalability, so we'll focus there if that's what they're looking for. Bring in a lot of just software engineering, best practices, right Code reviews and deployment strategies and that sort of thing. Bring a lot of that in big focus on security as well application security and you know how can we grow the team in a way that's effective All of those types of things I help my clients out with. So it's it's a bit of a mix. You know, different fractional CTO is kind of focus in different areas, but those are the areas that I tend to focus on most.

Tim Bourguignon:

27:05
OK, so I hear really laying down the foundation, whispering the right words, putting things in motion so that it evolves in the right direction from the get go, and then it will evolve without you. You'll probably be somewhere else, as I imagine your gigs probably short term or a few months, but not much more than this. Am I right there?

Brian Childress:

27:26
Typically, yeah, I kind of aim for three to six months. In most organizations it may be longer. We just might taper off how much time I'm committing to that particular engagement. Yeah ultimately, my goal is to work myself out of a job right, put those systems in place to empower the right people, potentially bring on board full time the people in the right role and then kind of work myself out of it. You know, that's tends to be the best and the most exciting approach for me.

Tim Bourguignon:

27:58
How do you manage to get in and right away start thinking about your exit? I would go full, all in and say, ok, now I'm there, and two years later I would wake up and say, oh gosh, where did time go. How do you handle this? Phasing in, phasing out and right away probably searching for next gig and phasing a different gig at the same time? How do you handle all this?

Brian Childress:

28:21
So it goes kind of can I give the classic, it depends. We've got a bunch of developers. So I tend to kind of ramp up quickly. We'll do, potentially, a discovery month where we figure out OK, what are the real problems here that we want to solve? Is it scalability, is it team collaboration, is it, you know, we pick the wrong technologies and we need to do a big refactoring. So we'll figure out what's going on, kind of put together a strategy, put together, you know, what resources do we need, what team members do we need, and then I'll tend to oversee that process as it goes through. You know, we'll kind of adjust as needed and then ultimately taper off. And so once the project is moving along well, the right team members are in place, then I'll taper off into more, like of you know, kind of an advisory or a retainer type of role when I'm still available to the team, but not necessarily as hands on day to day. But I mean it's nice because I can kind of come in and shake things up and really focus on what's best for the business, what's best for the project. You know, I don't have the same type of limitations. I think around like trying to be friends with everybody, right? I don't want to, you know, alienate anyone, but you know I am coming in there to solve a problem, I am coming in there to help the organization. So, with that focus, it allows me to, you know, make some decisions that I might not make if I were coming in as a full time person.

Tim Bourguignon:

30:13
Yeah, makes sense, makes sense. You mentioned the tagline oh, at least I know it's your tagline on LinkedIn Helping struggling projects. Do you think it's because of this tagline, because of this focus that you've been giving to your career, that companies which are struggling at a point in time go out and reach out to you? Or is it all those companies try to make it on their own and at some point realize something is not working right and at some point then reach out to find somebody with knowledge Call it a fractional CTO or any other name and then find someone to steer the ship back into the right direction?

Brian Childress:

30:55
Yeah, I don't know that it's the tagline necessarily that draws them in, but I have, from a lot of my LinkedIn content has drawn folks in to my world. So, you know, I've had the pleasure of working on a number of different projects that were struggling Because they, you know, the architecture, the technologies that they had chosen were too complex, the team wasn't delivering on time. They, you know, may have had other challenges. They might have hired a development agency or a freelancer who just kind of walked away with all the code. There's a number of different things that have kind of happened but, yeah, a lot of the content that I put out on platforms like LinkedIn kind of speaks to the challenges that I see, unfortunately, day to day, and its organizations that you know may not have a strong technical focus and so they relinquish a lot of control over to the development team or even an outside agency or an outside freelancer and they just lose control and ultimately, you know, a lot of the times when I come in, it's, you know it's the. I've got a lot of work to do. I rent things around sometimes.

Tim Bourguignon:

32:11
I hear you. I'm sure I want you to swear, but then know, if you could, if you, if you imagine going to a project that wouldn't be struggling right now, would you be attacking the this problem that's called the problem with the same, the same way, doing this discovery months, trying to find where the problems are? Would you go at it differently if it wasn't obviously struggling from the get go?

Brian Childress:

32:39
I think I would go at it a little bit differently. Typically when I come into a struggling project we've spent a lot of money, we're over budget, we're over time, the team is frustrated, they're working a lot of long hours I think we can make some very drastic, quick decisions to kind of turn us around. But if that's not the case, I love to come into projects where I just get to sit and hang out and talk with the developers one-on-one, maybe provide some mentorship to them and just see where things are. What is that normal process for the team and look for areas that I can add some efficiencies that I can continue to maybe push some of the developers towards opportunities of growth, if that's what they're looking for. So if I don't have to, I love to be able to sit back and just see how things operate and really just make sure that I focus on showing that I really appreciate all the work that has been done up until this point. Because if those developers hadn't put in all those hours and the blood, sweat and tears to develop the platform to what it is today, I wouldn't have a job. They wouldn't be bringing me in Now. I might be coming in to fix and tweak things, but it's because of all their hard work that I have the opportunity to come in. So I always want to be grateful for that and really show the developers that I'm there to help support them.

Tim Bourguignon:

34:08
Amen to that. It's always a hard balance to strike between coming in and seeing things and saying, hey, maybe we should change this, and you know you're going to hurt some feelings because that's the way they were successful so far. And so you're going to push places where it usually is painful, but at the same time listening in and really understanding from how it is called second degree observation, understanding why are things this way, why it was done this way and why it evolved into this situation. To just really understand how it came to being there and not just remove something that is absolutely crucial for the organization. It sounds silly. You just remove it and the organization crumbles. So really trying to find this balance is always hard. And how does it work on the three to six months timeline when you first want to observe? Do you have enough time?

Brian Childress:

35:04
So we can observe in a lot of different areas, and so I tend to really poke in a lot of different places. I'll not only schedule conversations with the kind of the key folks. I'll schedule conversations with members across the team. I'll poke around and slack, I'll look at the conversations that are happening and all the public channels and any private channels that I've been added to Just see what that conversation is. I'll look at pull requests and the comments that are added there how is code added and deployed and I'll look at documentation and how are we collaborating on that. And so there's a lot of different areas that I can kind of observe without it being a one-on-one conversation with someone, and so I'll look for those areas. I'll look for trends and from there I've been in enough organizations and on enough teams and projects that there's at least a few different solutions I might be able to propose to the team as an opportunity to improve, I see.

Tim Bourguignon:

36:16
You've mentioned burnout or kind of burnout before. This is going in, going out, jumping on a new project that's probably linked with a lot of stress, or at least long hours to really find the north, find north, understand what's happening, the topology of the company, etc. And then, by the time you're confident with all this, well, it's time to start with your company. Do you think you have stamina to do this for a long time? Do you see yourself doing this for years and years, and years?

Brian Childress:

36:54
I think so. I've certainly evolved my approach over time. I've got a much more robust playbook that I follow now. That allows me to kind of get to some of that information a little bit more readily. But I think some of my next phases are actually going to be to grow the group that I work with and collaborate with closely, so potentially bringing on other architects and technical advisors and other fractional CTOs to be able to help me to scale and take some of that day-to-day work off of my plate so I can be a bit more strategic with some of the work, but not I still want to be able to help as many organizations as I can to deliver great software at the end of the day.

Tim Bourguignon:

37:44
But when you mentioned playbook, it sounds like taking up a silly project of writing a book about all this, which would end up with even longer hours.

Brian Childress:

37:56
It's conversations like these, and so anytime that I find that I make a suggestion or come up with an idea, I'll dump it into the playbook and just kind of continually add to it over time, and so it's more of a what would I already be doing normally. Let me put that into one place. Instead of a concerted effort to write a book, it's more just kind of collecting from all my notebooks and all my conversations, pulling all that together.

Tim Bourguignon:

38:26
Is this publicly available? Is this your blog or is this still notes for yourself.

Brian Childress:

38:32
It's a mix, so some things I'm happy to share any of it. None of it's secretive, but I don't have it in a pretty format that is probably digestible by most, but yeah, anything like there's. How do I do due diligence on a technical project? How do I do an architecture review? A lot of those things I've absolutely shared with other fractional CTOs or technical advisors in the industry. I'm happy to share any of that if it's helpful in any sense.

Tim Bourguignon:

39:04
If we can link some to the show notes to give a taste of what we've been talking about. I think that would be great for the audience.

Brian Childress:

39:12
Absolutely yeah, happy to share.

Tim Bourguignon:

39:14
Awesome. Do you see yourself doing this for years and years and years? So you said yes, kind of. But I heard I heard helping more companies. Is this scalable, being in the trenches and doing some strategic work, etc. Will you work change basically?

Brian Childress:

39:35
That's what I'm trying to figure out now. If I'm honest to him, what does that scaling look like? Having a playbook, having a set of repeatable processes, certainly helps, I think, helping to scale it. I need folks to collaborate with colleagues that have years and years of industry experience and have been in those trenches before and have really that level of experience and made some of those similar mistakes to be able to collaborate with. I think that's something as an industry, we're struggling a little bit with because we don't have a ton of people at that experience level that are still practitioners in the industry. I'm always looking for opportunities to collaborate with folks in that way.

Tim Bourguignon:

40:24
There you put the word I was trying to find and ask my question very clumsily being a practitioner. What I fear for you when I hear this is that you're going to graduate into some kind of management slash, strategic position and not be a practitioner anymore. I fear it because I have a feeling that you need this practitioner stance from 14 minutes discussion together. If I'm putting you in the wrong box, sorry about that. I fear you would be missing it at some point.

Brian Childress:

41:00
You're absolutely right. So, selfishly, I hang on to a couple projects where I'm still hands-on coding, where I still have the opportunity to bring in some new technologies, some new patterns. I think I will always maintain that I may not do as much hands-on keyboard coding as I have, but I'll always hold on to a few projects there, and part of the way that I've tried to design my business and ultimately the life around it is to have time to be able to go and explore some of those new areas and really just have fun with it. I think that's a thing that really keeps a lot of us technologists in the industry is there's so much new things that we can play with and experience and explore. I certainly want to be able to continue to do that for a long, long time.

Tim Bourguignon:

41:50
Oh yeah, I mean to that. If somebody was wondering, hey, this fractional CTO thing kind of sounds like fun They've been more or less as a senior software developer somewhere doing a lot of things inside a company but saying, hey, this is helping other companies put out the right foundation at the right time, that sounds like fun. What would be your advice to start getting into this direction?

Brian Childress:

42:18
Yeah, I like to say that technology is the easiest part of what we do. In many ways, it is as technologists. I can Google my way to a solution. On the technology side, I think the skill that we have the opportunity to continue to develop is around. How do we collaborate with other humans? How do we collaborate and communicate across time zones? Like you and I are today Putting yourself in a much more of a leadership position and really focusing on not only the people, the collaboration, but also the business as well. I think as technologists, we're always excited about implementing new technologies and new patterns, but at the end of the day, we need to make sure that it serves the business, because the business needs to make money in order to pay our fancy developer salaries. I would encourage anyone that's considering something like this to really start to focus on the leadership and the business acumen. We're solid technologists. We can continue to learn and evolve there. That's a small portion of what we really need to be focused on to be successful.

Tim Bourguignon:

43:37
Absolutely. Thank you for highlighting this, Brian. It's been a blast. Thanks for coming to your story, starting in GIS and diverging entirely and ending up whispering in the ears of CEOs and CEOs worldwide. Where would be the best place to continue the discussion with you?

Brian Childress:

43:59
I would say right now I'm most active on LinkedIn. I encourage everyone to reach out, connect with me, send me a message on there. I'm happy to connect and schedule a call if it makes sense. That's going to be the best place to connect.

Tim Bourguignon:

44:12
Do you have anything on your plate that you want to highlight before we call it a day?

Brian Childress:

44:17
I've got a lot of really interesting projects going on right now A couple in the healthcare space that are AI focused, a couple in education, in finance, cybersecurity. I'm really, really excited about what this next year holds. I think there's going to be a lot of really fun projects and opportunities.

Tim Bourguignon:

44:41
Can we read about it on LinkedIn or on your homepage when you write about it?

Brian Childress:

44:45
Yeah, absolutely, I'll definitely be sharing. I'm learning every day. Typically, what I share on LinkedIn is something I learned the day before.

Tim Bourguignon:

44:56
That's the best source of ideas. It's just falling flat on your face and saying, oh, I have to write about that.

Brian Childress:

45:04
Absolutely right.

Tim Bourguignon:

45:06
Brian, thank you so much. I will add some links to the show notes with LinkedIn, your own page and maybe a couple of pages of the playbook you've been gathering along. If you want to connect with Brian, don't hesitate. Go to LinkedIn and reach out. Brian, thank you so much.

Brian Childress:

45:21
Tim, thank you.

Tim Bourguignon:

45:23
That's been another episode of DevGhost Journey. I will see you there next week. Bye-bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you like the show, please share, rate and review. It helps more listeners discover those stories. You can find the links to all the platforms the show appears on on our website devjourneyinfo. Subscribe. Talk to you soon. Bye-bye.