Presentation: Platform Engineering for Everyone - Success Can’t Be Coded

Max Körbächer · rss · 2026-07-20 Reader 🖥️

practical · mixed — A conference-talk transcript. Mostly argumentative (building the case that infrastructure-first thinking is the root cause of platform failure and product mindset is the fix), interleaved with expository framework definitions (iron triangle, principles, SPACE/DevEx) and narrative anecdotes (Backstage-portal failure, demand-management origin story, Telco shadow-IT drop) used as evidence in place of data.

Structure

Key terms

• Infrastructure-first thinking
  Designing a platform from the technology/architecture layer upward instead of from the user's need downward — the root failure mode, attributed to platform engineers' typical DevOps/infrastructure origin.
• Randomeering
  Adding a tool to the platform because the engineer personally liked it (e.g. saw it at a conference), without validating need — a subtype of over-engineering.
• Product mindset (vs. project)
  Treating the platform as an ongoing offering with a purpose, customers, and voluntary adoption, rather than a time-boxed deliverable with a deadline.
• Iron triangle (feasibility / desirability / viability)
  A reframing of the classic scope/time/cost iron triangle: can you build it right (feasibility), do people want it (desirability), does it make business sense (viability) — with the claim that only two of three can be fulfilled well at a given resource level, and that pulling toward one flattens another (a metal band, not a rubber band).
• 'We will' / 'you must' principles
  Two registers of guiding principle: 'we will' statements build collective ownership and unity ('we will drive transparency'); 'you must' statements are directive guidance for non-negotiables. A directive stated as an absolute command ('you have to do X, Y, Z') is not a principle at all.
• Drivers (strategic / personal / market / analyst)
  Four sources of pressure on platform decisions besides technical merit: strategic (management/partnership mandate), personal (individual ethical/moral resistance), market (licensing changes, sovereignty), analyst/report (paid inclusion in industry reports).
• Platform Engineering Purpose Canvas
  A workshop tool (free on Miro, from the speaker's book) that maps roles, targets, values, principles, KPIs, stakeholders and strengths to converge on an explicit platform purpose — distinct from a vision or mission, and revisable over time.
• SPACE metrics
  Satisfaction, Performance, Activity, Communication, Efficiency — preferred over DORA because they can be scoped per person/team/system and better contextualize raw numbers (e.g. code volume vs. review time), at the cost of more setup effort.
• Cognitive load (meeting/context-switch framing) Cognitive Load
  The disruptive residue of interruptions and context switches: a ~5-minute disruption can occupy the brain for up to an hour, and mood/topic carries over between unrelated back-to-back meetings.

Propositions

• explicitPlatform projects fail primarily for organizational reasons — undefined purpose, unmet management expectations, poor adoption, and unaddressed team needs — not primarily for technical reasons.conf: high
• explicitInfrastructure-first thinking — designing from the technology upward instead of from the user's need downward — is the single biggest cause of platform failure, and it persists because most platform engineers come from an infrastructure/cloud/DevOps background.conf: high
• explicitdevelopedA platform must be adopted voluntarily, as a desired product, rather than imposed by mandate; forced or 'thrown at your head' adoption produces resistance rather than uptake.conf: high
  supportsAchieving Compliance as a Platform Engineering Team by Helping Developers · p2 — Both talks independently converge on the same causal claim from different domains — forced/patronizing platform or governance adoption fails, alignment around shared purpose succeeds.
  supportsHow Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p5 — Körbächer generalizes the same voluntary-adoption-as-signal claim beyond developers to security, compliance, and business stakeholders.
  supportsThree Pillars of Platform Engineering: A Virtuous Cycle · p10 — Both identify trust-earned voluntary adoption, rather than mandate, as the load-bearing mechanism of platform success.
  extends ←Presentation: Platform Engineering in the Age of AI · p10 — Supplies a causal mechanism (AI-driven expertise leveling between platform engineers and developers) for why voluntary, collaborative platform adoption becomes more necessary, not just nicer, in the AI era.
• explicitA platform's real customer base extends beyond developers to security personnel, compliance officers, product owners, and business stakeholders (e.g., VPs consuming usage reports).conf: high
• explicitcorroboratedPlatform delivery is bounded by an iron triangle of feasibility, desirability, and viability; an organization can typically fulfill only two of the three well at a given level of budget, time, and people.conf: high
  supports ←Dare to Be Bad at Something (From Fixable) · p1 — Fixable's 'impossible triangle' (cost/quality/speed, pick two) generalizes the same pick-two logic Korbacher applies specifically to platform delivery's feasibility/desirability/viability triangle.
• explicitTeam decision-making should be governed by a mix of collectively-owned 'we will' principles and non-negotiable 'you must' principles, rather than ad hoc subjective calls from whoever is most senior or present.conf: high
• explicitcorroboratedPlatform decisions are shaped by four distinct driver categories — strategic (management/partnership mandate), personal (individual ethical or moral resistance), market (licensing changes, sovereignty pressure), and analyst/report (paid-for inclusion in industry reports) — each capable of overriding technical merit.conf: high
  supports ←Azure Virtual Desktop Hybrid Reaches GA with Licensing Details Unpublished · p7 — Korbacher's claim names licensing changes as one of the market-driver categories shaping platform decisions; the RDS CAL Software Assurance requirement functions as exactly that kind of licensing-driven constraint steering (or blocking) a concrete platform adoption decision here.
• explicitA platform needs an explicit, discussed purpose — for which reason, for which user — captured in a tool like the Platform Engineering Purpose Canvas, and this purpose is distinct from a vision or mission statement.conf: high
• explicitPlatform success cannot be validly measured unless baseline measurement begins before the platform exists; measuring only after launch removes the comparison point needed to demonstrate improvement.conf: high
• explicitcorroboratedDORA metrics are a double-edged measurement tool: informative for raising awareness of team performance, but easily turned into a pressure weapon by managers who don't understand the trade-offs between deploy speed, feature volume, and failure rate.conf: high
  refinesHow Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · p15 — Körbächer's claim that DORA 'in wrong hands... is a weapon' and stresses teams adds a governance caveat that golden-bricks' unqualified endorsement of the DORA/SPACE/DX-Core-4 stack as a 'sufficient evaluation apparatus' omits.
  supports ←DORA Community Discussion - DX Core 4 · p13 — Both warn that individual-level output metrics (DORA-style or diff-count) become a pressure weapon / Goodhart target unless scoped to team level.
• explicitcorroboratedSPACE metrics fit platform/team evaluation better than DORA because they can be scoped per person, team, or system and better contextualize raw output numbers (e.g. code volume against review time), at the cost of more setup and maintenance effort.conf: high
  supports ←DORA Community Discussion - DX Core 4 · p5 — Both argue SPACE/developer-experience measurement fills a gap DORA alone leaves open.
• explicitcorroboratedThe most valuable measurement layer is DevEx: flow-state signals (reopened commits, change requests, commits per pull request) combined with continuous, open-ended personal feedback — because two correlated-looking numbers can be coincidental, and only direct conversation reveals real user experience.conf: high
  supports ←Presentation: Platform Engineering in the Age of AI · p29 — Independent corroboration that qualitative, trust-gated developer feedback outranks quantitative proxies as the real measurement layer for platform success.
  extends ←Guide to scaling engineering organizations · p13 — Stripe's 2018 Developer Experience survey program (quarterly surveys surfacing the edit-sync-test loop as the top-leverage fix) is a direct, earlier instance of exactly the DevEx-as-measurement-layer practice the later platform-engineering piece recommends generalizing with flow-state signals -- this document supplies a concrete before/after case (50-80% satisfaction improvement) for that general claim.
• explicitdevelopedCognitive load compounds nonlinearly and outlasts its trigger: a roughly five-minute disruption can occupy the brain for up to an hour afterward, and unrelated back-to-back meetings carry emotional residue into the next context.conf: high
  extends ←DORA Community Discussion - DX Core 4 · p11 — Korbacher states cognitive load compounds nonlinearly after disruption; this talk supplies the underlying neuroscience mechanism (glutamate signaling from context switches).
• explicitFeedback loops must be continuous and specific rather than an annual company-wide survey, because individual sentiment about tools fluctuates day to day and a single yes/no snapshot produces near-worthless data.conf: high
• explicitTechnical debt should be retired against explicit, pre-defined depreciation criteria (established with the same discipline as the platform's purpose), because otherwise sunk-cost reasoning keeps failing tools in production indefinitely.conf: high
• explicitA measurable decline in shadow IT (unauthorized tools, personally-expensed cloud services) is reliable evidence that a platform is meeting real, previously unmet demand.conf: high
• explicitLong-term platform success depends on building a self-sustaining community that invites external contribution (InnerSource or open source), because inviting contribution correlates with higher adoption and satisfaction.conf: high
• explicitDeliberately using Conway's Law — building the ideal platform workflow and then changing the organization's processes to follow it, rather than accepting existing process as fixed — is one of the most effective, though slow, levers for platform adoption.conf: high
• implicitOvercoming infrastructure-first thinking is a disposition/identity problem rather than a skills gap — asking users what they want is framed as literally 'not my nature,' implying the fix is deliberate role practice (e.g. a demand-management rotation) rather than hiring smarter infrastructure engineers.conf: medium
• implicit'Randomeering' implies that engineers' professional status-seeking, not incompetence, is a structural cause of platform bloat — meaning the fix is a principle/process gate on what enters the platform, not simply better individual engineers.conf: medium
• implicitThe claim that companies 'cannot do any consequences' for non-adoption implies that in the current high-skill labor market, coercive management levers are functionally unavailable to platform teams — making voluntary, product-style adoption not merely nicer but the only mechanism that can actually work.conf: medium
• implicitFraming wasted platform spend as money unavailable for 'more cooler things' implies platform economics should be understood as a zero-sum competition for discretionary engineering investment inside the org, not as an isolated infrastructure line item.conf: medium
• implicitRecommending that depreciation criteria be defined 'the same way' as purpose implies technical-debt retirement is fundamentally a political/legitimacy exercise — managing stakeholders emotionally invested in a sunk investment — rather than a technical assessment.conf: high
• implicitInsisting a platform's 'customers' include security, compliance, and business stakeholders — not only developers — implies developer-experience framing, common shorthand elsewhere in the field, is too narrow a lens for defining what makes a platform succeed.conf: medium

Arguments

Narratives

• Organizations buy a shiny developer portal (e.g. Backstage) first because 'Spotify does it,' deploy it, find it empty, spend five engineers and months configuring extensions, and still fail to feel the expected value.
  → Concrete instantiation of infrastructure-first / tool-before-purpose failure; frames the portal-before-platform pattern as the paradigmatic mistake the whole talk warns against.
• The speaker's own 1.5 years working in demand management after his studies, forced to interview users, write requirements, and challenge what people 'really' wanted — described as personally painful and against his nature as an infrastructure person.
  → Authenticates the claim that product/user-research thinking is learned, not innate, for people with an infrastructure background; grounds the abstract 'infrastructure-first thinking' diagnosis in first-person testimony.
• A large Telco customer's external IT service expenses dropped drastically shortly after the platform began solving even one or two identified problems, before it was finished.
  → Evidence that platforms suppress shadow IT and that partial, early value delivery matters more than completeness — supports the 'thinnest viable platform' and shadow-IT-as-metric claims.
• Toyota tracks how many people use platform-provided documentation and finds nearly everyone in IT uses it, because it consolidated hundreds of previously scattered sources (repositories, websites, intranet pages) into one place.
  → Supplies a concrete example of an active-usage adoption metric and illustrates why consolidation itself can be the value delivered.

Questions addressed

• ✅ Why do platform engineering projects fail?
  Lack of purpose, infrastructure-first thinking, over-engineering ('randomeering'), unmet user needs, and unmanaged technical debt.
• ✅ How should a platform be measured?
  Adoption/experience/outcome-style layered measurement — SPACE and continuous DevEx feedback preferred over DORA, plus shadow-IT tracking and time-to-market, started before the platform is built.
• ✅ How do you decide what belongs on the platform and resist scope creep?
  Via explicit principles ('we will'/'you must') and by naming the driver category (strategic, personal, market, analyst) behind any given push.
• ✅ How do you retire a failing platform investment despite sunk cost?
  Define depreciation criteria in advance, with the same discipline used to define purpose, and frame the retirement in terms stakeholders can accept rather than as an admission of waste.
• ⭕ The talk claims purpose 'can change' — who has the authority to change it, what triggers a re-evaluation, and how is a changed purpose re-legitimized with stakeholders who bought into the original one?
  Not addressed; purpose revision is asserted as possible but no governance mechanism is described.
• ⭕ When the four driver categories conflict — e.g. a strategic/partnership mandate collides with a team member's personal/ethical objection — how is the conflict actually resolved?
  The talk narrates exactly this scenario (a security expert refusing to include a tool for political reasons) but does not say how it was resolved.

Gaps

• uninformedThe entire talk is grounded in the speaker's own consultancy experience and anecdote ('one larger Telco customer,' 'in my experience') with no named case studies, published data, or citations — including the claim that 'the latest studies' show AI projects 'failing more than being successful,' which names no study at all. The specific cognitive-load figure in p13 ('for every 5 minutes you are disrupted, you can add up to one hour where your brain is still processing') is likewise unsourced and reads like a garbled version of task-resumption/interruption-recovery research (commonly cited figures are on the order of ~20+ minutes to fully re-engage after an interruption, e.g. Gloria Mark's work) — the specific 5-minutes-to-1-hour ratio should not be repeated without checking the original source.
  Read next: Cross-check against corpus documents and any published platform-engineering surveys (DORA's own reports, PlatformCon state-of-platform-engineering surveys) that DO publish quantitative adoption/failure data, the way extract-compliance-platform-engineering-team#g1 already flags the identical evidentiary gap for a closely related InfoQ talk.
• misinformedThe speaker explains the sunk-cost fallacy as caused by German accounting/tax rules requiring an asset to be 'used until you get all your taxes back,' calling it 'such a German thing.' This mischaracterizes sunk-cost bias, which is a well-documented, cross-culturally observed cognitive/loss-aversion bias (not primarily a tax-driven behavior), and it overstates depreciation-schedule mechanics as a legal usage requirement — accounting depreciation is a bookkeeping convention, not a mandate to keep operating an asset.
  Read next: Read the original behavioral-economics literature on sunk cost (Arkes & Blumer, "The psychology of sunk cost," 1985; Thaler on mental accounting) to see the bias documented as a general cognitive pattern, not a Germany-specific tax artifact — useful before repeating this explanation to others when advocating for depreciation criteria.
• incompleteThe talk asserts platform purpose 'can change' but never describes who has authority to change it, what triggers a re-evaluation, or how a changed purpose is communicated and re-legitimized to the stakeholders who bought into the original one — a real gap given the talk's own claim that platform failure often stems from purpose never having been (re)negotiated in the first place.
  Read next: Corpus material on strategy-and-direction (compressed, personally-believed narratives) and on organizational governance of changing strategic commitments without losing team trust.
• incompleteThe four driver categories (strategic, personal, market, analyst) are presented as a taxonomy but never resolved when they conflict — the talk narrates the exact scenario of a strategic/partnership-mandated tool colliding with a team member's moral objection ('I don't support the political orientation of where this company is located') without saying how the conflict was actually adjudicated.
  Read next: Corpus material on informal leadership and leader restraint for how leaders adjudicate genuine value conflicts within a team without either overriding the objector or letting one person veto a strategic commitment.
• illogicalThe talk argues both that mandates and enforcement don't work ('companies cannot do any consequences... it's very worthless that someone scream at you') and that strategic/partnership drivers routinely force teams to adopt tools they don't want ('you have the partnership... so use it... but you have to use it'). These are in tension: if genuine enforcement is unavailable, it is unclear how strategic mandates actually secure compliance where product-style persuasion is said to fail, or why they would prove more durable than the mandate-driven approaches the talk elsewhere says never work.
  Read next: Look for the speaker's book (Platform Engineering for Architects) or a follow-up talk addressing how forced/partnership-driven tool adoption is actually operationalized when direct managerial coercion is explicitly described as ineffective.

Closes gaps elsewhere

• How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery · g5 — Golden-bricks' Adoption/Experience/Outcomes scheme is flagged as measuring 'existence, not direction' — no mechanism for guiding which brick to build next. Körbächer supplies exactly that mechanism: continuous, open-ended user interviews plus SPACE/DevEx signals feed directly into deciding what feature to build next ('start with the thinnest viable platform... go step-by-step with the new features') and when to retire a brick (explicit depreciation criteria), turning the same three-layer measurement scheme into a design-direction input rather than only a C-level justification.

Related documents

• AI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action
  Developer Experience & Flow DORA & Engineering Metrics Platform Engineering Sociotechnical Architecture
• DORA Community Discussion - DX Core 4
  Cognitive Load Developer Experience & Flow DORA & Engineering Metrics Platform Engineering
• How to measure AI developer productivity in 2025 | Nicole Forsgren
  Cognitive Load Developer Experience & Flow DORA & Engineering Metrics Trust
• How Open Source Enables Collaboration in Creating a Platform
  Cognitive Load Developer Experience & Flow Platform Engineering Trust
• How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery
  Cognitive Load DORA & Engineering Metrics Platform Engineering Sociotechnical Architecture
• The 8 software engineering metrics AI broke
  Developer Experience & Flow DORA & Engineering Metrics Technical Debt
• Achieving Compliance as a Platform Engineering Team by Helping Developers
  Developer Experience & Flow Platform Engineering Trust
• 2024_final_dora_report
  Developer Experience & Flow DORA & Engineering Metrics Platform Engineering
• The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices
  Platform Engineering Sociotechnical Architecture Technical Debt
• How a Culture of Data-Driven Conversations Can Support Platform Engineering
  Cognitive Load DORA & Engineering Metrics Platform Engineering