Most enterprise engineering orgs are the wrong shape
The tools work. The platforms exist. The shape is the problem — and the reason enterprises won’t fix it has nothing to do with technology.
I have spent decades inside these organizations, as a builder, as a commercial leader, as the person sitting across the table from CTOs and CIOs who know something is wrong but cannot name it. Here is what I have concluded: the org chart is the most honest signal about where an enterprise is in its AI transformation. The adoption dashboard tells you what people want to believe. The pilot count tells you what is being attempted. The shape of the team tells you what is actually happening.
Right now, the shape is wrong.
The engineering talent model for the agentic era is a barbell. Weight at the top. Weight at the bottom. A deliberately skinny middle.
Most enterprises are still building pyramids. The more progressive ones have moved to diamonds. Both are the wrong shape for the agentic era, and the part nobody wants to say out loud is why enterprises resist changing it.
Model 01
The pyramid we all grew up in
The labor-based pyramid made sense when software delivery required human volume at every layer.
Twenty level-one engineers at the base. Eleven mid-career engineers above them. Seven leads. Three senior architects. One principal. Forty-two people to every principal. The economics of the services industry rested on that base, and for thirty years, it worked because the work was fundamentally labor: humans writing code, humans testing it, humans deploying it, humans doing it again.
Here is the problem. The pyramid did not just become a delivery model. It became a compensation structure, a career ladder, and an organizational identity. When the work started changing, those systems did not change with it. That lock-in is exactly what we are still paying for today.
Model 02
The diamond was progress. It isn’t the destination.
Agile and the modern engineering movement gave us the diamond. The widest layer moved to the middle, where advanced, strategic, program-level engineers were doing the hardest thinking. Fewer entry-level engineers at the base, because platforms absorbed the routine work. A smaller elite layer at the top.
The diamond was a genuine improvement. It matched where value was actually being created.
The diamond carries the same hidden assumption as the pyramid: humans execute the work. It just assumes senior humans execute instead of junior ones. When agents absorb execution, the fat middle becomes structurally unjustifiable. You do not need as many mid-career engineers sequencing human execution when agents are handling a significant share of that execution. The diamond starts looking like a diamond with a hole in the center.
An unstable shape. And yet most enterprises are defending it ferociously right now, because moving away from it means having conversations nobody wants to start.
The org chart is the most honest signal about where an enterprise is in its AI transformation.
Model 03 · The shape
The barbell. This is the shape.
Weight at the top. Weight at the bottom. A skinny middle, intentionally thin.
Top weight: platform architects and agentic architects. These are the people who design agent workflows, orchestration boundaries, governance, and guardrails. They set the rules the agents operate inside. Few in number, disproportionate in impact. One great agentic architect shapes the productive capacity of hundreds of agents. This role is the most valuable engineering role in the organization today, and most enterprises do not have it yet.
Bottom weight: AI-enabled engineers. Engineers who use AI platforms natively for development, testing, and deployment. Larger in number than the architect layer, but structurally different from pyramid-era level-one engineers. Their output comes from the platform, not from hours worked. One AI-enabled engineer with the right agentic tooling can deliver what five traditional engineers used to, with more consistent quality because the standards are embedded in the agents.
The handle: the skinny middle. Two roles live here, and this is where I see the most interesting and most misunderstood work happening.
The Engineering Orchestrator is the expert in the loop. They sit between architects at the top and agents at the bottom, validating outputs, handling exceptions, making the judgment calls agents cannot. Think of them as the conductor. The person whose job is to keep the system honest.
The AI Systems Engineer is the expert on the loop. Responsible for harness engineering: tuning agents, sharpening tools and skills, refining guardrails, managing context. If the AI-enabled engineers at the bottom use the agents, the AI systems engineers maintain them. Without this role, agents drift, quality erodes silently, and the whole barbell collapses back into a diamond.
Here is the rule that cannot be broken: the middle must stay skinny. Its purpose is coordination. Execution lives at the ends of the bar. The moment you fatten the middle — and enterprises will be tempted to, because they know how to hire mid-career engineers in volume — you have recreated the diamond and negated every advantage the barbell was designed to give you.
The real barrier
Why enterprises resist this
The technology is the easy part. I have watched agents do real engineering work across Ascendion’s own delivery floor and inside our clients’ environments. The platforms exist. The agents work. Clients see them in demos, in pilots, sometimes in production.
The barrier is organizational identity.
If you are a VP of Engineering in a large enterprise, your career was built on climbing a pyramid. Your organization’s career ladder is built on climbing a pyramid. The people you have managed, promoted, and advocated for climbed that ladder too. Telling your organization that the middle is going away means telling the people closest to you that the path they are on is no longer the path to the top.
This is an identity conversation wearing technology’s clothes.
And here is what makes it worse: the HR systems, compensation bands, and promotion frameworks of most enterprises are perfectly designed to resist this change. They were designed for a shape that no longer fits the work. The systems will keep producing pyramids and diamonds because that is what they know how to produce, until someone with enough authority changes the systems themselves.
I am direct with clients about this. The middle is going away because agents are absorbing the work the middle used to do. The orchestrator and the systems engineer who replace it are different jobs, requiring different skills. This is a transition. Different jobs, different skills, a different shape. Pretending the shape is stable is more damaging than saying plainly that it is changing. Every month you delay the conversation, you are compounding the reorganization you will eventually have to do anyway.
The path
Thirty-six months, four phases
For clients who commit, the path varies in speed and risk profile, but the structure is consistent.
Assess and map the roles honestly. Every engineering role on two axes: expertise level (how specialized and irreplaceable is the skill?) and agentic fit (how much value do agents actually add here?). From the map, three buckets emerge: augment quickly (high agentic fit, routine work), co-pilot (agent executes, human judges), and human-led (low agentic fit, high expertise, where agents are tools and never decision-makers).
I will be direct: this sounds obvious until you are in the room. The instinct is to protect the wrong roles for political reasons and sacrifice the wrong ones for speed. The honest map, built from what roles actually do day to day rather than what the job description says, is the single most valuable input into the transition. It is also where you discover that parts of the organization have been overstaffed for years, and other parts have been critically underfunded.
Define priorities together. Fast efficiency wins, like manual QA and legacy modernization, are the right starting point for most enterprises: high impact, fast payback, lower disruption. Higher-value transformations like DevOps, data engineering, and core platform work take longer but deliver durable change. I do not hand clients a priority stack. They know their P&L better than I do. What I bring is a view of what has worked, and what has caused pain.
Choose the path that matches your appetite. There are two modes. High-impact launch for organizations with executive conviction and a mandate to move fast. Phased evolution for organizations that need controlled change and step-by-step adoption. Both arrive at the same destination. The difference is speed and variance. The destination is identical. Treat the choice as a calibration question: how much change can this organization absorb this quarter?
Build the roadmap with honest timelines and honest conversations.
The transformation timeline for quality engineering organizations averages thirty-six months. Four phases across the arc: transition; human-led delivery with early efficiencies; agentic pilot; full agentic-led delivery, with human oversight moving from high to moderate to low across the timeline. Some will compress to eighteen months. Some will stretch to forty-eight.
Some will never start and die.
That last outcome is more common than anyone in this industry wants to say out loud. The cause is almost always change failure. Specifically, the failure to have the people conversation before the platform conversation. Technology is rarely what breaks the program.
Here is what the thirty-six months will feel like from the inside. The first six months will be deceptively smooth. Pilots run. Metrics look promising. Leadership is energized. Then month seven arrives, and the mid-career engineer who has been the most reliable person on the team for six years asks a direct question: what does this mean for me? If you do not have a real answer ready, specific to their future and delivered honestly, you will lose them. And when you lose them, you lose the institutional knowledge the agents are not yet ready to replace.
The restructuring pain is real, and it concentrates in two places.
The first is the career ladder collapse. The barbell eliminates the rungs that most of your senior mid-career engineers were standing on. The engineering manager who spent a decade building coordination skills finds that coordination is now partially automated. The program-level engineer whose value was holding the full delivery picture in their head finds that AAVA or a similar platform now holds a significant portion of that picture. These are concrete concerns: people with mortgages, with performance reviews, with self-identities built around being irreplaceable. Telling them “the model is changing” without telling them “here is specifically where you fit in the new model” is attrition by ambiguity dressed as change management.
The second is the promotion pipeline freeze. In a pyramid or diamond, there is always a next rung. In a barbell, the middle is intentionally thin, which means the promotion pathway from AI-enabled engineer to orchestrator to agentic architect is narrow by design. Organizations that do not address this explicitly will find that their highest-potential junior engineers, the ones with the most agentic fluency, leave for competitors who have figured out how to offer them a credible upward path inside the new shape.
The transition has to happen anyway. The point is that the people architecture must be designed with the same rigor as the platform architecture. Role definitions for the new shape — the Agentic Architect, the Engineering Orchestrator, the AI Systems Engineer, the AI-Enabled Engineer — need to be written, compensated, and career-pathed before the restructuring begins, not after it stalls.
The organizations that get to eighteen months are the ones that started the people conversation in month one. The ones that stretch to forty-eight or never finish are the ones that treated change management as a communications exercise rather than a redesign of how the organization operates.
Thirty-six months is the average. What stays constant is the direction, and the shape at the end: a barbell. Where you land on that range comes down to whether leadership had the courage to redesign the people model before the pain of not doing so became impossible to ignore.
The stakes
The cost of staying in place
The cost of defending the pyramid or the diamond while your competitors move to the barbell accumulates quietly. A slow erosion of delivery speed. A slow increase in rework. A slow drift in quality. A slow climb in engineering cost as a percentage of revenue.
Three years from now, you will look at your P&L and wonder why engineering spend is growing faster than output. The answer will be that your talent model is wrong for the era of delivery you are operating in, while the enterprise that redesigned its org chart for the agentic era has been compounding advantages you did not see accumulating because the trade press missed them too.
The gap is real. It is already forming. The enterprises that move first are opening a lead in cost, speed, and capability that is harder to close with every quarter that passes.
If you are a CTO and the middle of your org is starting to feel heavier than it should, you already know what I am describing.
The chart needs to be redrawn. That question is settled. The question is whether you redraw it on your terms — or wait until your competitors’ results make the conversation unavoidable.
I would rather redraw it.
About the Author
Arun Varadarajan is Chief Commercial Officer and Co-founder at Ascendion, an AI-native engineering company. Ascendion helps organizations build world-class products and platforms through Engineering to the Power of AI, underpinned by AAVA, Ascendion’s Agentic AI Platform.
