6. Strategic steering

Reading mode

EngineerDecision-maker

Laurent Moreau’s journal, chapter 6 (fiction)

Valenciennes, 18 June 2026. Fifteen months after the March 2025 committee, Laurent comes back before the same leadership team. Same room, same faces, with one exception: Jean-Marc, the CFO who joined in December, does not know the history.

Five slides. The central figure is not a saving but an avoided loss. Over the last twelve months, cumulative production stoppages fell from about eighteen hours to five. The thirteen hours avoided are valued at the hourly cost agreed with management control. They represent about €1 million in preserved margin, for €415,000 invested (the initial budget plus the industrial extension). The payback period comes out at about five months after the first services went live. The median time to restore major incidents dropped from about four hours to thirty-five minutes. On compliance, eight NIS2 measures out of ten can be demonstrated; the other two depend on suppliers and are covered by a contractual plan.

Laurent also presents what did not work. The cloud migration of the Cambrai site was postponed by six months. The self-service platform fell behind because the product teams were not available. Two quick wins stayed on the list. And the first dashboards for production were rejected by Jean-Paul as too technical: it took a four-hour workshop with him to settle on four indicators phrased in his vocabulary.

Jean-Marc asks three questions: the budget trajectory over the next twenty-four months, the dependence on the application monitoring vendor, and what Laurent would do differently if he started over. Laurent answers all three candidly. The next plan is approved without objection.

The CIO needs different indicators from those of the operations team. Knowing how to translate the technical into business impact is what separates projects that survive a change of leadership from those that get cut at the first budget trade-off.

Executive indicators and technical indicators

For the executive committee

• Service availability, as the customer sees it: the share of time the service is fully usable from the user’s point of view, not the infrastructure’s.
• Cost per incident: mean and median, including lost margin, remediation and penalties.
• Resolution time as the customer sees it: from the first complaint to actual restoration.
• Meeting contractual commitments: share of service levels met over rolling 30 and 90 days.
• Cost of observability: relative to the IT budget or, better, to business activity (see lesson 4).

For the operations teams

• SLOs and burn rate: how fast the error budget is being consumed, which triggers the alert before the breach (see the error budget simulator);
• MTTD and MTTR by severity level;
• error rate by service and by route;
• latency in percentiles (p95, p99);
• instrumentation coverage of critical services.

Every executive indicator must be tied to at least one technical measure. That mapping is what lets the committee ask precise questions when a figure drifts.

The executive dashboard

Five principles:

1. Five indicators at most on the home page. Everything else is available in detail, not displayed up front.
2. Three colors. Green, orange, red, with written thresholds. Ten-level gradients survive neither projection nor a change of tool.
3. Always a comparison: against the target, against the previous period. A figure on its own says nothing.
4. A path to the detail: each indicator opens onto the technical measures that make it up.
5. Continuous updates, a monthly review with commentary by the IT department. Without a review, the dashboard turns into wallpaper.

The interactive executive dashboard applies these five principles to Helinord’s fictional data: click an indicator to drill down to its technical measures.

Recommendation: five indicators, not twenty-five

In my view, an executive dashboard with fifteen or thirty indicators does not get read. Five are enough: read in two minutes, discussed in ten. I recommend sticking to the five indicators listed above (availability as the customer sees it, cost per incident, resolution time as the customer sees it, meeting contractual commitments, cost of observability) and keeping everything else in the detail view for anyone who wants to dig. A cluttered dashboard makes the IT department invisible at the very moment it is trying to be seen.

AIOps, without illusions

AIOps, the application of AI techniques to operations, is one of the most marketing-wrapped topics around.

What it actually does, on good data: reduce alert noise through anomaly detection, group alerts that belong to the same incident, spot recurring patterns, anticipate some short-term saturation.

What it does not do: replace defining SLOs (without a target, it has nothing to optimize), make up for poor data, fix an architecture, or decide alone on a major incident.

Prerequisites: several months of clean history, consistent tags across services and environments, controlled cardinality, structured post-mortems that make it possible to label past incidents.

Five questions to ask a vendor: which models, and how explainable are they? What OpenTelemetry compatibility? What cost, capped in the contract? What results on your data, in a proof of concept, rather than in a demo? What exit plan?

Safety rule

AIOps helps you decide; it does not decide alone on a critical incident. False correlations exist in every model. A human stays in the loop on major incidents.

Leading change with ADKAR

The ADKAR model, published by Prosci, describes five stages a person goes through to adopt a change. Applied to observability:

Stage	What the person experiences	Levers
Awareness	they understand why change is needed	cost of incidents quantified, comparable cases
Desire	they want to take part	internal champions, visible quick wins, recognition
Knowledge	they know how to do it	training, written procedures, pairing, community of practice
Ability	they can do it day to day	platform in service, SLOs in production, self-service, up-to-date documentation
Reinforcement	the change lasts	blameless post-mortems, indicators presented to the committee, adjusted roadmap

Recommendation: change happens one person at a time

I recommend ADKAR because it starts from the person and not from the system. In my view, an observability transformation rarely fails on technology; it fails when three or four key people have not gotten past the desire stage. Identifying them at the start of the project and building a plan for each one pays off more than any collective communication plan.

Five weak signals of a project in trouble

The thresholds below are benchmarks I suggest for triggering a discussion, to be adjusted to your context.

Signal	Warning threshold	What it means
Departures from the team	several departures in a year from a small team	expertise and context leave with the people
Alert noise	the vast majority of alerts require no action	the real signals are drowned out
Trace coverage	a minority of critical services instrumented	diagnosis happens blind
Post-mortems	none in six months	the same mistakes keep repeating
Alert debt	hundreds of rules never reviewed	obsolete rules mask the real anomalies

When several of these signals appear at the same time, the project deserves a reset led directly by the CIO.

Workshop: your executive dashboard

Duration: 45 minutes, on your own.

1. Choose five indicators for your executive committee.
2. Tie each one to at least one existing technical measure, or note that it is missing.
3. Set a target for each, and green, orange and red thresholds.
4. Write the commentary you would give at the next monthly review.
5. If an indicator concerns a business unit, plan a workshop with them before locking it in.

My next action: what action, by what date, with whom?

Going further

• The bridges: the dictionary between technical signal and business indicator.
• The MTTR business case.

Mark as read

BridgesWhat this page changes beyond the technical team.

BusinessValue, cost, risk

An executive committee thinks in euros, customers and risks. A dashboard of five indicators, each tied to its technical measures, lets it do so.

OrganizationWho decides, who owns

A dashboard without a monthly review with commentary turns into wallpaper. The ritual matters as much as the tool.

PeopleTeams, on-call, skills

ADKAR is a reminder that a transformation rarely fails on technology: it fails when three or four key people do not want to move forward.

Business linesProduct, finance, risk, customer

A business dashboard is built with the business, in its own words. Production's dashboard does not look like the IT department's.

Why bridges matter →