Russell East's blog

The Rise of Engineering Career Ladders

Years ago, most medium and large technology organisations had architects. Today, many organisations are reducing dedicated architecture functions in favour of engineering career ladders: Senior Engineer, Staff Engineer, Principal Engineer. Architects have not disappeared, but architectural responsibilities are increasingly being absorbed into engineering leadership roles.

In many ways, that can be seen as a healthy correction. The industry was right to challenge architecture when it became a disconnected governance function: diagrams no one implemented, review boards that slowed down delivery, and decision-making detached from operational reality. Cloud platforms, DevOps, and platform engineering have shifted more responsibility to teams and brought architectural decisions closer to the people building and running systems.

That was mostly a good thing. But in some organisations, the pendulum may have swung so far toward engineering ownership that system-level architectural thinking is becoming undervalued.

This is not because engineers are incapable of thinking architecturally. Many do. And many of the best architects came from engineering backgrounds. The issue is not capability. It is structure.

Architectural thinking operates at a different level of abstraction and over a different time horizon. Engineering tends to focus on implementation, correctness, maintainability, performance, and delivery. Architectural thinking focuses more on system behaviour, boundaries, interactions, long-term evolution, and trade-offs.

Engineers often ask:

• How do we build this?
• What technology should we use?
• How do we deploy and test it?

Architectural thinking asks:

• Should this capability exist at all?
• Where should it live?
• What dependencies does it create?
• What fails when this fails?
• What will this decision look like in five years?

Both perspectives matter. But they are not the same perspective. And when architecture is fully collapsed into delivery-based feature teams, something important can get lost.

Architecture Needs Space To Breathe

Feature teams are optimised for delivery. They are measured by roadmap progress, sprint commitments, team outcomes, production health, and local ownership. Those are reasonable incentives. But they naturally reward solving the problem directly in front of the team.

Architectural thinking often requires something else: the space to step back from immediate delivery pressure and ask what the system, platform, and organisation are becoming over time.

When architectural responsibility is absorbed entirely into delivery teams, architecture does not disappear. But it often loses the space to breathe.

That matters because many of the most important architectural questions sit outside any one team’s backlog:

• Are our boundaries still fit for purpose?
• Can teams evolve independently?
• Are we accumulating architectural drift?
• Are we creating accidental complexity faster than we are removing it?
• Is our platform becoming a force multiplier or a coordination bottleneck?
• Are we scaling the system, or merely scaling the effort required to change it?

These are not feature-level concerns. They are system-level concerns. And they often have no obvious owner.

Architecture Maturity Versus Technical Debt

This is where architecture maturity becomes important. Engineers often discuss code quality, refactoring, and technical debt. Architectural thinking asks a broader question:

Is the organisation becoming easier or harder to evolve?

Architecture maturity is not just about whether today’s design is acceptable. It is about whether the wider system, operating model, team topology, platform, and governance model are becoming more coherent and more resilient over time.

A mature architecture is one that can absorb growth, support independent team evolution, tolerate change, and reduce accidental complexity rather than constantly producing more of it.

Those questions rarely belong neatly to a feature team. Often, nobody is explicitly rewarded for asking them.

What Architecture Is Actually Optimising For

One reason architecture is often misunderstood is that architects are rarely measured by the same outcomes as delivery teams.

Feature teams are expected to deliver capabilities.

Architectural thinking is responsible for ensuring those capabilities can continue to operate and evolve successfully over time.

Its outputs are rarely features.

Its outputs are system qualities.

• Reliability
• Scalability
• Security
• Resilience
• Operability
• Observability
• Recoverability
• Compliance
• Adaptability
• Cost efficiency
• Architectural coherence

These qualities are easy to overlook because they are not usually visible during feature delivery.

They become visible when they are absent.

• Customers notice outages.
• Engineers notice operational friction.
• Businesses notice rising costs and slower delivery.

Architecture exists to influence those outcomes before they become problems.

This is perhaps why architecture has always struggled to demonstrate its value.

Organisations are very good at recognising visible value: features shipped, delivery speed, customer outcomes, roadmap progress.

They are much worse at recognising invisible value: avoiding scalability failures, preventing future coupling, reducing operational fragility, identifying security risks before launch, or preserving the ability for teams to evolve independently.

Architecture is often judged poorly because its best outcomes look like nothing happened.

• A scalability failure that never occurred.
• A security incident that never happened.
• A costly rewrite that was avoided.
• A product that continued evolving long after its original design life.

Success is often measured by the problems that never materialised. That does not make the work less important. It simply makes it harder to explain.

Did Organisations Lose Faith In Architecture?

Many of the criticisms levelled at architecture over the years were justified. Some architecture functions became detached from delivery, overly governance-focused, and disconnected from operational reality. But that does not necessarily mean organisations stopped needing architecture. It may simply mean they stopped seeing the value because the value was poorly articulated. Perhaps businesses did not lose faith in architecture. Perhaps many never fully understood what architecture was for in the first place.

Architecture was often presented as diagrams, review boards, standards, governance, and documentation. Those are outputs. They are not the purpose.

The purpose of architecture is to guide systems toward desirable outcomes and away from undesirable ones. The artefacts are merely tools. The value lies in shaping the conditions under which systems remain reliable, secure, scalable, maintainable, and capable of evolving over time.

Why AI Changes The Equation

For a while, the gap was easier to ignore. With cloud-native, many architectural choices became standardised. Infrastructure patterns matured. Deployment models became repeatable. Observability stacks, platform abstractions, and managed services reduced the number of foundational decisions each organisation had to make from first principles.

That made it easier to flatten architecture into engineering seniority and still function reasonably well.

AI-native systems may expose the limits of that model. These systems introduce concerns that are not purely implementation concerns:

• Model selection
• Grounding
• Memory
• Orchestration
• Evaluation
• Agent coordination
• Runtime governance
• Human oversight
• Cost behaviour

These are not simply feature decisions. They are system decisions.

An engineer might ask: How do I integrate an LLM?

Architectural thinking asks: What role should reasoning play in this system in the first place?

An engineer asks: Which model should we use?

Architectural thinking asks: What happens when that model changes, degrades, or becomes economically unviable?

An engineer asks: How do I call the API?

Architectural thinking asks: What new dependencies, failure modes, operational risks, and governance challenges have we just introduced?

These are questions that span teams, products, platforms, and business strategy. Historically, they are exactly the kinds of questions architecture disciplines emerged to address.

The Real Question

This is why I think the more interesting question is not whether organisations need architects.

It is whether they have preserved architectural thinking while reshaping the role.

Many organisations seem to assume that architectural capability naturally emerges at higher levels of engineering seniority.

Sometimes it does.

Many principal engineers absolutely think architecturally. Many staff engineers do too. But seniority and architecture are not synonyms.

Promoting someone into a more senior engineering band does not automatically create the incentives, space, or organisational mandate to think about cross-system coherence, long-term evolution, architecture maturity, or systemic risk.

Engineers create value by delivering capability. Architectural thinking creates value by shaping the conditions under which capability can continue to be delivered safely, reliably, and coherently over time.

The real question is not whether organisations need architects.

It is who is thinking about the system qualities nobody else is incentivised to own.