May 9, 2026 · 7 min
Eight Weeks to Twelve Minutes
Patrick McClory
We took an eight-week release cycle down to twelve minutes. The pipeline work was the easy part. What the acceleration revealed was that most of those eight weeks wasn't work. It was dwell time, and the processes that owned that dwell time had never had to justify themselves against a world that moved faster.
Eight Weeks to Eight Minutes
We took a team’s release cycle from eight weeks to twelve minutes.
That’s not a typo and it’s not a cherry-picked metric. Eight minutes to build and publish to dev. Two minutes to staging. Two minutes to production. Twelve minutes, gate to gate. The eight weeks was everything else: the dwell time, the scheduled reviews, the handoffs, the waiting periods that existed because that’s how the schedule was built and the schedule had been built around the assumption that releases were infrequent and significant and required advance notice and formal process at every stage.
The pipeline work was simple. The team got it. We built the automation, validated the process, ran the numbers. Eight minutes to dev, two to staging, two to prod. Twelve minutes, gate to gate.
The technical work behind those numbers wasn’t exotic. Existing tools, known patterns, nothing that required inventing anything new. Parallelism throughout. Test fan-out that most teams only dream about. Every test that could run simultaneously did. The kind of execution architecture that makes you realize how much time most pipelines spend waiting for things that don’t need to wait. We applied the available tooling liberally and rigorously. The test coverage went up, not down. The rigor went up.
Which means the organizations still running eight-week release cycles aren’t being held back by technology. The tools exist. The patterns are documented. Something else is holding them back.
Then the eight-week process had nowhere to go.
What Eight Weeks Was Actually Made Of
When you compress a release cycle from weeks to minutes, you don’t eliminate the work that was happening in those weeks. You reveal what it actually was.
Some of it was real work. Testing, integration validation, build processes, deployment steps. That’s what the twelve minutes covers. Real work, automated, fast.
Most of it was dwell time. The code sitting in a queue waiting for the next stage. The review meeting scheduled two weeks before release that couldn’t happen earlier because that was when it was on the calendar. The approval that required a specific person who was available Tuesdays and Thursdays. The notification period that existed because operations needed two weeks to prepare for a deployment that, once automated, required no preparation at all.
Dwell time doesn’t feel like a problem when your release cycle is eight weeks because the whole cycle is so long that the waiting blurs into the working. When the actual work takes twelve minutes, the dwell time becomes visible. All of it. At once.
The security review meeting scheduled two weeks before release didn’t have a release to review two weeks out anymore. The schedule had assumed a world where releases were events, planned in advance, with enough lead time for every stakeholder to prepare. In the new world, releases were routine. They happened continuously. The event model of release management didn’t apply.
And this is the part worth sitting with: the security team’s two-week dwell time didn’t just shorten. It disappeared. There’s no “two weeks before release” when releases happen continuously. The meeting-as-process didn’t compress to fit the new timeline. The new timeline made it physically impossible to keep their standard operating model. They weren’t given less time. They were given zero time, in the old sense of the word. The delay they depended on as a means to schedule their work ceased to exist as a unit of work at all.
The Process That Was Protecting Against Itself
The security team wasn’t the villain. Worth saying directly.
They’d been handed a policy written by someone who came before them. They’d updated it incrementally over the years, changing a tool here, adjusting a requirement there, kept it current in the narrow sense that the tools referenced still existed. But they’d never had to go back to first principles. Nothing had ever moved fast enough to force the question.
The question, stated plainly, is: what are we actually protecting against?
Not “what does the policy say.” What is the actual risk, what is the actual threat model, what are the controls that reduce meaningful risk versus the controls that exist because they were in the policy when we inherited it. Must versus should versus nice to have. And for the must-dos, how do you implement them in a way that’s compatible with continuous delivery rather than a two-week pre-release review cycle.
This is hard work. It requires real security thinking, not policy maintenance. It requires going back to the fundamentals of risk management and building from there: what are we protecting, what are the real consequences of failure, what controls are proportionate to those consequences. The team that had been maintaining the inherited policy had never done that work. Not because they couldn’t. Because nothing had ever required it.
The acceleration required it. We went from two weeks of scheduled review time to a world where “two weeks before release” had no meaning. The security requirements had to move into the pipeline, implemented as policy in code, executing continuously against every change. That meant understanding which requirements were actually mandatory and which were comfortable habits dressed up as requirements.
Reeducating, Realigning, Rebuilding
Getting from “scheduled review meeting two weeks before release” to “security policy implemented as continuous automated checks” required three things in sequence.
First, reeducation. The security team had to go back to the fundamentals of what they were protecting and why. Real world compliance requirements, real threat modeling, the actual risk landscape the business operated in. Not the inherited policy. The underlying reasoning that should have produced the policy. Some of what they inherited survived that scrutiny. A lot didn’t.
Second, realignment. The security requirements that survived had to be implemented in a way that worked with continuous delivery. Not as gates that blocked deployment pending human review but as automated checks that ran on every commit, failed fast when something was wrong, and provided clear actionable feedback to the engineer who introduced the problem. Security as a property of the pipeline rather than a review that happened downstream of it.
Third, rebuilding. Some of the inherited process couldn’t be realigned. It assumed a model of software delivery that no longer existed and couldn’t be retrofitted. The meeting that existed to review releases before they went out had no equivalent in a world where releases happened continuously. The approval workflow that existed because someone had decided releases needed sign-off existed because nobody had ever asked whether the sign-off was providing value proportionate to its cost. We let go of a lot of what had been inherited and rebuilt from what the actual requirements were.
It took real effort. We were held to a high compliance bar, real world requirements not theater. The work was legitimate. But the difference between meeting a real compliance requirement and maintaining the process that had grown up around meeting it is the difference between security and security theater. We rebuilt toward the former.
What the Process Was Actually Protecting
The hardest conversation in any delivery transformation is the one about what the existing process is actually protecting.
Sometimes the answer is: a real risk, in a way that’s proportionate to that risk. Those processes survive. Sometimes the answer is: a risk that used to be real and no longer is. Or a risk that’s real but the process addresses it so inefficiently that there are better ways. Or, most commonly, the process is protecting against the discomfort of having to think about the risk clearly.
Eight weeks of dwell time as a substitute for real security thinking is the last one. The scheduled review meeting wasn’t doing the security work. It was scheduling a time when the security work might happen, in a format that couldn’t scale, at a frequency that was incompatible with any reasonable definition of continuous delivery. The appearance of rigor without the substance of it.
Compressing to twelve minutes forced the substance question. What does security actually require here, implemented in a way that works at the speed the business needs to move? That question produces a better answer than “what does the inherited policy say.” It also requires more work to arrive at, and that work had to happen before the pipeline could be trusted.
The team did it. It wasn’t comfortable. It required letting go of the garbage that had accumulated and going back to basics. The compliance bar was still there. The way of meeting it changed entirely.
The Platform Wasn’t Slow
The release cycle was eight weeks because eight weeks was what the process required, not because the technical work took eight weeks.
This is the pattern that shows up in almost every delivery transformation I’ve been part of. The engineering team looks at the pipeline, measures the actual work, and finds that the technical execution is a fraction of the total cycle time. The rest is process: dwell time, scheduled reviews, approval workflows, notification periods, handoffs between teams that were designed around a release frequency that’s no longer what anyone is actually targeting.
The platform isn’t slow. The process is slow. And the process is slow because nobody had to justify it against a world that moves faster.
The twelve minutes isn’t magic. It’s what happens when you remove everything that isn’t work. The question every team should ask is: what’s the ratio between the twelve minutes and the eight weeks in our environment? And which parts of the eight weeks are protecting against real risk versus protecting against the discomfort of having to think about it?
The answer is in the dwell time. It’s always in the dwell time.