From Pyramids to Diamonds: Rethinking Engineering Teams in an AI-Native World
In my last post, I explored the idea that we may be moving from a knowledge-based economy towards something that places greater emphasis on judgement, framing, and leverage.
That shift doesn’t just affect individuals. It has implications for how we structure teams, how we develop capability, and how we think about the long-term sustainability of engineering organisations.
Most engineering teams today are still built on a familiar model.
The pyramid
The traditional structure is broadly pyramidal:
- A wide base of junior engineers focused on execution
- A layer of mid-level engineers translating intent into delivery
- A smaller group of senior engineers shaping systems and making trade-offs
- A thin layer of leadership setting direction and owning outcomes
This model has worked well for a long time.
It scales. It creates a pipeline. It allows organisations to balance cost, throughput, and capability. Juniors gain experience by doing. Seniors amplify their impact by guiding.
But it relies on a key assumption:
There is a steady flow of entry-level work that justifies a large base of junior engineers.
That assumption is starting to look less stable.
Pressure at the base
AI is particularly effective at the kind of work that has historically been used to onboard and develop junior engineers.
Boilerplate code. Routine transformations. Incremental feature work. First-pass implementations.
Individually, none of these tasks define a role. Collectively, they form a large proportion of the work that fills the bottom of the pyramid.
As that work becomes easier to automate or compress, two things happen:
- Fewer junior roles are created
- The remaining roles demand a higher baseline of capability
This is already visible in some parts of the industry — teams are hiring fewer juniors, expecting more from those they do hire, and leaning more heavily on a smaller number of experienced engineers supported by AI tools.
Which leads to an uncomfortable question:
If the base of the pyramid shrinks, what happens to the structure built on top of it?
From pyramid to diamond
One alternative framing is a shift towards a more diamond-shaped structure.
Instead of a broad base, you have:
- A relatively small intake layer
- A dense core of highly capable engineers
- A continued emphasis on senior judgement and leadership
This is closer, conceptually, to how some high-performance teams operate in other domains.
Specialist military units, for example, do not optimise for large numbers of entry-level operators. They recruit selectively, invest heavily in capability, and expect individuals to operate across a broader range of responsibilities earlier in their careers.
The analogy is not perfect, but the structural idea is useful.
A diamond model assumes:
- Fewer people overall
- Higher average capability
- Greater individual leverage
- Faster progression from entry to meaningful responsibility
AI acts as a force multiplier within that structure, increasing the effective output of each individual.
Figure: Traditional pyramid vs diamond-shaped team structure
The pipeline problem doesn’t go away
The diamond model solves for efficiency at a point in time. It does not automatically solve for sustainability.
You still need a way to develop future senior engineers.
If anything, the problem becomes harder.
With fewer junior roles and less exposure to real-world complexity early on, the path to deep expertise becomes less obvious. You risk creating a system that is efficient in the short term but brittle over time.
So the question becomes:
Where does the next generation of capability come from?
Some possibilities are already emerging:
-
More deliberate training environments
Structured programmes, internal or external, that simulate the kinds of experiences juniors used to gain on the job -
Greater reliance on adjacent talent pools
People entering from non-traditional backgrounds, or transitioning from other disciplines -
AI-augmented learning
Using AI not just for output, but as a tool for accelerated skill development and feedback
None of these are drop-in replacements for the old model. All require intentional design.
The short term vs the long term
This is where the tension becomes more explicit.
Most organisations are optimised for delivery.
Roadmaps, deadlines, revenue targets, and operational pressure all push in the same direction. Output matters. Predictability matters. Efficiency matters.
In that environment, investment in capability development is often seen as discretionary.
Training juniors is slower. Mentoring takes time. Creating structured learning environments requires effort and budget. None of it shows up immediately in delivery metrics.
So it gets deprioritised.
That's rational in the short term, but it creates a structural problem over time.
You end up optimising for immediate output at the expense of future capability. The pipeline narrows. The dependency on a small number of highly capable individuals increases. The organisation becomes more efficient, but also more fragile.
This is not a new problem, but AI accelerates it.
By making experienced individuals more productive, it reduces the perceived need to invest in developing others. That, in turn, reinforces the short-term bias.
Designing for both horizons
The challenge is not choosing between short-term delivery and long-term capability.
It is designing systems that can support both.
That requires a more deliberate approach:
- Being explicit about where capability development happens
- Treating learning as a first-class activity, not a side effect
- Creating environments where less experienced individuals can still engage with meaningful complexity
- Using AI as a tool for acceleration, not just substitution
This is where many organisations struggle.
The incentives are misaligned. The feedback loops are long. The benefits are indirect.
Bridging that gap between tactical delivery and strategic capability is not trivial. It requires intent, discipline, and, often, external perspective.
The shape of the individual
Alongside changes in team structure, there’s a parallel shift in how we think about individual capability.
The idea of the T-shaped individual has been useful for a long time:
- Broad understanding across multiple areas
- Deep expertise in one
It still has merit. But it may no longer be sufficient as a standalone model.
In an AI-augmented environment, both breadth and depth are under pressure, but in different ways.
- Breadth is easier to simulate, because AI can provide rapid access to adjacent knowledge
- Shallow depth is easier to replace, because routine expertise can be automated
That suggests a different shape emerging.
Not a single deep spike, but multiple areas of meaningful depth, combined with the ability to connect them.
You might think of it less as a T, and more as a set of reinforced pillars connected by a flexible layer of understanding.
The exact metaphor is less important than the underlying idea:
Individuals need both deeper expertise in selected areas and sufficient breadth to operate effectively across systems.
Figure: T-shaped vs multi-pillar individual capability
Judgement as the connective tissue
This is where the themes from the previous post reappear.
If knowledge becomes more accessible and execution more automated, then the differentiator shifts.
Judgement becomes the connective tissue between areas of expertise.
Knowing which tool to use. When to trust the output. When to override it. How to balance competing constraints. How to make decisions under uncertainty.
These are not new skills, but they become more central as other aspects of the work are compressed.
A transition, not a switch
It’s worth being clear that this is not an overnight shift.
Most organisations today still look broadly pyramidal — many will continue to do so for some time.
But the pressures are already visible at the edges:
- Fewer junior roles.
- Higher expectations.
- Greater reliance on tooling.
- More emphasis on senior judgement.
The shape is starting to change.
The question is whether we acknowledge that change early enough to design for it, or whether we let it emerge by accident.
Because if the pipeline breaks, you don’t feel it immediately.
You feel it months or years later, when you realise you no longer have enough people who know how to make the hard decisions.