CI/CD pipelines rarely fail for technical reasons: they inherit the dysfunctions of the organisation that creates them. A team spends weeks building a careful pipeline; six months later, nobody dares touch it, builds fail at random and the wait is counted in tens of minutes. This lesson describes the five mechanisms that produce this degradation, copy-paste, the untouchable pipeline, debt, slowness and hero culture, then what teams that last do differently.
What you will learn
- Link a pipeline symptom to its organisational cause
- Recognise copy-paste, the untouchable pipeline and hero culture
- Identify the four forms of pipeline debt
- Explain why a slow pipeline degrades commit size
- Adopt the practices of mature teams
The pipeline, a mirror of the organisation
A CI/CD pipeline is not a simple chain of scripts: it is the crystallisation of a team's processes, responsibilities and culture. Each step reflects an organisational decision: who may merge, which tests are mandatory, who answers for a failed deployment, how long you accept to wait for a result.
Conway's law applies directly: a pipeline reproduces the communication structure of the organisation that builds it. A siloed team produces a fragmented pipeline; a team where nobody wants to take responsibility produces a pipeline with no owner.
Organisational symptoms
The table links what you observe in a pipeline to what it reveals about the organisation. Read it left to right as a diagnosis: the right-hand column says where to act, and it is rarely in the configuration file.
| What you see | What it reveals |
|---|---|
| Steps that pile up and never disappear | Nobody has the authority to simplify |
| Permanent exceptions for some projects | Political negotiation rather than technical standards |
| Tests disabled "temporarily" for months | Delivery pressure with no regard for quality |
| A different pipeline for each team | Organisational silos, no shared vision |
| Nobody knows why a step exists | Departures and lost context |
Copy-paste as a birth certificate
The way a pipeline is born often shapes its fate. In many organisations, the first one is copied from a tutorial or another project, then hastily adapted to get the build through. Three problems follow. Cargo cult first: steps remain without anyone understanding their purpose, kept "just in case".
Lost context next: the original pipeline answered precise constraints of team size, application or security, which do not necessarily apply elsewhere. Finally impossible evolution: changing a poorly understood pipeline is risky, so the team prefers adding steps to simplifying.
How it shows
Take a team of three people that copies the production pipeline of a large company for an internal project. It inherits integration tests on fifteen environments, multi-level security validation and a three-stage approval. A five-minute deployment becomes a two-hour wait, and the team ends up bypassing the pipeline by deploying by hand "to go faster". The pipeline meant to protect is no longer used.
The untouchable pipeline
Over time, some pipelines become sacred artifacts nobody dares modify. Three factors lead there. The person who created it has left, taking the context of their decisions with them. A past incident has instilled fear: a harmless change caused an outage, and the implicit rule became "don't touch the pipeline". And the accumulated complexity takes days of investigation to understand the smallest detail.
This pattern has a name: a bus factor that has dropped to zero. The bus factor counts the people whose absence would be enough to block a project; here, the only person who understood the pipeline is gone. It is no longer a risk to watch, it is a situation that has already happened.
The stability paradox
A pipeline nobody dares change looks stable. In reality, it piles up invisible debt: its dependencies are no longer updated, its known vulnerabilities remain, optimisations are never applied, and it no longer adapts to new needs. This stability is a time bomb: the day a change becomes unavoidable, end of support for a tool or a critical flaw, the team discovers the size of the problem.
Pipeline debt
Like application code, a pipeline accumulates technical debt, but this debt is invisible because nobody measures it. It takes four forms, and a single pipeline often has all of them. The diagram shows how they feed each other.
Obsolescence debt comes from tools and practices dating from the pipeline's creation. Duplication debt comes from each project's own copies, which force every improvement to be replicated by hand. Documentation debt comes from decisions never written down. And test debt comes from a pipeline that is itself never tested, so every change is a gamble.
Why the debt builds up
Debt settles in behind excuses that seem reasonable. The table sets each one against the reality it hides; the last row matters most, because the promise of a big rewrite often serves to do nothing right now.
| Common excuse | Reality |
|---|---|
| "The pipeline works, no need to touch it" | The absence of change is not a sign of health |
| "We don't have time to refactor" | Each workaround adds future maintenance time |
| "It's just scripting, not real code" | A pipeline is critical code, which deserves the same standards |
| "We'll do a big rewrite one day" | Big rewrites fail, incremental improvements succeed |
The slow pipeline
A pipeline that is too slow is not a minor annoyance: it is a source of dysfunction for the whole team. When it takes 45 minutes, developers stack several changes into a single commit to wait less often, problems become harder to isolate, the feedback loop gets longer and workarounds multiply ("I test locally, it's faster").
A slow pipeline thus favours big commits that are infrequent over small frequent ones, whereas the latter are associated with better delivery performance, as shown by the DORA metrics. Slowness therefore degrades practice, not just comfort.
Where does the time go?
Slowness rarely comes from a single cause: it results from an accumulation. Redundant or poorly parallelised tests, dependencies downloaded again for lack of a cache, sequential steps that could run in parallel, environments recreated on every build and full scans where an incremental scan would do. Each step adds "just a few minutes"; multiplied by the number of daily builds, they become hours of lost productivity.
Hero culture
In some organisations, a single person "handles" the pipelines: they are the one called when the build fails, the one who knows the tricks, the one who can merge urgent changes. This centralisation creates a toxic dependency: the team never learns to solve problems itself, the hero becomes a bottleneck, and their departure triggers a crisis.
Hero culture is often celebrated ("thank goodness we have Jean-Pierre"). In reality, it is the symptom of an organisational failure: the lack of documentation, training and shared ownership. It is the same mechanism that, a few months later, produces the untouchable pipeline.
What sets mature organisations apart
Teams that keep pipelines effective over time share five practices. None is technical in the strict sense: they all concern ownership, the pace of change and transparency. The table sums them up, with the degradation mechanism each one neutralises.
| Practice | What it means | What it neutralises |
|---|---|---|
| Collective ownership | Every developer understands and improves the pipeline; changes are encouraged | Hero culture |
| Continuous evolution | Small regular improvements, not a big rewrite always postponed | Obsolescence debt |
| Living documentation | Each step has its reason written down, and kept up to date | The untouchable pipeline |
| Tracked metrics | Duration, failure rate, deployment frequency measured continuously | Creeping slowness |
| Psychological safety | A failure is analysed collectively, without looking for a culprit | The fear of changing things |
These practices reinforce each other: tracked metrics make the degradation visible, psychological safety makes it possible to talk about it, and collective ownership gives everyone the right to act. The feedback loop describes this mechanism in DevOps culture, and the reasons why security fails follow very similar dynamics.
Key points
- Pipelines fail mostly because they reflect the dysfunctions of the organisation that creates them.
- Copy-paste passes on a complexity whose reason nobody knows any more.
- An untouchable pipeline piles up invisible debt that blows up the day a change becomes unavoidable.
- Pipeline debt takes four forms: obsolescence, duplication, documentation and test.
- A slow pipeline pushes towards big commits and degrades delivery.
- Hero culture is an organisational failure, not a solution to celebrate.
- Mature teams cultivate collective ownership, continuous evolution, living documentation, metrics and psychological safety.
Knowledge check
Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.
Knowledge check
Check what you have learned with this interactive quiz
How it works
- The timer starts when you click Start
- Multiple choice, true/false and short answer questions
- You can move between questions
- Detailed results are shown at the end
Starts the quiz and the timer
Review
(0/0)Score by domain
A domain groups several guides and gets several questions, so its score is more reliable than a per-topic score, which often rests on a single question.
Summary
Strengths
No topic passed at 80% on at least two questions yet.
Weak areas
No topic below the pass mark.
Recommended next
Hints before you try again?
Continue the course: DevSecOps: security built into development
Continue the course: DORA metrics: measuring DevOps performance
A new full quiz with random questions
Work again only on the questions you missed