You cannot transform what you have not measured.

Here is something I have learned the hard way over the past year and a half. The biggest obstacle to AI transformation is not resistance. It is not budget. It is not even the technology. It is the assumption that you already know where your team stands.

Every CTO I talk to has a general sense of how their engineering team is using AI. Some engineers are using copilots. The QA team is generating test cases. A few people are experimenting with agents. There is activity. There is energy. But when I ask a simple question, "Is it compounding?", the room goes quiet.

The truth is that most engineering teams are moving, but very few know whether they are moving in a direction that compounds. Individual stages accelerate, but the full process stays roughly the same. Some engineers produce exceptional results with AI while others on the same team produce inconsistent work. There is motion, but there is no map.

This is exactly why I wrote The Cognitive Leader. Because AI transformation is not a technology challenge. It is a leadership challenge. And the first act of cognitive leadership is having the clarity to know exactly where your organization stands before you try to move it forward. You cannot orchestrate what you have not measured. You cannot coach what you have not assessed. And you cannot lead a transformation built on assumptions.

That is why we built the AI Transformation Assessment. A structured diagnostic that evaluates your engineering organization across three dimensions: People, Process, and AI Adoption. It tells you exactly where you stand on a six-stage transformation curve, where the gaps are, and what your concrete next steps should be.

As I wrote in the book:

"Those twenty, thirty, or forty percent productivity gains will not show up on day one. They take maturity, structure, and time. In the beginning, you will probably need to go slower before you can go faster."

Knowing where you are is what allows you to go slow in the right places and fast where it counts. The assessment is not a report card. It is a starting point. A way to move from gut feeling to a structured, data-informed path forward.

From Raul Escobar, VP of Engineering — Teravision Technologies

What we actually find when we assess engineering teams.

I have been part of every AI transformation assessment we have conducted at Teravision. And the pattern is remarkably consistent.

What leadership believes about their team's AI readiness and what the assessment reveals are almost never the same thing.

-The most common assumption- I hear is "my team is already using AI." And they are. But when we look closer, what we typically find is that a handful of engineers are driving most of the AI adoption. They figured it out on their own, they are producing strong results, and leadership points to them as evidence that the team is transforming. The problem is that those engineers are the exception. The rest of the team is either experimenting without direction, using AI superficially, or quietly avoiding it altogether because they do not know where to start.

The gap between the best and the rest is wider than most leaders realize. And without structured training, that gap does not close over time. It widens. AI amplifies whatever skill level the engineer already has. A strong engineer with AI becomes exceptional. An engineer without a clear foundation produces work that looks fast but creates problems downstream.

-The second- thing we consistently find is that AI adoption is happening in silos. The QA team might be generating test cases with AI. Developers are using copilots. Product might be using AI for PRDs. But none of these efforts are connected. There is no shared framework linking them together, no way to measure whether AI usage at one stage is creating value or problems at the next.

-The third- finding is almost always about governance. Two patterns show up consistently. Some teams have no formal AI policies at all. Engineers are using personal accounts, free tools, and whatever they found on their own, and leadership is largely unaware of the extent of it. Other teams do have policies, clear rules about approved tools, data handling, and model usage. The challenge there is enforcement. Without the right tooling, there is no practical way to know whether those policies are being followed. Either way, the result is the same: no centralized toolchain, no reliable data privacy standards for AI usage, and no validation process for AI-generated outputs. In a production environment, that is real risk regardless of what the policy document says.

-The fourth- finding is the one that surprises leadership the most. When we ask who owns AI transformation, there is usually someone with nominal responsibility, a CTO, a transformation officer, a senior technical lead. The real issue is that ownership has sometimes landed with the wrong person, or the right person is working without the cross-functional authority, budget, and mandate to move the whole organization. And beyond ownership, what is almost always missing is a shared goal for everyone else to align around. Organic adoption has real value. Engineers exploring, experimenting, and finding what works on their own is a strength worth building on. What prevents scale is that energy having no common direction, no structure to build on, and no way for the gains to compound across teams. The opportunity is in giving that momentum somewhere to go.

None of this is a failure. It is a starting point.

Every team we have assessed has real strengths to build on. The value of the assessment is not in telling you what is wrong. It is in giving you a clear, honest picture of where you actually are so you can build a plan that starts from reality instead of assumptions.

If any of this sounds familiar, that is because it is. You are exactly where most engineering organizations are right now. The question is whether you want to stay there or start moving forward with structure.