Building a Future-Proof Observability Platform to Empower Engineers

The talk opens with a two-minute sketch that every on-call engineer will recognise. Wayne Bell is on the phone to the Chief Commercial Officer because travellers cannot book. Dan Gomez Blanco, owner of a service in the middle of that flow, checks his dashboards and his alerts, finds everything green, and says the line that ends the conversation: "It works in my machine." Both statements are true, and neither of them helps. The sketch, Bell later reveals, is a dramatisation of something that actually happened at Skyscanner.

Dan Gomez Blanco is a Principal Observability Architect at New Relic and an OpenTelemetry contributor; at the time of the work described here he led the observability team at Skyscanner. Wayne Bell introduces himself as Director of Platforms at Skyscanner, a role he reached after an abrupt overnight swap from running product teams to running the platform organisation. Their argument comes in two halves that map onto their two backgrounds. Gomez Blanco argues that OpenTelemetry is the right technical foundation because it decouples what engineers write from what any vendor ingests. Bell argues that this is the easy half, and that the reason platform rollouts fail is cultural: engineers do not adopt a platform because it is better, they adopt it because it arrives inside the toolkit they already use and because someone credible showed up when it mattered.

This 49-minute talk was recorded at InfoQ Dev Summit Munich 2025 and published by InfoQ on April 27, 2026. These notes report what the speakers presented and mark the small amount of background context added for readers new to OpenTelemetry.

What You Will Learn

• Why treating metrics, traces, and logs as three "pillars" produces two different kinds of silo, and what correlated signals replace them with.
• How OpenTelemetry's separation of API from SDK makes telemetry a stable cross-cutting concern rather than a vendor dependency.
• What exemplars, semantic conventions, and trace-context injection actually buy you during an incident.
• How to decide where your platform's boundary sits, and why pushing it into the application side is what makes standards real.
• How Skyscanner migrated from OpenTracing to OpenTelemetry as a minor library version bump, and the adoption curve that produced.
• Why mandating a platform predictably backfires, and the adoption lifecycle the team used instead.
• The maturity model and outcome metrics Skyscanner reported, and how to read them honestly.

The Problem: Pillars Produce Silos

The conventional framing of observability is three pillars — metrics, traces, and logs — which a service emits into one or many observability platforms so that you can answer two questions: is the service working as expected, and if not, why. Gomez Blanco's objection is that the pillar metaphor is load-bearing in the worst way. Pillars stand apart, and so does the data.

He identifies two distinct silos. The first is between signals. If a regression shows up in your traces, nothing in the pillar model tells you which metric it corresponds to, or which log lines were emitted during that same unit of work. You correlate by hand, by timestamp, in the middle of an incident. The second silo is in how engineers reason. Everyone knows intellectually that they own one node in a complex distributed system with upstream and downstream dependencies, but the tooling puts their service at the centre of the world and they debug accordingly. The holistic view is lost. His worked example: CPU throttling in one service, late in a transaction, degrades the experience of a specific set of end users. Connecting those two facts — which users suffered because of that throttling — is not a hard query if the data is linked, and is essentially impossible if it is not. What is missing is not data. It is context.

Correlated Signals, Concretely

The alternative is to carry shared context through every signal so that the platform can join them for you. Gomez Blanco walks through the mechanisms OpenTelemetry provides, using the failed-booking scenario.

Standard attributes. An end user ID is a standard attribute in OpenTelemetry. Because it is standard, observability vendors know what it means and can build insights on top of it — such as counting how many users were affected by a regression — without you teaching each tool your private naming scheme. That same attribute is present on the traces, so the count and the traces refer to the same population.

Traces across services. A single trace shows one transaction crossing many services, each rendered in a different colour, in one view. This is the cross-service correlation most teams already expect from distributed tracing.

Exemplars. This is the cross-signal link, and Gomez Blanco calls it super important to understand. A backend team alerting on what he describes as a standard HTTP server duration metric — in current OpenTelemetry semantic conventions, http.server.request.duration, though he did not name it on stage — sees an aggregate. An exemplar attaches example trace identifiers to individual metric data points, so you can click a spike and jump to actual traces recorded on the replica where that data point was produced. You move from "the p99 got worse" to "here are requests that were slow" in one hop.

Logs in context. Logs can carry the trace context of the operation that emitted them. Crucially, this works even for code that is not instrumented with OpenTelemetry: legacy logging libraries can use OpenTelemetry instrumentation to inject the context on the way out. Gomez Blanco's example of the payoff is finding the correlation between a span that errored, the memory usage at that moment, and the backpressure recorded in the logs.

Profiles, soon. He notes that continuous profiling is coming to OpenTelemetry, letting you dig into the call stack of a specific application replica as it served a specific request. As presented, this was a near-future capability rather than something Skyscanner was relying on.

The connective tissue underneath all of this is semantic conventions: an agreed vocabulary for describing systems, so that a standard duration metric or an end-user attribute means the same thing in every service and every backend. Without conventions you have correlated data that nothing knows how to correlate.

Skyscanner's Starting Point

In 2020 Skyscanner began a large initiative to re-architect all of this. The before-state is a familiar accumulation rather than a design: separate vendor relationships for synthetics, for browser monitoring, and for tracing; several open-source systems run and maintained internally; and a layer of internally sourced abstractions and libraries built on top so that engineers got a stable experience regardless of what churned underneath.

The cost was not primarily licensing. It was disjointed telemetry, and therefore context switching in the middle of an incident — manually correlating between two platforms at the exact moment when attention is scarcest.

The North Star they set has two principles. First, rely on OpenTelemetry at the instrumentation, export, transfer, and processing layers. Second, use a single platform to correlate all of that telemetry in one place and generate insights across it. At the time of the talk, Bell and Gomez Blanco described Skyscanner as almost there, not quite.

Why the API/SDK Split Matters

The part closest to the developer is the API and SDK layer, and this is where Gomez Blanco makes his strongest technical argument.

A platform team's obligation to the rest of the company — who are its customers — is a stable experience. You do not want to return a year later and tell 800 engineers to refactor their code because you changed an implementation detail. That is hard for telemetry specifically, because telemetry APIs are cross-cutting concerns, and cross-cutting concerns violate the design principles engineers normally rely on. You cannot encapsulate them. You can wrap a logger in an abstraction, but you still have to call that abstraction from every file in the codebase. There is no seam behind which to hide a change.

Because a cross-cutting API is impossible to migrate cheaply, it has to be designed to never need migrating: no breaking changes, and no leaking of implementation details. Gomez Blanco says this is at the core of OpenTelemetry's design. The API surface — the trace API, the metrics API, the logs API, plus the semantic conventions — is what application code and instrumentation libraries both compile against. The SDK is the separate, swappable half where all configuration lives: which attributes to export, which format to use, whether to expose a Prometheus endpoint for pull-based scraping or push over OTLP, and how to process telemetry in between.

Two consequences follow. Instrumentation applied automatically by an agent to common libraries and instrumentation you write by hand for your own business logic use the identical concepts, so they compose. And because spans, histograms, and counters are industry-standard vocabulary rather than house-specific abstractions, a new hire arrives already knowing them — lower cognitive load, which is the whole point of a platform.

Gomez Blanco stresses that the most important thing to instrument is your own business logic, not the framework glue an agent can cover for you.

Native Instrumentation and the Agentless Vision

The ecosystem effect is already visible. He lists JavaScript runtimes such as Deno, Java frameworks such as Quarkus, the Azure SDK, the Elasticsearch client, Kubernetes, Envoy, Istio, and gRPC as projects using OpenTelemetry natively and leaving SDK configuration to the user.

Two benefits fall out. Telemetry ships with features: use a new capability of a library and its instrumentation is already there, rather than arriving later when an APM vendor gets around to writing an instrumentation shim for it. And overhead is lower. Where the industry is currently obsessed with agentic everything, Gomez Blanco notes wryly that OpenTelemetry's direction is agentless — telemetry baked into libraries rather than injected by a byte-code-manipulating agent at runtime.

(Background for readers coming from APM tooling: a traditional agent attaches at process start and rewrites or hooks library code to emit telemetry. It works without source changes, which is its main appeal, but it must chase every library version, and its coverage of your own business logic is necessarily generic.)

Architecture And Data Flow

The following diagram is a synthesis assembled from the talk's prose rather than a reproduction of any single slide. It summarises the target architecture and, just as importantly, the distribution path for configuration — which is the part most teams leave to chance.

flowchart TD
    subgraph app["Application process"]
        BL["Your business logic"] --> API["OTel API
traces / metrics / logs
+ semantic conventions"]
        LIB["Natively instrumented libraries
(Quarkus, gRPC, Azure SDK, ...)"] --> API
        LEG["Legacy logging library
(trace context injected)"] --> API
        API --> SDK["OTel SDK
attributes, sampling,
processors, exporters"]
    end
    CFG["Platform-owned config:
env vars, shared config file,
base Docker image, internal library"] --> SDK
    SDK -->|OTLP push| COL["Collector agents / pipelines
(+ non-OTel components:
log forwarders, Kafka)"]
    SDK -->|Prometheus pull| COL
    COL --> PLAT["Single observability platform"]
    PLAT --> INS["Correlated insights:
traces to metrics via exemplars,
logs in trace context,
users affected via standard attributes"]
    MOD["Reusable modules:
Terraform, templates, scripts"] --> SLO["Team SLOs, burn-rate alerts,
common dashboards"]
    PLAT --> SLO

Where Does Your Platform Stop?

Gomez Blanco poses the question that reframes the rest of the talk: what is your platform, actually? Is it the infrastructure? The libraries that go with the infrastructure? The configuration that goes with the libraries?

Most teams he speaks to answer "infrastructure." For observability that means collector agents, the non-OpenTelemetry components you still run such as log forwarders and Kafka, the pipelines, and — if you host your own backend — the ingest and query APIs behind your dashboards and alerts. Then you stop. You provide the infrastructure and decline to tell people how to use it.

What you get is autonomy, and also inconsistency. His verdict is blunt: in the middle of an incident, the last thing you need is inconsistency. If you are the observability experts, you know how the platform should be used, and leaving that knowledge in documentation is a choice to have it ignored. The fix is to move the boundary so that the platform reaches into the application side.

OpenTelemetry makes this cheap, because SDK configuration is external: it can come from environment variables or config files, which means it can be delivered through a shared config file, a base Docker image, or an internal library. What that delivers is what Gomez Blanco calls minimal viable telemetry — the standard set of signals a service needs in order to be operable in production, present by default rather than by discipline.

The same logic applies one layer up, to how telemetry is consumed. Alerts, dashboards, and SLOs are things you want out of a service, and they have standards too. His examples: mandating a 28-day SLO window across the company, or moving everyone onto error-budget burn-rate alerting, which he calls the best way to alert on SLOs and also fiddly enough to configure that most teams will not do it correctly unaided. So you ship reusable modules — Terraform, templates, scripts — that make the standard the path of least resistance. A pre-baked Kubernetes pod-count alert is the same everywhere, so give it away. Common dashboards mean that during an incident nobody is looking at a private view of reality. And once distribution runs through modules and libraries, rolling out a change becomes a version bump.

(Background: a burn-rate alert fires on how fast a service is consuming its error budget, so a short severe outage and a long mild degradation both page appropriately, which threshold alerts on raw latency or error rate do not.)

His summary is a correction to a phrase he has watched fail repeatedly: it is less "if you build it, they will come" — he has built good infrastructure nobody used, and found it frustrating from both sides — and more build it into their toolkit so there is nowhere for engineers to go and nothing for them to adopt.

The Migration, and What Adoption Looked Like

Skyscanner had done this before, which is why they trusted it. OpenTracing used the same API-and-implementation decoupling and the same client design principles, and Skyscanner had already wrapped it in internal libraries. So the OpenTelemetry migration shipped as a minor version bump of those libraries. They ran with early adopters, declared GA, and then, in Gomez Blanco's account, had over 150 services on OpenTelemetry within weeks and more than 600 within a couple of months — largely as a side effect of teams doing routine dependency upgrades.

That number is the argument for the API/SDK split in a single data point: the migration was invisible because the API the application code touched did not change.

Tooling Is the Easy Part

Gomez Blanco hands over with a claim that his experience as a principal engineer has taught him tooling is the easiest part, and culture is the hard part — getting people to believe in the platform and use it in anger.

Bell's half begins in February 2023, when Skyscanner's CTO suggested he and the platform leader simply swap roles. Two days later they had, overnight; Bell went from leading product teams, product owners, designers, user research, and experimentation to running the platform. The first question put to him was Gomez Blanco's: how do we get mass adoption of this observability platform across 860-plus engineers?

The uncomfortable part, he says, was not the work but the proximity. His customers were now the people he passed in the corridor and got stuck in the lift with, each carrying immediate feedback on everything he was doing wrong.

Standards, Automation, Ownership — and Friction Anyway

Skyscanner had standards, automation, and clear ownership. Published production standards, a culture people genuinely lived. And the rollout still ground. The objections Bell relays, in the voice of the engineers raising them, were not unreasonable:

• Standards without a stated reason. "These standards that someone set, why? Tell me why." I have shipping to do for the traveller; I have zoned out.
• Automation that may not actually cover me. "If you make this change, will that automation test every single aspect that I don't need to worry about it?" If not, you have moved the risk, not removed it.
• "Are you saying that I don't own my stuff?" Ownership was a stated value. A platform arriving with instructions reads as ownership being taken back.

Why Mandating Fails

Bell's instinct — one he says is common in enterprise platform teams — was to mandate the change. Gomez Blanco talked him out of it by predicting exactly how it goes wrong, and the prediction is worth internalising.

First comes "this doesn't apply to me." Then teams comply on paper: they adopt the mandated system and keep the old one running. Bell is emphatic that this is not malice or laziness. The old system is the one they understand. At three in the morning, it tells them what they need to know. The new one is a new mental model in the worst possible conditions. Underneath that is a fear of losing autonomy — you are changing how I look after my own production systems — which nobody says out loud and everybody expresses behaviourally.

The next symptom is that people attack the tooling. Bell reads this as displacement: the real objection is to a shift in mindset about how and where telemetry is produced, but the tool is what they touch every day, so the tool takes the criticism. Then trust erodes, the rollout stops being credible, and you end up with fragmented adoption — which is precisely the messy multi-system diagram they showed at the start. The architecture problem and the culture problem turn out to be the same problem.

His reframe: all of this is feedback, and it is valuable feedback. Previous attempts at rolling out observability platforms had failed in exactly these ways, and the team could enumerate them.

What Culture Actually Is

Bell had close involvement with Skyscanner's culture interviewing, so this was familiar ground, and it made the difficulty more puzzling rather than less: he describes 1,600-plus people turning up every day genuinely living the company's values. His working definition is that culture is how we behave when we think nobody is watching. He follows it with a second formulation that the transcript garbles; the sense of it is that culture is the standards you hold when there is no applause for holding them. His illustration is the test you decide not to write on a quiet public holiday because the change will probably be fine. You cannot measure this with an engagement questionnaire.

He tested the diagnosis and it did not fit. Skyscanner's people were not letting standards slip. Production standards existed and were published. Nor was the missing ingredient Simon Sinek's "why" — Skyscanner already opened every strategy document with one.

The thing that did move was the framing of the platform itself. A platform is usually seen as a cost centre. Call it an investment and the conversation improves. Call it a product and the questions the platform team asks itself change: should we do user research on this change before we make it? Skyscanner's platform enables build, deploy, host, routing, and observability among much else. It is needed, it exists, and it has users. It is a product.

Empowering Engineers, Not Enforcing Standards

The flip Bell describes is from adopt our platform to we exist to empower engineers to build for travellers. He grounds it in the scale those engineers are operating at, as stated in the talk: 160 million travellers a month, 180 countries, 37 languages, over 100 billion searches (he says per day, and remarks that the number blows his mind), 94% of searches returned in under three seconds, well over 1,000 components deployed in the cloud, 22 petabytes of business data, and over 800 terabytes of observability data shipped per month.

Read that as the reason the objections were rational rather than obstructive. Product engineers already carry the load of not regressing any of it. The platform team was proposing to pull the rug out from under their monitoring while they did so.

So the pitch changed to what observability does for the traveller. Catching issues before they become incidents. SLAs, SLOs, and error budgets that mean something. Visibility from the top of the stack to the bottom. The question put to teams was whether that would help them in their day-to-day engineering — and the answer was yes, which it had not been when the question was whether they would adopt a new platform.

Three practices followed:

• Shared outcomes. The platform team now spends time with product owners asking what the gap is: what do you not know, what would you like to know, how can we help? When the answer is "I don't know, that's your job," they take it back to the team and work out how to identify the gap themselves.
• Defining good together. Standards are no longer written in isolation and circulated for nodding. Engineering teams co-author them. Bell's answer to how that scales across 860 people is to start with your largest customers.
• Measuring maturity, and celebrating failure. You need to know where you are. And failure is a learning event, which matters most while you are actively pushing change into the organisation.

The Platform Adoption Lifecycle

Bell maps the platform onto a product lifecycle that anyone from a product background will find familiar, and that he thinks platform teams implement poorly.

Bell calls the advocates stage the secret sauce, and the reason is precise: scaling a message across 860-plus people is impossible from the centre, but it works when the message leaves the room in each champion's own framing and reaches their team from inside it.

Show, Don't Tell

He then interviewed his own platform team for their learnings, and the one they gave him was: show that you care, get in the trenches with the end users, let them see it when it counts.

The opening sketch is the example. It really happened. Bell got the call, they got Gomez Blanco on it, and he debugged the website from the pixels down to the tin — in his phrasing, "from the pixels on the website down to the tin" — a chain that ended with Skyscanner on a call with one of the largest CPU manufacturers in the world and one of the largest cloud providers in the world, carrying enough data to say "you're causing an issue on the website." The engineering teams were watching that happen. The reaction Bell reports is not "the platform is good" but "you can see my server? Show me how you did that." That, he says, is where transformation starts. His generalisation: be present at incidents and game days — wherever your tool is closest to real pain.

Be Comfortable with the Uncomfortable

The second learning from his team initially confused him: he assumed it meant telling customers to get comfortable being uncomfortable. It meant the opposite. The platform team must be comfortable with uncertainty so that it can lead confidently. It is not the platform team's job to remove uncertainty — Skyscanner's 130 teams are the subject-matter experts in their own domains. What the platform team owes them is certainty about where the platform currently stands, while everyone learns together. Bell suggests this is a survival skill in the GenAI era, where the uncomfortable feeling is now attached to everything.

Measuring Maturity

High adoption is not the finish line, because standards and technology keep moving and every team sits at a different point. Skyscanner established three maturity levels so that the state of the estate is legible enough for a CTO to talk about publicly:

The design intent of the "non-negotiable" tier is worth noting: it converts a prioritisation argument into a non-event. The framing Bell was given was "why are we having this conversation? You need to move that back up."

Reported Outcomes

The results the speakers gave, in their words:

• Observability was rolled out across all of Skyscanner, with 90% of squads attending cross-team workshops for feedback and co-design. The squads that did not attend were the early adopters already in an advanced state, which Bell argues makes the effective figure 100%.
• A 20% reduction in repeat incidents. Bell stresses the word repeat: the prior pattern was the same incident recurring because investigations produced learnings without reaching the underlying cause. Better correlation shortened the path to that cause.
• A 40% reduction in duplicated effort across squads, which he characterises as toil, cognitive load, and complexity removed from an engineer's day.
• SLOs are now owned by product teams and tied to traveller outcomes, rather than being engineering-owned proxies like latency and memory usage. That also makes prioritisation inside those teams sharper.
• Over $1 million saved year on year from the work — a figure Bell raises in Q&A specifically as the language that lands with executives.
• The rollout pattern itself has been reused for other platform capabilities, and Bell reports they are getting faster at it each time.

Trade-offs And Limitations

The numbers are one company's reported experience, without baselines. The 20%, 40%, and $1M figures were stated as outcomes, not derived on stage, and no measurement methodology or counterfactual was given. Treat them as evidence that the approach worked at Skyscanner, not as an expected return.

"Single platform" is a real concentration trade-off the talk does not examine. OpenTelemetry decouples instrumentation from vendors, which genuinely lowers switching cost — but the North Star deliberately consolidates onto one backend to get correlation. Correlation quality and commercial leverage pull in opposite directions here, and the talk argues only the correlation side. It is also worth knowing that Gomez Blanco now works for an observability vendor; the OpenTelemetry material is standards-focused rather than product-focused, but the reader should hold the context.

Cost and volume control go unaddressed. Skyscanner ships over 800 terabytes of observability telemetry a month. Sampling strategy, retention, cardinality control, and ingest cost are the operational core of running observability at that volume, and none of it appears in the talk. If you adopt the "minimal viable telemetry by default" model, you are also adopting a default spend.

Moving the platform boundary into applications does reduce autonomy — that is the point. Gomez Blanco is explicit that leaving usage to teams yields inconsistency, and his answer is to bake configuration into base images and internal libraries. Bell's half of the talk is essentially the compensating control: if you take that ground without co-designing the standards and showing up during incidents, you get the mandate failure mode instead.

The library-distribution mechanism assumes preconditions many orgs lack. Skyscanner's near-frictionless migration worked because internal libraries already existed, teams already upgraded them routinely, and the previous abstraction (OpenTracing) shared OpenTelemetry's design principles. In a polyglot estate you need this per language, and in an estate that does not upgrade dependencies you have a different problem to solve first. Gomez Blanco's own answer to this objection, in his closing remarks, is that OpenTelemetry is now working to make much of what Skyscanner had to roll for itself easier for everyone — an effort in progress rather than a finished replacement for the plumbing Skyscanner built in 2020.

Continuous profiling was presented as imminent, not shipped. Do not plan around it as a current capability.

One figure appears to be misstated. Bell says "100 billion-plus searches per day" and lingers on the number. That is what the transcript records; readers should treat the scale as illustrative rather than citable.

Observability for data platforms is not solved by OpenTelemetry. Asked by an audience member moving from software engineering into data engineering why the pain of unobservable systems is felt so much less on the data side, Gomez Blanco was clear that data observability is a distinct domain and not currently OpenTelemetry's remit. He pointed to OpenLineage as a project applying the same API/SDK decoupling in that space, and argued the two worlds are converging: with GenAI and machine learning, drift in offline data affects the online system. Skyscanner uses ML to optimise search results, so a degradation there shows up as travellers finding the product less useful and eventually as an SLO regression. His view is that semantic conventions are the seam that will eventually let offline and online telemetry be joined, and that it is the right time to start on data observability using existing lineage and data-quality tooling — with regulatory traceability as an additional motivation.

Selling the Platform Upwards

The other substantial Q&A thread came from a former platform engineer asking how to bridge the gap between engineering and product or executives — the "democratic battle" of bottom-up culture change.

Bell's answer is to frame the platform as reusable capabilities and then translate that capability into each audience's language: the software framing for engineers, the technical outlook for the platform itself, and business outcomes and ROI for executives, since a platform is otherwise read as a cost centre. Get all three and you have the case covered from every angle. This is where the $1M year-on-year saving does its work: it is money that drops to the bottom line and can be reinvested elsewhere. His second point is that platform teams are frequently too modest to say so. The Skyscanner team had a genuine win and was quiet about it. Celebrate it — that is how platform work gets seen differently.

Gomez Blanco's addition inverts the usual posture. Go and ask product teams' engineering managers "how can I make your life easier?" For most of his career in platform it ran the other way: the platform team, in his image, coming down from the mountain with tablets of stone reading thou shalt respect these engineering standards.

Asked what comes next, Bell's answer is that the 2020 timing turned out to be fortunate — the foundation is what now lets Skyscanner extend into GenAI concerns such as model drift in LLMs, and to think about driving the full incident lifecycle on top of it. Gomez Blanco's answer for OpenTelemetry is stability: expanding the remit into browser, mobile, and GenAI while stabilising the semantic conventions and instrumentation so teams can adopt with confidence. The project is looking for contributors.

Practical Takeaways

• Stop describing your observability as three pillars. Audit whether you can get from a metric alert to a representative trace, and from that trace to the logs it produced, without copying a timestamp. If not, you have silos regardless of how much data you collect.
• Turn on exemplars. They are the cheapest available link between the aggregate you alert on and the individual request you need to look at.
• Instrument your business logic yourself. Auto-instrumentation covers the frameworks; nothing covers your domain.
• Adopt semantic conventions before inventing attribute names. Standard attributes are what let a backend generate insights, such as counting affected users, without bespoke configuration.
• Decide explicitly where your platform boundary sits. If it stops at infrastructure, you have chosen inconsistency; say so out loud and see whether the team still agrees.
• Ship configuration, not documentation. Base images, shared config files, and internal libraries deliver a default; wiki pages deliver an intention.
• Define your minimal viable telemetry and make it the default rather than a checklist item.
• Give away the fiddly things. Burn-rate alerts, standard SLO windows, and common Kubernetes alerts are identical across teams and hard enough to get right that most teams will not.
• Make rollout a version bump. If a change to your standard requires each team to edit code, it will land unevenly and slowly.
• Never mandate. Expect "this doesn't apply to me," dual-running of the old system, tooling blamed for a mindset change, and eroded trust.
• Build a champions community, and let them use their own words. Central messaging does not scale past a few hundred engineers; peer messaging does.
• Show up during incidents and game days. One visible debugging session that the teams could not have done themselves does more for adoption than a quarter of documentation.
• Ask product owners what they cannot see. "What's the gap? What don't you know?" is a better opening than presenting your standards.
• Publish a maturity model with a non-negotiable floor, so that fixing a regression stops being a prioritisation debate.
• Translate capabilities into ROI for executives, and then say the number out loud. Quiet platform teams get funded like cost centres.

Key Terms

• Observability signal — A category of telemetry: metrics, traces, logs, and soon profiles. The talk argues these should be correlated, not treated as independent "pillars."
• Exemplar — A trace identifier attached to an individual metric data point, letting you jump from an aggregate metric to example traces recorded on the replica that produced it.
• Semantic conventions — OpenTelemetry's standard names and meanings for attributes and metrics, which allow backends to interpret telemetry without per-customer configuration.
• Trace context — The identifiers propagated through a request so that spans and log records emitted anywhere in the call graph can be joined.
• Cross-cutting concern — A concern such as logging or telemetry that cannot be encapsulated behind a module boundary and therefore appears throughout a codebase, making its API expensive to change.
• OTel API vs SDK — The API is the stable surface application and library code compiles against; the SDK is the replaceable implementation that holds all configuration, processing, and export behaviour.
• Collector — A separately deployed OpenTelemetry component that receives, processes, and forwards telemetry over OTLP, decoupling applications from backends.
• Minimal viable telemetry — Gomez Blanco's term for the baseline signals a service must emit to be operable in production, supplied by the platform by default.
• Burn-rate alert — An alert on how fast an SLO's error budget is being consumed, which Gomez Blanco calls the best way to alert on SLOs. Skyscanner standardised on a 28-day SLO window.
• Continuous profiling — Ongoing sampling of application call stacks, coming to OpenTelemetry, allowing per-replica call-stack analysis of a served request.
• OpenTracing — OpenTelemetry's predecessor tracing standard, sharing the same API/implementation decoupling; Skyscanner's prior instrumentation layer.
• OpenLineage — An open standard for data lineage, cited as applying the same API/SDK decoupling in the data observability domain.
• Observability champions — Skyscanner's community of team-embedded advocates who carried the platform message into their own teams in their own words.

The speakers compress all of this into three closing lines. Bell's: your platform is your product, and engineers are your customers. Gomez Blanco's: open standards are the way to give those customers a stable API layer to build on, and — the lesson he says surprised him most as a principal engineer — culture is what actually drives adoption, trust, and ultimately the impact of a platform, which means getting out of the engineering box and talking to product and to the rest of the company.

The through-line is that both halves of the talk describe the same move. Gomez Blanco removes the seam between signals so that engineers stop debugging their own service in isolation. Bell removes the seam between the platform team and its users so that the platform stops being something imposed from outside. In both cases the fix is context: telemetry that carries enough shared context to be joined, and a platform team that carries enough of its customers' context to be believed.

Reference: Dan Gomez Blanco and Wayne Bell, Building a Future-Proof Observability Platform to Empower Engineers, InfoQ Dev Summit Munich 2025, published by InfoQ on April 27, 2026.