The Machine That Builds the Machine — Part 2: When the Machine Slows You Down
In Part 1, we talked about the unsung hero of modern software development and delivery,— the machine that builds the machine — our CI/CD and automation infrastructure. We saw how, when designed well, it can turn an idea into a deployable, testable, and secure reality in minutes.
But here’s the twist: not all machines are built equally. While modern CI/CD and automation infrastructures promise speed and resilience like a precision Swiss watch, many organizations are still running on outdated, fragmented, or over-engineered versions of the machine
When the Pipeline Turns into a Parking Lot
In many organizations, the delivery pipeline is slowed not by the code, but by the machine that’s supposed to move it. Legacy Jenkins configurations stitched together with brittle scripts like that old lawnmower you would have to kick three times before it starts. Manually maintained test environments get “just one quick fix” until they turn into snowflake servers no one dares to touch, and tightly coupled deployment logic that creates a maze of fragile dependencies.
It reminds me of a trip from Gothenburg, Sweden, to Oslo, Norway — a simple 3.5-hour train ride on paper. Along the way, a fallen tree on the track stopped the journey. What should have been a brisk journey turned into a 12-hour, delayed, and frustrating trip. If you’ve ever traveled that long with kids, you’ll know: patience…
That’s exactly what happens with brittle delivery pipelines. The code is ready to ship, the “train” is fine, but one flaky test, a misconfigured environment, or a missing dependency is the fallen tree that stops everything cold. And like that family journey, the delay ripples through everything else — plans shift, tempers fray, and the whole experience becomes memorable for all the wrong reasons.
Over-Customization
Some teams complicate their delivery process by over-engineering(over-customizing) to the extent that it would take a cartographer to map it and a therapist to explain it. Pipelines sprawl across repositories with no clear ownership. Documentation? Outdated. Ownership? Ambiguous. Scaling? Let’s not talk about it.
When Tools Don’t Communicate
Other teams fall into the silo trap: separate systems for CI, CD, secrets, infrastructure provisioning, and observability, all speaking different dialects, resulting in delays, blind spots, and inconsistent delivery. Without proper integration, you end up with a delivery process that’s more like a relay race — except the runners are on different tracks, passing invisible batons.
The Illusion of Control
Then there’s the false security of manual gates masquerading as “control” — tickets for approvals, ops handoffs, or out-of-band code reviews. While they sound like “good governance,” these practices compromise the core advantage of automation — speed without sacrificing reliability.
The Fallout
When your delivery machine is this kind, every deployment is a gamble. The fear of breaking production slows releases to a crawl. Engineering velocity drops, and innovation stalls.
The irony? These slow, fragile delivery machines are often built with the best intentions — but without a clear strategy for scalability, resilience, or developer experience. Instead of empowering delivery, they accidentally become the blocker.
If the wrong machine can grind your ambitions to a halt, what does the right machine look like?
Let’s come back again to look at what the right machine looks like — and how to start building one that works for you, not against you.
By Isaac Arnold McSey (CTO)
