How a Culture of Data-Driven Conversations Can Support Platform Engineering

Ben Linders · rss · 2026-06-04 Reader 🖥️

Cognitive Load Data Sovereignty DORA & Engineering Metrics Platform Engineering SRE & Incident Response Team Topologies

To survive growing cognitive load and operate as a multi-platform team without scaling headcount, a platform org should run SRE as a service through a center of excellence, embed Federated SREs and new bridging roles (production manager, technical tribe lead) into business units, and make SLOs/SLAs a shared organisational currency so that operational ownership is pushed down into product teams rather than centralised in the platform.

practical · expository — Conference-talk write-up (Sergiu Petean at InfoQ Dev Summit Munich 2025) plus a brief InfoQ Q&A. Reports prescriptions for evolving an internal SRE/platform capability at an insurance company. Mostly testimony-as-evidence: 'we did X, X worked, therefore consider X.' Not an argument with premises so much as a sequence of organisational moves presented as a model.

Structure

Part	Role
Opening framing: SRE-as-a-service via a center of excellence, Federated SREs, production manager, technical tribe lead — culture of 'data-driven conversations' where SLOs/SLAs are democratised	Thesis statement / unity
Petean's separate InfoQ piece referenced: platform engineering is socio-technical, shaped by all stakeholders, governed by written principles	External legitimation / context
The 'easy vs hard' contrast: defining the SRE process and tools was easy; getting stakeholder exchange was hard — hence the center-of-excellence framing	Motivating diagnosis
Dual measurement: DORA metrics operationally, cost per change financially	Governance/legitimation layer
The three roles: Federated SRE (20% from each squad), production manager (owns incident process), technical tribe lead (sits next to business decision-maker)	Central organisational mechanism — the named contribution
Authority + evangelism framing: new roles must be empowered to tell engineers what matters for business and operations	Implementation caveat / political requirement
Multi-platform scaling story: same team, more platforms, cognitive load 'reached new heights' — therefore continuous simplification	Pressure narrative + corollary prescription
'Destroyed and rebuilt our architecture at least four times' — using any change opportunity as licence to redesign	Vivid anecdote / heuristic
Sovereignty + resilience as design constants — and Q&A elaboration on cost-per-change drivers and political actions for sovereignty	Strategic horizon + Q&A elaboration

Key terms

Federated SRE
An internal community of software engineers (not a separate SRE team) who spend 20% of their time on operational work — vulnerabilities, SRE practice, SLA stewardship, CI/CD extension, APIs — inside their own squad. They are the platform team's 'emissaries' to the business.
Production manager
A technical role that centralises and owns the full incident-management process: reporting, reacting, improving, SLA stewardship. One throat-to-choke for incidents across the org.
Technical tribe lead
A technical person seated next to the business decision-maker inside a Spotify-style tribe — there to translate technical reality into business decisions and vice versa.
Center of excellence Platform Engineering
The platform team's re-framing of itself: not the team that runs operations, but the team that educates the organisation on how to automate its operational needs into the process and close its own feedback loops.
Democratised SLOs/SLAs
Making service-level objectives and agreements a shared vocabulary across the org — visible to and owned by business squads, not the private property of an SRE team. Used to anchor 'data-driven conversations' about cost, security, performance, compliance.
Cost per change DORA & Engineering Metrics
Financial metric used alongside DORA — how much it costs the organisation to ship one change. Petean reports it going down because of platform effect, expertise maturity, federation, and business scaling.
Sovereignty (digital / innovation) Data Sovereignty
Innovation sovereignty = the capacity to create, via internal talent and culture rather than treating IT as a cost centre. Digital sovereignty = the ability to move from a hyperscaler to a private cloud or data centre at known speed and cost.
Multi-platform team Platform Engineering
The same platform team, of roughly the same size, running several platforms (because a new AI cloud-native reference architecture got added). Marker for unrelieved cognitive load on the platform org.
Continuous simplification
Treating any organisational change (new tenant, new business line, cloud migration) as licence to rebuild the architecture — Petean's team did so four times. The platform team's survival heuristic under multi-platform load.

Propositions

explicitAn internal SRE capability should be delivered as a service through a center of excellence rather than as a centralised ops team.conf: high
explicitFederated SREs embedded in business squads — at a mandated 20% time investment — outperform a separate central SRE team for sustaining platform-quality outcomes at scale.conf: high
explicitIncident-management quality requires a single technical owner (production manager) of the full reporting/reacting/improving/SLAs loop.conf: high
explicitA technical role co-located with business decision-makers (technical tribe lead) is necessary to keep platform/business decisions aligned.conf: high
explicitMaking SLOs/SLAs visible and owned across the organisation ('democratising' them) is what turns federated roles from headcount into a culture-change mechanism.conf: high
explicitPlatform impact must be measured along both operational (DORA) and financial (cost-per-change) axes.conf: high
explicitWhen a platform team cannot grow with its scope, continuous architectural simplification — including periodic full rebuilds — is the only survival strategy.conf: high
explicitcorroboratedDigital sovereignty (the cost and speed of moving off a hyperscaler) must be a first-class design constraint of every platform decision.conf: high
extends ←AI Sovereignty: Bargaining with Big Tech and the Promise of Full Stack Open Source AI · p5 — Extends the abstract claim that digital sovereignty 'must be a first-class design constraint' with a concrete, layer-by-layer inventory of what open-source sovereignty actually requires (harnesses, inference, protocols, storage, observability).
supports ←Azure Virtual Desktop Hybrid Reaches GA with Licensing Details Unpublished · p12 — Both treat data sovereignty / residency as a first-class constraint shaping concrete platform and deployment architecture decisions, not an afterthought bolted on later.
explicitThe new bridging roles only work if they are explicitly given authority to override engineers on what matters for business and operations.conf: high
implicitThe organisation is already shaped as Spotify-model tribes/squads with a platform team adjacent to them — federation is laid onto this topology, not designed in tension with it.conf: high
implicitBusiness squads have the slack to absorb a mandatory 20% operational tithe without renegotiating their delivery commitments.conf: high
implicitThe cost of three new role layers (Federated SREs, production manager, technical tribe lead) is lower than the cost of cognitive overload on a single platform team.conf: high
implicitSenior engineers are willing and available to play bridging/evangelism roles rather than building product — and the labour market supplies them.conf: medium
implicitCost per change went down because of platform effect, not because the change-mix got easier — Goodhart's law is bracketed.conf: medium
implicitRepeatedly destroying and rebuilding the architecture (four times) did not impose a hidden cost on the business squads consuming it.conf: high
implicitBoard-level technical leadership is a precondition for the whole programme, not an outcome of it.conf: medium

Arguments

Operational ownership should be pushed into product squads via Federated SREs rather than concentrated in a central SRE team. strength: medium

Explicit premises:

Defining the SRE process and tools was easy; the hard part was making stakeholders consume them.
Federated SREs are emissaries who 'better look after the business needs like costs, security, performance and compliance.'
Mandating 20% of each squad's time creates a business case the federation can defend.

Implicit premises:

Squads have the slack and skill to absorb 20% operational work without breaking feature delivery.
Engineers embedded in product squads will represent platform/operational concerns faithfully rather than capitulate to local feature pressure.
The platform team retains enough authority over the federation to keep practices consistent across squads — i.e. federation does not fragment into squad-local variants.

Inferences:

Therefore a separate SRE team becomes an anti-pattern at this org size, not just an optional alternative.
Therefore the platform team's job shifts from operating to enabling — which has implications for the headcount mix (fewer operators, more enablers) the article does not draw.
Therefore squad-level OKRs need to be rewritten to allocate the 20% explicitly, or the mandate becomes overtime by another name.

A 'culture of data-driven conversations' where SLOs/SLAs are democratised is the mechanism that makes federation work. strength: low

Explicit premises:

Federated SREs were 'empowered to better look after business needs' because SLOs/SLAs were a shared vocabulary.
Without shared metrics there is no basis for the cross-tribe conversations the federation depends on.

Implicit premises:

Business decision-makers have the operational literacy to read and act on SLOs/SLAs — or the technical tribe lead reliably translates for them.
SLOs/SLAs can be designed so that democratisation does not collapse into negotiation (squads bargaining down their SLOs).
Cultural change of this scope is a side-effect of structural change (new roles + metrics), not a separate intervention.

Inferences:

Therefore observability investment must precede federation — you cannot democratise what is not measurable.
Therefore the production manager's authority over the incident loop is what keeps democratised SLOs from being toothless.

Continuous architectural simplification — including periodic full rebuilds — is necessary when a platform team cannot scale headcount. strength: medium

Explicit premises:

The same team had to take care of several platforms while staying roughly the same size.
Cognitive load reached new heights.
Seizing any change opportunity (new tenant, new line of business, cloud migration) gives licence to redesign things that normally never change.

Implicit premises:

Four architectural rebuilds did not destroy backward compatibility or consumer trust — or, if they did, the cost was absorbed elsewhere.
The platform team had decision-rights to rebuild without going through external change-approval boards.
Simplification reliably reduces cognitive load (rather than just shifting it onto the rebuild itself).

Inferences:

Therefore evolutionary architecture and platform engineering are coupled — you cannot do platform-as-a-service without continuous redesign authority.
Therefore stability commitments to consumers must be at the brick/contract level, not the architecture level.

Cost per change went down because of structural choices (platform effect + federation + maturity + scaling). strength: low

Explicit premises:

Platform effect: more services/tenants with no extra cost.
Expertise maturity: more senior engineers with holistic view.
Federated SRE: self-service from day one.
Massive business scaling: more customers, more markets.

Implicit premises:

The cost-per-change denominator (number of changes) was comparable across periods — i.e. changes did not get smaller on average, which would deflate cost-per-change without any structural improvement.
Business scaling drives down cost-per-change rather than just amortising fixed costs — i.e. it's a real efficiency gain, not a measurement artefact.
Goodhart's law did not bite — squads did not start gaming change-size to optimise the metric.

Inferences:

Therefore cost-per-change is a defensible C-level metric for platform investment — but only when reported alongside change-mix data.
Therefore the cost-down story is at least partly endogenous to business growth, which makes it hard to use as a template for orgs not growing.

Narratives

The 'easy vs hard' moment: defining the SRE process and tools was easy, but getting an exchange with the stakeholders consuming them was hard — which is why the team had to become a center of excellence and educate the org.
→ Origin story for the whole federation move. Implicitly argues that platform engineering's hard part is sociotechnical, not technical — which legitimises the role-heavy solution.
The four-rebuilds anecdote: 'We destroyed and rebuilt our architecture at least four times. We seized any change opportunity... It worked perfectly for us.'
→ Vivid evidence-by-example for continuous simplification; also a quiet brag about the team's decision-rights and skill. Does the persuasive work that an argument would otherwise have to do.
The cost-per-change decline story in the Q&A — four causes listed, none weighted.
→ Supplies the financial legitimation for the whole programme. Implicit claim: 'this paid for itself.' The 'massive business scaling' factor is the elephant in the list.

Questions addressed

✅ How should an internal SRE capability evolve as the org grows beyond what a central SRE team can absorb?
Become a center of excellence; federate operational work into squads at 20%; install a production manager and technical tribe lead to bridge.
✅ How should platform impact be measured and justified to leadership?
DORA metrics operationally, cost-per-change financially.
✅ How does a platform team survive scope growth without headcount growth?
Continuous simplification; rebuild architecture at any change opportunity.
⭕ How is the 20% operational tithe actually funded inside business squads — what gets dropped, who decides, how is it tracked?
Not addressed.
⭕ What is the actual mechanism by which 'democratising SLOs/SLAs' changes day-to-day decisions, and how is regression prevented (squads negotiating their SLOs down)?
Asserted as cultural outcome of federation, never decomposed.
⭕ What does the org look like in which this works — and what's the cost of getting there?
The Spotify-style tribe/squad topology is treated as given; the cost of redesigning to it is invisible.
⭕ What happens when a Federated SRE's loyalties conflict (squad delivery deadline vs platform SLO commitment)?
Not addressed; the 'emissary' framing assumes the conflict resolves in the platform's favour.
⭕ Does cost-per-change actually measure platform efficiency, or does business scaling do most of the work?
Both causes listed in the same bullet list with no weighting.
⭕ How does sovereignty connect to the federation/SRE story, or is it a separate horizon?
Bolted on at the end; the article does not show how the role/metric apparatus supports the sovereignty design constraint.

Gaps

incompleteSame gap as the Golden Bricks extract, in a different colour. The whole programme assumes a Team-Topologies / Spotify-style organisation already exists — stream-aligned squads inside tribes, a platform team adjacent to them, business decision-makers sitting at tribe level. The Federated SRE, production manager, and technical tribe lead are role inventions overlaid on this topology, not designed to produce it. The article describes role responsibilities mechanically but treats the underlying org redesign — the part that costs years and political capital in most enterprises — as already done. For a reader whose org is functionally shaped, this is the part that matters most, and it is invisible.
Read next: Skelton & Pais, Team Topologies (esp. the 'enabling team' interaction mode, which is what Federated SREs functionally are). Cutler on operating-model design and accountability layering. Pais on cognitive-load assessment as a precondition for federation. Reinertsen on capacity allocation and queueing — the 20% tithe is a capacity-allocation decision that needs queue-theoretic defence.
incompleteThe 'democratisation' mechanism is never opened up. The article uses 'democratised SLOs/SLAs' as the load-bearing cultural claim but never explains how democratisation happens — who publishes the SLOs, in what tool, who is allowed to negotiate them, what stops squads from quietly setting easy SLOs to escape scrutiny, what the production manager does when a squad's SLO drifts. Without this, 'data-driven conversations' is a slogan with no enforcement surface. The mechanical specification matters: democratisation without governance is just SLO theatre.
Read next: Google SRE Workbook on error budgets and SLO policy (the governance scaffolding democratisation usually rides on). Honeycomb / Charity Majors on observability ownership. Forsgren et al. on metrics that resist Goodhart pressure.
incompleteThe 20% mandatory squad investment is presented as a structural lever, but the article never says how it is funded. 20% of every squad is a large standing tax on feature delivery; in most orgs this is the single most contested resource decision a CTO can make. The article gives no defence of the figure (why 20% and not 10% or 30%), no description of how it shows up in planning (is it a fifth person, a fifth of everyone's week, a rotation?), no answer to what gets dropped when the rest of the squad's commitments don't shrink. This is the place where the prescription would either hold or shatter in practice.
Read next: Reinertsen, The Principles of Product Development Flow, on capacity allocation under variability. Allen Holub on the politics of capacity-as-budget. Cutler on the operating-system level of organisational design.
incompleteThe four-rebuilds story is reported as triumph but never costed. Destroying and rebuilding the platform architecture four times has a cost — for the consuming squads who must re-learn it, for the regulators who must re-approve it, for the institutional memory that bleeds out at each rebuild. The article reports the platform team's experience ('it worked perfectly for us') without checking the consumer side. The same testimony from the squads might read very differently.
Read next: Ford, Parsons & Kua on evolutionary architecture (the disciplined version of what Petean is describing). Hohpe on architecture decision records and the institutional cost of irreversibility. Naur on programming-as-theory-building — what gets destroyed in a rebuild that isn't in the code.
incompleteSovereignty is bolted on, not integrated. The piece spends most of its length on federation, roles, and metrics, then in the last beats pivots to digital sovereignty as a 'must-have' design constraint. There is no analysis of how the role/metric apparatus supports sovereignty — does the production manager track hyperscaler-exit readiness as an SLO? Do Federated SREs price each architecture decision against move-off cost? Without this connection the sovereignty section reads like a separate talk, and the unified 'culture of data-driven conversations' frame doesn't reach that far.
Read next: EU NIS2 / DORA (financial regulation) on operational resilience requirements. Gregor Hohpe on multi-cloud strategy and exit costs. Honeycomb / CNCF material on platform portability.
closed byAI Sovereignty: Bargaining with Big Tech and the Promise of Full Stack Open Source AI — That gap flagged sovereignty as 'bolted on, not integrated' — mentioned as a must-have without elaboration. This piece supplies exactly that missing integration: a full-stack breakdown of which open-source layers sovereignty actually depends on, and where the gaps in that stack currently sit.
incompleteCost-per-change is offered as the financial counterpart to DORA but is not interrogated. Of the four reasons given for the decline (platform effect, expertise maturity, federation, massive business scaling), the fourth alone could explain the result via simple denominator inflation. Without weighting or counterfactual ('cost per change held flat through a comparable scaling period before federation'), the metric is decorative. This matters because cost-per-change is the kind of number that gets quoted as proof of platform ROI without the caveats travelling with it.
Read next: FinOps Foundation material on attribution and unit economics. Cutler on signal-vs-noise in metrics. The DORA / SPACE original papers on the limits of self-reported organisational improvement.
uninformedNo engagement with the existing literature on embedded/federated SRE. Google's SRE Book has a chapter on the embedded-SRE model; the CNCF Platforms WG has written on platform-team interaction modes; Team Topologies' 'enabling team' is functionally close to the Federated SRE role described here. The article presents the three-role pattern as if it were freshly invented, which makes it harder to compare against the failure modes the prior literature documents (embedded SREs going native to squads, central guidance eroding, federation creating shadow operators).
Read next: Beyer, Jones, Petoff, Murphy (eds.), Site Reliability Engineering, esp. the embedded-SRE chapter. CNCF Platforms WG whitepapers on team topologies for platforms. Skelton & Pais, Team Topologies, on the enabling-team interaction mode.

How a Culture of Data-Driven Conversations Can Support Platform Engineering

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents