Matt Dixon, a seasoned tech leader and fractional CTO, shares insights on aligning technology with business goals, addressing revenue leaks, and the importance of mindset in leadership. He discusses the role of a fractional CTO, the significance of metrics that matter, and the challenges of managing technical debt. Matt emphasizes the need for effective team dynamics and the dangers of shiny object syndrome in tech. He also explores the future of AI in business and the evolving role of CTOs in modern organizations.

Chapters

00:00 Tech, Business, and Leadership

04:16 Revenue Leaks and Fractional CTO Work

08:41 Working with Existing Tech Teams

13:02 Managing Expectations and Misunderstandings

16:39 Code Program and Misaligned Priorities

20:58 Technical Debt and Shiny Object Syndrome

26:47 What CTO's Should Be Doing

28:55 AI in Tech and Business

About Matt

Matt Dixon is the Founder and CEO of Front Range Systems, serving as a Fractional CTO for growth-stage companies generating $10-75 million in revenue. With over 25 years of technology leadership experience, Matt specializes in identifying and eliminating "revenue leaks": the invisible operational inefficiencies that cost companies significant money through manual processes and misaligned systems.

Now based in Nashville, Matt focuses on logistics, insurance, healthcare, and sports industries, delivering operational clarity and measurable cost reductions within 90 days.

When he's not helping CEOs fix their operations, you'll find him on track days pushing limits behind the wheel or traveling with his wife.

Where to find Matt

• Website: https://frontrangesystems.com/

• LinkedIn: https://www.linkedin.com/in/mattdixon/

• Instagram: https://www.instagram.com/fractionalctomatt

• YouTube: https://www.youtube.com/@FractionalCTOMatt

I've seen a lot of different organizations worked on a lot of different projects. So I've seen most of the movies they have to play and I know how it ends.

So I can help them either have the successful ending or the not so successful ending. It's really a matter of helping them get their business goals together.

And then we say, all right, what are your tech initiatives that we can do? To support those business goals.

Welcome to the CTO Compass podcast. I'm your host, Mark Wormgoor, tech strategist and executive coach. In every episode, we meet tech leaders from startup CTOs to enterprise CIOs to explore what it means to lead in tech today. They share their stories and their lessons so that you can navigate your own journey in tech. Let's dive into today's episode. Here's someone who knows how to align tech with business insights. Matt Dixon, he and I met on Dan Martell's Elite Coaching Group. He's the founder and CEO of Front Range Systems, and he serves as a fractional CTO for a growth-stage company between like say 10 million and 75 million in revenue. He has over 25 years in tech leadership and he helps businesses eliminate, and we're going to talk a lot about that, revenue leaks.

So those invisible inefficiencies that quietly drain the profits. Beyond the technical work, Matt really loves bringing the founder mindset to businesses and because he's part of Dan Patel's group, we are gonna go hard on scaling systems and mindset.

So let's dive into how Matt has actually combined his deep technology with the execution side of it. So Matt, welcome. Before we start, Tell us a little bit about yourself.

Yeah. Thanks for having me. I have been doing tech for a long time. It feels like forever. 26 years in March.

So that's exciting. And yeah, One thing I like to do when I'm not at the computer is I have a racing simulator and then I have a BMW like taken to the track.

So, Those are two fun activities, especially racing on the track or driving on the track. It's not actual racing. But it's fun to be out of your comfort zone and to try something that you've never done before and think you're going to die. And look, I didn't. That's I have a 21 BMW M2 competition.

So cool, racing on the track. Can I ask what kind of BMW?

Yeah. Cool car. It's a ton of fun.

Yeah, sounds like it. Let's get into the tech a bit more. You started in deep tech and now you're helping businesses and you're even going more into leadership and mindset as well. How did that switch happen over the 26 years?

Well, I started as a software developer and I didn't know what I was doing. Obviously, no one does when they first start their career. And I just continued to learn about the tech, trying to be the best developer I could.

And then I was job hopping to get a raise because no one's going to give you a big raise. But if I go to another company, they will.

So I was doing that. My wife's like, OK, can I take the kids to this doctor? How about that one?

So I thought, all right, maybe if I start my own business, I can abstract that from her. And it's like all this came into play to build a business and build an organization.

So once I started my own business, then I needed to manage the team. I'd never done that before.

So then I had to dive deep into learning that. You know, the skills I have today are not the skills I need tomorrow. And that's really where this evolution came.

From. And then I do have to ask, you joined Dan Martell's Elite Coaching Group just a month and a half ago. We're both there. What's like a framework or a mindset? What has been the biggest change from that one for you?

Well, in the conversation that led up to joining one thing that he asked that I just It just, digs at me, he said, are you playing to win? Are you playing to fail? And so I think that alone is a huge mindset shift that I need to play to win, right? If I knew I was going to win, how would I behave?

So that's kind of where I'm trying to take things.

Yeah. And I love what he says. And it's very much in line with what you said is like, you can, you have a decision every day. Do you want to stay amateur or go pro? Right and a lot of us we do things at 70 80 it is very hard to do everything at 100 every day but still if you want to win that is the way to go so i love that from him as well Then I think the revenue leaks, I said about it, I talked about it in the intro. You talk about revenue leaks quite a bit.

So what are they? What does that mean?

Revenue leaks, it's just a... Phrase I coined trying to come up but put a name with what I've been doing for 25 years.

So let's use an example. We had an insurance company. Insurance is super boring, but there's a lot of boring things that we can improve. They had a claims entry system and they would take 15 to 20 minutes to enter a claim. And the insured had to be on the phone with the representatives. Right.

So you can imagine, you know, they're trying to get this claim filed. They need to get things figured out. And it takes 20 minutes.

So then we rewrote that. And then that 15 to 20 minutes turned into 15 to 20 seconds and integrated with a bunch of systems. It saved them a ton of work. They had five or six job openings that they ended up closing because they didn't need more people. Now they had a system that could help them do more with less and they were happier while they were doing it as.

Well. Yeah, I can imagine it's not the most exciting work sitting on a phone with the clients for 15 to 20 minutes. Entering basically what they're telling to you into a system. What happened? Did they end up having the client actually enter the claim or how did they move it back to 20, 15, 20 seconds?

Well, the interface for the original application was just horrible. It was like a million different dropdowns.

And then they added a little widget on the website that would just do the initial information, like the claimant and what happened and things like that. So they could start it and then they could follow up as needed.

So, and it sounds very easy. Why did you have to come up with that idea? Why do businesses just keep living with these revenue leaks without addressing them all the time?

I think a lot of it is they don't think otherwise. This is the way we've always done it is a phrase that I've heard a lot. And They don't have someone that's from the outside saying, well, why do you need to do it that way?

Well, can you think of another way? - I can, yeah, Yeah, you mentioned mindset and that's all it is.

Sure. - So just having that outside in view, fresh perspective on how things we're always done. And maybe that that's not the best way to go.

It's a mindset of here's what needs to get done. We're doing it this way now. How can we do it a different way that would help people out?

So Well, fractional CTO, it didn't exist a while ago, right?

Cool. A lot of the work that you do is like fractional CTO work. How does that work?

It's a fairly recent thing. So think of fractional as part-time, But it's a little bit more than just a part-time employee. It's not like you come and bring someone in to clean your office part-time, you know, that that's very valuable, but it's a little bit different. I help them, I help founders, non-technical founders and CEOs think strategically about their business from a tech standpoint. Cool.

Yeah. And so can you give an example like of where you did that?

Well, I yeah, I've done it with so I started with my consulting company and we would just do that as part of our service. I didn't really know I was doing that until I looked back and thought, yeah, that's what I've been doing for 15, 20 years.

So typically what we'll do is we'll come in, we'll take a look at what's going on, you know, assess where they are, and then we'll come up with a tech roadmap for them so that they can have their business goals. Match their technology goals.

Yeah, that's the next question I was going to ask. I mean, if you're a CTO and you're in a business somewhere, you have time to get up to speed. But if you come in as a fractional CTO, they do want... Value really quickly, I can imagine. How do you make sure that they get that value as quickly as possible like within like First month, maybe even.

Well.

That's the greatest part is that I've seen a lot of different organizations worked on a lot of different projects. So I've seen most of the movies they have to play and I know how it ends.

So I can help them either have the successful ending or the not so successful ending. It's really a matter of helping them get their business goals together.

And then we say, all right, what are your tech initiatives that we can do? To support those business goals.

So you actually started with not looking at the tech landscape, but actually started with those business goals and what are you trying to achieve and then how can tech support that?

Yeah, exactly.

So still, you work with these larger companies like the 10 to 75 million. I'm assuming like the insurance company that we talked about, a lot of these companies have maybe a small tech team in place already. What is it that you bring to the table that their internal teams maybe can't or don't or haven't?

Yeah. So those types of companies, they don't have the budget for a full-time CTO and that's but they need the leadership.

So sometimes you'll have, you know, two to five developers and then one of them is, fallen told that they'll be the leader of the team. A lot of them don't want to be a team leader. They want to solve problems with their source code, right? They want to write code. They want to build software. They want to solve problems that way.

So don't make them do that. Let everyone play to their strengths. I love leading teams. I love talking strategy.

So that's really where I flourish and that's where I want to live. So let them do what they're good at. I'll do what I'm good at. The CEO can do the same with the entire organization, right?

So the CEO is not down in the weeds. He's strategy, vision. Here's where we're going to be in the next five years.

Not having to manage or co-manage the five developers that are just... Building stuff out there. Nice.

So, and then moving on a little bit. So you talked about building lightweight operating system for managing tech. I think these companies that have maybe five developers or part-time teams are probably a very good place for that. What does that mean in practice and how does that work?

What it means in practice is you want something, you want a little bit of structure. But you don't want it to be overbearing.

You know, think of it Yeah, I can't think of a good analogy right off the top of my head. But you know, there's lots of things where, for instance, when I'm driving my car, I love to drive cars fast. I have the flappy paddle shifters. A lot of people like a manual transmission, but that's not the fun part to me. The fun part to me is learning how to throttle outside of a turn and get your braking point just right.

So for me, that is where it's lightweight. It's not overbearing. I don't need to worry about all the complexities of shifting. I know how to do that, but now I can focus on driving instead of shifting.

So trying to have a framework that is light enough where it doesn't get in the way, but it provides enough structure so that it provides value. I.

Love that analogy. It makes it very simple. And in line with that, when we talk about metrics, you talk a lot about vanity metrics as well. What are vanity metrics for you?

Vanity metrics would be something like, How many app downloads you got? Or how many views you got on the latest post? Or just something that's not really... It's just fluff. It's not anything that provides value. Versus, you know, what is your lifetime customer value. That's a very important metric.

And then what's your cost of acquisition? So if you don't have those in line, then you're... If you do have those in line, you're making money. If you don't, you're losing money. Those are two very simple but very powerful ways .

Sort of, if we take it back to tech, what are sort of the KPIs that you normally work with that are value-driven.

It's different for every organization. For instance, I'm working with this nonprofit. They're in the live events and sports space. We have been having some technical issues with their website because someone else was managing that. Now, you know, I think we're going to be doing my recommendation that I had a year ago, But that's, you know, downtime is very critical for them because that drives the business. If they have downtime, it makes them look bad, makes them look like they don't know what they're doing. Kind of makes me look bad if people think that I was in charge of that, but I wasn't.

So, yeah, that's where we can do something that's very valuable for them is find out what the metrics are for them. And, you know, everything's bespoke. Everything's custom. It's not one size fits all. And that's the beauty of it as Yeah, especially during the finals, right?

Well. Yeah, I can imagine for a website like that, uptime is everything and being available to their customers. - - So, and then, and you said this is your recommendation from a year ago, it takes a long time to make these decisions.

The big event.

In tech, you always have these daily. There's always the day-to-day, there's the pressures, there's the long-term. How do you make sure with your customers that you do both?

Yeah, I think that's where prioritization comes in. You have to have a long-term vision, but then there's always a short-term play that could make a big difference.

So let's take that website. You know, we recommended it over a year ago. There was resistance from another team.

So they said everything was fine. So at that point, We, what we did as a team is we let the client know these are the potential outcomes. If you don't change it.

And then now that we're in the thick of things, you know, the team's working to try to get that in place, but switching infrastructure is not a quick thing sometimes. So now we can learn this technique. Now we can take this as a learning lesson.

You know, either we're winning or learning, right? That's a phrase I love because, you know, we I don't like the word failure because fail means I stopped trying. But learning, yeah, I'm constantly learning because I don't know everything.

So now what we're doing is we're making those small decisions today to build up that infrastructure for next year when it's not going to go down next year.

And I think that's something that I think a lot of us struggle with and I would... Off the air how you deal with that. From the outside, it's always very easy to see what should be done, what needs to be done, what the next steps are. I think there's often resistance because this is how we've always done it. And sometimes organizations need to experience it themselves. They need to learn the lessons that maybe we have already learned. The company you just talked about, How do you deal with those situations where you think this really has to be done and it has to be done quickly, but the client thinks it's okay like this?

That is the most challenging place to be in where the CEO or the board, you know, they want one thing done and, I know that that's not really where they should be spending their time. So what we can do is we try to educate them to help them make informed decisions but they can't have all the information that's in my head. Because they're not me and I can't have all the information that's in their head because I'm not them.

So we have to communicate that. We have to provide an example of what the risk is for not making this change. And for instance, back to that website, it was what we were proposing was so brand new to this other team that they couldn't conceptualize how that would work and how it would work any better when it's always worked in the.

Past. So, and how did you go explain to the team or... That you have to wait until they came along and saw that what you predicted actually happened.

Yeah, well, we asked for some metrics, which they didn't have, you know, just simple website metrics, server load, all sorts of things like that. We're getting down in the weeds. But if you don't have that information, you can't make an informed decision.

So we had to speculate. We did some load testing in the stage environment and it didn't go so well.

So we were concerned about what was gonna happen. And you know, they need to like a whole rebuild of the actual website itself because The way they've built it has been slow. The infrastructure is not going to save it forever.

True. Makes sense. Okay. It's okay to get into the weeds a little bit, I think, with our audience. That's okay. Let's go on to the tech side of it as well, or the leadership side of it as well. You lead different teams. You actually created... Code, which talks about leadership.

So tell us about code, what that actually is, what the acronym stands for in terms of leadership and how you apply that to culture.

Yeah, that was a while ago. I haven't been doing a whole lot of that, but. Basically, we had a really tough project. With one of our clients. We Did everything right? The client thought that we didn't. But what happened was we went in with project A, right? This is what we're going to build.

And then once we started building it, they're like, yeah, well, we're going to do that. But then we're going to do this other thing over here, which is much bigger. And so they were holding us to the same timeline and budget. Of the original estimate and wondering why we're over budget and behind schedule.

So I thought, how can we do this better? And what we did is we came up with this program. And it's basically a coaching program to help development teams be more effective. Because Any project that fails in the technology space is almost never because of the technology. It's usually because of the people and typically because of the leadership.

So our point of contact, they said thank you to the team exactly twice over a six-month project. So the team was like, well, are we doing a good job? Are we not? I'm like, I don't know. And they were in meetings all the time, so it was just trying to help them. Declutter and organize and be more.

Effective. Cool.

And then So you said underperforming teams, I mean... I think a lot of businesses don't understand enough about technology sometimes, and they think their tech teams may be underperforming or not delivering what's expected. There's often a culture or a communication problem gap between that. You often have like business teams, like the CEOs or the leadership teams that you talked about, and you have these tech teams and there's often a perception that the tech team is underperforming, under delivering, not doing well enough when the tech team itself has a very different perception of the situation. How do you see those situations where the tech team is not underperforming? They're just not... Showing actual value.

Yeah, that is a common problem that I've seen numerous times. So when a tech team is not performing very well, but the tech team thinks they're performing well, it's usually a misalignment of a couple different things. First, it's probably a misalignment of priorities. And then that's, it's missing. Transparency So what I do in those situations is I do talk to the leadership teams. I talk to the dev teams and each of the dev members. And I really try to gauge what their perspective is of this entire situation.

And then I'll ask him, you know, what do you think the problem is and what's the fix? And then you'll get a vastly different you'll get the two camps, right? And they'll both think that The problem is the other camp. But really the problem is the alignment.

So in those situations, a lot of times the leadership has changed priorities so many times the dev teams like I don't know what we're working on right now. And then the leadership won't know what the dev team's working on because there's no progress shown.

So then that's what Scrum is for. I know some people kind of hate Scrum, but it's really the least worst option that we have right now. Much better than waterfall. If they worked on a waterfall project, they would see what a blessing Scrum is to have.

So, you know, have a burndown chart, do a strip sprint demo, you know, your backlog refinement, get the prioritization from the business. Then they'll see what's actually being worked.

Well, they'll see progress and they'll be able to see, you know, what did we do over the last two weeks?

Yeah. And I think, well, my genome scrum, right? I'm a big fan of it, but I think there's a lot of people that execute scrum without scrum. Really understanding what the right things are to do, how to do it properly, and how to execute properly. And I think that a lot of the bad name actually comes from that side.

So I do value scrum quite a bit myself.

100%.

So let's talk a bit about technical debt as well because that's I think almost, well, IT goes so fast, technology goes so fast. Every company has technical debt.

Some of it's small, some of it's incredibly large or somewhere in between. You help a lot of businesses with their aging systems. And it's difficult, right? You talk about this website and you need to completely overhaul it. That's something that happens way too much. How do you approach that? Technical debt when you step into these.

Businesses? Yeah.

So everyone has a different tolerance for debt, right? You know, our personal debt, right? I don't have enough money to go buy a house when I first bought a house to buy a house cash.

So I have to incur some debt. But at the same time, I wouldn't buy a house with a credit card.

Like that just doesn't make sense. So that's kind of what we need to evaluate, Are we... Incurring more debt, are we incurring high interest debt or is it low interest debt? Can we maintain this level of incurrence of our debt.

So if you take that financial analogy and look at it with code and how we're developing software, A little debt is okay. But For instance, let's say you've got a helper function that formats a number into a currency or formats a date into a specific format that you like, right? A different time zone, whatever. If everyone uses that same method, that's great. It's a maintainable code. But then once you do it inline here, and then you have another method over here that does that, and one over there, this is one simple thing that you've got it in three different spots over it.

So you need someone that's This is where the architect or team lead would come into play, right? They'll be looking at each of the code reviews, the pull requests and say, all right, here we have this method over here. Use that one.

And then we're not incurring as much debt. How much time does it take to call that method? Nothing, right?

So? So that's a good... A backstop for incurring technical debt is a good team lead or a good architect.

So I love talking about technical debt because everyone wants to just say, all right, let's pay off all our debt right now. But then you don't get features done.

So you have to have that balance between paying off some technical debt and implementing new features.

Yeah. Yeah, and I think one way to go is often we dedicate 10, 15% of our sprint to technical debt or cleanup and the rest to features or maybe incidents if we're doing DevOps.

So, but still, how do you get priority? Because you will have people on the business side, business leadership that say, we want the new features. We want all the new stuff, the fancy stuff that's going to make us money and technical debt. We don't care as much. Just deal with that later. It's not a problem today.

Yes. And sometimes they're right.

Sometimes they're less right. What we want to do is we want to Think strategically with them. And, you know, if we have some looming thing that we know is going to happen if we don't pay off a specific part of technical debt, We need to speak up. That's our duty, right? Our duty is to them to help them make better decisions. And sometimes what we'll do is we'll kind of slip in a little bug fix here and there or a little refactoring without adding to the cost of the sprint.

So if we can deliver our, let's say, 10 stories that we've committed to for the sprint, but we can pull in a couple backlog issues that would reduce the technical debt, that's great. Another way to do that is when we're working our stories, is to not incur any more technical debt moving forward. And if we touch something that we know is a little messy, to clean it up as we go along.

Cool. Yeah, and I think that helps. The other thing that we see a lot in tech, that I see a lot in tech, and we all suffer from it, I'm sorry, is shiny object syndrome, right? We have all these tech people that want to go with the latest and the greatest and implement AI and implement the next version of framework and just which Most of the time it doesn't add any real business value. How do you deal with the shiny object syndrome that most of us in tech suffer.

From? I don't know what you're talking about. I've never seen that ever.

He wanted to use Golang when it first came out. I'm like, don't use it. We're not using that language anywhere. I want it. To be in something that we could move to a production level ready code base when we need to do that.

So he used Golang. So in those types of situations, that one didn't matter. At all. But he wanted to learn it. It, It's just more of a funny story. But when you're working in technology and you have a new shiny, like a framework or this new.

Get all your stories done in a sprint, you shouldn't do that. And it needs to be decided as a team too, if we're going to evaluate something and then the business team This is where it comes into play a little tricky because the business doesn't want anything new. They want features, right? But if there's something that could make our lives easier as a development team, if we spent a sprint work on this little new shiny thing, and it actually saves us time. Down the road and we can develop faster. That's worth evaluating.

Yeah. So keeping them in control a little bit when you have to, unfortunately. And I think it happens a lot.

I mean, my background is in operations, right? And infrastructure and all these technical debt projects. And it's not always the most rewarding, fun, new tech that we work on, but it's so extremely valuable to a business to still do it and still get it right.

Something else that you said, and this is about leadership and about CTOs, if your CTO is writing production code or code for production, they're likely not or sorry, functioning effectively as a CTO. What did you mean by that?

CEOs don't write code.

CTOs.

Sorry. Yeah, CTOs, they shouldn't be writing code.

So if your CTO is writing code or if they're working in the AWS environment getting stuff provisioned, Why? Your team should be doing that your CTO should be a visionary and a strategist. I don't speak Linux very well, for example, but we use a lot of Linux containers on our projects because it's cheaper and it It's easy and it's more secure.

So I don't set it up. I just say, go set it up. You're the expert in this area. You go do what you do well. I'll do what I do well. That's it's the division of labor. I know a lot of people like cross training, but there's a certain degree to that It just doesn't work. And one thing to remember, like Disney only has one CTO. If He was in AWS all the time. How could he drive the technology for Disney?

So if.

You have to give one, like, one lesson that every tech leader needs to learn or should learn. What would be the one? How would you describe it?

I think what people struggle with is No one can do it as good as I can. They may be true. They may be right. I found that that's not true for myself. They're like even writing. I came up with a software development. All right. I started in 2000 as a software developer. Are young kids I mean, they're the age of my kids, so they're kids. I know they're adults. There are some really sharp guys out there. Let them go figure it out. Let them grow and just have a team lead to help them.

Yeah. So delegate. Let others do the hardcore work. Coding, infrastructure work, AWS work, and actually focus on delegating and leadership.

Well.

How do you see that for the clients you work with? Where are they?

So with AI, none of my, just maybe one or two of my clients have really implemented any real systems in AI. : most just aren't the where the space I work in is the mid level and they just don't have the budget to try something that may or may not work. Right. And so that's kind of the perspective of the CEOs that I work with. But dev teams, they use it every day, like Cloud Code or GitHub Copilot.

You know, they're writing prompts. They're not writing code. But then when the junior devs are doing that, that's kind of a little different. A little danger zone, right? You got to be careful that you don't end up with a big mess that AI tries to create for.

You. Yeah. No, I need, that's I think the concern that we have now is that how do junior devs still learn to code when they can actually go to AI?

Yeah. But not learn the architecture, the structure, all the right patterns to implement.

So, but still, and I think it's interesting to see it's so, and I see this With corporates as well. So many companies that have only like started to scratch the surface of AI and haven't gone anywhere where you have these other startups, right. And all these cool new startups that go like, all in and do everything with AI. I think there's this whole divide that's coming up. How do you think that's going to play out over the next I'd say three to five years, which is a very long time in tech and AI land.

That's an eternity in AI land. Yeah, for sure.

Well, and they talk about an AI bubble. I don't know what's going to happen with that. I don't know how much of a bubble it is.

You know, they're burning money, but You have to at this stage and in your development. But it seems like, you know, people that are implementing AI are either those startups, the AI startups, and then over here are big companies. And the people in the middle are just kind of getting, forgotten about. But what I see happening is I see some cool things happening. That are going to come into play where a mid-market company will be able to take one of these off-the-shelf AI things that will help them run things more smoothly. You can always do that with, you know, NAN. You can create some automations and things like that, or any automation tool to now implements AI.

So you can have it make some decisions for you. Some data analytics and forecasting and stuff like that. I think those are very real spots where it still has a human in the mix. Where you don't want to trust it with everything because it's still kind of dumb at this point. -.

Yeah, absolutely true. Sometimes and sometimes not. The problem is you will only know once the result comes in. Matt, it's been incredible having you on. If people want to go and find you, where can they go and find you? Where.

Are you? Yeah, I'm on LinkedIn, Matt Dixon, and then fractional CTO Matt on Instagram. And yeah, I'd love to help out and see what you've got going on and see what you're working on.

Cool. And we're going to put all those links in the show notes as well. Matt, thank you very much for being here today.

Yeah, thank you. Appreciate it.

As we wrap up another episode of the CTO Compass, thank you for taking the time to invest in you. The speed at which tech and AI develop is increasing. Demanding a new era of leaders in tech. Leaders that can juggle team and culture, code and infra, cyber and compliance. All whilst working closely with board members and stakeholders. We're here to help you learn from others, set your own goals and navigate your own journey. And until next time. Keep learning. Keep pushing and never stop growing.