When I tell people that my current team went from releasing every six weeks to averaging 5.1 releases per day, they often assume we built some revolutionary deployment pipeline or discovered a groundbreaking new methodology. The truth is far simpler: we removed the organisational barriers that were preventing us from doing what comes naturally.
Think about it. When you're working on a personal project, what do you do when you finish a feature? You deploy it. You don't wait six weeks, batch it up with other features, write extensive documentation about what might go wrong, and then hold a committee meeting to decide if it's ready. You just ship it, see how it works, and iterate.
The natural state of software development is small, frequent releases. If your organisation isn't releasing often, it's because something organisational is preventing it. There might be a good reason for that constraint, but it's worth being absolutely sure.
The Six-Week Struggle
When I took over the technology team, we were stuck in a painful cycle. Every six weeks, we'd release a batch of features and fixes. Then we'd spend the following two weeks frantically addressing bugs and incorrect functionality that invariably emerged in production. Our CEOs needed to know exactly what was going out in each release and had to approve everything because they needed to coordinate with the rest of the business, preparing for things to be broken or wrong.
To give them credit, they worked incredibly hard at this damage control. Our customers were probably unaware of the chaos we were managing behind the scenes. But internally, the process was grinding us down.
The most telling symptom was how much time we spent between releases. While you might assume those four weeks were dedicated to building features, a significant portion was actually consumed by negotiation. Product teams and engineering would go back and forth with the rest of the business, producing lengthy technical specifications that read more like legal contracts than development plans.
These documents were meant to provide clarity and accountability, but they created the textbook waterfall problems instead. What we built was never quite right because requirements had been locked in stone weeks earlier, before we'd learned what we needed to know. We spent almost as much time arguing about whose fault the discrepancies were as we did actually fixing them.
This adversarial relationship between departments was the root cause of our deployment paralysis. When teams don't trust each other, they create processes and documentation to protect themselves. When you're protecting yourself, you're not collaborating.
Finding the Natural Path
The solution wasn't revolutionary technology or a complex new framework. It was Vanilla Scrum. Basic Agile 101. I called it Vanilla on purpose because there's nothing wrong with doing the fundamentals well, and it's often exactly what organisations need.
We restructured into small teams of four to five engineers, each with a dedicated product owner and QA person. These teams were organised around their stakeholders: one focused on our customer-facing app, another on APIs consumed by external businesses, one on internal systems, and one working closely with our CEOs on experimentation.
We introduced the practices most people try first: daily standups, two-week sprints, sprint planning, and retrospectives. We added refinement sessions and used story points to estimate work, planning sprints based on team velocities. Nothing groundbreaking, but everything essential.
The transformation this created was remarkable, not because of the practices themselves, but because of what they enabled. For the first time, engineering teams could accurately estimate work. Instead of cracking the whip when external deadlines loomed, we were negotiating based on scope. Product and engineering were working together to find the best solution within realistic constraints.
Most importantly, we stopped producing those lengthy technical specifications. Instead of contracts designed for hitting each other over the head when things went wrong, we were creating working software together, quickly and incrementally.
The Compound Effect of Small Batches
Once we brought down the size of our deliverables, something interesting happened: the quality went up. Smaller changes meant fewer variables when something did go wrong. Problems were easier to identify, understand, and fix. The feedback loop between development and reality shortened from weeks to hours.
We already had decent CI/CD infrastructure and feature flagging in place, so the technical foundations for frequent deployment existed. What we'd been missing was the organisational foundation: teams that trusted each other enough to work in small increments rather than large, defensive batches.
The transformation took about six months for a team of around 25 people. We went from those painful six-week cycles with two weeks of bug fixing to averaging 5.1 releases per day across the entire team. But more importantly, we started producing software that our users loved and that was genuinely high quality.
The CEOs initially needed that approval step because they'd learned it was necessary for business continuity. I didn't ask them to give it up until they felt comfortable doing so. As we began releasing so frequently, it became impractical for them to approve every change anyway. They deserve credit for trusting my experience and taking that leap of faith. The process became self-reinforcing: better software meant less risk, which meant less need for defensive approval processes.
The Natural State of Development
What struck me most about this transformation was how natural it felt once the barriers were removed. Developers want to ship their work and see it used. Product owners want to validate their ideas quickly. Users want improvements and fixes delivered promptly. The adversarial dynamics and defensive processes we'd built up weren't protecting value; they were preventing it.
This experience reinforced something I now consider fundamental: frequent releases aren't an advanced DevOps practice that requires sophisticated tooling and processes. They're the natural state of effective software development. Everything else is organisational friction.
When I work with companies now, I don't start by asking what deployment tools they're using or how their CI/CD pipeline is configured. I start by understanding what organisational forces are preventing them from shipping small changes quickly. Sometimes those forces exist for good reasons, but more often they're legacy solutions to problems that no longer exist, or defenses against collaboration failures that could be addressed more directly.
For us, the solution was Vanilla Scrum and breaking down those adversarial departmental relationships. For another company, it might be addressing technical debt that makes small changes risky, or building automated testing that gives teams confidence to deploy frequently. It could be training that helps teams work in smaller increments, or simply questioning approval processes that made sense years ago but now just add friction.
The most powerful deployment culture isn't built on tools or methodologies. It's built on trust between teams, clear communication about what success looks like, and the organisational courage to let teams work the way they naturally want to: by building something small, shipping it, learning from it, and building the next small thing.
That's how you get from six weeks to 5.1 times per day. It might feel revolutionary when you're living through it, but you're really just removing the barriers that were preventing what should have been happening all along.