LinkedIn "wisdom"

by "Stavros"

Challenging the assumption that platform teams automatically create leverage

BY STAVROS · APRIL 22, 2026
Challenging the assumption that platform teams automatically create leverage infographic

The proof is indisputable.

THE INSIGHT

A pattern I keep seeing, and I want to name it plainly.

A company decides product teams are too slow. The remedy is a platform team. Abstractions, golden paths, a nice internal developer portal. Eighteen months later, the platform team is proud of what it built, and half the product teams have quietly stood up their own Terraform, their own CI, their own secrets manager, because the "paved road" did not pave the part of their road that was actually rough.

Then come the meetings. The platform team says the product teams are not adopting. The product teams say what was built does not fit. Leadership asks for a mandate. The mandate arrives. Adoption goes up on the dashboard. Trust goes down everywhere else.

The data is starting to get embarrassing. DORA 2025 says 76% of organisations have a dedicated platform team. Humanitec's survey says around 9% of those teams are mature by any reasonable measure, and 45% of them measure nothing at all. Spotify's own head of Backstage engineering admits average external adoption is stuck at around 10%. DORA 2024 found platforms lifted individual productivity by about 8% while reducing change throughput by 8% and change stability by 14%. We are making individual developers a little faster while making the system as a whole a little worse.

Team Topologies was clear about why this happens, and I think a lot of us stopped listening. Skelton's line has stayed with me: teams build "mini Amazons, mini clouds without even talking to the developers." The Platform Manifesto puts adoption and engagement ahead of mandates and standards for a reason. A platform is a product with internal customers who can, and will, route around you. Camille Fournier said it in plainer language. If the platform does not support what a team needs, the team will build shadow infrastructure. They will be convinced it solves their problem. Sometimes they are right.

Two things have actually worked for me.

Start from where developers lose hours, not from the architecture diagram. Atlassian's 2025 survey has half of developers losing ten or more hours a week to tooling friction, and 63% saying leadership does not understand what the friction is. If your platform roadmap was not built from that list, it was built from someone's taste.

Then, be honest about whether you need a platform team at all. Manuel Pais keeps pointing out that organisations reach for "platform team" when what they really need is an enabling team. Enabling teams sit with product teams, unblock them, and leave. They do not accumulate surface area. They do not need a mandate. They are allowed to disband.

A platform strategy works when it tracks real workflow friction and earns its usage. It fails when it is designed to make the org chart look tidy.

THE EVIDENCE

Research brief: Platform teams, leverage, and the adoption gap

Core finding for the thesis: The quantitative evidence is striking. Platform team existence is approaching near-ubiquity (DORA 2025: 76% of orgs have a dedicated platform team; 90% have internal platform constructs), [1] yet the effectiveness evidence is mixed-to-poor. DORA 2024 measured platforms as improving individual productivity (+8%) and team productivity (+10%) [2] while decreasing change throughput (−8%) and change stability (−14%). [3] Spotify's own head of Backstage engineering says the average external Backstage adoption is "stuck at 10%." Humanitec's 2024 State of Platform Engineering (Vol. 3) found that only ~9% of platform teams meet CNCF's maturity bar, 45% measure nothing at all, and only 22% report significant metric improvements after introducing platform engineering. Every well-known framework (Team Topologies, Thoughtworks Radar, Fowler's platform prerequisites, Fournier, Larson) converges on the same diagnosis: platforms fail when built as architecture rather than as product.

Below is the raw material organised for reuse, with attributions and source URLs.

1. Team Topologies — quotable primary material

Thinnest Viable Platform (TVP)

  • Canonical definition (book p.101): "A TVP is the smallest set of APIs, documentation, and tools needed to accelerate the teams developing modern software services and systems." [4][5] — Skelton & Pais, Team Topologies (2019).
  • Skelton on TVP minimalism (InfoQ podcast, 2020): "This TVP could be just a wiki page if that's all you need… [6] you don't make it any thicker than necessary." [7][7] / "The thinnest platform you can build is a Wiki page with a list of four services that [a cloud provider] provides, and someone has curated an experience for the engineers." [8]
  • Source: [7]

Failure modes — direct language from the authors

  • Skelton on platforms built in isolation (InfoQ 2020): "I've definitely seen teams… that built out amazing kind of mini Amazons, mini clouds without even talking to the developers. I'm like, no wonder they're not using it. You never talk to your customer." [8]
  • Pais on platform-as-bottleneck (DX podcast Ep.40, 2023): "We need to be looking at — are we helping the teams actually go faster or [are] we becoming a bottleneck? Then we're not being a real platform team in the sense of Team Topologies." [9] Also: "There's a very real risk of the platform actually blocking those teams." [9]
  • TT Key Concepts page (live text): "Most internal platforms become bloated monstrosities that slow teams down rather than accelerate progress." [10]
  • TT Newsletter, Nov 2024, "Revisiting Team Topologies: Misuses of Platform Teams" names six platform team missteps: Lack of Consultation, Malicious Compliance, Knowledge Bias, Firefighting Mode, Siloed Operations, Distrust from Non-Technical Stakeholders. [11] Direct quote on malicious compliance: "Developers who adopt tools out of obligation may feel resentful." [11] Source: [11]

Platform-as-a-product framing

  • Skelton, ThoughtWorks Technology Podcast (2021): "The platform is a curated experience for engineers. And that's the starting point. The starting point is not technology." [12][13]
  • Skelton, InfoQ "Business and Technical Agility" talk: "It should be optional for me to use this product. That means the platform is optional to use. No team is forced to use it." [13] / "Internal platform team should effectively use internal marketing techniques, advocate for their platform product and market it to internal teams." [13]
  • Pais, DX podcast (2023): "Platform team essentially ends up being an internal product team, a team that creates services and tools and products… for internal use." [9]
  • Pais, summarised by Mia-Platform from his PlatformCon talk: "A key ingredient for success in finding this balance is that platforms must be compelling to use, they cannot stand on a mandate alone." [5][14]

The Platform Manifesto (teamtopologies.com/platform-manifesto)

Six principles in "over" form, most useful: "teams & interactions over tools & functionality" / "adoption & engagement over mandates & standards" [11] / "rich customer experience over technical prowess." [15] Stated aim: "superlinear impact with sublinear growth." [15]

Enabling vs platform team — the distinction the user may want to exploit

  • Pais (DX podcast 2023): "Platform is really about internal product, whereas enabling teams are almost more of internal consulting." / "If the enabling team is becoming a dependency… That's an antipattern in terms of fast flow." [9]
  • Pais's specific prescription for a large retailer considering a platform: "Start by doing enabling work… before you even build any technology, before you build any service, get people to know each other and to trust." [9]
  • Useful framing: an org that reaches for a "platform team" when what it actually needs is an enabling team is the single most common structural mistake Pais identifies in 2023-24 talks.

Conway's Law implications

  • Book (Ch.2): "Conway's law tells us that we need to understand what software architecture is needed before we organize our teams, otherwise the communication paths and incentives in the organization will end up dictating the software architecture." [16]
  • Pais (DX podcast 2023) on drift: "Platform teams become sort of quite attached to their domain… the platform boundaries that you defined in the beginning or earlier were not correct." [9]

Second edition (Sept 2025) — "Platform Grouping"

Key refinement: a platform is now framed as a grouping of teams, not a single team. "In organisations with more than 40 to 50 people, an internal platform typically requires more than one 8-person team… [17] hence the introduction of the term 'platform grouping'." [18] Useful if the user wants to note that TT itself has updated as platforms scale. Source: [18]

2. Quantitative evidence — the adoption gap

Gartner's headline prediction (verify and nuance)

  • Gartner, "Top Strategic Technology Trends for 2024: Platform Engineering" (Blosen & Delory, 16 Oct 2023): "By 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components and tools for application delivery — up from 45% in 2022." [19]
  • Important nuance: Gartner has since placed platform engineering in the "trough of disillusionment" on its dedicated Hype Cycle (from 2024 onwards). [20] Gartner's 2026 Top Strategic Technology Trends (released Oct 20 2025) does not re-list platform engineering as a top trend; emphasis has shifted to AI-native platforms. [21]
  • Landing page: [22]

Puppet / Perforce State of DevOps — Evolution of Platform Engineering

  • 2023 report: 93% of respondents say platform team adoption is a step in the right direction; 94% agree it's helping them realise DevOps benefits; [23] 57% of orgs have 2–4 platforms and 30% have 5+ internal self-service platforms [24] — i.e., proliferation, not consolidation.
  • 2024 report (n≈500): 43% have had a platform team 3–5+ years; [25] 65% expect continued investment; [25] 52% think a product manager is "crucial" to platform team success; [26] report explicitly notes "senior management often champions investment in Platform Engineering, not all developers feel the same way."
  • Source: [27]

Humanitec / platformengineering.org — the hardest evidence of the gap

  • Vol. 3 (Nov 2024, n=281 platform teams): 56% of orgs have had platform teams less than two years; only 13% more than five years; [28] 13% admit they relabeled their DevOps team "platform engineering" to sound more fancy; [28] only ~9% qualify as "mature" by CNCF's model; [28] 45% of platform teams don't measure anything at all; [28] only 22% report significant metric improvements; 43% describe feedback mechanisms as "ad-hoc" or "inconsistent." [28] Summary: [28]
  • Vol. 4 (Dec 2025, n=518): 29.6% of platform teams still don't measure success at all; 47.4% of platform initiatives run on <$1M annual budget; 55.9% of companies operate more than one platform. [29] Source: [29]
  • Humanitec DevOps Benchmarking 2023: 93% of top performers use an IDP vs 5% of medium and 2% of low performers [30] — useful counter data to include for balance.

DORA — the single most important quantitative citation

  • 2024 DORA report (n≈3,000): Platform engineering / IDP impact measured as: individual productivity +8%, team productivity +10%, change throughput −8%, change stability −14%. [3] The report hypothesises faster-released changes may be why stability drops.
  • 2025 DORA report: 90% of orgs have internal platform constructs; 76% have a dedicated platform engineering team; [1] the 2024 stability/throughput concerns are re-framed rather than re-validated, with focus shifting to AI foundations.
  • Sources: [31] and [32]

Developer experience context

  • Atlassian + DX State of Developer Experience 2024 (n≈2,100): 97% of devs lose significant time to inefficiencies; [33] 69% lose 8+ hours/week; only 44% think leaders are aware. [34]
  • Atlassian State of DevEx 2025: 50% of devs lose 10+ hours/week; [35] 63% say leaders don't understand their pain points (up from 44% the year before). [36] Useful to argue that platform teams not anchored to workflow friction are building for the wrong problem.

Backstage adoption — the flagship example

  • Helen Greul, Head of Engineering for Backstage at Spotify (The New Stack, 2023): "The average Backstage adoption rate is stuck at 10%." She attributes this to adopters not making it past POC because "they fail to understand the challenges developers are facing" [37] and to the tool's surface area ("more than 70 steps and 100 plug-ins"). [37]
  • Backstage has 3,400+ adopters worldwide (2025) [38][39] and 270+ public adopters (Oct 2024), [40] with ~1,600 contributors [39] — adoption as a project is genuine; adoption within adopting companies is the problem.
  • Sources: [37] and [41]

Data-quality warnings

  • The widely-circulating "64% of developers bypass your internal platform" figure (Medium, 2026) could not be traced to a primary survey — treat as derivative.
  • The "60-70% of platform engineering initiatives fail within 18 months" claim (Byteiota) is a secondary blog analysis, not a survey finding. Avoid citing directly.
  • The Bezos 2002 API mandate has no public primary source — all citations trace to Steve Yegge's 2011 "Google Platforms Rant."

3. Named anti-patterns and failure modes — with attributions

Thoughtworks Technology Radar has the crispest catalogue of named anti-patterns, all directly citable:

PatternRadar ringDirect quote
Ticket-driven platform operating modelsHold"One of the ultimate goals of a platform should be to reduce ticket-based processes to an absolute minimum, as they create queues in the value stream."Thoughtworks
Miscellaneous platform teams(the "junk drawer")Hold"We're seeing the 'platform team' label applied to teams dedicated to projects that don't have clear outcomes or a well-defined set of customers… these miscellaneous platform teams struggle to deliver due to high cognitive loads and a lack of clearly aligned priorities."
Platform engineering product teamsAdopt"We caution against layered platform teams that simply preserve existing technology silos but apply the 'platform team' label as well as against ticket-driven platform operating models."ThoughtworksThoughtworks
Platformania(HBR-origin coinage re-used by Thoughtworks UK)—Framed as "a land grab, where companies feel they have to be the first mover."Thoughtworks
"Field of Dreams platforms"—Rickey Zachary (Thoughtworks global platform engineering lead)brighttalk— built but no users.

"Ivory tower architecture" — cleanest attribution is Gregor Hohpe (architectelevator.com). In "Keeping Architecture out of the Ivory Tower" (LinkedIn, Oct 2016): "The proverbial ivory tower denotes the state when a central architecture team deals only with abstract topics, losing touch with reality." [42] Also his famous aphorism: "Strategy without execution is ivory tower architecture; execution without strategy is chaos." [43] And: "Excessive complexity is nature's punishment for organizations that are unable to make decis Ibrahim Cesarions." His 2024 book is titled Platform Strategy: Innovation Through Harmonization — the harmonization vs standardization framing maps cleanly onto the user's thesis.

"Rent-seeking platform teams" — Will Larson, "Maintaining platform-product fit" (Nov 2019, lethain.com/platform-product-fit): "companies missing a structured investment thesis for their internal platforms [engage in] rent-seeking behaviors, even though everyone involved [is] attempting to rationally maximize their impact." [44][44] Also: "new product teams find themselves unable to plan or staff meaningful product development due to the stream of mandatory platform migrations generated by the platform's need to maximize platform leverage to justify their own existence." [44] This is arguably the single best essay for the post's thesis.

Shadow infrastructure — Camille Fournier, "Make Boring Plans": "If Platform doesn't support Kubernetes, some team will decide to build shadow infrastructure because they're convinced that it will solve the problem they have to handle." Fournier & Nowland's 2024 book Platform Engineering (O'Reilly) names "Shadow Platforms," "Accidental Complexity," and the "Second-System Effect" as formal patterns. [45] From her "Platform Engineering Beyond CFEngine" (Oct 2024): "Taking a product approach to platforms doesn't mean making everyone happy all the time… It means taking the time to understand what is actually making your application teams less efficient, and doing hard work yourself so they don't have to." [46]

"Pave the path with gold" (paved golden path) — Charity Majors, "Software Sprawl, The Golden Path, and Scaling Teams With Agency" (Dec 2018, charity.wtf): "Pave the path with gold. Nobody HAS to use these components … but if they don't, they're on their own. They will have to support it themselves." Also from her recent writing: "Platform teams are oriented around providing a good experience for developers to self-serve and self-manage their code. The more swiftly and easily developers can move, the better your platform team." [47] And: "from a functional perspective, platform engineering is still ops." [48]

Martin Fowler bliki / "Mind the Platform Execution Gap" (Ford & García García, 2021): "The platform team needs to think of the platform as a software product, needing dialog with its users, attention to reliable operations, and a healthy team environment." [49] And from Fowler's own platform prerequisites advice: "Mandatory migration to the platform is a shortcut that has the long-term risk of eroding your team's product thinking discipline."

Evan Bottcher, "What I Talk About When I Talk About Platforms" (martinfowler.com, 2018) — the canonical definition Skelton/Pais cite: "A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product." [50][51]

4. Case studies — paved roads, mandates, and failures

Netflix — origin of "paved road"

  • Dianne Marsh, "The Paved Road at Netflix: At the Junction of Freedom and Responsibility," OSCON 2017: "The Paved Road is… a concept, formalizing a set of expectations and commitments between the centralized teams and our engineering customers." [52][53] / "Investments to pave a road (or elements of it) are made in partnership with the consuming team." [53]
  • Critical caveat for UK healthtech: at OSCON 2017 Marsh was asked whether the paved-road model works in regulated industries like healthcare/finance. She said no, citing Netflix's lack of financial-penalty SLAs, lack of regulation, and senior-only hiring [54] (skippy.net OSCON 2017 writeup). The user should be aware: the originator of this concept explicitly doubted its transfer to the user's exact industry.
  • Netflix Tech Blog, "How We Build Code at Netflix": "Teams have the freedom to implement alternative solutions, but they also take on additional responsibility for maintaining these solutions." [55][55]

Spotify — Golden Paths and Backstage (mixed evidence)

  • Gary Niemen, "How We Use Golden Paths to Solve Fragmentation" (Spotify Engineering, Aug 2020): "The Golden Path is the 'opinionated and supported' path to build your system." [56][57] Pre-existing state described as "rumour-driven development" — useful phrase.
  • Backstage internally: Spotify reportedly achieved 99% voluntary adoption internally (thenewstack.io). Externally, Helen Greul says average adoption is stuck at 10% — the most cited gap statistic in the industry.
  • Squad model walked back: ex-Spotify engineer Jeremiah Lee, "Spotify's Failed #SquadGoals" (2020): "The Spotify model is revealed as a collection of cross-functional teams with too much autonomy and a poor management structure. Don't fall for it." [58][59] The Golden Paths/Backstage investment is effectively Spotify's answer to this fragmentation.

Monzo — the UK regulated-industry counter-example

  • Suhail Patel, Monzo (Container Solutions interview): "There is a defined paved road when you start work on a microservice, and as a result the microservices all look very uniform — you can go and contribute to another team's service because the structure is entirely familiar to you." [60] Container Solutions' analysis: "Monzo's emphasis is a little different from that of, say Spotify or Netflix, in that whilst you can still deviate from the paved road if you really want to, doing so at Monzo has a very high barrier to entry." [60]
  • Because of this uniformity, Monzo's platform team can run migrations across 2,800 microservices centrally rather than asking service teams. This is a compelling example of what strong, opinionated paving buys you in regulated contexts — relevant to UK healthtech.

GOV.UK PaaS — the cleanest UK platform-failure case

  • Tom Read, CEO GDS (July 2022): "GOV.UK PaaS has not seen the rapid and continued growth that we've seen with some of our other platform products, and is now at a point where we either invest heavily in some significant technical architecture changes, or we make the difficult decision to sunset the product." [61] Decommissioned 23 December 2023 [62] after serving 60+ departments and 172 digital services since 2015. [63] Primary source: [61]. This is the UK-public-sector case study the user can reference directly.

Airbnb — honest "forced migration" admission

  • From "Continuous Delivery at Airbnb": "We were able to get to the 100% finish line by shifting our strategy towards adding more friction and eventually deprecating our old tool." [64] Useful because it shows a real company admitting pure voluntary adoption didn't work and they actively introduced friction to migrate off the legacy path.

Uber — Michelangelo's evolution

  • Uber publicly admitted that v1 of Michelangelo didn't serve deep-learning workloads and had to be rebuilt: "One important reason that hindered the adoption of deep learning is the lack of end-to-end deep learning support in Michelangelo 1.0." [65] Clean example of a centralised ML platform forcing product teams to wait for or route around the platform.

Shopify and Meta — mandate success stories (counter-evidence)

  • Shopify (Aparna Sinha): "Shopify decided to take the approach of Platform Engineering. And have a platform where all of these tools are built, custom-built for our business… there's one unified way of deploying things to production." Works because the underlying stack (Rails monolith) was already uniform.
  • Meta: Internally-mandated toolchain (Phabricator, Sandcastle, mandated Mercurial); ex-Meta engineers consistently rate dev tooling as best-in-industry. [66] Pattern: mandates succeed at massive scale + heavy investment + pre-existing homogeneity.
  • Amazon's "Bezos API mandate" (2002) — still the canonical mandate-success citation, via Yegge's 2011 rant: "All service interfaces, without exception, must be designed from the ground up to be externalizable… Anyone who doesn't do this will be fired. Thank you; have a nice day!" Caveat: no primary source; treat as directionally true.

Wise (UK) — platform mission statement worth quoting

  • Wise Product Platform team mission: "Provide a 'paved road' for Wise engineers that balances our autonomous culture with feature velocity and business goals, while still ensuring our systems are reliable and observable." [67] Neat UK-fintech formulation of voluntary-but-supported.

NHS England — relevant institutional context

  • NHSDigital Software Engineering Quality Framework (github.com/NHSDigital/software-engineering-quality-framework) explicitly states: "Loosely-coupled & cloud-native composable components as the default mode of construction." [68] NHS Developer Hub: [69]. Relevant for the user's domain — NHS's stated architectural principles align with a compelling-not-mandated posture.

5. The counter-argument — when mandates work

This is where the post needs to avoid oversimplification:

  • Octopus Deploy research (counter-evidence): "Our research found that mandatory platforms report almost 2.5× higher confidence that their funding will remain secure over [70] the next five years." ([70]) Mandates secure funding even when they frustrate users — a political not technical outcome.
  • The pattern across successful mandates: mandate works when scale is massive (Meta/Google/Amazon), uniformity has clear regulatory/business value (Monzo), and investment makes the paved path genuinely better than alternatives. Mandate fails when the platform team is underfunded, product teams have legitimately heterogeneous needs, or the platform is imposed on an already-diverse stack.
  • Humanitec 2023 benchmark: 93% of top-performing engineering orgs use an IDP vs 5% of medium/2% of low performers — platforms correlate with high performance, but the direction of causation is ambiguous.
  • Google Cloud Platform Engineering Research (~500 IT pros): 71% of leading platform adopters significantly accelerated time-to-market vs only 28% of less mature adopters. Maturity — not existence — is what predicts value.

6. Ten pull-quotes ready to deploy (all <25 words, attributed)

  1. "Mandatory migration to the platform is a shortcut that has the long-term risk of eroding your team's product thinking discipline." — Martin Fowler / Evan Bottcher, Mind the Platform Execution Gap (2021)
  2. "Platforms must be compelling to use, they cannot stand on a mandate alone." — Manuel Pais, PlatformCon
  3. "Mini Amazons, mini clouds without even talking to the developers… no wonder they're not using it. You never talk to your customer." — Matthew Skelton, InfoQ (2020)
  4. "Most internal platforms become bloated monstrosities that slow teams down rather than accelerate progress." — Team Topologies Key Concepts
  5. "The average Backstage adoption rate is stuck at 10%." — Helen Greul, Head of Engineering for Backstage at Spotify
  6. "If Platform doesn't support Kubernetes, some team will decide to build shadow infrastructure." — Camille Fournier, Make Boring Plans
  7. "Pave the path with gold. Nobody HAS to use these components… but if they don't, they're on their own." — Charity Majors (2018)
  8. "Strategy without execution is ivory tower architecture; execution without strategy is chaos." — Gregor Hohpe
  9. "Platform teams generate a stream of mandatory migrations to justify their own existence." — paraphrase of Will Larson, Maintaining platform-product fit (2019)
  10. "One of the ultimate goals of a platform should be to reduce ticket-based processes to an absolute minimum, as they create queues in the value stream." — Thoughtworks Radar, "Ticket-driven platform operating models" (Hold)

7. Key sources (for the user's own verification)

  • Team Topologies Key Concepts: [10]
  • "Misuses of Platform Teams" (Nov 2024): [11]
  • DORA 2024: [31]
  • Humanitec State of Platform Engineering Vol. 3: [28]
  • Humanitec Vol. 4: [29]
  • Puppet 2024: [27]
  • Will Larson, Maintaining platform-product fit: [44]
  • Fowler, Mind the Platform Execution Gap: [71]
  • Bottcher, What I Talk About When I Talk About Platforms: [72]
  • Netflix, How We Build Code: [55]
  • Spotify Golden Paths: [73]
  • Backstage adoption (Spotify admission): [37]
  • GOV.UK PaaS decommissioning: [61]
  • Monzo paved road (Container Solutions): [60]
  • Charity Majors, Software Sprawl, The Golden Path: [74]
  • Thoughtworks Radar — platform engineering product teams: [75]

Three framings the user could lean on

Framing A — the "adoption gap": "76% of orgs have a platform team (DORA 2025). 9% are mature (Humanitec). Average Backstage adoption sits at 10% (Spotify's own admission). The gap between having a platform and leveraging a platform is now the central story in platform engineering." This is the crispest, most quantitative version.

Framing B — the DORA paradox: Lean hard on DORA 2024's finding that platforms decrease change throughput by 8% and stability by 14% while raising per-developer productivity. Platform teams are optimising the wrong level of the system — local productivity at the cost of global flow. This is the most analytically interesting hook for a Director of Technical Strategy audience.

Framing C — the architecture diagram vs the workflow: Use Hohpe's "ivory tower" aphorism plus Larson's "rent-seeking" essay plus Skelton's "mini Amazons" quote to argue that platforms fail when designed around what architects think is elegant rather than around where developers actually waste time (Atlassian: 8+ hours/week, 69% of devs). Pair with the Monzo/GOV.UK PaaS contrast — opinionated paving can work in UK regulated contexts (Monzo), but only when the paving tracks real workflow friction, not a consolidation agenda (GOV.UK PaaS).

A UK healthtech post will be strongest if it names the Dianne Marsh caveat (paved roads may not transfer to regulated industries), then uses Monzo as the proof that an opinionated paved road — not a mandated platform — can work in UK regulated contexts when designed around developer workflow friction.

  1. Substack — https://adamferrari.substack.com/p/ai-insights-from-the-2025-dora-report
  2. Cortex — https://www.cortex.io/post/2025-playbook-for-devops-excellence
  3. DevOps Launchpad — https://devopslaunchpad.com/blog/dora-report-2024/
  4. GitHub — https://github.com/TeamTopologies/Thinnest-Viable-Platform-examples
  5. Mia-Platform — https://mia-platform.eu/blog/platform-as-a-product/
  6. Thoughtworks — https://www.thoughtworks.com/en-de/radar/techniques/incremental-developer-platform
  7. Team Topologies — https://teamtopologies.com/key-concepts-content/what-is-a-thinnest-viable-platform-tvp
  8. infoq — https://www.infoq.com/podcasts/software-architecture-team-topologies/
  9. getdx — https://getdx.com/podcast/team-topologies-platform-work/
  10. Team Topologies — https://teamtopologies.com/key-concepts
  11. teamtopologies — https://teamtopologies.com/news-blogs-newsletters/2024/11/24/revisiting-team-topologies-misuses-of-platform-teams
  12. Thoughtworks — https://www.thoughtworks.com/insights/podcasts/technology-podcasts/team-topologies
  13. InfoQ — https://www.infoq.com/presentations/team-topologies-technical-agility/
  14. Kratix — https://platformengineering.org/talks-library/platform-as-a-product
  15. teamtopologies — https://teamtopologies.com/platform-manifesto
  16. IT Revolution — https://itrevolution.com/articles/conways-law-critical-for-efficient-team-design-in-tech/
  17. Martin Fowler — https://martinfowler.com/bliki/TeamTopologies.html
  18. Team Topologies +2 — https://teamtopologies.com/key-concepts-content/groupings
  19. Ahead — https://go.ahead.com/gartner-platform-engineering
  20. Humanitec — https://humanitec.com/platform-engineering
  21. Gartner — https://www.gartner.com/en/newsroom/press-releases/2025-10-20-gartner-identifies-the-top-strategic-technology-trends-for-2026
  22. https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering — https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering
  23. Perforce — https://www.perforce.com/press-releases/2023-state-devops-report
  24. DevOps — https://devops.com/state-of-devops-report-finds-a-rise-in-platform-engineering/
  25. Perforce — https://www.perforce.com/press-releases/puppets-2024-state-devops-report
  26. Puppet — https://www.puppet.com/blog/state-devops-report-2024
  27. https://www.puppet.com/resources/state-of-platform-engineering — https://www.puppet.com/resources/state-of-platform-engineering
  28. thenewstack — https://thenewstack.io/the-2024-state-of-platform-engineering-fledgling-at-best/
  29. platformengineering — https://platformengineering.org/blog/announcing-the-state-of-platform-engineering-vol-4
  30. Humanitec — https://humanitec.com/whitepapers/devops-benchmarking-study-2023
  31. https://dora.dev/research/2024/dora-report/ — https://dora.dev/research/2024/dora-report/
  32. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report — https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
  33. Atlassian — https://www.atlassian.com/blog/developer/developer-experience-report-2024
  34. The New Stack — https://thenewstack.io/why-do-developers-lose-1-day-a-week-to-inefficiencies/
  35. Medium — https://medium.com/@gdsources.io/my-review-of-the-atlassian-2025-devex-report-7425520cbf64
  36. Atlassian — https://www.atlassian.com/blog/developer/developer-experience-report-2025
  37. The New Stack — https://thenewstack.io/spotifys-backstage-roadmap-aims-to-speed-up-adoption/
  38. Roadie — https://roadie.io/backstage-spotify/
  39. The New Stack — https://thenewstack.io/five-years-in-backstage-is-just-getting-started/
  40. CNCF — https://www.cncf.io/blog/2024/11/15/internal-developer-platforms-at-scale-with-the-certified-backstage-associate-cba-certification/
  41. https://www.techtarget.com/searchitoperations/news/366558592/Behind-the-scenes-Spotify-Backstage-a-work-in-progress — https://www.techtarget.com/searchitoperations/news/366558592/Behind-the-scenes-Spotify-Backstage-a-work-in-progress
  42. LinkedIn — https://www.linkedin.com/pulse/keeping-architecture-out-ivory-tower-gregor-hohpe
  43. LinkedIn — https://sg.linkedin.com/in/ghohpe
  44. lethain — https://lethain.com/platform-product-fit/
  45. Google Books — https://books.google.com/books/about/Platform_Engineering.html?id=0EQoEQAAQBAJ
  46. Medium — https://skamille.medium.com/platform-engineering-beyond-cfengine-daa9268c9c5b
  47. Charity — https://charity.wtf/tag/sre/
  48. Charity — https://charity.wtf/
  49. Martin Fowler — https://www.martinfowler.com/tags/platforms.html
  50. Cote — https://cote.io/platform/
  51. Gitbook — https://yoan-thirion.gitbook.io/knowledge-base/xtrem-reading/resources/book-notes/team-topologies
  52. Xebia — https://xebia.com/blog/is-the-paved-road-right-for-you/
  53. Slideshare — https://www.slideshare.net/diannemarsh/the-paved-road-at-netflix
  54. Skippy — https://skippy.net/oscon-2017
  55. Netflix Tech Blog — https://netflixtechblog.com/how-we-build-code-at-netflix-c5d9bd727f15
  56. InfoQ — https://www.infoq.com/news/2021/03/spotify-paved-paths/
  57. LinkedIn — https://in.linkedin.com/posts/grabnerandi_how-we-use-golden-paths-to-solve-fragmentation-activity-7013429552001527808-Hpdi
  58. businessofsoftware — https://businessofsoftware.org/2020/06/lessons-critique-spotifys-failed-squad-model
  59. Jeremiahlee — https://www.jeremiahlee.com/posts/failed-squad-goals/
  60. Container Solutions — https://blog.container-solutions.com/how-monzos-opinionated-platform-and-tools-support-their-developer-experience
  61. Government Digital Service — https://gds.blog.gov.uk/2022/07/12/why-weve-decided-to-decommission-gov-uk-paas-platform-as-a-service/
  62. Service — https://www.cloud.service.gov.uk/
  63. Hitachi Solutions — https://www.hitachi-solutions.co.uk/blog/2022/10/gov-paas-migrate/
  64. Airbnb — https://airbnb.tech/infrastructure/continuous-delivery-at-airbnb/
  65. Uber — https://www.engineering.fyi/article/from-predictive-to-generative-how-michelangelo-accelerates-uber-s-ai-journey
  66. audible — https://www.audible.ca/fr_CA/podcast/Stacked-diffs-and-tooling-at-Meta-with-Tomas-Reimers/B0F3GQ87RC
  67. Medium — https://medium.com/wise-engineering/introduction-to-the-wise-platform-team-b4dffe9d7390
  68. GitHub — https://github.com/NHSDigital/software-engineering-quality-framework
  69. https://digital.nhs.uk/developer — https://digital.nhs.uk/developer
  70. Octopus Deploy — https://octopus.com/blog/adoption-strategies-internal-platforms
  71. https://martinfowler.com/articles/platform-prerequisites.html — https://martinfowler.com/articles/platform-prerequisites.html
  72. https://martinfowler.com/articles/talk-about-platforms.html — https://martinfowler.com/articles/talk-about-platforms.html
  73. https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem — https://engineering.atspotify.com/2020/08/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem
  74. https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/ — https://charity.wtf/2018/12/02/software-sprawl-the-golden-path-and-scaling-teams-with-agency/
  75. https://www.thoughtworks.com/radar/techniques/platform-engineering-product-teams — https://www.thoughtworks.com/radar/techniques/platform-engineering-product-teams

EDITORIAL BRIEF

Commissioned from our research desk. Subject to final editorial discretion.

Challenging the assumption that platform teams automatically create leverage. Explore the failure mode where an internal platform team builds for abstraction and consistency while product teams need speed and exceptions, resulting in shadow infrastructure and political friction. Reference Team Topologies concepts and any available data on internal platform adoption rates versus mandated usage. The takeaway is that a platform strategy only works when it's designed around actual developer workflow friction, not around an architecture diagram.