Why IT Hero Culture Fails: Engineer Resilience Into the Service

Why IT Hero Culture Fails: Engineer Resilience Into the Service

When Matt Weston won Olympic skeleton gold for Team GB at Milano Cortina 2026, the result looked intensely individual: one athlete, one sled and four runs under extraordinary pressure.

But high performance in skeleton is not produced by one person trying harder. It depends on coaching, materials science, aerodynamics, track knowledge, manufacturing precision, physical preparation and thousands of small decisions made long before race day. Team GB described Weston's performance as the product of meticulous preparation, and that distinction matters far beyond sport.

IT services often celebrate the opposite model: the person who stays late, remembers every workaround, knows which component to kick and “saves the account” when the system fails.

Occasional exceptional effort is part of any demanding job. Repeated heroics are different. They are often evidence that resilience has not been designed into the service.

Key takeaways

• A heroic recovery can conceal weak ownership, documentation, monitoring, spares or escalation.
• Resilience is the ability to produce an acceptable outcome repeatedly, including when a key individual is unavailable.
• Contracts should define responsibilities, service clocks, parts, escalation and exclusions before an incident.
• Multi-vendor estates need one coherent operating model even when several organisations deliver parts of the service.
• Post-incident reviews should improve the system rather than simply praise the person who rescued it.

The hidden cost of the dependable hero

Every IT team has people who carry more context than anyone else. They know the history of the estate, the unofficial dependencies and the fastest route through a crisis. Their experience is valuable, but an organisation becomes fragile when the service depends on that knowledge remaining inside one person's head.

The symptoms are familiar:

• escalations always go to the same engineer;
• incidents wait for somebody to return from leave;
• parts are found through personal contacts rather than an agreed supply route;
• monitoring generates noise but not clear action;
• the contract says “response” without defining restoration;
• customers do not know which supplier owns the next step;
• post-incident reviews celebrate effort but do not remove the cause.

This is unmanaged friction. It exhausts good people, makes service quality variable and gives leaders an inaccurate view of operational risk.

What engineered IT resilience looks like

Clear service ownership

For each supported service, somebody must own triage, dispatch, communication, escalation and closure. This is especially important in a multi-vendor estate where the hardware provider, software vendor, network team and application owner may all be different organisations.

The customer should not have to coordinate suppliers during an outage unless that responsibility has deliberately remained in-house.

A verified asset and dependency picture

Resilience starts with knowing what is installed, where it is, what it supports and which dependencies remain with the OEM. Model, serial number, location and warranty status are necessary, but not sufficient. The service also needs the business owner, criticality, firmware dependency, access constraint and restoration requirement.

Service levels tied to outcomes

Fast acknowledgement can be useful, but it is not the same as engineer arrival or service restoration. A credible support contract defines the service clock, coverage hours, remote triage, on-site attendance, parts, escalation and customer responsibilities.

The fastest tier should be reserved for assets where the business impact justifies it. Less critical equipment may be better served by next-business-day cover, customer-held spares or time-and-materials support.

Parts positioned for the real geography

A national claim means little unless the provider can explain how an engineer and the correct part will reach each site. Spares strategy should reflect failure history, device criticality and location. The answer may be depot stock, forward-positioned parts or customer-owned spares; what matters is that the route is deliberate and testable.

Monitoring connected to action

Monitoring only improves resilience when alerts have owners, thresholds, runbooks and a response service. BMC monitoring, patch management and incident response can all form part of a managed service, but only where the contract includes them and the operational responsibilities are clear.

Rehearsed escalation and communication

People should know who takes control when the first fix fails, when the customer is updated and when another supplier or senior technical specialist joins. An escalation process written only for tender responses is not an operational process.

The contract is part of the engineering

Service resilience is sometimes treated as a purely technical property. In practice, ambiguous commercial boundaries can cause as much delay as a failed component.

Before award, test scenarios such as:

1. A server fails outside normal hours. Who answers, and what cover has been purchased?
2. The engineer identifies a firmware issue rather than a hardware fault. Who owns it?
3. A replacement drive contains customer data. Who controls sanitisation and evidence?
4. The correct part is not at the nearest depot. What is the escalation route?
5. An overseas site needs attendance. Which regional partner delivers, and who remains accountable?

The answers belong in the scope, service description and operating procedures. They should not depend on goodwill or mountains of gold during the incident.

From individual brilliance to repeatable performance

The goal is not to remove expert judgement. Good systems allow experts to spend their time on the difficult work rather than repeatedly compensating for missing basics.

A resilient service makes the normal path obvious, gives the first responder the right information and brings specialist help in at a defined point. It also learns: incident data changes spares, thresholds, documentation and lifecycle decisions.

That is the IT equivalent of the unseen engineering behind a gold-medal run. The customer sees a fast, controlled outcome because the work was done before the incident.

How Myrmekes structures delivery

Myrmekes provides one commercial and operational point of contact for support contracts, engineering resources, professional services and hardware fulfilment across multi-vendor estates. UK delivery is provided by Cantel through its network of 66 engineers and six depots. Requirements elsewhere are coordinated through appropriate regional partners, with the delivery party and coverage confirmed country by country.

The relevant delivery model and credentials can be reviewed during due diligence. Cantel holds the referenced ISO certifications and B Corp status; Myrmekes should not be described as independently holding them.

If your service depends too heavily on a small number of heroes, book a discovery call. We can map the assets, sites, service boundaries and escalation points that need to become part of the system.

Source notes

• Team GB: Matt Weston crowned Olympic skeleton champion
• Team GB: Matt Weston's Olympic gold in pictures