5 min read
I have had this conversation five times in the last two months. The titles change (VP of Engineering, CTO, Senior Director of Platform), the companies change (financial services, healthcare, logistics, insurance), the size changes (eighty engineers, four hundred, two thousand). The conversation is always the same.
I ask about their goals. Their constraints. Where they are right now. The answer is some version of: “We did an all-hands. Overview of the tools. Where to find the docs. We told people to experiment.” Sometimes it is a Friday afternoon lunch-and-learn. Sometimes it is a four-part webinar series. Sometimes it is a Slack channel with links to articles nobody reads.
I ask what happened after. Some people tried it. Most did not. The ones who tried ran into code review policies, security friction, or architecture approval and stopped. The early adopters kept going because they already knew how to navigate around the process. Everyone else went back to the way things were.
So I ask: can we do a two-hour session where your teams see what modern software development actually looks like in 2026, powered by agents? What it looks like when engineers pair with AI agents to ship production code. How the workflow changes. How code review changes. How testing changes. What governance has to look like when your team is producing code at three times the velocity your approval chain was designed for.
The response, almost every time: “We are super busy. What can you do in thirty minutes?”
That answer tells me everything I need to know about an organization’s readiness.
The Two Hours Is a Test
The session is not the product. It is not the strategy. It is a test.
Most readers also read: Stop Reviewing Code. Start Proving It Works. My Take on AI in the Quality Process of Software.
I am not asking you to solve your AI adoption problem in two hours. I am asking whether your organization can carve out two hours to see what modern development looks like and have an honest conversation about what needs to change. That is the lowest possible bar. If you cannot clear it, we are having a different conversation entirely.
Organizations that cannot find two hours are telling me that the calendar is more important than the strategy. That existing commitments (most of which exist to maintain the current operating model) take absolute priority over the work required to change it. That is an honest answer. But it is not one that leads anywhere productive.
What Awareness Does Not Buy You
Workshops, webinars, lunch-and-learns, Slack channels — all of it buys you awareness. People now know the tools exist. They have a vague sense that things are changing. But awareness is not adoption. And no amount of it closes the gap on the things that actually matter.
It does not close the governance gap. Your code review process was designed for humans writing code at human speed. When your engineers start producing code three times faster, the bottleneck moves to review, architecture approval, and your change advisory board. If you do not know what real governance looks like (not a 47-page policy document, but enforceable operating rules), those bottlenecks will multiply faster than your teams can ship.
It does not uplift capability. Real uplift means changing what people do on Monday morning. It means telling your senior engineers that the way they learned to build software has fundamentally changed and giving them a supported path forward. It means building an AI-native engineering team, not handing AI tools to the team you already have.
It does not force the hard decisions. Which teams get restructured. How compensation changes when an AI-native engineer delivers in weeks what used to take quarters. Whether you build a parallel organization or try to transform in place. These are executive decisions with organizational consequences. They require time to think, time to debate, and the willingness to commit.
The Real Cost of Not Having Time
If you do not have two hours to identify the structural barriers to AI adoption, you will have dozens of hours for the consequences of not identifying them. Hours of meetings about why the pilot failed. Hours of steering committee discussions about which tool to pick (it does not matter, the tool is a commodity). Hours of one-on-ones with frustrated engineers who hit a wall of process friction that nobody gave them permission to change.
You will find the time. The question is whether you spend it up front, when it can shape the outcome, or after the fact, when it becomes damage control.
I have watched this pattern for twenty years. Agile. DevOps. Cloud. The organizations that carved out time at the beginning to do the hard thinking outperformed the ones that tried to squeeze transformation into the margins of an already full calendar. Every single time.
What Happens After
People leave the session with a shared picture of what agent-driven development looks like right now, where the bottlenecks will move, and a short list of governance decisions that need to be made in the next 30 days.
But the two hours is the beginning, not the end.
Nathan is the clearest example I can point to. He was planning to hire ten engineers. Instead, he committed to changing the operating model. Two engineers using agent-driven development outproduced the ten he was planning to hire. Not because the tools were magic. Because the governance changed, the roles changed, and the way work flowed through the system changed. The results followed.
The organizations I work with that produce real outcomes share a pattern. They treat the kickoff as a diagnostic, not a deliverable. They redesign their governance model within the first 30 days. They start measuring what actually matters (cycle time compression, defect escape rate, revenue per engineer) instead of tracking utilization dashboards. They build the parallel organization rather than trying to transform the existing one in place.
None of that starts in a workshop. All of it starts with the willingness to block two hours and have the conversation.
The conversation usually ends the same way. Can I send them some materials instead? A deck. A recording. Something their team can watch on their own time.
That is not how this works. The reason the session produces results is not the content. It is the commitment. Leadership sitting in the room saying “this matters enough to block my calendar.” You cannot delegate that to a recording.
Some of them find the two hours. Some do not. The ones who do not will spend the next twelve months running experiments that fail for the same structural reasons, one after another, until someone asks why the AI initiative has not produced results.
The hard decisions are still waiting. The governance model still needs to change. The roles still need to evolve. The capability gap is widening every quarter you defer.
