How teams share change management roles and responsibilities

Change manager/coordinator

Change managers—sometimes also known as change coordinators—are typically responsible for managing all aspects of IT changes. They prioritize change requests, assess their impact, and accept or reject changes. They also document change management processes and change plans. Importantly, they prep for, organize, and act as chair of CAB meetings. A change manager’s success is typically assessed by whether they meet timing and budget objectives.

Change authorities/approvers

A change authority is a person who makes the decision on whether or not to authorize a change. Sometimes this is a single person, such as a manager or executive. Sometimes it’s a group of people on a change advisory board. Sometimes it’s a peer reviewer. According to ITIL 4, “In high-velocity organizations, it is common practice to decentralize change approval, making the peer review a top predictor of high performance.”

Change managers typically work closely with the change authority to approve changes and move them forward within an organization. In some cases, particularly in small organizations, the change manager is the change authority and has the power to make these decisions without looping in additional people or teams.

Business stakeholders

Business stakeholders are often involved in change management and may be looped into the authorization process. This is increasingly common, given the critical importance of software services to most enterprises.

For example, if a change impacts the connection between the finance team’s payment tracking software and the sales team’s CRM, stakeholders from the finance and sales teams may need to be involved in CAB meetings and the ultimate decisions made about a change.

Engineers/developers

Development teams typically submit changes for approval and document the case for its necessity. Once a change is approved, in companies that have taken on a you-built-it-you-run-it approach, these teams deploy the change, monitor it, and often respond to any incidents or problems related to the change. In other cases, the incident management team responsible for any incidents caused by the change may be separate from the developers implementing the change.

Service desk agents

Service desk agents can bring a unique, front-line perspective on incidents and common service issues that a change may cause.

Ops managers

Since they’re responsible for keeping systems running on a day-to-day basis, operations managers weigh in on risk and dependencies.

Customer relationship managers

To represent the voice of the customer, relationship managers can provide knowledge about customer mindsets, frustrations, and ever-changing needs.

Information security officers and network engineers

Network security and cloud infrastructure experts bring important insight about threats and vulnerabilities.

What is a CAB?

Convening those with the responsibilities described above, change advisory boards (CABs) are groups tasked with assessing the risks of each change request and approving (or not approving) them. Typically, a CAB holds regularly scheduled meetings to review all proposed upcoming changes, and pulls in experts as needed to explain, defend, or assess the change with them. Traditional CABs are known as gatekeepers controlling the release of changes.

For this reason, plus the tedious meetings, long change request backlogs, and distance from the work itself, CABs are often viewed with disdain. Fortunately, many CABs are evolving to better enable agile software delivery, taking on a more strategic advisory role. CABs are transforming into advisors responsible for monitoring change trends, recommending practices that can address them, and looking for ways to better enable teams to deliver value to customers and reduce risk.

The challenge of CABs

The cliches around bad meetings also apply to CABs. We fairly criticize them as time wasters, for not accomplishing enough, involving too many random people, and existing when they “could have been an email instead.” This is partially owing to the way that traditional CABs have been overburdened with responsibility.

Let’s look to an aviation metaphor to illustrate the challenge. We can imagine the CAB as a control tower at an airport. That control tower has one job -- tell the planes when they are clear to land. It would never be tasked with assessing whether the planes are structurally safe or whether the pilot has the right credentials, because those factors are already confirmed by the FAA and others.

Meanwhile, far too many CABs assemble a variety of stakeholders and are tasked with making broad safety decisions about all kinds of different changes. And, this often occurs at the end of the week, as fatigued people become eager to leave for their weekends. The CAB is simply not set up to succeed.

Moreover, CABs often are concerned primarily with the risk of changes causing incidents. This is of course important, but they also must weigh the risk of delaying valuable changes. Moving too slowly can hurt customers, and in an ultra-competitive software as a service world, sink an organization.

It’s possible to elevate and focus the role of the CAB. With the right practices in place, many changes could be automated. This way, the CAB can become an important advisor, tracking trends, and partnering with teams on ways to enable faster changes that benefit customers.

How to position your CAB as a strategic advisor

The first step in repositioning the CAB is dispelling the notion that heavyweight change management produces positive outcomes. Data from the State of DevOps Report 2019 found that processes that require the approval of a CAB had a negative impact on software delivery performance and respondents following these processes were 2.6 times more likely to be low performers. Moreover, there was no evidence to support that a formal approval process was associated with lower change fail rates!

For this reason, modern teams are taking these steps to improve their CABs.

Stop treating change requests in a “one size fits all” way

Every change request is an opportunity to track and gather information. We can learn about success rates, related incidents, and the factors correlated with them. Over time, with the application of data, it should be possible to pre-approve and automate more and more changes. Only the most consequential and risky changes should require in-person approval.

Bring change and release management closer together

The legacy approach to releases was to bundle them together and launch them all at once. CABs are then left to painstakingly review and approve huge packages of changes. This approach can lend itself to major incidents and makes it harder to find the source of a problem when one arises. It also slows the rate by which teams can deliver value to their customers. This also means that change and release managers can allocate less time to project management tasks.

Use progresssive releases to test and iterate

Progressive deploys canary or feature flag with a small subset of users to test and prove stability before the full deployment. This limits the scope of a potential incident and proves the success of a deploy before rolling it out to all environments.

Use automation and tools to streamline change management

High-velocity teams are starting to rethink previous approval models. Rather than addressing a long change request backlog in a weekly in-person meeting, it’s possible to make use of virtual collaboration. That can be as simple as an email detailing change requests so they can be reviewed in advance of a CAB meeting. In other cases, things like Jira tickets and Confluence pages can enable change reviewers the context they need to asynchronously collaborate and approve changes. Using Jira Service Management, teams can collaborate in these ways, to even hop on a video conference or create a designated Slack channel. Depending on how your team prefers to stay in touch, it’s still housed in the same place so everyone is on the same page.

Legacy ITSM tools make it difficult for infrastructure, operations, and development teams to raise a change request. Look to automation and modern software to reduce the burden of manually inputting change information. The last thing a developer wants to do is fill out tickets in a clunky, separate system, if that work could be automatically tracked. Within Jira Service Management, teams can harness automatic to streamline change process, minimize risk, and cut back on downtime.

Shift left and bring change management closer to practitioners

One of the most common strategies that’s often replacing or reducing CAB approvals is peer review, which puts the responsibility for identifying issues in the code on those who understand the code best. ITIL 4 points out that in “high-velocity organizations, it is a common practice to decentralize change approval, making the peer review a top predictor of high performance.” Similarly, The 2019 State of DevOps report recommended that “organizations should “shift left” to peer review-based approval during the development process.”

To keep compliant with regulations, this approach needs to be meticulously documented, which is where systems like Bitbucket come in, automatically tracking authors and peer reviews and keeping changes from being pushed live without the required process.

At Atlassian, peer review is a core part of our approvals process. As one of our IT risk and compliance experts explains: “All Atlassian code is stored in Bitbucket. When a developer wants to make a change, they check the code out of Bitbucket and onto their laptop. When they check it back into the Bitbucket repository, instead of updating the code, the system is set up to require peer review. Only after that review is done and approved is the code pulled back into the repository. And if the code isn’t approved? It gets sent back to the original developer with the peer reviewer’s notes. They fix what’s wrong and submit it for another peer review.”

Convene experts to enable good practices

As organizations become more complex, facilitating information flow and coordination among teams is increasingly critical. Rather than approving individual change requests, CABs can move their focus to practice improvement. In this paradigm, they can look to provide practice improvement recommendations, implement better capabilities, and provide resources and tools that result in better performance. This extends the purview of the CAB to address the risk of being too slow to ship value to the market.

Even in more traditional IT organizations, the CAB can become a place for coming up with creative solutions. In one case, a risk-averse university adhering to legacy ITSM tools and practices needed to figure out how to inform students about an important service that would be unavailable. The CAB became a forum for brainstorming new communications tactics. They settled on scattering candy and posters, in a campaign that was effective in deflecting incoming requests about a planned system upgrade.