The first fear was for our junior engineers. When we started experimenting with AI in our innovation lab, we saw a pattern that concerned me deeply: junior engineers jumped in believing AI was magic, but they delivered low-quality work. They were getting code from the models, using it without understanding it, and introducing problems they didn't have the experience to catch. I saw an entire generation of engineers whose value in the industry could be at risk if we didn't find a way to train them properly. That fear was real, and it stayed with me for a while until we realized that with structured training, we could actually level the field and help them grow into this new way of working.

The second fear was for the survival of Teravision. We had built this company over twenty years with a clear model: we provide engineering teams to help companies build software. But I started seeing the teams shrink. A project that used to need eight to ten people now needed three or four. Our company went from 240 engineers to 180, and the trend wasn't stopping.So yes, fear motivated me. But I didn't panic. It was the realization that there was no turning back. AI was going to get better every day, probably exponentially. The question wasn't whether this would change our industry. It already has. The question was whether we were going to lead the change or get run over by it.We decided to lean in. We leveraged our twenty years of software engineering experience and started figuring out what the new way of building software looked like. That work became the a training and coaching system we now use with clients (consisting of the Cognitive Engineering Framework™, then the AI-Ready Engineering Certification, then the 90-Day Loops), and finally the realization that this was a leadership problem, not just a technical one. That realization is why I wrote The Cognitive Leader the book.

‍I tell my team something that I believe deeply: AI is not going to replace your work. But an engineer who is willing to harness this situation, who is willing to learn and work with the company to figure out this disruption, is the one who will thrive. The ones who refuse to adapt are the ones at risk. And that applies to companies too, not just individuals.

I am an optimist at heart. I always see the glass half full. That is my instinct, and it hasn't changed. What has changed is the clarity of what I'm optimistic about.

When AI first disrupted our industry, everything felt like a blur. Before, our lines of revenue were very clear: staff augmentation and dedicated teams for software delivery. Suddenly, I wasn't sure what the company was going to look like in two or three years. I couldn't see the path.

Now I can. After interviewing more than 150 CTOs and VPs of Engineering (and incorporating many of their suggestions into this book), after testing frameworks with our own teams, after seeing the results, I know exactly what the industry needs. Every CEO is asking their CTO the same question: how can I use AI to increase the productivity and the value my engineering team is providing to the company? And every CTO is struggling to answer that question because they're being told to transform while they're still delivering. Very few people are showing them how.

That's what The Cognitive Engineering Framework™ is. It's the map—and through The Cognitive Leader and Teravision’s work with other companies, we’re leading the way. And I'm optimistic because the need is real, the solution works, and very few companies in the market are providing it with the specificity and the practitioner credibility that we have.

I cannot be concerned about what I cannot control. I don't know what the software industry will look like in five years. But I know that the companies that approach this with structure, measurement, and intention will be in a far better position than the ones that either panic or wait. That's what I'm building for.

It happened during our innovation lab experiment. We created three fully autonomous software delivery pods, each one designed to take a product from idea to release using AI across every stage. Each pod had a Scrum master, a product specialist, a developer, a QA engineer, and a DevOps engineer. We gave them a week to research whatever AI tools they wanted, then eight weeks to deliver a product that would normally take seven months. And to make it even harder, they had to build it in programming languages the developers had never used before.

By the second or third week, the patterns were undeniable. The product work, the user stories, the business analysis, and the design work that used to require a product owner, a business analyst, and a designer could be accelerated dramatically using AI models. The QA team went from spending days writing test cases to generating comprehensive test matrices in hours. And the code, while not perfect, was being written by AI models at a speed that made it clear: the old team structure wasn't coming back.

Before this, a typical team had eight to ten people, and the engine of the team was the developers. When you wanted to accelerate a project, you added more developers. But AI changed what the engine is. The bottleneck shifted from producing code to defining what to build and validating that it works. That's a fundamentally different problem, and it requires a fundamentally different team.

Was it hard to admit? Absolutely. I had built Teravision on a model that worked for twenty years. I was losing deals for the first time. Clients were saying "that's fine" and walking away. Someone was doing something different, and I had to understand what it was. Later, at a CEO conference in 2024, I discovered that 90 percent of companies hadn't even started their AI software development transformation. Everyone inside the AI world felt late, but in reality, we were early. That gave me the confidence to commit fully. We were going to be the ones who figured this out.

I decided to write the book after the fifteenth interview, because every single person was trying to answer the same question. By the time I reached 150, the pattern had only gotten stronger. Every CTO, every VP of Engineering, regardless of company size, industry, or geography, was dealing with some version of the same challenge: how do I use AI to increase the productivity of my engineering team without breaking what already works?

‍What surprised me most was not that they all had the question. It was that while some companies were doing an amazing job, the majority had not found a systematic way to answer it. A lot of them were doing something. They had given their teams AI tool licenses. Some had done training. A few had champions inside their engineering organization who were getting great results individually. But when I asked them about their plan, their framework, their way of measuring whether this was actually working across the engineering organization, most of them didn't have one.

They were investing in tools without investing in process. They were training individuals without transforming teams. And they were measuring activity, like how many engineers are using Copilot, instead of measuring outcomes, like are we delivering more value faster with better quality.

The other pattern that surprised me was the human side. About half of the leaders I spoke with said they didn't need help. They could figure it out themselves. But when I dug deeper, what I found was that many of them were figuring it out in the dark, subscribing to dozens of information sources, reading articles where only one sentence was actually useful, and reinventing the same wheel that every other CTO was reinventing independently. One VP of Engineering told me he was following 30 to 40 different sources trying to piece together a coherent picture of what to do, and he still felt like he was guessing.

That's why I wrote the book. Not because the answer is complicated, but because most leaders didn't have it organized into a recipe. A one, two, three, four, five set of steps that a CTO could follow with confidence instead of guessing.

The symptom is always the same. A company buys AI tool licenses, distributes them to the engineering team, and says go. What happens next is predictable: about five percent of the engineers become power users and do amazing things. Another five percent are trying and struggling. The majority, sixty to seventy percent, use the tools occasionally for simple tasks but never integrate them deeply into their workflow. And twenty-five to thirty percent become detractors.

Think about that last group for a moment. You're telling someone who has been writing code for twenty years that the thing they've built their entire career and identity around is about to change fundamentally. Their value has always been in the code they write. And now you're telling them they're not going to write code anymore, that they're going to orchestrate a machine that writes code. That's not a technology problem. That's a deeply human problem.

Some companies go further and add training. That helps. You might see ten percent getting great results and another ten percent using the tools in meaningful ways. But you still have eighty percent of the engineering organization not really understanding how to make this work in their daily delivery. They understood why, probably. They just didn't have a roadmap. They didn't have a definition of success. They didn't know what good looked like.

And here's the critical part: when you have the pressure of delivery, and every engineering team does, people will always default to what they know. If using AI means slowing down this sprint, they'll skip the AI and write the code themselves. Every time. Unless someone intentionally creates the conditions for them to experiment, gives them permission to be slower for a few sprints, measures what's happening, and coaches them through the discomfort. That's leadership, not technology.

Every time I see a company treating AI transformation as a technical problem, their transformation stalls. They buy the tools, they might do some training, and then nothing changes at the engineering organization level. The companies that succeed are the ones where a leader, what I call a Cognitive Leader, intentionally orchestrates the transformation with structure, measurement, iteration, and coaching.

Here's a real example from our own teams.

When we started using AI for code generation, engineers, junior and senior, were taking the model's output and using it without fully validating it, because we didn't yet have a process to catch technical debt before it hit the codebase.

A group of our engineers pushed back directly: this doesn't work. If I use this code, I'm going to introduce technical debt into the application. And they were right. The code coming out of the model wasn't perfect. But I told them something that changed the way we operated: we know the code isn't perfect, and it's not perfect for many reasons. But this is the future of how software gets built. So we need you to get in, work with it, accept the technical debt for now, and then we'll figure out together how to prevent it or fix it. That permission, to ship imperfect AI-generated code and fix the process around it, would have been unthinkable a year earlier. And we did build those tools and checks.

The amplification problem goes beyond code. It shows up everywhere AI touches the software development life cycle. If you don't provide the proper context to a model, whether you're generating user stories, unit tests, or architecture decisions, you get a result that looks right but is wrong. Then you have to go back, reask with better context, iterate, and sometimes start from scratch. You've amplified a bad input into a bigger mess, spending more tokens, more compute, and more time than if you'd gotten it right from the beginning.

This is exactly why Chapter 6 of the book is called Standards Before Scale. AI cannot compensate for a weak engineering foundation. If your team has messy requirements, inconsistent code review practices, or unclear definitions of done, AI will scale those problems faster than any human team ever could. Establishing your minimum engineering standards before you introduce AI is the difference between optimizing your strengths and scaling your mistakes.

We could not help anyone if we didn't know how to do it ourselves. That was the starting principle. We have the advantage that most consulting firms don't: we run a 200-person engineering organization. We have real teams, working on real projects, under real delivery pressure. That gave us something no amount of theory could provide, which is multiple data points.

Team Zero is a cross-functional group inside the engineering organization whose job is twofold. First, they create the initial version of the AI Adoption Map: the tools, the guidelines, and the implementation strategies that the rest of the company will eventually use. Second, they are the first team to apply every new practice in real product work. They break the typical rules. They operate in an innovation mode, testing hypotheses, measuring results, and figuring out what works and what doesn't before anyone else has to take the risk.

Our C-level team has deep expertise in Agile methodologies and in how to introduce technical innovation into an engineering organization. We knew from experience that you cannot transform everybody at the same time. Innovation has to start with a small, protected group that has executive backing, capacity protection, and the freedom to experiment. Once that group proves the model works, you take what they learned, package it into a Transfer Package, and scale it to the next teams.

That's exactly what happened at Teravision. Team Zero tested, measured, and iterated. We saw what worked and what didn't. We gave engineers permission to introduce technical debt, something unthinkable before, and then built the guardrails to manage it. We created the AI-Ready Engineering Certification because we realized training couldn't be random. And we designed the 90-Day Loops because we realized that without structured measurement cycles, everything stalls after the initial excitement wears off.

Only after all of that, after testing with our own teams for months and seeing measurable results, did we start helping clients. And by then, we weren't guessing. We had a tested playbook.

Adoption stalls for a predictable set of reasons. The first is that there is no intentional plan. Everybody is trying to figure it out at the same time. Some people inside a team might find something that works for them personally, but there's no mechanism to capture that, standardize it, and spread it across the engineering organization. The wins stay siloed.

The second is that there are no measurements and no definition of success. If you don't know what good looks like, you can't tell whether you're making progress or spinning your wheels. Teams don't have a hypothesis to prove, a baseline to compare against, or a cycle for reviewing whether what they're doing is actually producing results. Without that, the initial energy fades and people default to what they've always done.

The third is the delivery pressure. Every engineering team is evaluated on what they ship. When the choice is between experimenting with AI, which might slow you down this sprint, and delivering the features your CEO is expecting, delivery wins every time. Unless someone intentionally protects the space for experimentation and gives the team permission to be slower for a few cycles while they build new habits.

What we did differently was design around all three of these problems. The Cognitive Leader concept is about intentionality. It's the leader who connects the AI tools, the team, and the process in a harmonious way to create a synergy. This doesn't happen by giving people licenses and hoping for the best. It requires deciding which measurements matter, building a hypothesis about what will improve, executing for a defined period, measuring the results, and then deciding whether to continue, adjust, or pivot. That's the 90-Day Loop.

The loop creates a rhythm. It gives the team a defined period where they know they're being measured, where they have a clear goal, and where there will be a review at the end. It replaces the vague sense of "we should be using AI more" with a concrete plan that has milestones, accountability, and evidence of progress. That's what prevents the stall.

Adoption stalls for a predictable set of reasons. The first is that there is no intentional plan. Everybody is trying to figure it out at the same time. Some people inside a team might find something that works for them personally, but there's no mechanism to capture that, standardize it, and spread it across the engineering organization. The wins stay siloed.

The second is that there are no measurements and no definition of success. If you don't know what good looks like, you can't tell whether you're making progress or spinning your wheels. Teams don't have a hypothesis to prove, a baseline to compare against, or a cycle for reviewing whether what they're doing is actually producing results. Without that, the initial energy fades and people default to what they've always done.

The third is the delivery pressure. Every engineering team is evaluated on what they ship. When the choice is between experimenting with AI, which might slow you down this sprint, and delivering the features your CEO is expecting, delivery wins every time. Unless someone intentionally protects the space for experimentation and gives the team permission to be slower for a few cycles while they build new habits.

What we did differently was design around all three of these problems. The Cognitive Leader concept is about intentionality. It's the leader who connects the AI tools, the team, and the process in a harmonious way to create a synergy. This doesn't happen by giving people licenses and hoping for the best. It requires deciding which measurements matter, building a hypothesis about what will improve, executing for a defined period, measuring the results, and then deciding whether to continue, adjust, or pivot. That's the 90-Day Loop.

The loop creates a rhythm. It gives the team a defined period where they know they're being measured, where they have a clear goal, and where there will be a review at the end. It replaces the vague sense of "we should be using AI more" with a concrete plan that has milestones, accountability, and evidence of progress. That's what prevents the stall.

Chapter 1: The End of Isolated Improvements.

This is the chapter that makes CTOs stop and recognize their own situation. It opens with the story of our innovation lab, where we set up three autonomous delivery pods and gave them eight weeks to build products that normally take seven months. The results revealed everything we feared and everything we hoped for: real efficiency gains, but chaos everywhere because nothing was connected.

The chapter then tells the story of a client who built an impressive AI-powered QA process. They were generating test matrices in hours instead of weeks. It was a genuine success. But when QA started surfacing defects at that new speed, the development team couldn't absorb the feedback fast enough. Tickets piled up. The faster QA moved, the more obvious it became that speed in one stage does not create speed across the system.

That's the core insight of Chapter 1, and it's the one that early readers reacted to most strongly: you cannot layer AI on top of existing tools and expect transformation. You might get incremental gains, but they will be fragmented and shallow. Real transformation happens when AI becomes structural, embedded into workflows, connected across systems, and changing how people think, not just what tools they use.

If a CTO reads Chapter 1 and sees their own engineering organization in it, they'll want to read Chapter 2 immediately, because they'll be asking: okay, so what do I do instead? And that's where Team Zero comes in.

I thought it was a technical problem. At the beginning, when we were running the innovation lab experiments, the challenges were technical: which tools to use, how to get better output from the models, how to prevent technical debt in AI-generated code, how to validate quality at the speed AI produces. Those were real problems, and we had to solve them.

But they were just the tip of the iceberg.

The real problem was helping my team transform the way they work. These are engineers who had spent ten or twenty years writing code. Their entire career, their professional identity, their sense of value was built on the craft of writing software. And we were asking them to stop being the executors and start being the orchestrators. To stop writing the code themselves and start directing a machine that writes code for them. That's not a tool change. That's an identity change.We had to give them permission to jump in without a parachute. We had to tell senior engineers who had built their reputation on code quality that it was okay to introduce technical debt temporarily while we figured out the guardrails. We had to coach people through the discomfort of not being good at something they used to be great at. Training wasn't enough. You can teach someone how to use the tools, but if you don't address the fear, the resistance, and the identity crisis that comes with this kind of change, the training doesn't stick.

If I walked into a new company today, here's what I'd do differently from day one: I would not start with technology. I would start with leadership. I would sit with the CTO and align on what success looks like, how we're going to measure it, and what the engineering organization needs to hear from their leader before any of this starts. I would set up Team Zero with executive protection and clear boundaries. I would establish the baseline measurements before we change anything. And I would build in structured coaching from the very beginning, not as an afterthought once things get hard, but as a core part of the program from day one.

That's exactly what the AI Transformation Accelerator Program is. It's everything I wish I had when I started this journey, packaged into a structured engagement where my team walks alongside yours: the strategy, the measurement, the technical implementation, the coaching, and the executive support. If you're a CTO facing this transformation and you want to get there faster and with more confidence, that's what we built for you.

I love the way you brought this question around to coaching. Thoughts on adding a personal call-out:

I didn't write this book to sell a service. I wrote it because I went through something hard, figured out what actually works, and I don't want other leaders to have to learn it the same painful way I did.So if any of this sounds like where you are, I want to hear from you. Whether that means having me speak to your leadership team or at your next event, working with your organization directly through coaching, or bringing me in through a custom book package (to be linked) where my team and I sit alongside yours as part of the transformation itself, I'm available for all of it. This is the work I care about now. Reach out, and let's figure out what that looks like for your team.