Redefining Release Cycles for Larger Companies

During a recent (imaginary) gathering of some of the most brilliant minds in software engineering, the air was charged with varying opinions and perspectives. The topic of the debate – “Are you deploying as fast as you need”.

There were diverse voices in the room. If you listen carefully, one of these voices was probably from your organization!

“We are a large organization with many moving components. Why go faster when you are doing well at your speed?” pondered a leader from an established enterprise, The focus was stability over speed.

In contrast, a voice from a cloud-native startup countered, “We were born cloud native and modern; why go slower when you can go faster?” The focus on speed and agility was obvious.

“We are not built for speed; we have far too many legacy systems (from our history of Mergers & Acquisitions) to account for each time we deploy,” shared a leader from a company grappling with the weight of its historical infrastructure, underscoring the challenges of modernizing at pace.

Meanwhile, another participant expressed a common desire to break free from constraints, “We would like to deploy more frequently and much faster, but it is risky and expensive,” highlighting the balancing act between aspirations for speed and the realities of risk and cost.

This conversation underscored a fundamental question: How often is too often to deploy?

This blog delves into the nuances of deployment strategies, taking a closer look at how company size & history influences not only the pace but also the approach to releasing software.

I make a general assumption that smaller/newer companies have it slightly easier than larger companies with a long history and complex IT infrastructure.

Large Organizations – what are the challenges?

Large organizations with a long history generally have the financial means to effect a technological revolution. Money is rarely the challenge for them. What really hinders them is the need for a massive cultural change.

These are the kind of organizations where people have spent their entire professional lives in one company. Their earliest tech stack typically includes a lot of mainframe based solutions and continues to depend on them for their current business.

The ‘young developers’ they hired in the 80s & 90s are slowly beginning to retire, but the systems continue to run as they did for decades. Most of these companies have always wanted to modernize their systems, but it was always too risky, until now. The tech start-ups are pushing and penetrating the market faster than ever.

The large companies also struggle due to the silos in their organizations. If you ask them publicly, they are unlikely to admit. But the insiders know how difficult it is to get the entire organization banding together to implement a change that impacts different parts of the organization differently.

For example, if a start up decides to use a different set of tools for their CI/CD pipeline it doesn’t take long to get an executive decision on it. However, the same in a large organization isn’t that straightforward. Imagine a company with multiple M&As with multiple sets of IT systems put together – and all of them having to ‘transform’ at the same time.

These organizations are at crossroads now – to either risk a massive modernization programme to revamp their entire tech stack, or do it in phases.
But here comes the even bigger challenge – changing the mindset of the entire organization. Which change comes with risk to careers, and in an organization with a rich history and long careers, it is a tall mountain to climb.

It is difficult, but not impossible. Many large companies have done it successfully. Let’s look at some of the key elements of a successful transition in the next section.

Fostering Cultural Change

Leadership and Vision

Many companies hire external consultants to implement agile processes. But it almost never works. Faster deployments are a by-product of companies embracing agility into their culture. Cultural change brings in technical change, but it doesn’t work the other way.

And external consultants rarely leave a lasting impact, especially when it comes to cultural change. The best bet any organization has is when the change happens within, especially from the top of the organization.

When the CEO and board of directors embrace agility, their directions to the leaders in the company will reflect that mindset. The CIO gets the budget to run the massively overdue transformation programs, the engineering leaders get the money to invest in the CI/CD tools.

And in general, the risk appetite of the organization increases. The press releases flow out showing off their investments in modernizing their backbones.

There is no greater influence than the signs of top leaders pushing for agility. Their commitment to change is the single most important fuel that drives the entire organization.

Change Management

Transformation is change. Modernization is change. While change can be exciting, it can also be scary. In organizations rich with history and long careers, change is usually a lot more difficult.

There are multiple change management strategies and organizations must carefully pick the ones that have the biggest impact for them. Some may opt for a big bang change and some may want smaller increments.

Regardless of the strategy, identifying and empowering change agents within the organization is critical. These individuals can be pivotal in driving the adoption of new technologies and methodologies by exemplifying the benefits and mentoring their peers. They act as the bridge between the old and the new, facilitating knowledge transfer and mitigating resistance.

Continuous Learning and Adaptation

Change also necessitates learning. The engineers who have worked for years (or even decades) on a set of tech stack suddenly need to learn new technologies. This isn’t easy, but can be accomplished.

Each organization needs to find the right strategy to push itself to become a learning being. On the surface level, this may include training etc., but incentives deeper than paid learning courses add to the fuel. The prospects of shifting to newer jobs, more responsibilities coupled with learning becoming fun can push people out of their comfort zones.

And when people learn new technologies, they also must have opportunities to test their new skills. Different methodologies offer options, for example Scaled Agile framework build in a sprint specifically for planning and innovation. I have seen organizations use this time to run innovation marathons, ‘build it in a day’ events etc., where the engineers can show off their skills.

And for a true engineer, nothing is more motivating than seeing their code work.

Embracing Technical Modernization

Incremental Modernization

Given the reliance on legacy systems, particularly mainframe-based solutions, an incremental approach to modernization is pragmatic unless the company is in dire need for a more dramatic change.

Gradually integrating modern technologies, such as cloud services and microservices architectures, with existing legacy systems can be a great start. This phased approach allows for continuous assessment and minimization of risks associated with system overhauls. It also allows time for people to adapt to change.

DevOps Integration

One of the things that software engineers love the most is to see their code go to work in production faster. The only thing that tops that – the actual users giving them direct feedback. In short, DevOps. In my 20+ years in the industry, I’m yet to meet one engineer who isn’t a fan of DevOps.

In large organizations, especially the ones in regulated industries like Financial services, Pharma etc., change isn’t easy. Their ‘safety first’ approach is partly driven by external forces as much as their own culture.

So when the engineers are offered a choice to get their code out of their machines/sandbox environments into a shared dev/test environment, they usually take the offer with both hands.

So regardless of how often code is deployed into production, getting faster and more frequently into a staging environment / pre-production environment is exciting for engineers.

There are multiple strategies for implementing DevOps and the technical stack upgrades to foster CI/CD culture. Your engineers usually have the best answer on what might be the best method for your organization.

Advanced Testing Strategies

According to The Future of Quality Assurance Report 2023, the vast majority (almost 90%) of the organizations have adopted some sort of CI/CD into their engineering culture, but more than half of them still trigger their automated tests manually.

This indicates two things – most organizations, regardless of their size, want to embrace agility as reflected by the high adoption rate of CI/CD culture. It also indicates that they struggle to automate the pipeline as much as they would like to.

This is similar to building a great skyscraper, but forgetting to put the elevators in. It looks tall and amazing, but getting to where you want is bloody hard.

Consider adopting more sophisticated testing strategies. Consider automated regression testing, canary releases, and blue-green deployments, ensuring that new changes can be deployed and tested in production-like environments without disrupting the existing user experience. These strategies allow for real-time monitoring and quick rollback capabilities, enhancing the reliability of the deployment process.

Asking for help from external experts can save you time if you are unsure how to go about it. Companies like Lambdatest have deep experience in the area, and would be able to help you build an automated CI/CD pipeline.

Wrapping Up

The need for speed is clear. Regardless of the size, all organizations want to deploy faster aiming for the ‘first mover advantage’ and obtain customer feedback. However, as reality shows, intentions aren’t enough.

Smaller companies generally have an easier process towards implementing change, of course including how often they need to deploy. However larger companies struggle due to complexities that come with size. Decision making is generally slower and the implementation gets more complicated due to the involvement of multiple teams whose priorities may not be completely aligned.

But it doesn’t mean that the larger organizations cannot improve their speed of deployment. Commitment and a clear direction setting from the top coupled with aiding a cultural shift needs to happen. In Addition, the engineering leaders need to find out the right strategy for modernization including investing in microservices & the right set of tool stack.

If there is a strong will, there are multiple ways to speed up your deployments regardless of size!