Most leaders who read my last piece walked away with the right diagnosis and the wrong next step.
I know this because of the conversations that followed. A CTO at a major financial institution told me he had forwarded the article to his entire engineering leadership team and scheduled a two-day offsite to discuss the implications. A Chief Digital Officer said she was commissioning a training program to develop product thinking skills across her developer population. A Head of Engineering at a regional bank told me he was planning to rebrand his senior engineers as “product engineers” in the next performance cycle.
Every one of those responses is understandable. None of them will change the system.
I have spent three years now building at Arula — sitting inside the engineering organizations of some of the largest financial services firms in the world, not observing the transformation from a conference stage but doing the work inside institutions that manage trillions of dollars — and what I have learned is that the gap between understanding a problem and closing it is wider than most leadership teams expect. This article is about what is actually in that gap.
The Three Things That Do Not Work
Before I describe what does work, I want to name the three responses I see most often, because recognizing them is the first step to getting past them.
The first is buying tools without redesigning the workflow. The organization adopts Copilot, or Cursor, or an internal AI coding assistant, watches individual developer velocity climb, and reports this as AI transformation. It is not. It is the first step of Stage 2, which I described last time as the false summit. The tool is real. The productivity gain is real. The transformation has not started.
The second is training individuals inside an unchanged operating model. The engineers go through an AI certification program. They come back more capable. They return to a sprint structure, a backlog grooming process, and a handoff model that was designed for the world before AI. Their new skills have nowhere to land. Within six months, the training investment has dissolved into the existing system, and the organization is wondering why nothing changed.
The third is rebranding existing roles without changing what those roles actually do. A job description gets updated. “Product-Minded Engineer” appears in the hiring criteria. The actual work — the tickets, the sprints, the sign-offs, the handoffs — stays identical. The new title describes a different job. The organization never builds the different job.
What all three responses have in common is that they treat this as an individual problem. They try to change people inside a system that has not changed. The system always wins.
What the Work Actually Looks Like
At Arula, we run a sprint we call Forge. Every three weeks, a small team goes deep inside a client organization — talking to the senior leaders whose judgment has never been codified, the veteran engineers whose pattern recognition lives entirely in their heads, the compliance officers who have spent twenty years developing instincts about where risk actually lives. And we encode that knowledge into an agent system.
One sprint. One fully operating agent, making decisions within defined boundaries, handling the volume of work that used to require a human to be in the loop for every instance.
The first time a client team sees this, the reaction is almost always the same. They expected a tool. They got a redesigned operating model. Because the process of building the agent — decomposing a decision into its component logic, designing the guardrails, defining where autonomous action is appropriate and where a human needs to intervene — forces the organization to have conversations it has been avoiding for years. Who actually owns this decision? What are the criteria? What does good look like? What does failure look like and how fast do we catch it?
Those conversations are not technical conversations. They are organizational conversations. And the engineering team that can lead them is a fundamentally different animal from the engineering team that implements a spec.
What the Foundry Model Teaches About Org Design
Arula’s Foundry model delivers client work through small, outcome-based pods. No product manager writing user stories. No designer handing off comps. No project manager tracking dependencies between teams. The engineers in a Foundry squad talk directly to business stakeholders, make tradeoff decisions with real consequence, and own the outcome — the business metric, not the ticket.
The enterprises that engage us this way ship two to three times faster than their internal teams running traditional models. Not because our engineers are smarter. Because the model eliminates the coordination tax.
The lesson for CIOs is not “hire Arula.” The lesson is that the coordination tax in your own organization is a structural cost you have learned to treat as normal. Every handoff between product and engineering, every approval cycle between an engineer and a business stakeholder, every sprint ceremony designed to align people who should be aligned by structure — these are not process features. They are process debt. And the organizations that redesign around small, empowered, outcome-responsible pods are not just faster. They are building the organizational muscle that AI-native delivery requires.
The Skill Nobody Is Training For
In the two years since we launched Prowess — Arula’s AI engineering certification program — the demand signal has shifted in a way I did not fully anticipate. Engineers enrolling in the program are not primarily looking for AI coding skills. They already have those. What they are looking for is the judgment layer: how to define the boundaries of autonomous action, how to evaluate AI output at the architectural level, how to make and defend a product-level decision in a room full of non-technical stakeholders, and how to explain AI risk to a compliance officer who needs to sign off on a system she has never seen before.
That last skill is where careers in financial services are made or broken right now, and it is the most underinvested capability in almost every engineering organization I enter. The organizations that are building it systematically — not through a single training program but through the accumulated practice of actually doing it in production environments — will have an advantage in the talent market that compounds year over year.
The Trench Is the Teacher
The enterprises that will lead in 2027 are not the ones with the most sophisticated AI strategy presentations. They are the ones whose engineers are already doing this work — building agents, owning outcomes, making product decisions, designing governance guardrails — and whose leadership has built the organizational infrastructure to make that work normal rather than exceptional.
The trench is not a metaphor. It is where the capability is built. And the question every CIO reading this needs to answer is whether their organization is in it yet, or whether they are still planning to get in.
In my next piece, I will describe what the organizations that are genuinely there look like — and the system that gets you from where most enterprises are to where the leading ones have arrived.
Keep Growing.
