Resilience Culture and Ownership

Resilience culture is the set of habits that determines whether resilience work actually changes a service: whether weaknesses are reported honestly, whether service owners feel responsible for user outcomes, whether tests are welcomed as learning, and whether lessons from incidents lead to fixes rather than to blame. Ownership is the other half of the same idea: a named person who answers for a service, including the parts run by other teams and suppliers.

A claims handling team shows how culture and ownership interact. If handlers notice that a workaround regularly delays payments, but feel that raising it will be unwelcome, the weakness will persist until a disruption exposes it. If the service owner treats that report as valuable evidence and owns the fix, the same weakness becomes an improvement before users suffer.

Named ownership matters because resilience fails in gaps between teams. A service that crosses channels, processing, suppliers, and data will have many contributors, and without a single owner who answers for the user outcome, each contributor can reasonably claim its part worked while the service as a whole failed. Ownership closes that gap by giving the service a person, not just a programme.

Ownership must include authority as well as accountability. An owner who cannot prioritise a fix, challenge a supplier, or escalate a tolerance breach is a figurehead rather than an owner, and teams will quickly learn that resilience decisions are made elsewhere. Real ownership shows in decisions taken, not in titles assigned.

Culture shows up in small decisions: whether a near miss is recorded or quietly worked around, whether a test is designed to find weakness or to pass, whether a supplier problem is disclosed early or hidden until it becomes an incident, and whether junior staff feel able to challenge a recovery plan they believe will not work.

Those habits are shaped by incentives. If teams are rewarded only for delivery speed or for clean test results, they will optimise for those measures, and resilience will suffer quietly. If reporting a weakness, fixing it, and retesting are recognised, teams will surface problems while they are still fixable, which is the behaviour resilience depends on.

Learning should work as a loop from incident or test to service change, with the change owned, dated, and retested. A lessons learned document that no one acts on is not learning, however thorough, and a review that assigns blame without fixing the service will teach people to hide the next weakness rather than report it.

Good learning also looks beyond the immediate cause. An incident caused by a failed change may reveal a deeper issue, such as a missing dependency on the service map, a tolerance that was never challenged, or a supplier arrangement that no one understood. Fixing only the immediate cause leaves the deeper issue ready to cause the next incident in a different form.

Leaders shape culture by the questions they ask and by how they respond to bad news. A leader who asks, for a service, what was found, what was fixed, and what remains open, and who thanks the team that found a weakness, will hear about weaknesses earlier than a leader who asks only whether everything is on track.

Leaders also shape culture by resourcing resilience as ongoing work rather than as a periodic programme. A service owner who must choose between delivery deadlines and resilience fixes, with no support for doing both, will learn which priority the firm really holds, whatever its policy says.

For one service, ask who owns it, who would speak up if its recovery plan looked wrong, and what happened after the last weakness was reported. If the owner is unclear, the reporting route is unsafe, or the last report led nowhere, culture and ownership are the resilience gaps to address first.

This guide is educational and does not prescribe a culture programme for any firm. It argues that resilience is ultimately a human discipline: services recover because people own them, report honestly about them, and learn from them, not because documents describe them well.