CJ Montano, CTO and Founder at MyHockeyIQ, DISCUSSES AI in Software Development

Oct 27, 2026 · @Forte Group

Host: Lucas Hendrich, CTO at Forte Group
Guest: CJ Montano, CTO and founder of MyHockeyIQ, board member at Forte Group

Introduction

Lucas Hendrich: Welcome to the CTO to CTO podcast, where chief technology officers discuss technology, trends, innovation, and what we do day to day. I'm your host, Lucas Hendrich, CTO at Forte Group. In this episode, I talk with CJ Montano, CTO at MyHockeyIQ. CJ and I discuss considerations for the use of AI in software development and for increasing developer productivity, among other things. Here's the conversation.

Welcome to the premiere episode of our CTO to CTO podcast. My name is Lucas Hendrich. I'm the CTO at Forte Group, which is bringing you this podcast. I'm here with CJ Montano. He's a friend and colleague, also a board member at Forte Group and a longtime CTO, now heading up his own stealth startup — or maybe not so stealth. He'll tell you a little bit about that.

We're here just to have a conversation about what CTOs do, what we face every day, and some of the things that are top of mind for us. Hopefully this won't get too technical, so that anyone who's not a CTO can listen too. We welcome everyone to listen, maybe learn a little, and get a look into our little world as CTOs. So with that, CJ, do you want to say a couple of words before we start?

CJ Montano: Sure. Thank you for the introduction — very kind. This is also the first time that Lucas and I have sat down and really gotten after it.

I worked at Forte. My company was acquired by Forte about 10 years ago, and I was lucky enough to help decide on bringing in Lucas as a new CTO and a new generation. We're excited that Forte is looking to the future and embracing artificial intelligence, data science, and the new era of programming.

A little bit about me: I've been up and down the stack most of my career. I've been in quality assurance and product management. I was a software developer and made my way to chief technology officer, both at Forte and at a group before that, and I did it for the last 18 months at another organization, a vertical SaaS company. Technology is a great place to be.

I'm now venturing back into the world of product and founding my own company. It's called MyHockeyIQ, and it's in the space of sports management. I'm sure I'll weave in a few nuggets about that company as we have this conversation.

LLMs in Software Development

AI as a gap-filler for founders

Lucas Hendrich: That's exactly where I think we're going to go, so let's dive right in. One thing many people are almost tired of hearing at this point is how LLMs are becoming pervasive and ubiquitous in all parts of life and business. In software development, there's a trend I don't think is going away anytime soon: using LLMs to generate code in your IDE, whether it's suggesting code or writing big snippets that you can then copy and paste into a project.

Where do you see that fitting in? You're founding a company right now, and I'm sure you're hands on keyboard. Are you getting benefits from it? From my point of view, as a starting point, is it helping you with scaffolding — just getting the project up and running?

CJ Montano: I see LLMs and generative AI positioned very differently in commercial software development than in the startup space. But both have one thing in common: they cover gaps in whatever your organization is short on.

And yes, I am very much hands on keyboard. Practically speaking, at MyHockeyIQ we're building software driven by three dimensions and artificial intelligence, and we're building it on the Unity platform. I've never written a line of Unity code in my life. I've written lots of code in most of the stacks you've heard of, but with no Unity experience, AI — Copilot, ChatGPT — has become my best friend.

It's not necessarily another developer next to me, but it helps me cover the gaps. That could be as simple as this: I know the basic patterns of software programming, but I don't know how to generate a three-dimensional object on the screen, or the best ways to do that.

Whether I'm having a conversation with ChatGPT about perspective — what are the best ways to do this, what is the accepted standard — or working right there with Copilot to generate the pattern, it doesn't just accelerate the software development process. It's actually a learning tool for me. As you'll probably come to know through this podcast, I'm very detail-oriented, and I like to know all the parts of what's going on, both in the business and in the code. From that perspective, generative AI and LLMs have been a godsend.

Trusting junior developers with AI-generated code

Lucas Hendrich: Fast-forward a year: you're scaling up teams and bringing on different developers, and you'll clearly have to bring on people who are less experienced. How do you think about trusting them to use LLMs to generate code when they may not have the experience and are getting to know the code base for the first time?

CJ Montano: The simple answer is yes, I would absolutely trust them. Given how little time the seniors — the 10x developers around them — have, we're going to have to rely on it. I think the best organizations, and we'll be one of them, should really embrace the concept of letting generative AI — Copilot, CodeWhisperer, or even just ChatGPT — be part of that process.

Here's why. With 25 years of software engineering experience, writing in a new technology stack in Unity, I'm noticing two things. When I use Copilot, it gives me recommendations based on the entire code base. That often triggers questions in my mind: Why is it doing it that way? That's not how I would write the code. It creates curiosity about what's going on across the entire code base that would lead it to generate that.

That ties into something I want to talk about: small techniques for using Copilot. I don't think people realize that Copilot can be used simply as a better IntelliSense. We've had IntelliSense forever, but sometimes I'll start writing code and it writes out the whole method for me — the whole method signature — and I think, I didn't want that, but it's interesting. Why did it do that?

If you have juniors with that curiosity, who want to understand, then you're going to see -1x developers become 2x, 4x, 5x, 10x developers. The skill you now need at the junior level is curiosity: "I'm not just going to generate code. I'm going to understand why it's generating this code, based on a code base that probably 15 other 10x developers wrote, and that's probably pretty good code." That's where I'd say embrace it, and let those juniors really learn through their curiosity.

The last-mile problem and build times

Lucas Hendrich: I think there are two sides to that coin. One side is that you're going to amplify the right patterns. The potential downside is a last-mile problem: it doesn't compile, it breaks, and the more complex the snippet you get — whether from an LLM or any kind of suggestion — the more of the 10x developer's time it takes to debug. How do you think about that balance? Is it going to change how we do pull requests? Is it going to change at all, or will it just become fluid?

CJ Montano: Good question. I'll get to the process side — pull requests, approval, deployment, and so on — because I think it has a different impact there.

When it comes to last-mile compilation, IDEs have gotten so good. I'm just using VS Code; I'm not even using a full-fledged IDE at this point. I moved over to Copilot — I was using AWS CodeWhisperer for a while — and I rarely see compilation issues. It interprets in real time, so it gives you the squiggly line and tells you, "I can't do this." You pretty much know right away. And as we get into more hybrid AI, with auto-generated code and auto-interpreted code, those two start working together to say, right in that moment, "Yes, it works. Let's give it a shot."

Where I think it will create issues is this: the patterns of software engineering have been set, and they largely haven't changed. The languages haven't changed much over the years either. A big part of what many commercial organizations focus on is compilation times, build times, and deployment times, and much of that comes down to dependencies. How the code is generated determines how much code has to be recompiled, redeployed, and so on. The elusive, illustrious 10-minute build can become a 30-minute build.

I don't think AI has a good sense of that right now. But as we move into hybrid AI and see different LLMs solving different problems in different spaces, we'll see a solution to that too.

Lucas Hendrich: I agree on both counts. It's hard to imagine an AI architect that could solve those higher-level problems as a code base becomes more complex.

CJ Montano: Sure.

Lucas Hendrich: On the other hand, I think you're right that as training becomes more sophisticated, these aren't unsolvable problems.

AI Across the Business

Rethinking how projects are executed

Lucas Hendrich: What does that mean for the organization in general? Most practitioners have been running Agile for about 20 years — that's a fair general statement on the timeframe. Do you see changes in how we'll actually execute projects? Will we find different kinds of efficiencies? Will we understand business requirements differently, and faster?

CJ Montano: These are great questions. And remind me to go back to the PR question as well — I don't want to leave your questions unanswered.

Lucas Hendrich: It's actually tied to that. Sorry for interrupting, but we're thinking not just about the space from task to implementation. We're thinking about the whole nine yards: ideation, and maybe even creativity in defining the product itself.

Using LLMs to test product-market fit

CJ Montano: I'm going to plug my own thing here and talk a bit about AI and business. My software and our business are about what's called hockey IQ. It's the concept of building up a youth athlete — in this case a hockey player, but it could be any athlete — in their ability to understand game-like scenarios.

I had an idea for a business that would create a space for younger athletes, their parents, and their coaches to communicate and help each athlete develop their hockey IQ individually. I went out with a really strong idea: this is the software we're going to build. Then I met a really good product marketer who said, "You should find out whether you have product-market fit, because a lot of people are blinded by their love and passion for their idea."

So I went out and interviewed hockey directors and coaches, all the way from the professional NHL level down to an assistant coach just starting out at the seven-and-under level. I asked questions as generically as possible: Tell me about your coaching process. How do you define hockey IQ? Can you teach it? Can you grow it? Do teams versus individuals get in the way? Those types of things.

Where am I going with this? As I'm working through product-market fit, I don't have hundreds of thousands of dollars to hire product marketers to run these interviews and do the analysis. So I've been using different LLMs. I used AI tools like Otter to transcribe the conversations, tagged them, and fed them into a large language model.

My first question was basically, "What business should I run?" It was shocking how many ideas ChatGPT came up with. It more or less confirmed some of the ideas I was pursuing, but it also poked a lot of holes and found spaces I hadn't considered: "Based on what 50 coaches have been saying, there's a real problem right here." Things my brain couldn't come up with. Things that maybe 100 people would have told me, but I wasn't hearing because I was so set on my idea.

ChatGPT doesn't care about your idea. LLMs don't care about your idea. They care about statistical trends. It's a probabilistic model, so it's basically saying, "Here's your best chance at a business, right here." So how is it going to change the game? In product, in value, and in vetting your ideas and understanding how and where you need to pivot. If it's not challenging you, you're losing.

From idea to business, faster than ever

Lucas Hendrich: That's fascinating, because you think about stages of evolution. What did it take to start an internet company in the year 2000? I remember — I don't know if you do. It took a pretty hefty investment. You had to get your server and stand it up; it was all physical. Then you had to write everything from the bottom up.

Fast-forward: we've lived through the cloud computing boom, where you can choose your cloud and have your website up and running very quickly, or just use a third-party e-commerce platform. All of that accelerates the path from idea to business. Now we're at another inflection point where that path will accelerate even faster, because for a founder who doesn't have time to be CMO, CTO, and CEO, it increases productivity along the whole chain. That's what fascinates me, and it sounds like it's working for you.

CJ Montano: One hundred percent. Not to age myself, but I worked at Sun Microsystems back in the day — I think I can say that. They were the "dot" in dot-com. They were behind all the startups; Pets.com was built on Sun and Solaris. Sun is gone now, apart from Java living on under Oracle.

Compare that to now: I just started a business by going to a virtual private server hosting company, and for $7 a month my software is up and running. Seven dollars. I could scale that to a few hundred dollars a month and be very happy with the scale I'll have in my first few years. Versus a Sun E10K, where it took a million dollars to build a startup.

Economies of scale, cloud technologies, Moore's Law — all of that is coming into play, and now artificial intelligence is empowering the entrepreneur, the first-time founder. A guy like me: 25 years of software experience, I've led teams, I've built my own business, I have software development skills, and I played hockey for 20 years. All of that culminates in: buy yourself a $7-a-month server, get ChatGPT and Copilot on your side, hire some junior developers, and let's see how far I can take this thing.

Within two months, we have a site up and a demo platform running, and we can show it to potential buyers and ask, "Is this interesting?" Even if they say no, I know that in two months, not two years, and for $1,000, not $100,000.

Lucas Hendrich: De-risking product validation and product-market fit — the biggest risk.

CJ Montano: Absolutely.

Coming up next: how to manage the hidden risks of AI in software development, plus the long-term impact of AI on issues such as technical debt and the software development lifecycle. Stay tuned for more CTO to CTO.

The Hidden Risks of AI

Lucas Hendrich: Welcome back to CTO to CTO, a podcast by Forte Group. I'm Lucas Hendrich, CTO at Forte Group, and I'm here with CJ Montano, CTO and founder of MyHockeyIQ and board member at Forte Group.

There are a couple of things I want to talk about, because this is a very utopian view: you take a few ingredients, throw them together, and you've generated a business. What about the tail risks? Say you've introduced a security issue into the code base, or used something that violates a copyleft license, and now you've got a problem. How do you think about those things when using LLMs? We talk about hallucinations all the time. How do you de-risk that?

CJ Montano: Honestly, I haven't thought about it that much. Here's how I'll answer.

I think there's a hype curve going on with AI right now, with a lot of experimentation around how it can be useful to us. I'll draw on my experience as a CTO and vice president running software departments with a lot more people. When I think of non-functional requirements like information security or quality, I don't know where AI fits there yet.

But I know this: nobody cares about those things until they have to. Nobody cares about information security until they have a breach, and then it's the most important thing. Nobody cares about software quality until they release and nobody can use it, or the site is down for an hour, two hours, or a week.

I'm not sure I'm directly answering your question, but I do think that if you're not embracing this technology, you're not doing your diligence. That includes using package managers to see how far behind you are on a package version, or understanding how many times a breached package is referenced, or how many pieces of software are using it — all of which is AI territory now.

I'm not a DevOps person or an information security person. But when we talk about hybrid AI, we're seeing AI emerge in every single field. What we can't do is say, "I'm generating more code, I'm generating higher-quality code, juniors can generate code better than they ever have, so information security and quality aren't problems anymore." That's just silly, because of the sheer amount of code we're generating.

AI is not a cost-reduction strategy

CJ Montano: Let me take a step back. One thing I'm hoping to talk about is that AI has been positioned as a cost-reduction technique and a way to accelerate coding — meaning we can do more with less. We could take 100 developers, reduce them to 20, and produce the same amount of code.

I think that's the most short-sighted thing we're going to see. I think there will be a big boom in job creation within the next two years, because software has never been about reducing cost. Ever. Look at OpenAI itself: they're burning billions of dollars and have a real shot at being the first trillion-dollar valuation of its kind. They're not doing that by hiring fewer developers; they're doing it by hiring more.

The organizations that get it right will be the ones that recognize that more developers building better code means more innovation, which means beating the competition — not doing the same with fewer people.

Lucas Hendrich: That's very interesting in almost economic terms. You can take a scarcity point of view, supply side or demand side, but I think the contribution to total factor productivity is going to be huge. I totally agree.

I also think there's confusion here, because very little replacing is actually going on. You say hybrid, and what I understand from that is that we're extending our capabilities — we're just using another tool. Our tools are getting more sophisticated, and in this case they're language-based. If it's easier for me to write pseudocode to generate code, I'll generate code faster, as you say. There will be quality risks either way. It's another layer of abstraction.

I was listening to a panel discussion about the risks of AI, and that's why I asked the question, because I felt there was something short-sighted in that conversation as well. We could have said the same things about Excel 20 years ago. How many businesses still run on Excel spreadsheets that aren't secure? There have been huge decimal-point errors costing millions of dollars because of dependence on Excel spreadsheets.

I think about that, and I think about my kids doing their homework with ChatGPT. It's becoming ubiquitous. So I don't think the risk is AI somehow becoming more intelligent than us. We just need to be mindful of how we use this tool so globally, because it will generate a different kind of technical debt — not apples to apples — a different kind of dependency, a different thing to manage in the software development lifecycle.

CJ Montano: Technical debt that AI will help us solve, too. You can't forget that.

Thinking of AI as a way to reduce costs is a bit like how organizations back in the '90s thought about copyrighting their software. Nobody does that anymore, because the answer is: just build code faster and be more innovative, and they'll never catch up. The whole VC world was built on that concept — build more, be more innovative, do new things.

Lucas Hendrich: Linux is more secure than Windows.

CJ Montano: Yeah, exactly.

Lucas Hendrich: I don't know if I should be saying that, but I think it's a commonly held belief.

The practical phase of the hype curve: hybrid AI

CJ Montano: Exactly. Taking a step back, I'm a very practical person. I believe in the human condition — humans are behind all of this — and I believe in what the hype curve tells us. We're overlaying multiple hype curves within the same discipline of AI right now. The generative AI hype curve has already peaked, and it's moving into the practical phase: How can I adopt it and use it? I love that part of the curve.

I'm not someone who's on the initial curve, saying, "I've got to build this whole thing, we've got to talk AI, and I'm going to change the world." I like the stage when things start to solidify, we find a place for them, and we actually use them productively.

When you think about the AI hype curve and adoption, I believe we're at a point where we don't have to be so freaked out by what's next. Is it symbolic AI? LLMs are built on textual data: you take all of this data and ask what it can generate conversationally. Once models start taking in images and video and become more contextual, we might start to see something closer to true intelligence. And the LLMs take — what is it? You live in New York City — something like a month of New York City's electricity to retrain on current data. When we get into the next hype curve and bring in symbolic AI, I think that will change the world in a different way.

But I'm more practical. We have ChatGPT, Copilot, AWS CodeWhisperer, DALL·E, even Canva. We can take those different GPTs and models and use them in a hybrid way. That's what I'm most excited about.

Take the legal industry. We could take all the documents in a case and use AI to determine which ones are responsive for a particular litigation or matter. Then we feed that into a rules-based engine, take the output, feed it back into ChatGPT, and say, "Help me understand contextually what's going on here." Three different models trained on different data, giving us different insights.

I don't think we need to be so concerned about where AI is going. We should focus on what we have right now, and how we can combine different large language models in a hybrid way to exponentially increase our value. That's what excites me right now.

Lucas Hendrich: Me too.

AI and the Software Development Lifecycle

Slow is smooth, smooth is fast

Lucas Hendrich: These are the tougher questions. We've been building software in a relatively similar way for the past 20 years — you could go back even further. The process from inception to requirements has become more efficient. We shift testing left, and we shift left to get to production and to market faster. But I feel we don't yet know how AI will impact the software development lifecycle.

It's hard to have best practices yet, because the ground is shifting so quickly. With every new model version: What do you choose? Is there a big difference? What's the differentiator in what we practically do every day? How do you think about that? Are you patient enough to sit it out and use what you can in the meantime?

CJ Montano: I'll approach it like the arc an athlete might follow — this is near and dear to my heart. Anyone who knows me knows I say this all the time: slow is smooth, smooth is fast. You need to practice things slowly and become an expert before you can move faster. Otherwise, you just get good at whatever you practice. If you practice the wrong way, you'll get good at that. In the software world, those become anti-patterns. In sports, they become bad habits — things that have to be unlearned.

So I take the perspective of: take it slow. But here's what I think will happen. As you said, the world of software has been designed and built a certain way. We have Agile, two-week cycles, DevOps engineers, developers, and test automation engineers. They each have their own industries and disciplines.

When I say take it slow, I don't mean "start with code-generation tools and do nothing in automation or DevOps." No. Let the experts — who practiced slowly and became fast — experiment with AI and LLMs in their own fields and disciplines, and then tie those together. You've delivered the code, tested it, and deployed it, each using different LLMs and tools in the hands of an expert. I think that's perfectly fine.

Then it emerges the way you described: we don't really know how this will change things, so just start. Just learn. Start deploying with command-line, Linux, or Zsh shell-based AI tools for Kubernetes, containers, or whatever, and see how far it goes. Let that cycle emerge. That's where we are in the hype cycle right now: adaptation and adoption of these LLMs.

Let's not try to find one system to rule them all and define how everything fits together. Let the experts work through their fields, see what becomes commonplace, and then we'll start integrating.

From developer to orchestrator

Lucas Hendrich: So, going back to the software development lifecycle and the roles on a Scrum team, it sounds like each role will have its own model, expertly trained for that role. Maybe the software developer of 10 years from now will be a software orchestrator.

CJ Montano: Yep.

Lucas Hendrich: Or a business integrator.

CJ Montano: Yes. Think of companies — I won't name-drop too much — there's a great company out there that does test automation as a service. They have hundreds of client companies, and all they do is write tests in Selenium or Playwright. Think about them training models on that.

Now compare hiring a test automation engineer and saying, "Extend the pattern at our company," with going to a company like that and saying, "Use AI to auto-generate automated tests for us, because you're trained on hundreds of companies and millions of lines of code — and I'm trained on just this one." There's no contest.

I don't think we've seen the effects of that yet, because those companies haven't had the ability — or have hesitated over the legal risk — to actually do it. They or their clients might be concerned about sharing or using that kind of data. But the technology is already there.

So whether it's a role on a team where a person says, "I'm going to be the expert and learn this": Which LLM will you choose? Where will the data be trained? Will it reflect the broadly accepted patterns in test automation, in Playwright, for a vertical SaaS company in this industry, solving this type of problem? That's a big advantage over bringing in even an expert and saying, "Build our test automation foundations."

Now I'm going to plug Forte a little, because this is what Forte does. You're talking about an organization with a thousand engineers who have access to a lot of different data. Setting aside the legal ramifications, that can be incredibly powerful. Whether I'm generating, deploying, or testing code, we not only have the collective consciousness of a thousand engineers using AI — we could also have models trained on data from all of these clients. I know we don't today, but we could.

Data as the next problem to solve

Lucas Hendrich: Essentially, that's the extra value a company like Forte should provide: you're not accessing one brain, you're accessing a thousand. That's how I think about LLMs in a lot of ways, too.

Without plugging Forte too much, let me take the thought a step further. To do that effectively, data itself becomes the problem to solve. In the broader market, if you don't have the right data to train your models, or it's hard to ingest that data and have it flow through an organization, you've got a problem. We're seeing a lot of data debt out there that needs solving.

I'm curious about your product, because you're also the chief product officer now, and it sounds like you're sprinkling AI into it. Are you thinking about data as an asset for training models? You think about user adoption: get as many users as possible, start pushing transactions through, build up the transactional database, then analyze it — that's your asset. Some aggregation happens, and maybe you can sell that data. But now there's an aftermarket for all kinds of data: training models. Are you thinking about that?

CJ Montano: Slightly. And here's why I don't think about it much: it's too exciting. Again, I'm a pragmatic guy. Right now we're trying to get to MVP.

At the core of what we do, we're helping youth athletes — and at the younger ages, their parents participate in their growth. How can I take part in my own growth if I'm not an expert and my parent certainly isn't? Traditionally, it's just been a coach telling you things, and you glean what you can.

Some coaches will say some kids just get it — "I know it when I see it" — and some kids won't, and those kids move on. Then you get this effect where the kids who seem to get it receive more investment and more ice time, and they get better simply because they follow that pattern. There's a name for it; I can't think of it right now.

When I think about taking control of my own development as an athlete, what made me a good hockey player was my own love of the game and my own curiosity. It wasn't really a coach. It was me going into my garage and shooting a puck a certain way a thousand times. Unfortunately, my dad was very good at building things, and he made me a steel hockey puck — so I had to shoot a steel puck a hundred times. But that's the point: I had a good shot and could do things other kids couldn't do on the ice because I did that.

So when I think about data: How can we help kids and athletes learn more about who they are? You have to give them a lot of data. That comes from coaches, from what they watch on television, from videos prescribed to them, from a camp they attend, or from an assistant coach whispering in their ear. It's all data — audio, image, whatever form it takes.

If we can start to glean trends from that, we can make recommendations: "Here's what coaches keep telling you, and here's what you keep struggling with." Then we get into computer vision and tendency analysis in sports. We could say, "These are your instincts on the ice. This is a weakness. You should go to this camp. By the way, there are three experts in your area — here are their prices and when their next session is."

So of course we're thinking about it. It's just so exciting that it isn't worth dwelling on yet, because right now we're creating the conditions — the space for that to happen. Then we'll get into it. It's a very exciting area, but again, I'm so practical: let's use what AI gives us today.

Lucas Hendrich: And you need to get the data first before you can start.

CJ Montano: Exactly, exactly.

Doubling down on strengths

Lucas Hendrich: I have a hypothesis, prompted by your comment about what AI is really good at: synthesizing and surfacing insights you wouldn't normally get—

CJ Montano: Because of your own bias.

Lucas Hendrich: Right. Hearing you, I'm thinking of a jiu-jitsu coach, John Danaher, who's very well known in that community. He says you can practice all these techniques, but if there's one technique you're naturally intuitive with, you'll have an edge with it — and that's what you need to exploit. It's a kind of 80/20 principle: that's where you double down.

It would be really cool to think about that in hockey. I don't know hockey at all, but I'm sure there are player attributes that align with certain techniques and give a higher success rate. Having that information at a point where someone can really practice it would be a real advantage.

CJ Montano: The investment community has known this forever: invest in your winners, drop your losers. That's the truth. Diversification isn't the path to success and wealth — everyone who's wealthy knows that. Find what you're good at, invest in it, double down, and keep moving in that direction. Diversification helps you explore and discover what you're good at and what you're not. But continuing to invest in things that aren't working for you is just madness.

It's the same in hockey, and that's where players get their flavors: "This kid is really fast." That was me — I was a really fast hockey player, so the approach became "let's double down on that," and that became my thing.

Developer experience as a data source

CJ Montano: But let's bring it back to tech. Think about it from the perspective of an Agile or development team. What do we know — and not know — about the team today that we're not benefiting from? This is where I'm really interested in frameworks like SPACE, DORA, and DevEx (DX). What is your team's productivity? Its happiness? Its motivation? What are they good at? Where do they focus?

There's a not-so-silent movement happening behind the scenes — AI just masked it — around developer experience. I know Forte is going down the path of measuring not just developer productivity, which can be tough, but developer value and efficiency: How good are they at creating outcomes aligned with value and with what the product is building?

Because of the frameworks SPACE, DORA, and DevEx are creating, these tools will generate more and more data. I know you're using one of them; I use one too — different ones — but it's all more data. That data could be run through LLMs trained to say, "This team is really good at this." Then you can keep pushing them down that path, try to train them, or replace them. Or maybe your company isn't what you thought it was. It's a collection of assets — the human minds in it — and you should go in the direction of the assets you actually have.

I think we might see businesses emerge right out of that: Forget who we want to be. Who does our company have? What should we be? I think AI will help create some interesting spaces there.

Closing Thoughts

Lucas Hendrich: I agree, and I think that's a great way to wrap up. It's been wonderful talking to you, CJ — a ton of fun. Thank you so much. Any final thoughts before we wrap up?

CJ Montano: Just my big thing around AI, having this conversation with you as a Forte board member. When we at Forte — myself, you, Mikhail, Steve, Lee Barnes, the big influencers — think about this, we think in terms of: What can we do right now? What is the practical use, for acceleration, for improving quality, and for creating a learning environment that lets engineers move forward our clients, our clients' organizations, and ourselves as an organization?

I wanted to plug Forte on this because, of the many services firms out there, Forte is very practical about how it does things. You measure where you are, you experiment, and then you improve. I think AI, in this DevEx space, has given you a really nice position to say: "We're not blasting AI everywhere just to attract attention. We're using it pragmatically and measuring our success."

As a board member, I'm biased, but I am using Forte's services because of that. It's a very practical approach, and more companies need to think that way. Stop dreaming and start doing what practical AI gives us today. I think Forte does it well.

Lucas Hendrich: I couldn't have said it better. Very generous — thank you very much.

CJ Montano: Yep, thank you.

Lucas Hendrich: Thank you so much for listening to our podcast — or watching, if you're seeing this. It's been a lot of fun. Coming up soon, we'll have another exciting conversation with someone from the private equity community, and I think it will be very insightful as well. Thank you.

Thank you for listening to the CTO to CTO podcast. If you liked what you heard, be sure to subscribe so you don't miss future episodes. We'd love to hear your feedback, so leave us a review as well. Keep exploring and innovating. See you next time.

‍