It's not about the how, it's about the why
Could you explain your backup design to your CEO in two minutes? Lessons from my UK Veeam User Group talk on designing data protection from business outcomes.
UK Veeam User Group, April 2026
Back in April I rounded out the UK Veeam User Group. After a properly technical session on APIs and dashboards, I went the other way: no product talk, just a bit of thinking differently about the job. Calling it thought leadership would make me sound grander than I am.
The question running through the session was whether the decisions we make when we design data protection still make sense when the pressure is on. Let’s go through my points.
When was the last time you had to explain your backup design to a non-technical audience?
Most of us could explain exactly how our backups work: proxies, data movers, repositories, immutability, 3-2-1-1-0, RTOs and RPOs. But everything we put in place is there for the business, and the business talks revenue, risk, reputation and regulation. Those vocabularies rarely meet.
** Tip: If something went wrong tonight, could you explain the impact to your CEO in two minutes, in business terms? **
The “why” is the business reason behind each decision.
- Why does this workload recover first?
- Why is retention 30 days and not 90?
If the honest answer is “that’s just how it’s always been configured,” you’ve only got the how.
“Kind of obvious, Craig,” I hear you say.
Fair.
But most designs go wrong right here: we build around what the platform can do and retro-fit the justification later.
Flip it.
Start with outcomes, derive requirements, then configure the technology to match.
Put your hand up if every workload in your environment is Tier 1?
Treating everything as equally critical feels safe, but it means you’ve decided nothing in advance. Prioritisation still happens; you’ve just left it to the worst possible moment, with the CEO standing next to your desk.
** Tip: Pick one workload this quarter that’s Tier 1 by default and challenge it. Ask who agreed that, and when. **
Backups don’t fail as often as decision-making does. The usual failure points are unclear ownership, unclear authority and unclear escalation.
- Who decides we restore?
- Who signs off on accepting data loss?
- Who explains the trade-offs to leadership?
You can have immutability, air gaps and a perfect architecture and still fail, because no one owns recovery decisions, no one practises restores, security and backup teams don’t talk, and the first test happens during the incident.
Resilience lives where people, process and technology meet.
It’s a team sport, and no storage feature will do it for you.
So, who makes the call to recover in your organisation, and is that written down anywhere?
Knowing which check box to tick is the easy bit. Your value is knowing which trade-offs matter, which risks are acceptable, and how to explain those choices clearly to the business.
It runs both ways: business outcomes into technology decisions, and technology limitations back into the language of risk and reputation.
Being that middle man makes you more than a backup person.
Try calling yourself a resilience engineer at your next one-to-one or annual review. You might be surprised what a difference it makes.
I asked the room where they add most value today: building the systems or shaping the decisions? Trick question. It’s both really.
Every design looks great on a slide. The test is whether it still makes sense when you’re tired, under pressure, and the business is watching. he phone rings at 3am tomorrow.
- Would your recovery priorities be obvious?
- Would the calls you make on the fly be defensible afterwards?
That’s about being predictable more than perfect.
Good environments feel calmer during an incident because the recovery paths are understood, the assumptions have been tested, and the decisions were made before the pressure arrived.
Boring sounds a harsh word, but boring, repeatable recovery is the goal. Confidence beats complexity every time.
It isn’t one and done either.
Values agreed in January might not stand two or three quarters later, so keep checking.
Resilience is alignment: outcomes, business values and technology pulling the same way. I’d call that a habit more than a framework. Start with outcomes, design backwards, make priorities explicit, test your assumptions with tabletops, virtual labs and real restores, and communicate intent in both directions.
If you can explain your backup design to the business and they agree with it, you’re doing resilience properly.
Data resilience won’t give you all the answers, but it does give you better questions.
So, with a new quarter just started, what’s one thing you could change to make your recovery decisions clearer to your business? Let me know in the comments or find me on socials.