How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery

Ben Linders · rss · 2026-05-21 source ↗ Reader 🖥️

Cognitive Load DORA & Engineering Metrics Golden Path Modularity & Coupling Platform Engineering Sociotechnical Architecture Team Autonomy Team Topologies

Internal platforms should be run as products that expose composable 'golden bricks' rather than prescriptive 'golden paths,' so that developer teams can self-assemble their own flow of value with low cognitive load while the platform team is held accountable to adoption, experience, and DORA-like outcome metrics.

practical · expository — A conference-talk write-up (Daniel Bryant at GOTO Copenhagen) with a follow-up InfoQ Q&A. Mostly expository reporting of practical prescriptions; the implicit imperative is 'build your internal platform this way.' Not an argument with premises so much as a curated set of recommendations backed by appeals to authority (Fournier, Nowland, DORA, SPACE, DX Core 4).

Structure

Part	Role
Opening framing: platform engineering must have a product focus; developers are customers; composable golden bricks beat rigid golden paths	Thesis statement / unity
Bryant's autobiographical setup: Java -> SOA -> microservices, cognitive load 'shot through the roof'	Motivating narrative — establishes the problem the platform is supposed to solve
Definition: a platform is a sociotechnical thing — self-service APIs, tools, and service knowledge as an internal product; goal is higher-pace feature delivery with reduced coordination	Key-term definition
Three goals: go faster, decrease risk, increase efficiency	Decomposition of the unity into measurable sub-goals
Product-not-project stance + 'if developers avoid the platform, that is feedback' + 'right thing easy to do' + ticket-as-flow-disruption	Practical principles + diagnostic heuristic
Golden bricks vs golden paths: a path can become a golden cage; teams assemble their own path from composable bricks	Central conceptual move — the named contribution
Metrics for the C-level: Adoption, Experience, Outcomes (citing Fournier, Nowland, SPACE, DX Core 4, DORA)	Legitimation by authority + governance/accountability mechanism
Warning about leaky abstractions	Caveat / risk
Closing imperative: developers should demand product focus	Call to action
InfoQ Q&A: layered architecture (infra orchestration / platform orchestration / app teams) and platform-software symbiosis	Architectural elaboration — shows what the brick-set looks like structurally

Key terms

Golden brick Golden Path
A composable, self-service platform capability (a DBaaS, a CD pipeline, an environment-as-a-service, etc.) that teams can pick up and combine to build their own way of working.
Golden path Golden Path
A single prescribed way to do something on the platform. Bryant treats this as the default platform-engineering offering and warns it 'can become a golden cage.'
Platform Platform Engineering
A sociotechnical internal product: self-service APIs, tools, and service knowledge bundled into something developer teams choose to use.
Cognitive load Cognitive Load
The amount of stuff a developer must hold in their head to get code shipped; the thing platforms exist to reduce.
Flow of value
A team's end-to-end ability to deliver business value without being blocked by external dependencies (raising tickets, waiting on DBs, ports). Each team — including the platform team — must 'own' theirs.
Product (vs. project)
An ongoing, customer-facing engagement measured by adoption and satisfaction, with no end date — applied to internal developer tooling.
Adoption / Experience / Outcomes
A three-tier measurement scheme: are teams using it (adoption), is it pleasant and fast (experience, via SPACE / DX Core 4), and does it move the business (outcomes, via DORA-like lead time, deployment frequency, change failure rate).
Leaky abstraction Modularity & Coupling
A platform abstraction whose internals show through, causing developers to depend on implementation details so the platform team can no longer change them.
Sociotechnical
Platforms are simultaneously social (team-to-team relationships, service knowledge, collaboration) and technical (APIs, tools).
Separation of concerns (across platform layers)
Infrastructure orchestration, platform orchestration, and application consumption must each have clear interfaces so layers can evolve independently.

Propositions

explicitAn internal platform should be run as a product, not a project.conf: high
explicitdevelopedComposable self-service capabilities ('golden bricks') outperform prescribed end-to-end paths ('golden paths') for enabling fast flow.conf: high
extends ←Presentation: Platform Engineering in the Age of AI · p6 — The panel's 'never answered question' (centralize vs. autonomy) is the same tension golden-bricks addresses via composable bricks vs. prescribed paths; this roundtable broadens the question into AI-specific territory (context, tooling, licensing) without taking a side.
explicitcorroboratedReducing developer cognitive load is the primary purpose of a platform.conf: high
extends ←Presentation: Platform Engineering in the Age of AI · p7 — Extends 'reducing developer cognitive load is the primary purpose of a platform' to cover a specific new mechanism — platform-distributed AI context/skills — not addressed in the golden-bricks piece.
supports ←How Open Source Enables Collaboration in Creating a Platform · p6 — 'Reducing cognitive load ... sensible defaults and opinionated workflows so developers focus on their applications' directly instantiates the claim that reducing developer cognitive load is the primary purpose of a platform.
explicitPlatform success must be measured along three axes: adoption, experience, and outcomes.conf: high
explicitestablishedVoluntary developer adoption is the canonical signal of platform fit; avoidance is itself evidence the platform is wrong.conf: high
supports ←Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p3 — Körbächer generalizes the same voluntary-adoption-as-signal claim beyond developers to security, compliance, and business stakeholders.
supports ←How Open Source Enables Collaboration in Creating a Platform · p11 — 'Open source was never a directive from management ... a compass' plus trust-driven willing adoption supports the principle that voluntary adoption (not mandate) is the canonical signal of platform fit.
explicitTicket-based provisioning is a flow-of-value pathology — any wait-on-another-team step indicates a platform failure.conf: high
explicitPlatforms and software architecture are symbiotic — each shapes the other.conf: high
explicitcorroboratedClear layering (infrastructure orchestration / platform orchestration / application consumption) is required for platforms to evolve as the org grows.conf: high
supports ←Netflix Details Its In-House LLM Serving Platform with Triton and vLLM · p2 — Netflix's CPU-in-process vs. GPU-via-MSS/Triton delegation is a concrete instance of the clear infra/platform/application layering the golden-bricks piece argues platforms need to evolve as an org grows.
explicitcorroboratedLeaky abstractions trap the platform team — once developers depend on the leak, implementation freedom is lost.conf: high
supports ←Netflix Details Its In-House LLM Serving Platform with Triton and vLLM · p12 — Netflix's account — where feature gaps and statefulness problems persist underneath a shared serving interface — is a real-world case of exactly the 'leaky abstractions trap the platform team' dynamic the golden-bricks piece describes.
implicitApplication teams are competent and motivated enough to assemble correct, safe systems from primitives — given good bricks, they will not need a prescribed path.conf: high
implicitConsistency and safety can be encoded into the bricks themselves rather than into a prescribed sequence of using them.conf: high
extendsHow Fast-Growing Companies Can Make Better Decisions · p4 — Applies the curated-options move to platform engineering: organizational knowledge is encoded into vetted composable bricks while teams keep autonomy over assembly.
implicitOrganisational design (autonomous, stream-aligned teams owning their flow) is a prerequisite for bricks-style platforms; without it, bricks become rubble.conf: high
implicitcontestedGovernance and compliance concerns (security, regulatory, cost) can be satisfied at the brick level rather than at the path level.conf: medium
contradicts ←Achieving Compliance as a Platform Engineering Team by Helping Developers · p7 — Golden Bricks argues compliance can be satisfied at the brick level (decentralized, encoded in the composable primitive itself); this article's platform team keeps enforcement centrally owned — SCPs, Tag Policies and Security Hub are platform-wide controls the platform/compliance team defines and operates, with consuming teams winning voice and buy-in but not guardrail ownership.
implicitInternal developers behave like external customers in the relevant sense — they have alternatives and exercise choice.conf: high
implicitdevelopedThe DORA / SPACE / DX Core 4 framework stack is a sufficient evaluation apparatus for internal platforms.conf: medium
refines ←Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p10 — 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.

Arguments

Platforms should expose composable golden bricks rather than prescribed golden paths. strength: medium

Explicit premises:

A prescribed single way ('golden path') can become a 'golden cage.'
Composable capabilities let teams move quickly while maintaining safety and consistency.
Each team must own their flow of value.

Implicit premises:

Teams are sufficiently capable to assemble correct, safe systems from primitives without prescription.
Safety and consistency can be encoded into the bricks themselves, not into a prescribed sequence.
The cost of a wrong assembly by a team is lower than the cost of a wrong prescription by the platform team.
The organisation already runs on stream-aligned, autonomous teams (Team Topologies-style).

Inferences:

Therefore platform teams should resist the temptation to ship 'the way' and instead ship building blocks plus optional reference compositions.
Therefore the unit of platform versioning is the brick, not the path — which has implications for backward-compatibility commitments the article does not draw.
Therefore 'paved roads' in the Netflix/Spotify sense are an intermediate, not a target.

Platforms must be run as products, not projects. strength: high

Explicit premises:

Developers are customers.
If developers avoid the platform, that is feedback.
'If the platform makes the right thing easy to do, developers will choose to use it.'

Implicit premises:

Developers actually have the option not to use the platform (i.e. no mandate, no monopoly).
Voluntary uptake reliably tracks platform quality (rather than, say, lock-in or politics).
The platform team has the authority and resources to behave like a product team — including saying no to demands.

Inferences:

Therefore mandating platform use is self-defeating; it removes the diagnostic signal.
Therefore platform teams need PMs, user research, and roadmaps — not just SREs.

Platform value should be measured via adoption, experience, and outcomes (DORA-style). strength: medium

Explicit premises:

Adoption shows whether teams are actually using the platform.
Experience captures provisioning time and developer satisfaction (SPACE, DX Core 4).
Outcomes connect to business impact via lead time, deployment frequency, change failure rate.

Implicit premises:

These three layers compose to a sufficient picture of platform health.
DORA metrics, designed for delivery performance, transfer cleanly to platform performance.
C-level audiences will accept these metrics as legitimate platform-value evidence.

Inferences:

Therefore platforms without instrumented usage telemetry cannot be defended at the C-level.
Therefore there is no real defence of a low-adoption-but-strategically-necessary platform — an awkward implication the article does not address.

Platforms must be layered with clear interfaces (infra orch / platform orch / app consumption) to remain evolvable. strength: high

Explicit premises:

Separation of concerns is the critical principle.
Mixing concerns makes platforms fragile.
Clear interfaces let layers evolve independently.

Implicit premises:

The three-layer carve-up Bryant offers is the right carve-up (not, say, two layers or five).
Interfaces can be designed stable enough to absorb the changes the underlying tech imposes.

Inferences:

Therefore a monolithic 'IDP' that crosses all three layers is anti-pattern by construction.
Therefore Conway's law applies — the platform team itself probably needs three sub-teams.

Narratives

Bryant's own career arc: classical Java -> SOA -> microservices, with each step ratcheting up his cognitive load until 'it was a lot of stuff to learn to get code shipped' and he wanted 'a bunch of tools I could mix and match.'
→ Origin myth for the bricks idea — frames composability as the developer's own felt need, not an engineering fashion. Implicitly argues 'I am you; I needed this; therefore you need this.'
The ticket vignette: 'You're waiting for someone to give you a database or open a port. Your flow of value is disrupted.'
→ Concrete instantiation of the abstract 'flow of value' concept; supplies a vivid failure mode that the brick model claims to dissolve.
The 'golden cage' image — a golden path that has become a prison.
→ Metaphor doing argument-work: makes the path-model feel oppressive without having to demonstrate that it actually is. Rhetorical lever for the bricks proposition.

Questions addressed

✅ What is the right operating model for an internal developer platform?
Run it as a product offering composable golden bricks, measured by adoption/experience/outcomes.
✅ How should platforms be measured and justified to executives?
Adoption (are they using it), Experience (SPACE/DX Core 4), Outcomes (DORA-like).
✅ How should platforms be architecturally structured?
Three layers with clear interfaces — infra orchestration, platform orchestration, app consumption.
⭕ Under what organisational conditions can the bricks model actually work?
Not addressed — autonomy, team topology, and decision rights are assumed.
⭕ How does safety/consistency travel through composition when teams freely combine bricks?
Asserted ('composable capabilities let teams move quickly while maintaining safety and consistency') but the mechanism is never explained.
⭕ What about regulated environments where prescription is non-optional (audit, segregation of duties, data residency)?
Not mentioned.
⭕ What happens when adoption is low but the platform is strategically necessary (e.g. consolidation, cost, risk)?
The 'adoption = feedback' frame assumes this case away.
⭕ How do you avoid leaky abstractions while still exposing enough of the brick to be useful?
Warning issued, no design guidance.

Gaps

incompleteThe 'golden path vs golden brick' distinction is rhetorical, not analytical. What actually changes when you move from path to brick? The article never decomposes the shift along the three axes where the shift really lives: (a) governance — who owns correctness, the platform team (path) or the consuming team (brick); (b) composability — who designs the assembly, and against what contract; (c) team autonomy — does the consuming team have the decision-rights, time, and skill to assemble well? Without this decomposition, 'bricks' is a slogan, not a model.
Read next: Skelton & Pais, Team Topologies (esp. platform team / stream-aligned team interaction modes). Camille Fournier's writing on platform teams. Gregor Hohpe on architecture decision records and IT architecture as conversation. Manuel Pais on the cognitive-load assessment.
incompleteThe organisational shift the article requires but does not theorise. Bricks-not-paths only works in an organisation that has already pushed correctness, security review, cost ownership, and incident response down into stream-aligned teams. In an org where the platform team is also the compliance team and the on-call team, bricks-without-a-path means each stream team must reinvent guardrails. The piece treats this organisational redesign as free — but it is the actual hard part.
Read next: Cutler's TBM essays on institutional overload and accountability. Allen Holub's #NoAccountability work. Conway's Law re-readings (Skelton/Pais). Andrew Clay Shafer / DevOps adoption literature on the politics of platform ownership.
incompleteStrawmanning of the golden path. In Spotify's original formulation and most current usage, a golden path is an opinionated default route through optional tooling — not 'the single way to do things.' Bryant collapses 'golden path' into 'golden cage' to set up the brick contrast, which makes the move feel sharper than it is. The real design choice is the ratio: which bricks ship with reference compositions (paths) attached, and which don't.
Read next: The Spotify Backstage docs on golden paths. The 'paved road' material from Netflix engineering. Honeycomb's writing on opinionated developer platforms.
incompleteNo treatment of the leaky-abstraction risk that the brick model amplifies. The more composable the platform, the more surface area developers can latch onto — and the harder it becomes to change the implementation later. Bryant raises leaky abstractions as a warning but never connects them to the brick model, which is precisely where they bite hardest.
Read next: Spolsky's original 'Law of Leaky Abstractions.' Ousterhout, A Philosophy of Software Design, on deep vs shallow modules — bricks must be deep modules or the abstraction tax is real.
incompleteMeasurement loop is one-way. Adoption / Experience / Outcomes is a defensive scheme for justifying the platform upward to C-level, but the article does not ask whether these metrics are good enough to guide platform design decisions downward (which brick to build next, which to deprecate, where the composition contracts are wrong). They measure existence, not direction.
Read next: Fournier & Nowland on platform-team operating cadence. Cutler on operating-system design and signal-vs-noise in metrics. SPACE paper original (Forsgren et al.).
closed byPresentation: Platform Engineering for Everyone - Success Can’t Be Coded — 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.
uninformedNo engagement with the actual maturity literature on internal developer platforms — CNCF Platforms Working Group whitepaper, Team Topologies' Thinnest Viable Platform concept, the platform-engineering maturity model from PlatformCon. The piece treats the field as if Bryant is naming things for the first time.
Read next: CNCF Platforms WG whitepaper (2023+). Team Topologies' TVP material. McKinsey/ThoughtWorks platform engineering reports for the practitioner-economics view.

How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents