The connection between change management and incident communication
Jake Bartlett · 6-minute read
Change is constant in the fast-paced world of software development. With the advancements in technology, tools, and software methodologies, engineers are shipping code faster than ever. In the early days, software would undergo annual releases, but modern-day software teams can deploy code hundreds of times daily.
Whether rolling out new features, updating existing functionality, or fixing bugs, software development teams constantly ship changes to meet customer needs and stay relevant in today’s competitive market. However, with each change comes the potential for disruptions. Any time you introduce a change in software, you incur risks from minor performance glitches to major outages. This is where incident communication and change intersect.
Today, teams must embrace proactive and transparent communication with customers about changes and be prepared to communicate during software incidents that those changes can cause. By understanding the relationship between change management and effective incident communication, teams can better manage risks and ensure transparency with users, fostering more trust and customer loyalty.
Types of software changes
Software changes generally fall into three primary categories: updates, upgrades, and fixes. Let’s quickly examine each of these types of changes.
Updates
Software updates improve the user experience by introducing incremental improvements or new features. These types of changes enhance the software without overhauling the entire system. A software update may introduce a new feature or improve existing functionality, driven by user feedback or advancements in technology.
Example: Instagram introduces a new filter in their mobile app.
Upgrades
Upgrades are larger-scale changes, often involving transitioning to a new software version or overhauling a large part of the core system. Software upgrades might also include architectural overhauls, a significant new set of features or products, or a shift to more advanced frameworks. Software upgrades can bring users considerable benefits, but they also carry a higher risk of downtime and compatibility issues.
Example: Shopify upgrades its liquid templating to a more powerful version.
Fixes
Patches or fixes address specific bugs or vulnerabilities in the software. These changes are often urgent and aimed at resolving known issues, improving stability, or addressing security concerns. While patches are typically minor and targeted, they can still have unintended consequences if not carefully tested and communicated, especially when they relate to critical functionality.
Example: Zoom addresses a bug that caused connections to drop on mobile devices.
The risk of change: incidents and outages
Software changes are essential for innovation and continuous improvement but are inherently risky. Even the most carefully planned upgrade, patch, or update can introduce unforeseen issues, ranging from minor inconveniences to catastrophic system-wide failures.
A recent example of this risk playing out is the famous CrowdStrike outage in July 2024. As a prominent cybersecurity company, CrowdStrike provides critical services to thousands of businesses, helping them protect against cyber threats. After deploying a software update, they suffered a major outage that affected numerous clients, with a widespread global impact.
This incident highlights an important lesson: even the most reliable and successful platforms can experience outages due to software changes, and proactive communication can help mitigate the impact and shock of such disruptions.
With modern software being so interconnected and dependent on other systems, a change in one system might have a significant downstream effect. To manage these risks, companies must implement robust testing practices, have contingency plans, and maintain open communication with users.
The CrowdStrike outage serves as a cautionary tale, reminding us that the stakes are high when it comes to software changes, and the cost of an outage can be massive – not just in terms of financial loss but also damaging the brand’s reputation and customer trust.
Learning from our own mistakes
Sorry™ onboarded a few large customers at the beginning of 2024 and began seeing some performance issues shortly after. As these issues surfaced, they quickly became incidents that impacted the product’s reliability. While we communicated about these incidents on our status page, we knew we needed to address the root problem and ship fixes to restore our performance.
After addressing the performance issues, we encountered several significant and unexpected incidents related to the changes we made. These changes weren’t communicated externally, as we felt the risk was minimal.
We were wrong. These well-intended changes ultimately ended up negatively impacting customers.
One tool for incident communication and release notes
As a result, in August 2024, we decided to start communicating every change we introduce to our application, no matter how big or small. You can find these changes on our changelog.
To support this new approach to communicating changes, we built a new General Notices feature in Sorry™, giving our customers a dedicated way to communicate more than just incident updates on their status page. The Sorry™ team is using this new feature to provide a changelog our customers can reference at any time. Learn more about General Notices here.
The importance of communication in change management
No matter how well-prepared your team is, software changes can still result in customer-impacting disruptions. Any change is still a risk, even when you intend to improve things.
By keeping users informed, you can reduce frustration, build trust, and ensure users are more prepared to handle anything that could go wrong.
Communication is essential at every stage of change management:
- Informing stakeholders about upcoming changes
- Updating users on newly deployed changes
- Addressing incidents caused by recent changes
The benefits of optimizing your communication around changes are vast.
Sets clear expectations
Informing customers of upcoming or recently deployed changes lets them know what to expect. This transparency empowers users to make decisions accordingly, and it reduces the element of surprise if something goes wrong.
Similarly, letting customers know about unplanned disruptions gives them the information they need to react accordingly, and it sets expectations as you work to resolve the issues.
Subscribe to our blog
Have our insights on incidents and changes delivered to your inbox monthly - no spam!
Drives adoption and loyalty
Telling customers about recent changes drives excitement about new capabilities they can use and helps them see the evolving value of your product or service. It reassures them you’re continuously investing in improvements to meet their needs.
Reduces anxiety and increases trust during incidents
When a change to a product or service inadvertently leads to an incident, effective incident communication is crucial to maintaining customer trust and confidence. Clear, timely updates reassure customers that your team is fully aware of the problem and actively working to resolve it.
Maintain trust and transparency
Some changes impact customers negatively, even if they don’t necessarily cause an “incident” that breaks something. For example, a customer might execute a weekly task that relies on a critical workflow in your app. If you change how that feature works, it might impact the customer’s workflow and cause delays. In this case, informing customers about the upcoming change would build more trust and show you value transparency.
How to mitigate risk from changes
Successful software releases rely on a strategic approach that involves thorough testing, staged rollouts, clear rollout plans, and effective communication at every stage.
Thorough testing
Rigorous testing is the foundation for a reliable release. By conducting various types of testing – such as unit tests, integration tests, performance tests, and user acceptance tests – teams can identify defects before they reach production, giving them more confidence that the release will be stable and reliable.
Tip: Document key workflows and features that should be tested before each release.
Staged rollouts
Staged rollouts introduce changes incrementally. Instead of deploying changes to your entire user base, staged rollouts release updates to small subsets of users. This enables teams to monitor the release in a production environment and gather feedback before doing a broad release to all customers.
This release strategy reduces the risk of causing a catastrophic customer-wide outage or disruption as it only involves a small group of customers. These rollouts aren’t suitable for every release (such as large database migrations) but are an excellent strategy for feature releases or UI updates.
Tip: Use a feature flag tool like LaunchDarkly to introduce changes to a small percentage of users.
Clear rollout plans
A rollout plan is like a well-planned road trip itinerary: it maps out each stop, sets timelines, and provides backup routes.
A well-defined rollout plan helps minimize risk by ensuring the entire release process is managed smoothly. They outline key details such as when the release will happen, who it will be deployed to, and how/when/where you will communicate about it. They also specify any troubleshooting or rollback steps if things go wrong.
Tip: Create a rollout plan template and fill this out for each major release to ensure team alignment and smooth release.
Communication
A well-executed rollout plan requires strategic and thorough communication at all stages. From giving customers a warning about upcoming changes, announcing the actual release, and nailing communication around incidents related to changes, thorough communication ensures users know what to expect.
Tip: Use a tool like Sorry™ to communicate about incidents and product updates.
Incident communication: A key pillar of change management
Many software companies excel at incident communication, promptly informing customers when issues arise. However, they often overlook the importance of communicating about product changes. At Sorry™, we believe that keeping customers informed about software changes—new features, updates, and improvements—is just as critical as incident communication.
Sharing updates about changes not only empowers users to take full advantage of your product but also reinforces its value. Being transparent about what’s coming, what’s changed, and what’s not working helps build customer trust. For us at Sorry™, great communication means not just responding to issues, but proactively connecting with customers about every meaningful change.
Interested in improving how you communicate about incidents and changes? Start your free trial of Sorry™ today.
Interested in improving how you communicate about incidents and changes?
Setup up a Sorry™ status page in just a few minutes, no cards required.
