Why
Working on projects that can have a lot of downstream unexpected effects is an ever present risk. Having a methodical way to assess where you may find unexpected impact from your changes is really important. Especially when you may be working in highly distributed teams or ownership of domains are not as clear as you may like.
There are two key components to a good impact analysis:
- A severity matrix to help teams calibrate the blast radius or risk of each area.
- A checklist of typical engineering areas that may be affected by the work, with clear ownership and follow-up actions where needed.
An impact analysis allows you to have a checklist of a sorts that identifies areas where you may need additional upfront discussions and decisions before executing on a larger piece of work
This list may vary greatly depending on your domain but broadly speaking it should cover the usual basis around what your wider remit is in engineering. Having specific call outs, even if that call out is "we don't need to worry about this" is really important.
What
Here's an example definition I've used in the past for this type of thing. I would say its worth evaluating more domain specific things if you feel it's relevant.
When filling this in, aim for clarity over completeness — even a first pass with rough guesses is better than skipping it. Use the follow-up column to trigger additional RFCs, Slack discussions, or design reviews if needed.
Severity Definition:
P0 = This has potential to cause a major outage or issue in our systems. It will certainly impact a wide user base (>5-10%), there is no workaround as of yet.
P1 = This will cause issues within our infrastructure, the issue may have workaround but will have a wide blast radius. Any clean up operations are “relatively” automated.
P2 = The risk has a workaround and only affects a small subset of customers. Any side effects are currently managed or we have a mitigation for this currently in flight
| Area | Impact (P0–P2 or None) | Accountable Owner | Notes / Follow-ups |
|---|---|---|---|
| API Documentation | |||
| Data Modelling | |||
| 3rd party integrations | |||
| 1st party integrations | |||
| Observability tools | |||
| Testing infrastructure | |||
| Internal dashboard/data tools | |||
| Authentication / Identity Flows | |||
| Feature Flags | |||
| Data Privacy (GDPR) |
When
This should ideally be utilised as mentioned when starting a larger piece of work. Anything that you think could require some thinking outside of your direct team its a good exercise to take on.
hat-tip to John Conneely for first introducing this concept to me.
Luke Curtis
Engineering Leader with over 10 years of experience in building and leading high-performing teams. Passionate about transforming organizations through technical excellence and empowered engineering cultures.