Locality

09 Feb 2026

In The Claes Test, I ask a critical question about collaboration: Do boundaries get out of the way so teams can solve problems together? (Question 7).

In many organisations, this box is left unticked. Progress depends on hand-offs, approvals and waiting for other teams, and what is described as “collaboration” often turns into a series of blockers. Autonomy is confused with working in isolation.

To move this from a blank to a tick, we need to understand the concept of Locality.

Locality isn’t about doing everything alone. It’s about having the authority, capability and expertise to meet customer needs without being slowed down by external dependencies.

Building Locality across three dimensions is what turns boundaries from obstacles into enablers of progress.

1. Locality of Authority vs. Locality of Toil

A common friction point is the belief that a team must build its own infrastructure from scratch to be “autonomous”. That isn’t Locality; that’s toil.

True Locality means decision-making stays with the team. A platform engineering team provides “golden paths”: automated, self-service workflows that amplify Locality by removing low-value plumbing work.

The Claes Test connection: This maps directly to Question 11 (CI/CD). Locality allows changes to be deployed safely and frequently without waiting for manual hand-offs from an external operations or release team.

2. Developer Independence as the Metric

Locality exists when a team can own the full application lifecycle without relying on another team to carry out essential work.

If a team has to wait for a central function to provision a database or approve a firewall rule, Locality is broken. The boundary has become a blockade.

In a platform-enabled environment, the platform team treats developers as customers, building self-service products that keep teams in the driver’s seat.

3. Locality through Decoupling

You cannot achieve Locality in a “distributed monolith”, where every change requires coordination across multiple teams.

Locality is technically enabled through a loosely coupled architecture.

This ensures the team closest to the service has everything they need — logs, metrics and diagnostics — to identify and resolve issues independently (Question 9: Production Readiness). If you have to ask another team to access your own production data, you don’t have Locality.

Fixing the Environment

As I note in the Claes Test, behaviour is a function of both the person and their environment — (\(B = f(P, E)\)).

The question “boundaries don’t block progress” isn’t about collaborating harder; it’s about fixing the environment.

By building platforms that enable Locality, we remove the structural friction that prevents teams from being truly autonomous and collaborative.

Locality is about ownership. Platform engineering is what makes that ownership scalable.

Interestingly, Locality is the first of the Five Ideals of DevOps. It is not a “nice to have”; it is the structural foundation that enables flow, continuous improvement, psychological safety and real customer focus. The Claes Test is, in many ways, a practical way of measuring whether Locality actually exists inside an organisation.

If boundaries are blocking progress in your organisation, the Claes Test can help you pinpoint where Locality is breaking down.

Take The Claes Test