Due to the accelerated pace of delivery, decentralization of control, and other disruptions that come with DevOps, many career release managers today are feeling a little off balance. Software deployment teams are operating more independently and complexity is growing exponentially (in no small part due to many small, interdependent changes being continuously deployed to production). The idea that one person or team can coordinate the planning and delivery of it all is being tested to the breaking point.
Rather than being a source of anxiety, however, release managers should welcome these changes. They present an incredible opportunity to redefine what it means to excel at the delivery of value to customers.
Focus on Customer Delivery Instead of Deployment
Perhaps the biggest change of all has been the way that software deployment has become less and less about a big software release at a moment in time. Instead of involving a large planned outage with lots of teams and many software packages being updated at once, the moment a big feature goes live is often very quiet from a software deployment point of view. Rather than complicated deployment plans being executed in a command center to turn on what was previously a deployed but hidden feature, DevOps deployment entails just a few small coordinated changes.
The once important role of release managers to coordinate large technical deployments, although still critical in certain scenarios, is no longer the primary raison d'être for release management to exist. This change, however, provides a new opportunity for release managers to apply their talents in a way that is even closer to delivering business value. Instead of filling the command center with the teams executing a deployment, release managers can bring together the people who care about the delivery of this feature to their users. These people include product and marketing teams who helped design the features and who can measure its success; technical teams who can monitor system performance and react as needed in real time; and consumer support or sales teams who will interact with customers using the product. The empty space that a large technical delivery team once filled can instead be occupied by people actively working together to ensure the success of a new feature.
It’s strange to think about release management without a giant software release as capstone, but the overall purpose and requirements to succeed are the same – you still need lead-up and execution planning to coordinate all these activities. You must track complex dependency relationships to ensure everything is delivered as expected, closely monitoring risks and the potential for delays amongst constantly evolving dependency relationships. You need real-time communication about the results you’re seeing and how you’re adapting. Overall, you need a confident hand directing the entire activity to ensure it is a success. That, at its heart, is where release managers excel.
New Opportunities for Relevancy
We can take this idea of focusing on customer delivery over software deployments a step further. As we begin to think of release management in this new way, we can imagine other instances within technology organizations where there is a moment of delivery that is planned for and must be executed with precision. If the role of the release manager becomes less about deploying a software package and more about delivering a business objective, then we can begin to think about release management expanding outwards along these lines. This is where I see the greatest opportunity for release managers to become indispensable to the organizations they support: leveraging their unique skills in new ways and in entirely new parts of the business.
For example, release managers can be highly effective managing things like software-publishing pipelines (for example, publishing mobile builds to app stores) and major content updates, as well as supporting high traffic shopping days for retail businesses. Each of these is a repeatable, planned process that leverages the same kinds of skillsets release managers possess in spades: planning, contingency management, continuous improvement, and command center leadership. Although there is no big software deployment activity at the end, something of value is being delivered to customers, and release managers can help ensure a successful delivery.
Providing Business Planning Context
Even aside from these customer delivery moments, release managers play an important part in technology organizations. The ideal of Continuous Delivery and DevOps goes something like this: a constant hum of small changes to microservices happens in production, changes that are deployed by engineers and monitored by automated systems, and quietly and automatically rolled back if user experience metrics are negatively impacted. The reality, of course, is that things are never quite that simple. Sooner or later, the law of unintended consequences will come into play, and a “safe” change made on the biggest shopping day of the year will result in a big consumer impact.
Because of this reality, the air traffic control role of release managers will remain critically important to businesses. Engineering teams want to focus on building quality software and are not particularly interested in attending every meeting that might introduce an important date for a product launch, marketing push, or other kind of high-impact event. Release management teams provide a ton of value here by contextualizing these sorts of business interests to engineering teams in a clear and consistent way. Their ability to articulate how software development aligns with organizational goals solidifies their role as an important intermediary between business and technology teams.
Release management teams also have a unique perspective on vital DevOps metrics, such as the amount of time it takes to get from code commit to production deployment, particularly when trying to make sense of software creation across organizations rather than just within individual teams. When you look at feature delivery from a consumer point of view, these kinds of metrics nearly always cross internal team, department, and even organizational unit boundaries. Teams without a broad cross-capability mandate may have a difficult time making the connections, but it comes naturally to release managers who have spent their careers working across these lines.
The use of metrics to share this organizational perspective with engineering teams and business stakeholders is a win-win because it provides a meaningful way to measure DevOps success for the entire company. Engaging with delivery teams to consolidate metrics from various sources, adding new synthetic metrics, and contextualizing all of it against feature delivery is a great way for release management teams to continue to add value even in a world where they don’t directly plan and execute the software deployments.
Supporting the DevOps Rollout
Large companies face several other challenges when trying to implement DevOps: things like legal compliancy, corporate governance, risk management, and security. Release managers have been dealing with these issues for a long time and can provide much-needed support in ensuring that the new delivery model accounts for any associated requirements.
The release manager also acts as a kind of translator and accelerator during DevOps rollouts, helping each side understand the goals and interests of the other and steering around roadblocks that come from misunderstandings. Further, by being directly involved in implementing consistent auditing and control procedures, release managers assist in clearing the runway for engineering teams to focus on DevOps without worrying about security or compliancy nightmares coming out of nowhere.
Enhancing Release Management with Technology
Similar to how DevOps has challenged developers to learn a little system administration and system administrators to learn a little development, DevOps presents release managers with an opportunity to augment their personal skills and team composition with technical capabilities. Release management services such as change approvals and tracking, blackout periods/code freezes, and so on can all be exposed via APIs to allow automation to be built on top of them.
The release management tooling space is already beginning to evolve a little in this direction. Vendors are starting to introduce unified technical release management platforms that expose API hooks for data and events, integrate with other ticketing systems for things like change approvals and security/compliance auditing, implement workflows as code, integrate insights/continuous improvement, and provide other centralized release management functions that are as accessible to non-technical people as they are to engineering teams.
For example, blackout periods for key business dates could be enforced through a very simple API that returns, for a given platform, dates and times where no production deployments should happen. This capability can then be integrated with the deployment automation, ensuring that no changes occur during any production freeze. These sorts of automated integrations with release management make everyone happy: the release management team gets out of the business of trying to keep everyone notified manually (or worse, via e-mail). And, from a software engineer’s perspective, nothing could be simpler—this is exactly the kind of thing they are looking for from a modern, technology-savvy release management team.
Where do we go from here?
DevOps is not a threat that will minimize the role of release managers, make their jobs impossible, lessen their fun, or reduce their rewards. On the contrary. DevOps puts release management at the forefront of any DevOps transformation, elevating its connection between engineering and delivery and enabling it to connect everyone more directly with the business at that critical moment when we engage with our customers—where we need to be the very best that we can be.
What are your thoughts on the future of release management? Have I missed any important value adds?
Jason J. Lenny, Director of Technical Product Management, XebiaLabs
Image Credit: Profit_Image / Shutterstock