Summary
Every change in a shared environment carries potential impact far beyond the code diff. Blast radius thinking gives technology leaders a framework for sizing that exposure before development begins, containing it through deployment, and building the rollback guarantees that let teams move fast without breaking what already works.
Every change carries risk when a routine deployment affects teams, clients, and business units that share the same codebase. The “blast radius” concept provides a framework for sizing how far that exposure spreads before it’s caught. In shared infrastructure, such as a platform serving multiple fund vehicles or an environment supporting separately managed accounts, a single change can affect dozens of configurations on the same underlying systems.
Even when the code diff itself is often small, perhaps just a few hundred lines, the blast radius can encompass the entire book in a single release. So, the risk management work around that change dwarfs the diff. That asymmetry is the core problem that you make visible by assessing blast radius.
Catching the problem as early as possible requires strategies for anticipating impacts before they go live. You also need a framework for deciding how much scrutiny each change deserves, because you can’t do deep introspection on every single change. Effective triage means sizing the radius before development and designing it with deployment in mind. By working backward from the state you want to reach – where the change is live and everyone is happy – you contain the radius of potential fallout.
You should start by looking at the size of the exposure and who absorbs the impact before any change ships. The answers shape everything from deployment sequencing to rollback planning.
The first question is reach. If a change touches every client, segment, and downstream user, it carries a fundamentally different risk profile than one scoped to a single asset class or team. The wider the reach, the more people experience the consequences of anything unexpected.
After reach comes the question of system dependencies. A change that lives inside a single system allows self-contained rollback if something breaks. But if it crosses system boundaries, it forces synchronized rollout across all of them, multiplying both the coordination cost and the number of failure points.
Then, look at the volume and location of changed code. Many lines changed across many files signals broad exposure. A small, focused modification signals the opposite. However, line count alone can mislead. A vast change to a dormant code path may carry zero real impact, while a handful of lines changed at a system interface level could break every client’s ability to get data out.
The impact of timing can override every other measurement of the blast radius. In operations, it’s common sense not to change anything about your process right before things like month-end or quarterly reporting, regulatory filings, or tax deadlines. Whatever efficiency the change could deliver is unimportant compared to the risk of disrupting a critical cycle.
Assessing exposure, dependencies, code footprint, and timing turns the deployment decision into a matching problem. Consider two groups affected by the same platform change. One says the current workflow doesn’t work for them anyway. They’re far safer to receive the change. The other says everything is working fine, and they never asked for anything different. The first group needs the improvement. The second absorbs all the risk with none of the upside.
The teams that handle change best have usually practiced it relentlessly in small doses.
“It’s better to practice risky things often and in small chunks, with a limited blast radius, than to avoid risky things altogether.” — Charity Majors, CTO, Honeycombi
Blast radius assessment begins with the person who knows the codebase, understands the downstream effects, and is accountable for the outcome. That’s who immediately owns the change.
While self-assessment is the foundation, it comes with a built-in limitation. Many teams create hidden pressure to understate risk because flagging a high-risk change invites scrutiny and slows the timeline. It ties back to a sense of safety. Some people are candid about the risk and commit to managing it carefully. Others are under deadline pressure and convince themselves that the risk is lower than it is.
The goal is to give them the benefit of the doubt while building in an independent check in the form of automated tools that help the team score potential blast radius across affected systems, lines changed, and coordination requirements. Humans provide a qualitative judgment first. The automated system provides objective measurement.
Both of these pieces need to be in place. Sometimes an automated system would score a change as high risk, but the developer knows the affected code path is dormant and unused by any users today. Yes, the change is profound, but it has no real-world impact. Other times, a change looks trivial by the numbers, but the particular pieces that changed sit at a system interface level. They could damage the ability to get data out, making it riskier than the machine thinks.
The way to bridge the gap is for the human to explain the difference between their assessment and the automated score. Doing that brings sloppy assumptions to the surface. It’s where a team discovers whether its confidence in a change is warranted or wishful thinking.
When the assessment flags meaningful risk, blast radius thinking has to carry forward into the deployment strategy, which should drive the cost of a bad change toward zero. Three containment patterns do most of the work.
Parallel workflow. Run the old process and the new one side by side on the same inputs. The team does the work twice, compares the results, and both sets of outputs need to match. If they match, the new way passes. If there’s a difference, the team has to explain it before anything moves forward. The old way stays in backup until the new way has proven itself, and at a defined point, the old way gets decommissioned.
Rollback guarantee. If a problem surfaces after deployment, switching back to the old way is instant, and nothing is thrown away. Automated testing confirms that the new implementation performs exactly the same as the old one. Tests run in a separate environment first. When the change reaches production, reversibility is already built in.
Phased rollout. Sophisticated organizations leg into technology change the way a portfolio manager legs into a position. They release the change to a small group first, run automated comparisons between old and new paths, and expand only when each group validates.
These patterns depend on the same guarantee that you can rely on switching back instantly if a problem surfaces. According to Google DevOps research, Elite-performing teams deploy on demand, often multiple times per day, with change failure rates at or below 5%.ii Teams that batch large changes and deploy less frequently fail at significantly higher rates. The guarantee holds because it allows you to confirm the new implementation performs exactly the same as the old one before anything reaches production. When reversibility is built in from the start, the cost of being wrong approaches zero. You go slow to go fast.
The containment patterns described above apply to all kinds of change, but the standard rises when the change comes from internal teams rather than features or enhancements requested by users or business stakeholders. For example, if the team decides to consolidate systems or refactor a codebase without anyone else asking, any problems that surface are entirely the team’s responsibility. The leadership message to the team has to reinforce that nothing can break.
They work at the individual level as well. Before a change goes up for review, they should already ask who feels it and how fast they can fix it if their deployment breaks something. It’s something experienced developers do as a reflex, and junior developers learn by working next to them.
When the work moves to agentic systems, the habit looks different. A person on your team has immediate reasons to be careful. They don’t want to lose their job, get priority one alerts at 3 AM, or face making awkward apologies. An agent doesn’t face the same stakes or psychological motivations. Agents force you to make permissioning and guardrails explicit, because they will try things the prompt didn’t forbid. It’s critical for changes to be contained, phased and reversible.
Operational teams within firms can recognize this discipline in the way they handle change as well. Workflow redesigns, departmental reorganizations, and staffing adjustments can all seem sound in planning. However, you still have to scope the impact before anything moves. Choosing the timing and testing incrementally before committing is the same logic that development teams use. You ask what the impacts are and decide when it’s prudent to act and try it on a small scale to see if it works first.
Matt Katz
As Arcesium's Field CTO, Matt leads Arcesium's Forward Deployed Software Engineering and Client Success teams. His work to empower clients and simplify technical challenges stems from a 25-year career in financial technology working with clients and software. Outside of work, he enjoys books, bikes, and boards.
Sources:
[i] “I test in prod,” The Increment, 2019. https://increment.com/testing/i-test-in-production/
[ii] Google Cloud, 2024. https://services.google.com/fh/files/misc/2024_final_dora_report.pdf
No spam. Just the latest releases and tips, interesting articles, and exclusive interviews in your inbox every week.
