White paper — DevOps at scale: organisation and tooling

White paper · April 2026

DevOps at scale: organisation and tooling

Turning software delivery into an advantage — from 2 to 200 teams

“DevOps cannot be bought: it is organised. Tools follow the organisation — never the other way round.”

4 topologies

4 metrics

90 days

of teams are enough to describe every delivery organisation that works

DORA — the only ones that predict delivery performance, and how not to corrupt them

The action plan, from the flow diagnosis to the first golden path in production

This white paper draws on the digital-steering engagements of the Clarendis network; it reads on its own — and rereads at every growth threshold.

Contents

Foreword 03 Executive summary — the document in ten statements 04 Your reading path 06 1 The DevOps misunderstanding What DevOps is not · What the research says · The “DevOps team” anti-pattern · What the status quo costs 07 2 What scale really changes Conway's law cannot be dodged · Cognitive load, the limiting resource · The three growth thresholds · What breaks in practice 12 3 The organisation: four topologies, three interactions Stream-aligned teams · The platform as a product · Enabling teams · On-call and production ownership 17 4 The tooling: the complete chain, six blocks CI/CD · Infrastructure as code · Observability · Security and supply chain · Environments · Golden paths — and how to choose without being sold to 22 5 The blind spots Legacy · Compliance and security · Cloud costs · On-call wear · Corrupted metrics · The five-question test 28 6 The 90-day action plan Where are you starting from? · D1-D30: measure the real flow · D31-D60: organise and pilot · D61-D90: the first golden path · The five-number dashboard 33 Moving to execution 37 Appendices — Glossary, references, about Clarendis 38

Foreword

Twenty years after the word was coined, DevOps is everywhere — in job titles, tenders and tool catalogues — and the original promise remains largely unkept where it matters: delivering fast, often and serenely when you are no longer ten people, but two hundred. What works naturally in a two-team startup breaks at twenty: pipelines multiply without resembling each other, production becomes nobody's disputed territory, and every release becomes an event again.

This white paper was born of an engagement-room observation: organisations that fail to scale DevOps almost never have a tooling problem — they have an organisation problem that the tools reveal. Yet the answer, almost always, is one more purchase. We take the opposite path here: organisation first (chapter 3), tooling second (chapter 4), and measurement to arbitrate (chapter 6).

One point of intellectual honesty: this field has the rare privilege of real research — the DORA programme published in Accelerate, the State of DevOps surveys, Team Topologies. We lean on it explicitly, we flag what comes from our own field experience, and we recommend no vendor: Clarendis sells no licences, no cloud, and takes no referral commission.

How to read this document. The chapters stand alone. If your deliveries slow down as you grow, start with chapter 2. If you are reorganising, chapter 3 is your plan. If a tooling tender is coming, chapter 4 is your grid. Each chapter closes with the same panel, what this changes for you, written for three readers: the CEO, the CIO, the tech lead. It is deliberately the same subject seen from three angles, because DevOps fails precisely where leadership, IT and teams do not share the same definition of “delivering”.

Enjoy the read — and the deployments.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

for the Clarendis team

Executive summary

The document in ten statements. Each is developed in the chapter indicated.

1

2

DevOps is neither a job title, nor a team, nor a tool. It is a property of the organisation: the ability to deliver fast, often and safely, measurable by four metrics. Everything sold under the name is judged against that property. (Chapter 1)

Speed and reliability are not opposites. DORA research shows it year after year: the organisations that ship most often are also the ones that break least. The “fast or stable” trade-off is a belief, not a datum. (Chapter 1)

3

4

Conway's law cannot be dodged — it can be used. Your systems will end up resembling your org chart. So draw the organisation you want to see in your architecture, not the other way round. (Chapter 2)

The limiting resource is not budget: it is the teams' cognitive load. A team that must master the business domain, fifteen tools and three clouds masters nothing. All of chapter 3 is a machine for reducing that load. (Chapter 2)

5

6

Four team topologies are enough. Stream-aligned, platform, enabling, complicated subsystem — and three interaction modes. Any box on the org chart that fits none of the four deserves a question. (Chapter 3)

The platform is a product, not a project. It has customers (the teams), a product manager, a roadmap driven by their irritants — and its adoption is voluntary: a platform you impose is a platform people bypass. (Chapter 3)

7

8

Tooling is rationalised through the golden path, not the catalogue. One paved road end to end — from commit to production — covering 80% of cases, adopted because it is the simplest, not because it is mandatory. (Chapter 4)

Security and compliance are tooled into the flow, not bolted onto the end. A blocking check two days before release manufactures workarounds; the same check automated in the pipeline manufactures continuous compliance. (Chapters 4-5)

9

10

DORA metrics measure systems, never people. The day they serve to rank teams or evaluate individuals, they are corrupted — and your teams will learn to manufacture them rather than earn them. (Chapters 5-6)

A DevOps transformation is change management like any other. Sponsor, pilot, visible wins, anchoring: the platform teams that succeed do product and support — not infrastructure and directives. (Chapter 6)

Where to start, depending on your situation:

You are growing and everything is slowing down. Chapter 2 (the thresholds, cognitive load), then chapter 3: your problem is almost certainly topological, not technical.

A tooling programme is coming. Chapter 4 in full — the six blocks and the golden rule: the golden path before the catalogue. And §5.3 before signing anything cloud-shaped.

You have “already done DevOps” and the results disappoint. Chapter 5: the blind spots are where your transformation is lying. Then the chapter 6 dashboard, to put the “already done” to the test.

Your reading path

Three waymarked itineraries. The “What this changes for you” panels, at the end of each chapter, are written for your seat at the table.

CEO CEO 25 minutes

CIO CIO / CTO 1 h 30

TL Tech lead 1 hour

01 Executive summary

Full document recommended. Your critical path:

You live this daily. Your path:

02 chapter 1 (§1.4: what the status quo costs, in business language)

01 chapter 2, §2.2 (cognitive load: a name for your daily life)

01 chapter 2 (Conway, cognitive load, the three thresholds)

03 chapter 3, §3.2 (the platform as a product — the investment decision that falls to you)

02 chapter 3, §3.1 and §3.4 (your topology, your on-call)

02 chapter 3 in full (your organisation plan)

03 chapter 4 (the six blocks, and the anti-vendor grid)

03 chapter 4, §4.6 (the golden path — what to demand of the platform)

04 chapter 6, §6.4 (the five numbers to put on your agenda).

04 chapter 5 (legacy, compliance, FinOps, on-call)

04 the six “Tech lead” panels, at the end of each chapter.

You will know what to fund, what to demand, and how to check it is moving.

05 chapter 6 in full — the plan is yours.

What you came here for

Need

Where

In what form

Understand why growth slows delivery

Chapters 1-2

The real DevOps track record, Conway, cognitive load and the three growth thresholds

A target organisation plan

Chapter 3

Four topologies, three interactions, the platform-product and the on-call model

A vendor-free tooling grid

Chapter 4

Six blocks — for each, the function, the choice questions and the classic mistake

A plan executable tomorrow

Chapter 6

90 days in three phases, and the DORA+ dashboard in five numbers

Chapter 1

The DevOps misunderstanding

1

Before talking organisation and tooling, the word needs to be stripped of what has been loaded onto it — and what the research, for once abundant, actually says needs to be laid down.

1.1 What DevOps is not

The word was born in 2009 from a simple idea: the wall between those who build and those who operate is the first cause of slowness and incidents — tear it down. Fifteen years later, the market has made it something else entirely: a job title (“DevOps engineer”), a team (“the DevOps team”), a product range (“the DevOps toolchain”). Each of these reifications betrays the original idea, and the third is the costliest: it lets people believe the property can be bought.

The useful definition fits in one sentence: DevOps is an organisation's ability to deliver software fast, often and safely, end to end, without heroics. It is a property of the system — organisation + architecture + tooling — and it is measurable: deployment frequency, lead time from commit to production, change failure rate, time to restore. These four metrics, from the DORA research programme, are the through-line of this whole document.

Everything presented under the DevOps name — a hire, a reorganisation, a tool, a consulting engagement — is therefore judged by a single question: “which of the four metrics does this improve, for which teams, and how will we see it?” Applied honestly, that filter saves entire budgets.

1

Chapter 1 — The DevOps misunderstanding

1.2 What the research says — and why it is a stroke of luck

This field has a rare privilege in management: ten years of large-scale surveys (the DORA programme, published notably in Accelerate, Forsgren, Humble & Kim, 2018, and the annual State of DevOps reports). Three robust results structure everything else:

Speed and reliability go together

Practices matter more than tools

The highest performers deploy more often AND break less — the gap with the lowest performers is measured in orders of magnitude. The “speed/stability trade-off” is the most documentedly false myth in the industry.

Continuous delivery, small batches, trunk-based development, automated tests, a learning-from-failure culture: practices predict performance — the tool is only their carrier. Two organisations with the same tooling get unrelated results.

Culture is measurably causal

And one limit to know

Organisations where information flows and failure instructs (a “generative” culture in Westrum's sense) outperform. This is not a soft extra: it is a predictive variable in the models.

These surveys are declarative and correlational; they illuminate broad trends, not your particular case. We use them as a compass, never as a benchmark to copy — §5.5 says what happens when they are corrupted.

1.3 The “DevOps team” anti-pattern

The most widespread organisational answer is also the most counter-productive: creating “the DevOps team”, between the developers and operations. The intention is good; the effect is mechanical: where there was one wall, there are now two — plus a bottleneck team through which every pipeline, every release and every ticket must pass. The symptoms are visible from afar: a swelling infrastructure backlog, developers waiting, a “DevOps” team exhausted and blamed from both sides.

The nuance that changes everything: a dedicated central team is an excellent thing if it builds a product the others consume autonomously (the platform, chapter 3), and a very bad one if it executes for others what they could do themselves. The test is simple: if its workload grows linearly with the number of teams served, it is a bottleneck; if it grows much more slowly, it is a platform.

1

Chapter 1 — The DevOps misunderstanding

1.4 What the status quo costs — in business language

Slow, fragile software delivery does not show up as such in a P&L. It shows up elsewhere, on four cost items nobody ever reconciles:

The opportunity cost. Every week between a validated idea and its production is a week in which a competitor can learn in your place. When shipping is expensive, you ship big and rarely — so you bet big and learn slowly. Deployment frequency is first and foremost a learning speed.

The cost of concentrated risk. Rare releases are events: dozens of changes bundled together, a Friday evening, a crisis cell if anything goes wrong. Risk does not disappear when you space out releases — it concentrates. Small frequent batches are the only risk dilution that works.

The human cost. Release nights, endured on-call, tired heroes holding production at arm's length: this way of working selects its profiles — and exhausts them. The tech job market does the rest: the best engineers choose organisations where shipping is a mundane gesture , not an exploit.

The cost of the double life. When the official path is too slow, teams build their own: the “temporary” server, the personal deployment script, the cloud account opened on a credit card. Every workaround is a security and compliance debt in the making — chapter 5 returns to it.

The conviction that structures this document

At scale, DevOps is an organisation problem that the tools reveal — never the other way round. Organise first (chapter 3), tool up second (chapter 4), measure to arbitrate (chapter 6). Any effort that starts with a tooling tender has already taken the problem backwards.

1

Chapter 1 — The DevOps misunderstanding

The four DORA metrics — the document's shared vocabulary

Metric

What it measures

What it tells you

Deployment frequency

How often code actually reaches production

Your learning speed — and the size of your bets

Lead time for changes

The time from a commit to its arrival in production

Your chain's real fluidity — queues and approvals included

Change failure rate

The share of releases that degrade the service

The quality of your safety nets: tests, reviews, progressive rollout

Time to restore (MTTR)

The time to restore service after an incident

Your real resilience — observability, rollback, on-call organisation

Two rules of use, right away: these metrics are read together (optimising speed alone degrades the rest, and vice versa) and per system, never per person (§5.5). Chapter 6 turns them into a dashboard — completed by a fifth number DORA does not provide.

What this changes for you

CEO

CIO

TL

CEO. Ban the question “have we done DevOps?” and replace it with “how long between a validated idea and production, and which way is that number moving?”. One question — but it reorients every budget.

CIO. If you have a central “DevOps team”, run the §1.3 test this month: does its workload grow with the number of teams served? If yes, you are funding a bottleneck — chapter 3 says how to turn it into a platform.

Tech lead. Measure your team's lead time now, even by hand: commit date, production date, over the last ten changes. That number is your best argument in every discussion that follows.

© Clarendis — April 2026 10

1

Chapter 1 — The DevOps misunderstanding

Chapter 1 in three takeaways

4

0

2

DORA metrics: frequency, lead time, failure rate, time to restore — read together, per system

Speed/stability trade-off: the fastest are also the most reliable — the research is unambiguous

Walls instead of one: the mechanical effect of the interposed “DevOps team” — the bottleneck test in §1.3

The Friday test

A free diagnosis of your real maturity: can you deploy to production on a Friday at 4 pm without asking permission or warning anyone? If the answer is “certainly not”, you know your releases are risky events, not mundane gestures — and this whole document concerns you. The right answer is not “we forbid it”; it is “why would that be a problem?”.

© Clarendis — April 2026 11

Chapter 2

What scale really changes

2

What works with two teams breaks at twenty — and it is neither fate nor chance. Two laws structure the passage to scale: Conway's, and the lesser-known law of cognitive load.

2.1 Conway's law cannot be dodged — it can be used

I n 1968, Melvin Conway observed that organisations produce systems that copy their communication structure. Sixty years of software engineering have only confirmed it: your architecture will end up resembling your org chart. Three teams that must coordinate to ship a feature will produce a three-layer coupled system; a central approval will produce a central bottleneck in the code too.

The practical consequence is called the inverse Conway manoeuvre: rather than enduring the law, you use it — you first draw the organisation whose architecture you want to see emerge. You want decoupled, independently deployable services? You need decoupled, independently shipping teams: owning a scope end to end, with the minimum of synchronous dependencies between them. That is exactly the programme of chapter 3.

The corollary that stings: reorganising without touching the software boundaries, or refactoring the architecture without touching the organisation, produces the same failure. The two are drawn together — which is what makes scaling a matter for general management, not an internal IT project.

© Clarendis — April 2026 12