When building software, we far too often suffer from tunnel vision. Each team focuses on the features and fixes that are categorized as “important,” often forgetting that changing one thing can affect other parts of the ecosystem.

This is true in a microservices architecture as much as it is with a monolithic code base. Do we know who gets affected when we add, modify, or remove things from our systems? Do we understand the positives or negatives of making a change?

Huge cloud over a volcano
Photo by Yosh Ginsu / Unsplash

What is a Blast Radius?

As a literal definition, a blast radius is the distance from the source that will be affected when an explosion occurs. In terms of writing code or creating and working with operations tools, it means which parts of the system are affected by changes made to a different part of the system.

For example:

If you want to take advantage of new tooling and write custom code for an existing authentication system, your team might begin by implementing the tooling, writing tests to ensure it integrates properly, and then begin writing the code.

But, what other parts of the system depend on that authentication system? Did anyone check?

A simple change could affect your database, your user code, and probably parts of the UI/UX.

Then the questions to ask are:

Who was consulted on changes before getting started?

Are there people outside of the team working on authentication who are aware of what your team is doing?

Made with Canon 5d Mark III and loved analog lens, Leica APO Macro Elmarit-R 2.8 / 100mm (Year: 1993)
Photo by Markus Spiske / Unsplash

Avoiding collateral damage to other teams

Communication: The most obvious (and yet constantly overlooked) way to avoid catching other teams in your blast radius is communication. Notifying other interested or connected parties prior to making a change ensures no one gets “hit” when your change is integrated into the system.

Development Branches: Using development branches minimizes collateral damage as well. Instead of always working against the trunk or master branch, there is value in splitting off your development to keep it away from where the main activity is taking place. This may mean that it takes a little more time to put things into motion, but it will also reduce risk.

Cross-Team Collaboration: Having members of different teams rotating in and out of projects will help everyone get a wider view of what is being done on the larger scale. Increasing familiarity among team members will also help foster easier, more frequent communication.

together now
Photo by John Schnobrich / Unsplash

But what tools will help reduce your blast radius?

What resources will allow us to make changes without hurting others?

Simple communication tools like Discord and Slack are probably already in your tool belt when it comes to intra-company communication. That said, nothing beats meeting face-to-face. This doesn’t only work for in-office teams; remote teams can use video meeting software. These meetings don’t need to be formal - just a few minutes to meet and explain what’s happening and to gather feedback on how that might hurt, help, hinder, or benefit other teams.

But just telling people they may be in the blast radius isn’t helpful - you need to tell the right people.

That’s where a tool like Fluxroll comes in. Fluxroll helps you keep track of each point of contact for every part of your system and business, so you know who the appropriate players are in your organization, and can reach out to the people who may be affected by the changes you plan to make. With Fluxroll, it’s much easier to work together to create seamless improvements - reducing “blast radius” to tactical strikes, while building stronger inter-team collaboration.

Get Fluxroll