What Good Looks Like in 2026: A Systems View of Engineering Excellence

The question I'm asked more than any other by engineering leaders is some version of: are we doing well?

It's a reasonable question and a hard one to answer honestly, because "good" is context-dependent. Good for a startup is different from good for a regulated enterprise. Good for a platform team is different from good for a product team. Good five years ago is not the same as good in 2026.

But there are signals that cut across context. Patterns that show up in genuinely high-performing engineering organisations regardless of size, sector, or technology stack. Here's what I'm seeing in the organisations that are genuinely excellent right now - and what separates them from the ones that think they are.

---

The Numbers Are Not the Story

Elite performers by DORA standards in 2026 are deploying multiple times per day, moving from commit to production in under an hour, maintaining change failure rates below 5%, and recovering from failures in under an hour. These numbers are real and worth knowing.

But the numbers are outputs, not inputs. Chasing the numbers produces the numbers, not the capability that generates them. The organisations genuinely performing at this level didn't set a target of "deploy daily." They built the capability - the architecture, the pipeline, the culture, the platform - that made daily deployment the natural state. The number was the consequence, not the goal.

This is the distinction most improvement programmes miss. They target the metric and miss the system.

---

Culture Is Still the Foundation

Ten years of DORA research has produced one finding that never changes: generative culture is the strongest predictor of software delivery performance.

In 2026, this remains true. It remains underacted on.

A generative culture - in Ron Westrum's model - is one where information flows freely, where failure is treated as an opportunity to learn rather than a reason to assign blame, where problems surface quickly because surfacing them is safe, and where novelty and improvement are actively encouraged.

The engineering organisations I see performing at genuine elite levels share this culture. Not because they mandated it or wrote it into their values documentation, but because their leaders - over years - consistently responded to failure with curiosity rather than blame, consistently created space for honest conversations about constraints, and consistently demonstrated that raising a problem was a contribution rather than a complaint.

You cannot buy this culture. You cannot install it with a framework. You build it, slowly, through consistent behaviour at every level of leadership. And in 2026, the organisations that built it five or ten years ago are now compounding the advantage.

---

The Architecture Question

Every conversation about engineering excellence eventually arrives at architecture. Inevitably, because architecture shapes everything else: team structure, deployment independence, cognitive load, blast radius, lead time.

In 2026, the organisations performing best have architectures that enable independent deployability. Not necessarily microservices - over-decomposed architectures carry their own costs - but systems where the blast radius of any single change is contained, where teams can release without coordinating across five other teams, where the deployment of one service does not require the synchronised deployment of twelve others.

The move toward this architecture is slow, difficult, and political. It requires trading short-term delivery capacity for long-term flow. It rarely shows up in quarterly OKRs. But it is the single highest-leverage structural investment most engineering organisations can make.

The organisations still operating tightly coupled monolithic architectures in 2026 - without a credible plan to evolve them - are accumulating architectural debt that will increasingly constrain everything else they try to do.

---

Platform Capability as Competitive Advantage

In 2026, the presence or absence of genuine platform engineering capability is a significant competitive differentiator. Not the presence of a "platform team" - many organisations have those - but the presence of a platform that delivery teams genuinely use, genuinely value, and genuinely find accelerating.

The signal I look for: can a new engineer get from "laptop arrives" to "merged and deployed" in a single day? In genuinely platform-mature organisations, yes. In most organisations, no - and the reason is almost always that the golden path isn't golden enough, the documentation is incomplete, or there are too many manual steps in a process that looks automated on the surface.

Platform maturity translates directly to Deployment Frequency (lower friction, more deployments), Change Failure Rate (security and quality built into the path), and MTTR (observability and incident response tooling standardised and available). It is not separate from DORA performance - it is one of the primary drivers of it.

---

AI: Amplifier, Not Transformer

The organisations using AI most effectively in 2026 are not the ones with the most AI tools. They are the ones with the strongest foundations - good test coverage, observable systems, capable deployment pipelines - that AI is now accelerating.

AI makes good processes faster. It does not make bad processes good.

The clearest evidence of this: elite performers are using AI to reduce incident MTTR (faster triage, automated runbooks, better signal correlation), to accelerate code review (PR summaries, automated defect detection), and to reduce onboarding friction (instant answers to codebase questions). All of these improvements are additive to an already-capable system.

Organisations using AI primarily to generate code faster, without the test and pipeline infrastructure to validate that code safely, are creating new problems at the speed of AI generation.

---

The BVSSH Lens on 2026

Better Value Sooner Safer Happier remains, for me, the most useful single frame for evaluating engineering health. Not because it's a framework to follow, but because it keeps the focus on outcomes rather than activity.

Better in 2026 means: code quality is improving over time, not degrading. Technical debt is visible, managed, and reducing. Defect rates trend down.

Value in 2026 means: teams know whether what they shipped mattered. Outcome metrics exist. The connection between engineering work and customer impact is visible and taken seriously.

Sooner in 2026 means: lead time is measured honestly from idea to customer, not just from commit to deploy. WIP is managed. Flow is a system property, not a team aspiration.

Safer in 2026 means: security is a practice, not a gate. Change blast radius is understood and managed. Recovery is fast and blameless.

Happier in 2026 means: engineers are growing, have genuine agency, and trust that the organisation responds to problems rather than suppressing them. Attrition among high performers is not the story.

---

Where Most Organisations Actually Are

Honest answer: most engineering organisations in 2026 are not performing at this level. Most are in the low or medium DORA bands. Most have architectural coupling that constrains flow. Most have some version of a change approval process that slows deployment. Most have observability that is incomplete and incident response that involves too much heroics.

This is not a failing - it is a starting point. The question is not whether you're at the destination. The question is whether you have an honest picture of where you are, a credible theory of the constraints, and a sequence of investments to address them.

The organisations that will be elite in 2031 are the ones that are honest about where they are today and serious about the work.

That work is available to you. It is not easy, but it is knowable. And the distance is not as great as it can feel from inside the system.