Skip to content

Embracing continuous delivery: Our journey at 6clicks

Andrew Lawrence |

June 14, 2024
Embracing continuous delivery: Our journey at 6clicks

Audio version

Embracing continuous delivery: Our journey at 6clicks
4:02

Contents

Hello everyone, Andrew here. The practice of Continuous Delivery in software engineering has many benefits. The impact on a software company's efficiency, the quality of its product, and the culture of its team cannot be understated. However, reducing the average time it takes from feature conception to delivery while still ensuring the highest levels of quality involves a wide range of systems, processes, and approaches to come together.

Recognizing the need for change

When I began as the Chief Technology Officer of 6clicks, I considered our deployment schedule a bit slow. We would release every two weeks - a pace the team had deliberately slowed to after learning that a higher pace resulted in too many quality problems. I argued that to deliver top-tier value, we needed to increase our deployment to at least a weekly cycle, if not daily.

The impact of a bi-weekly release cycle

A two-week release cycle may sound relatively quick, but because the cut-off date for changes is two weeks ahead of the actual release date, to allow for regression testing, it means up to a four-week wait from a feature being ready for release until it reaches production. The implications of this latency are almost entirely negative: the latent value of features is delayed, frustrating customers and potentially costing sales; releases are large, with more potential for things to go wrong all at once; and the engineering team is incentivized to rush delivery at the expense of quality so they don't miss release cutoff.

Navigating the transition to more frequent releases

The transition to more frequent releases wasn't just a technical challenge; it was a significant cultural and communication shift for the entire company.

Overcoming technical challenges

We had to automate parts of our regression testing and deployment process that previously weren't, simplify workflows, and improve our monitoring systems to quickly detect and address issues. We had to be able to release across multiple regions with zero downtime, adequate approval steps, and utmost simplicity so that anyone on the team could request a deployment. We also had to utilize functionality like feature toggles to encourage small, more frequent iterations.

Adapting beyond the engineering team

Beyond the technical team, our sales team, accustomed to monthly updates, had to adapt their scripts to account for more frequent changes. Similarly, our marketing team, which used to plan big feature announcements every few months, had to pivot to marketing smaller updates more regularly. This required a shift from big, splashy campaigns to more continuous, agile marketing strategies.

Product management also underwent a significant transformation. Instead of planning for a big release every month, they had to break down projects into smaller, incremental updates. This meant rethinking how we approached project timelines and delivery schedules.

Committing to change and continuous improvement

The lesson we've learned from this transition is clear: increasing deployment frequency necessitates a holistic change across the company. It's not just about the engineering team; it’s about reshaping processes and mindsets across sales, marketing, and product management.

At 6clicks, this shift has led to significant efficiency improvements and productivity gains. We are able to deliver value to our customers faster and respond to their needs more effectively. The entire organization has become more agile, adaptable, and better equipped to handle the fast-paced nature of today’s tech landscape.

Transitioning to frequent deployments has undeniably been challenging, but the benefits have been well worth the effort. Our journey at 6clicks stands as a testament to the incredible productivity gains that come with embracing change and fostering a culture of continuous improvement.





Andrew Lawrence

Written by Andrew Lawrence

Andrew is responsible for the company's engineering practices and technical strategy, having led technology teams for over fifteen years. He has a passion for growing engineering teams, empowering them to scale up, and believes in market-leading quality and innovation that creates outstanding product suites. He has successfully led software engineering programs resulting in notable acquisitions. Andrew holds a Bachelor's in Computer Science from the University of Melbourne and is certified in ITIL, project management and solution architecture for the cloud.