Leadership & Culture

Accountability isn’t the price you pay for failure. It’s the asset that makes you — and the systems you build — genuinely hard to break.

Earlier this week, I found my digital bank account restricted with no warning. A few hours earlier I had used the card normally — six transaction alerts came through fine. Then nothing. App locked. I wrote to support.

Within hours I got an honest, measured response. The agent named the cause directly: a disruption at Amazon Web Services in Bahrain. He confirmed the money was safe. Physical card payments were still working. The team was on it around the clock.

It was a genuinely good response. And yet something stayed with me — not as a critique of the team, but as a prompt to write down something I have been turning over for years in BSS, CRM, and organizational work. The response was good. But the real question is what has to be true before the incident for the response to be unnecessary.

From Real support exchange · March 2026

Agent wrote:

…app is currently unavailable. This is due to disruptions at Amazon Web Services in Bahrain, which many financial services in the region rely on…

My Reply:

“…avoiding a single point of failure — even at a geographic level — is an architectural choice, not a technical impossibility. Trust is built over years but can be compromised in a single afternoon… My mission has always been to architect organizations and systems that don’t have to point at external calamities to explain a service lapse…”

The phrase “this is due to ” is factually true. It is also exactly the kind of framing that, repeated internally over time, quietly dissolves accountability culture — not through bad intent, but through habit.

Ownership is a strategic asset, not a liability

Most organizations treat accountability as a cost. A concession. Something to minimize, qualify, and route through legal before it reaches customers. This makes sense if you believe trust is a fixed resource — a tank you drain when things go wrong and refill with marketing when the crisis passes.

But there is a second kind of organization — rare, and disproportionately trusted — that has learned the opposite. Owning mistakes, practiced consistently, is a moat. Not a PR strategy. Not a values statement. A structural competitive advantage that compounds over time.

When you own the failure — not the vendor’s, not the market’s — you get to define what happens next. You own the narrative, the remedy, and the credibility that comes from being the organization that said plainly: that was on us, and here is what changes.

You cannot build a resilient organization by accident. Every gap in your architecture was signed off — silently or explicitly — by someone. Ownership starts there.

The difference between an explanation and an excuse

There is a thin, important line between explaining context and distributing blame. The sentences can be factually identical. The difference is in what comes next — and whether the speaker believes they have a role in the outcome.

“AWS went down and took us with it” is an explanation. It becomes an excuse the moment it closes the conversation instead of opening the right questions: Why did we have a single-region dependency in a geopolitically volatile corridor? What architectural decision made this outcome predictable? Who owned that decision — and what are we changing?

When the postmortem ends with “third-party failure” and no action items, you have not learned anything. You have filed the incident. The next one is already being scheduled.

The hidden cost of deferred resilience: Every architectural shortcut taken in the name of speed is a loan taken against future reliability. Unlike financial debt, reliability debt compounds with user expectations. The longer you wait to repay it, the higher the interest — and the more visible the repayment becomes.

What owning it actually looks like in practice

Building an ownership culture is not about being hard on people. It is about being honest about systems — including the human systems that design and approve the technical ones. Here is what it looks like in practice:

1. The postmortem starts with “we,” not “they” Even when an external vendor fails, the first question is: why were we exposed? What decision created this dependency, and who signed off on it? The external cause is a fact. Your exposure to it was a choice.
2. Blameless does not mean accountless Psychological safety means people can speak honestly without fearing punishment for that honesty. It does not mean no one owns the outcome. These two things coexist — always.
3. Resilience is designed, not assumed Geographic redundancy, degraded-mode UX, multi-region failover — these are architectural commitments that have to be made before an outage, not rationalized after one. If you can name the failure mode, you own the gap.
4. Leaders model the behavior first If your CTO says “the vendor failed us” in an all-hands with no follow-through, your engineers absorb the lesson that pointing outward is acceptable. Culture is demonstrated before it is mandated.
5. Think it beforehand — so you never have to save face later The only way to never need to explain a failure to your users is to have already asked: what is the failure mode here? Who owns it? What do we do when it fires? Architecture reviews that include these questions are worth more than any incident response plan.

Why this matters more in constrained environments

I want to be precise here, because it is easy to read organizational writing about accountability as an indictment of the teams involved. It is not.

Building a regulated fintech in Pakistan — capital-constrained, in a region with limited cloud infrastructure options, under real competitive and regulatory pressure — is genuinely hard. The tradeoffs facing engineering and product teams there are real, not invented.

This is exactly why culture matters more in constrained environments, not less. When you cannot afford to build everything at once, the only thing that closes the gap between what you can fund today and what resilience requires is a culture that owns the gap as its own problem to solve — not externally, not performatively, but in the practical way that creates a roadmap item with an owner and a date.

The support agent who said “we are treating this as our responsibility” had the right instinct. The work is making that instinct structural: wired into how architecture is reviewed, how postmortems are run, and how leadership talks about failure when the whole company is listening.

The three questions worth asking now

Before the next incident, not after it:

What gaps in your current architecture do you already know exist? Who owns them? What does it cost to fix them today — and what will it cost to explain them to users when they surface?

The distance between those two costs is the distance between a culture that owns mistakes and one that only describes them.

The organizations that close that gap — quietly, structurally, before anyone is watching — are the ones that earn the word resilient. Not because nothing ever fails. But because when something does, the response is already built in.