16 min read
I wrote recently about the VP of Agile Transformation who got a fifteen-year service award while the organization still could not release without a change advisory board meeting. A lot of people read that article. A lot of people sent it to their CTO. And then a few of those CTOs did the thing I was afraid they would do.
They started writing a job description.
Not for a VP of Agile Transformation. They know that title is dead. Not for a Head of AI. They read the article and they know the CoE pattern fails. So they got creative. “VP of AI Capability.” “Senior Director of Organizational AI Competency.” “Head of AI Enablement and Workforce Readiness.” The titles are new. The org chart is the same. A person in a box, arrows pointing outward, a charter that says “build AI capability across the enterprise,” and a twelve-month clock before anyone asks whether the arrows carried anything.
If that job description is on your desk right now, I need you to close the laptop and read this first.
The Hire Is the Problem
I want to be precise about why this does not work, because the instinct behind it is reasonable. You have a capability gap. You want to close it. The fastest path your organization knows how to take is to hire someone senior, give them a team, and tell them to close it. That is how you solved the DevOps problem (eventually). That is how you solved the cloud migration problem (sort of). That is how you have solved every capability problem for the last twenty years.
Most readers also read: Stop Reviewing Code. Start Proving It Works. My Take on AI in the Quality Process of Software.
But AI capability is different in a way that matters, and if you do not understand why it is different, you will spend two years discovering it the expensive way.
When you hired a VP of DevOps, the capability they were building lived in the pipeline. It was infrastructure. It was tooling. It was a thing that a centralized team could build once and everyone else could use. The person using the CI/CD pipeline does not need to understand how it was built. They need to understand how to push code through it. That is a training problem, and training problems can be solved with enablement teams.
AI capability does not work that way. The capability is not in the pipeline. It is in the person. An agent is not infrastructure that someone else builds for you. An agent is a description of your work, written by you, refined by you, maintained by you. The person who builds the agent has to be the person who understands the work, because the work is the input. You cannot centralize that any more than you can centralize the ability to write a clear email or run an effective meeting. Those are individual competencies, and they develop through practice or they do not develop at all.
When you hire a VP of AI Capability, you are telling your organization that building agents is someone else’s job. You are telling every director, every manager, every individual contributor that they can wait. Someone is coming to help. Someone will build the training. Someone will create the framework. Someone will figure it out and then teach it to them.
And they will wait. They are very good at waiting. They waited for the Agile CoE to teach them Agile (it did not). They waited for the DevOps team to teach them DevOps (they eventually embedded it, but it took five years longer than it should have). They will wait for the VP of AI Capability to teach them AI, and in eighteen months you will have a VP with a team of eight, a wiki with templates, a Champions program with monthly meetings, and an organization that still does not build agents.
The hire is the problem because the hire is the signal. The signal says: this is not your job yet.
What the End State Looks Like
Before I tell you what to do instead (and I will, and you will not like parts of it), I need you to see where you are going. Because most organizations skip this step. They start moving without defining the destination, and then they wonder why they are still driving in circles a year later.
The end state is not “we have AI capability.” That is a bumper sticker, not an organizational design. The end state is a specific operating model with specific structural changes, and if you cannot describe it, you are not ready to pursue it.
Here is what I see in the organizations that got this right.
Every team builds and maintains its own agents. Not a centralized team. Not a shared services group. The supply chain team builds supply chain agents. The QA team builds testing agents. The finance team builds reconciliation agents. The people who understand the work are the people who automate it, because they are the only people who can describe it with the precision an agent requires.
The coordination layers that exist because humans were slow have been restructured. Your project management office (PMO), your change advisory board, your architecture review board, your three-week regression cycle. These existed because human-speed development produced enough risk that centralized review was a reasonable trade-off. When development happens at agent speed and governance is automated in the pipeline, centralized review becomes a bottleneck that produces delay without producing safety. The organizations that got this right moved the function into the pipeline. The CAB does not disappear. Its function does not disappear. The meeting disappears. Automated tests, deployment gates, and audit trails give your compliance team and your regulators the same evidence they had before, faster, with less human error. If you are in financial services and your OCC examiner asks about change governance, you show them the pipeline audit log instead of the meeting minutes. (I wrote about what that governance model looks like.)
The roles that remain are the roles that require judgment, not coordination. Engineering managers who can evaluate agent output. Product people who can define what the agent should build. Leaders who understand the technology well enough to make architectural decisions without asking a vendor. The roles that disappear are the ones that existed to move information between humans who were too busy or too siloed to talk to each other. Agents do not have that problem.
Team sizes are smaller. Not because you laid people off (though some of you will, and some of you should, and I am not going to pretend otherwise). Because five people with agent capability produce what fifteen people produced before, and the economics of that are not something your board will ignore for long. The organizations I work with that are furthest along have teams of three to five producing what teams of ten to fifteen produced eighteen months ago. Nathan’s story is the clearest example I can share: he joined a company as CTO with a mandate to hire ten engineers, hired zero, and in twelve months he and one existing associate engineer decomposed a monolith, automated deployments, and outshipped the original ten-person roadmap — total engineering burn under $500K for the year.
That is the end state. Smaller teams, fewer coordination layers, governance in the pipeline, and every person in the organization building agents as a normal part of their work. Not a special initiative. Not a transformation. The way work gets done.
Now. How do you get there?
Force the Organization to Do It
I use the word “force” deliberately, because the alternative is “invite,” and invitation is how you got fifteen years of Agile coaches and a crystal clock.
When you invite an organization to adopt a new capability, the people who were already inclined to adopt it will adopt it, and everyone else will watch. You saw this with Agile. The early adopters ran sprints. Everyone else waited for the CoE to tell them when it was their turn. You saw it with DevOps. The teams that already wanted to deploy faster deployed faster. Everyone else kept filing tickets with operations.
Invitation produces islands. It does not produce organizational capability. And the gap between the islands and the mainland gets wider every quarter, because the people on the islands are getting faster while the people on the mainland are still doing the work the old way.
Forcing the organization means your leaders do three things that are uncomfortable, one of which will be actively resisted.
First: Your Leaders Have to Use It Themselves
I cannot overstate how important this is, and I cannot overstate how many organizations skip it.
Your VPs and directors are making decisions about AI capability every day. They are approving or rejecting tool requests, governance frameworks, team structures, hiring plans. And most of them have never built an agent. They have seen demos. They have attended vendor presentations. They have read the articles (including mine, which is kind of them). But they have not sat down and described a process to an AI and watched it execute. They have not experienced the moment where the agent handles an edge case they thought would require custom code. They have not felt what it is like to automate two hours of their own work in forty minutes.
That absence of experience is making your decisions worse in ways you cannot see. A VP who has never built an agent approves a three-month tool evaluation because it seems prudent. A VP who has built an agent knows the tool does not matter and kills the evaluation on day one. A director who has never built an agent approves a 40-page governance framework because it seems thorough. A director who has built an agent knows you need one page and an automated pipeline, because the framework is only useful if people are building, and nobody is building if they have to read forty pages first.
Get your leaders in a room. Not for a workshop. Not for a vendor demo. For two hours where they build something. Give each of them a real problem from their own work. A report they generate manually every week. A review process they do by pattern-matching through a spreadsheet. A communication they draft by copying and editing a previous version. Have them describe it to an AI and watch it work. That experience changes the quality of every decision they make about AI for the next year.
This is the step most organizations skip. It is the step that matters most. Because until your leaders understand this technology from the inside, they will keep approving structures designed for a world where AI is hard to use and risky to deploy. It is neither of those things anymore, and your leaders need to know that from experience, not from a slide.
Second: Define the Org Design You Are Building Toward
This is the part I see almost nobody doing, and it explains why most AI initiatives feel like they are moving without arriving.
You need to draw the organizational chart that you are building toward. Not the chart you have. The chart you want. What does your engineering organization look like when every team has agent capability? How many people are on each team? What roles exist? What roles do not exist anymore? Where does the architecture review go when the pipeline enforces architecture standards automatically? What happens to your PMO when cycle times compress from weeks to days?
I am not asking you to implement this chart tomorrow. I am asking you to know what it looks like so that every decision you make this quarter moves you closer to it instead of in a random direction.
When I work with organizations that are doing this well, the end-state chart has a few consistent features. Teams of three to five instead of ten to fifteen. No separate QA organization (quality is built into the agent pipeline). Change governance automated in the pipeline rather than managed through a monthly meeting. Architecture review enforced through automated checks in CI, not through a room where six people look at a diagram. Product and engineering collapsed into the same team rather than operating as separate functions that hand work back and forth. If you are in a regulated industry, the governance functions still exist, they just run as code instead of as committees.
Your chart will look different depending on your industry, your regulatory environment, and your starting point. But you need a chart. Because without it, you are making tactical decisions without a strategic frame, and tactical decisions without a frame are how you end up with eight Agile coaches and a crystal clock.
Third: Teach It Like You Teach Writing Code
This is the step that will be actively resisted, and I want to tell you why so you are prepared.
When I say “teach AI capability to your organization,” I do not mean training. Training is what the AI team does when it runs a lunch-and-learn about prompt engineering. Training is passive. It is information transfer. The person leaves the training knowing more than they knew before, and then they go back to their desk and do exactly what they were doing before, because knowing about a capability and having a capability are not the same thing.
Teaching is different. Teaching means your people build agents as part of their regular work, with support, with feedback, and with the expectation that they will ship something. Not a proof of concept. Not a demo. A working agent that solves a real problem in their actual workflow. And you give them the time to do it (four hours a week, protected, not “when you find time”), and you give them the tools (AI access for every team, not a pilot), and you give them the governance (one page, automated in the pipeline, not forty pages reviewed by a committee).
Here is why this will be resisted. Learning to build agents means accepting that the way you have done your job for ten or fifteen years is about to change fundamentally. That is hard. Especially for your most experienced people, whose expertise and identity are built on doing the work the old way. Be patient with them, but do not let their comfort set your timeline.
I have watched this play out at seven organizations in the past year. About twenty percent picks it up immediately — they see the tool, they see their work, and they connect the two without needing to be told. Another fifty to sixty percent comes along within two to three months, once they see the early adopters having success and their manager makes it clear this is expected, not optional. The remaining twenty to thirty percent takes longer, and some never fully make the transition.
That last group deserves an honest answer, not a euphemism. Some will find a different role where their domain expertise is the value and agent capability is less critical. Some will need structured reskilling with a timeline and support, not a link to an internal wiki. Some will decide this is not the organization they want to work for anymore. If you have a unionized workforce or tenured employees with contractual protections, you need to plan this transition inside those frameworks, not around them — your labor counsel should be in the room before you announce anything. Make the exit respectful and generous, because these are often your most tenured people and the way you treat them on the way out determines whether the fifty percent in the middle trusts you on the way forward. Have the plan before you need it. Severance terms, internal mobility paths, reskilling budgets, redeployment timelines.
Set the expectation. Provide the support. Protect the time. Measure the output: agents deployed, workflows automated, cycle time compressed. The organization will be uncomfortable for six to twelve months while the capability develops.
That discomfort is the transformation. It is not a side effect. If nobody is uncomfortable, nothing is changing.
Why You Cannot Outsource This
I need to say this directly, and I say it as someone who does this work for a living: some of you are already thinking “What if I hire a consultancy to come in and teach the capability instead of hiring a VP?”
That is a better instinct than hiring the VP, but it still misses the point. A consultancy can show your leaders what agent-driven development looks like. A consultancy can help you draw the end-state org chart. A consultancy can build the governance pipeline and the automated guardrails. Those are legitimate uses of outside expertise.
But a consultancy cannot build the capability for you. The capability is in your people’s hands or it is nowhere. A consultant who builds your agents for you has given you agents, not capability. When that consultant leaves (and they will leave, because that is the business model), you are left with agents nobody on your team knows how to maintain and a dependency you did not mean to create. (That is how vendors end up owning your strategy.)
This is a core competency. Building agents, using AI to automate your work, operating in an agent-driven development model. These are not things you outsource any more than you outsource writing code or managing your product roadmap. You can get help standing it up. You cannot hire someone to own it for you. The moment you try, you have created the CoE under a different name, and you already know how that movie ends.
The Rough Part
I promised you this would be rough. Let me be specific about what rough looks like so you can prepare instead of being surprised.
Your leaders will resist going first. They will want to delegate the learning to their teams while they continue to “lead strategically,” which is a polite way of saying they want to stay in the part of the job they already know how to do. You need to push past this, because a leader who has not built an agent is making decisions about AI adoption the way a person who has never driven a car makes decisions about highway design. Competently, perhaps, but missing something fundamental.
Some of your best people will struggle. The developer who has been writing code for fifteen years will have a harder time letting an agent write code than the developer who joined three years ago, because the experienced developer has to unlearn before they can relearn. Be patient with them. But do not let their timeline become the organization’s timeline.
Your middle management will try to turn this into a process. They will want to create an internal certification, a maturity model, a quarterly assessment. They will want to measure readiness instead of output. This is the organizational immune system responding to a threat. It is trying to absorb the change into existing structures so that nothing actually has to change. Do not let it. Measure agents deployed. Measure workflows automated. Measure cycle time compressed. Those are the numbers that tell you whether capability is developing. A maturity assessment tells you whether people can answer questions about capability, which is a different thing entirely.
You will lose some people. Not many, but some. The ones who built their identity around a way of working that is being replaced will decide they would rather work somewhere the old way still applies. Do not pretend the change is smaller than it is to keep them comfortable, because that pretending is how you end up with a CoE that spends fifteen years managing the gap between what the organization says it wants to become and what it is actually willing to do.
None of this is easy. But you already know that, because you watched the easy version fail for fifteen years.
The Two Paths
You have two paths, and by now you know what they are.
Path one: six to twelve months of discomfort. Your leaders learn something new. Your teams change how they work. Your middle management stops building process around the change and starts letting the change happen. You plan for the people who struggle and you treat them well on the way through. At the end, you have an organization where every team builds agents, governance runs in the pipeline, and AI capability is as ordinary as sending an email.
Path two: you hire a VP of AI Capability. They build a team. They create a wiki. They run a Champions program. They produce a quarterly report for the steering committee. Everyone feels good because someone is “owning” the problem. Nobody is uncomfortable because nothing is actually changing. And in three years, someone hands that VP a crystal clock, and your organization still cannot build an agent without filing a request with the team across the hall.
This is a core capability for your company. It is not a program, not a department, and not a hire. It is a competency that either lives in every team’s hands or does not exist. You would not outsource writing code. You would not outsource managing your product. Do not outsource this.
It is going to be rough. Do it anyway.
