How to Avoid Platform Engineering Anti-Patterns

How to Avoid Platform Engineering Anti-Patterns ![rw-book-cover](https://img.youtube.com/vi/2uvcglflDi8/maxresdefault.jpg) 🔗 **Source:** [How to Avoid Platform Engineering Anti-Patterns](https://www.youtube.com/watch?v=2uvcglflDi8) > [!note]+ Document Notes > tags: #platform-engineering #devrel #api-architecture #developer-experience > author: LeadDev > source: YouTube > reference: https://www.youtube.com/watch?v=2uvcglflDi8 > date created: 2024-12-19 16:15 > > # 🏷️ Title: How to avoid platform engineering anti-patterns >  ## 🧰 Action Inbox - [H1] Reduce cognitive load by identifying common workarounds — 08:30 #developer-experience - [H2] Implement visibility into platform abstractions — 21:45 #platform-engineering - [H3] Build trust through incident transparency — 35:20 #incident-management ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [CNCF Platform Engineering Community](https://github.com/cncf/tag-app-delivery) - [Platform Architecture by Gregor Hohpe](https://architectureelevator.com/) ## 📝 Summary - Platform engineering experts discuss common anti-patterns that cause platforms to fail their intended purpose of enabling teams - Why it matters: Organizations invest heavily in platforms but often see them become barriers rather than accelerators - Key stakeholders: Platform teams, product engineering teams, engineering leadership, SREs - Risks and tradeoffs: Platforms can become approval gates, accumulate workarounds, and lose trust if not properly managed - Bottom line: Successful platforms fade into the background while making it safe and easy to do the right thing ## 📖 Main Content Platform engineering aims to reduce cognitive load and enable faster delivery, but can easily become counterproductive. The panel identifies several key anti-patterns: pattern proliferation (hundreds of similar but slightly different golden paths), cognitive load increase rather than decrease, platforms becoming approval gates rather than enablers, and over-abstraction that creates black boxes users can't reason about. The experts emphasize that platforms should provide guardrails rather than rigid gates, maintain visibility even when abstracting complexity, and recognize different types of users with varying needs for platform management versus self-service capabilities. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/2uvcglflDi8?t=0) — [H1] Platform engineering anti-patterns introduction - Key idea: Panel discussion on avoiding common platform engineering failures - Evidence: "Sometimes between all of the enterprise scale and evolution platforms can be hard to use and easy to bypass and quietly resented" #### ⏱️ [03:15](https://youtu.be/2uvcglflDi8?t=195) — [H2] Pattern proliferation anti-pattern - Key idea: Golden paths multiply into hundreds of variants defeating standardization - Evidence: "I came back and found hundreds of patterns... 135 or more patterns... Found an awful lot of those patterns were actually duplicates" #### ⏱️ [05:45](https://youtu.be/2uvcglflDi8?t=345) — [H3] Silent workaround accumulation - Key idea: Small frictions compound when multiple teams work around them silently - Evidence: "Teams will accept little bits of friction... if you talk to four, five, six different teams and you realize all of these teams are doing the same workaround" #### ⏱️ [08:30](https://youtu.be/2uvcglflDi8?t=510) — [H1] Velocity drops as platform failure signal - Key idea: Blocked projects indicate platform isn't reducing cognitive load - Evidence: "Velocity will drop... this project is blocked because we're waiting on permissions... we have CI issues" #### ⏱️ [11:20](https://youtu.be/2uvcglflDi8?t=680) — [H2] Cognitive load scale challenges - Key idea: Public cloud increased cognitive load beyond what individual developers can handle - Evidence: "We're asking people who previously were maybe Java developers to suddenly know about Terraform, AWS, Google, Azure" #### ⏱️ [14:50](https://youtu.be/2uvcglflDi8?t=890) — [H3] Embedded vs centralized platform teams - Key idea: Central platform teams with fluid embedding for empathy work better than permanent embedding - Evidence: "We do a embedded like a fluid embedded model where we go spend time with teams... then we bring that information back" #### ⏱️ [17:30](https://youtu.be/2uvcglflDi8?t=1050) — [H2] Multiplayer mode platform approach - Key idea: Decompose platform work across multiple teams contributing components - Evidence: "We've started calling it multiplayer mode... they create their component, other teams have got components and we build a product out of that" #### ⏱️ [19:45](https://youtu.be/2uvcglflDi8?t=1185) — [H3] Avoid big bang migrations with smaller platforms - Key idea: Replace multi-tenant monolithic platforms with managed fleets of smaller platforms - Evidence: "Don't run multi-tenant platforms... lots of smaller platforms and managing the creation of the platforms" #### ⏱️ [21:45](https://youtu.be/2uvcglflDi8?t=1305) — [H1] Over-abstraction creates dangerous black boxes - Key idea: Platforms that hide too much prevent users from reasoning about their systems - Evidence: "When it tries to abstract away too much... you create then too much of a black box... can no longer reason about their systems" #### ⏱️ [24:20](https://youtu.be/2uvcglflDi8?t=1460) — [H2] Three types of platform consumers - Key idea: Organizations have self-managing, orchestration-preferring, and self-service user types - Evidence: "Teams that want to do self-manage... teams that are really good at just orchestrating things via requests... self-service world" #### ⏱️ [28:15](https://youtu.be/2uvcglflDi8?t=1695) — [H3] Platform evaluation through gates vs guidelines - Key idea: Warning sign when platforms focus on checkboxes rather than explaining the why - Evidence: "If I see that it's a lot of check boxes and gates rather than guidelines that explain the why... people don't know why something is important" #### ⏱️ [31:40](https://youtu.be/2uvcglflDi8?t=1900) — [H2] AI agents as new platform users - Key idea: Platforms must support both human and AI agent interactions - Evidence: "We have all these agents that can do stuff for us... not only humans can use our tools but also agents can use our tools" #### ⏱️ [33:25](https://youtu.be/2uvcglflDi8?t=2005) — [H3] 2026 as platform AI adoption year - Key idea: Platform teams will begin serious AI integration after dedicated AI teams establish patterns - Evidence: "2026 is the year that platform engineering teams start leaning into AI" #### ⏱️ [35:20](https://youtu.be/2uvcglflDi8?t=2120) — [H1] Rebuilding platform trust through transparency - Key idea: Public incident management and feature freezes can restore lost platform trust - Evidence: "Every time something broke within the platform, they made an incident for it and out in the open... people started seeing that and they're like, 'Wow, they really care'" #### ⏱️ [38:45](https://youtu.be/2uvcglflDi8?t=2325) — [H2] Successful platform characteristics - Key idea: Platforms succeed when they build trust, enable safety, and fade into the background - Evidence: "A successful platform is one that just fades into the background. It just works" ## 📚 References - [CNCF Platform Engineering Community Group](https://github.com/cncf/tag-app-delivery) - [Platform Architecture by Gregor Hohpe](https://architectureelevator.com/) - [Platform Maturity Model](https://platformengineering.org/maturity-model) - [LeadDev Slack Community](https://leaddev.com/community) ## 🗣️ Paraphrase - Platform engineering anti-patterns emerge when well-intentioned platforms become barriers rather than enablers, often through pattern proliferation, cognitive load increases, and over-abstraction - Organizations at scale need different approaches including multiplayer mode development, fleet management of smaller platforms, and recognition of diverse user types with varying self-service needs - Trust rebuilding requires transparency in incident management, responsiveness to user needs, and platforms that make it safe and easy to do the right thing while remaining largely invisible ## 📰 Newsletter Platform engineering continues evolving as organizations learn from early anti-patterns. This expert panel reveals how platforms can accidentally become the bottlenecks they're meant to eliminate. Key learning: The most dangerous anti-pattern is silent workaround accumulation - when teams quietly work around small frictions that compound across the organization. Platform teams must actively seek this feedback. Practical application: Implement "multiplayer mode" where multiple teams contribute platform components rather than centralizing everything. This scales expertise while maintaining coherence. Helpful insight: Successful platforms balance guardrails with flexibility, provide visibility into abstractions, and recognize that different user types need different levels of platform management. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create anti-pattern awareness content, conference talks on platform trust rebuilding - Education: Workshop series on platform user empathy, cognitive load assessment training - Developer experience: Platform visibility tooling, abstraction transparency improvements - Developer marketing: Case study campaigns on platform success stories, trust rebuilding narratives - Community management: Platform feedback collection systems, workaround sharing forums #### OSPO - Policy & Governance: Platform contribution policies, multiplayer mode governance templates - Strategic Alignment: Platform success KPIs beyond adoption metrics, trust measurement frameworks - Developer Support: Platform user journey mapping, cognitive load assessment tools - Community Engagement: Cross-platform team coordination, component sharing agreements #### Community - Maintainers: Platform component ownership models, fleet management templates - Contributors: Platform feedback mechanisms, workaround reporting systems - Sponsors: Platform ROI transparency, trust rebuilding investment cases #### WordPress - Core: Platform thinking for WordPress.org infrastructure, component decomposition planning - Meta: .org platform services assessment, anti-pattern identification across sites - CLI: Command visibility improvements, abstraction documentation - Hosting: Cross-host platform standardization, golden path simplification - Community: Platform team coordination across working groups ## 🧪 Hypotheses - Platform teams using multiplayer mode achieve better scale than monolithic platform teams - Organizations with visible incident management rebuild platform trust faster than those handling failures privately - Platforms supporting both human and AI agent interfaces have higher long-term adoption - Three-tier user model (self-manage, orchestration, self-service) reduces platform cognitive load better than one-size-fits-all approaches ### 📊 Methodology - Study design: Longitudinal analysis of platform adoption metrics before and after multiplayer mode implementation - Data sources: Platform usage analytics, developer satisfaction surveys, incident transparency metrics - Experiments: A/B testing of platform abstractions with and without visibility tools ### ❓ Questions - How can platform teams systematically detect silent workaround accumulation before it becomes problematic? - What metrics best predict platform trust loss before user satisfaction drops significantly? - How should platform governance adapt when AI agents become primary interface consumers? ### 🔮 Future Research - Quantitative analysis of cognitive load reduction across different platform architectural patterns - Study of platform trust rebuilding timelines and successful intervention strategies - Investigation of AI agent integration patterns in enterprise platform environments ### 💡 Implications - Practice: Platform teams need active workaround detection and user empathy building processes - Policy: Platform governance should explicitly account for different user types and AI agent interactions - Security: Over-abstraction creates security blind spots when users can't reason about underlying systems - Education: Platform engineering training must include anti-pattern recognition and trust rebuilding strategies - Funding: Platform investment should account for trust rebuilding cycles and multiplayer mode coordination costs ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade #### 👀 Visual learners - Present: Limited visual aids in video format - Improve: Platform anti-pattern diagrams, cognitive load visualization charts, multiplayer mode architecture diagrams #### 🔊 Aural learners - Present: Full panel discussion with multiple expert voices - Improve: Structured audio summaries of key anti-patterns, shorter audio segments by topic #### 🗣️ Verbal learners - Present: Rich analogies (car manufacturer model), clear terminology definitions - Improve: Platform anti-pattern glossary, step-by-step troubleshooting narratives #### 🧩 Kinesthetic learners - Present: Practical examples from real organizations - Improve: Platform assessment checklists, hands-on anti-pattern detection workshops #### 🧠 Logical learners - Present: Clear cause-and-effect relationships, systematic problem analysis - Improve: Decision trees for platform architecture choices, anti-pattern severity matrices #### 🧑‍🤝‍🧑 Social learners - Present: Panel discussion format, community emphasis - Improve: Platform team collaboration guides, cross-organization experience sharing forums #### 🧘‍♀️ Solitary learners - Present: Comprehensive content for individual consumption - Improve: Self-assessment tools for platform health, reflective exercises on team platform experiences #### 🌿 Naturalistic learners - Present: Ecosystem thinking about platform environments - Improve: Platform lifecycle analogies, organizational ecosystem impact analysis ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Video has clear speaker transitions, verbal content - Improve: Structured transcript with speaker labels, heading navigation #### Keyboard navigation - Present: Standard video player controls - Improve: Timestamped navigation, keyboard shortcuts for key sections #### Contrast and readability - Present: Video format limits text accessibility - Improve: High-contrast transcript version, customizable text sizing #### Text resizing and reflow - Present: Video content not resizable - Improve: Responsive transcript layout, zoom-friendly interface #### Media and captions - Present: Full transcript provided - Improve: Synchronized captions, audio description for visual elements #### Forms and interactions - Present: Standard video interaction model - Improve: Accessible feedback forms, keyboard-navigable discussion interfaces ### 🌍 DEIB Assessment #### Cultural breadth - Present: UK banking perspective, US tech company examples - Improve: Global platform engineering examples, developing market considerations #### Inclusive language - Present: Technical jargon well-explained, professional tone - Improve: Plain language summaries, avoiding military metaphors (anti-patterns) #### Neurodiversity support - Present: Structured discussion, clear topic transitions - Improve: Content chunking, visual topic indicators, processing time accommodation #### Representation - Present: Diverse panel including different organizational roles - Improve: More varied industry representation, explicit inclusion of different experience levels #### Psychological safety - Present: Respectful discussion of failures and challenges - Improve: Explicit encouragement of sharing platform failures, blame-free problem analysis ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical progression from anti-pattern identification to solutions - Inductive strength: Good use of specific organizational examples to support general principles - Causal reasoning: Clear cause-and-effect relationships between platform choices and outcomes - Analogical strength: Effective car manufacturer analogy for platform-operations separation #### Fallacies - Appeal to authority: Relies heavily on panel expertise without external validation - Hasty generalization: Some conclusions based on limited organizational examples #### Tone of voice - Overall tone: Professional and collaborative, focused on problem-solving rather than blame ### 🛡️ DARVO Analysis - Deny: No denial patterns observed - Attack: No attacks on accusers present - Reverse victim/offender: No victim/offender reversal - Emotional cues: Constructive tone focused on learning from failures rather than defensive positioning ## 🎯 Conclusion Platform engineering success requires --- ## Full Transcript [00:12] Hi everyone. [00:14] Thank you for joining us today on our [00:17] panel discussion on how to avoid [00:20] platform engineering anti-atterns. [00:22] This is a lead dev panel discussion [00:25] created in partnership with Postman. We [00:28] have 45 minutes today after which myself [00:31] and our lovely panelists will join you [00:33] all in the lead dev slack group. So make [00:37] sure you join there and ask and answer [00:40] and talk to us in the panel Q&A channel. [00:46] That's where we'll go to hang out with [00:48] you after this live webinar. We'll also [00:52] answer a couple questions live on air. [00:55] So, please submit your questions through [00:57] the Q&A function on Zoom and we'll get [01:01] to them as we have um you know our our [01:03] panel discussion today. Um again that [01:06] channel for lead dev is panel slash [01:10] nope panel-q- [01:14] a. Um all right so let's get started [01:17] with some introductions. My name is [01:18] Tiffany Jaka and I'll be joining uh you [01:21] all today as moderator. I am a senior [01:25] engineering manager at Yahoo. And we [01:27] also have our panelists who will each [01:29] introduce themselves and give a short [01:32] summary of who they are and why they're [01:34] excited on the pan to be on the panel [01:36] today. Let's start with Aerys. [01:39] >> Hi, I'm Aris Viel. Um I'm staff engineer [01:42] here at Postman. I've been here about a [01:44] year and a half now. Um previous to this [01:47] uh I worked at a bunch of big places um [01:50] Oracle and Amazon AWS and in all those [01:53] places we have platform teams and [01:55] they're all they all work very [01:57] differently. I'm excited to hear uh and [02:00] learn from uh the panelists today about [02:02] the the other side of platform [02:04] engineering. [02:12] I can jump in and go next. Hey everyone, [02:14] I'm Molly. I'm a site reliability [02:17] engineer at Netflix. I've been at [02:19] Netflix for about four and a half years [02:21] and prior to that I was at various [02:24] startups. I am particularly passionate [02:27] about understanding human factors uh [02:30] when it comes to software and often when [02:34] I review incidents to extract lessons [02:36] learned I'm going to be studying [02:38] engineers and how they interact with [02:41] central platform tools and then learning [02:44] how we can actually improve that tooling [02:47] to make it a safer environment for all [02:49] engineers. So I'm really excited to be a [02:51] part of today's discussion and share [02:53] kind of that S sur vantage point. [02:58] >> Hi, I'm Chris Plank. Uh I work for Nat [03:00] West Bank in the UK. Uh I'm a platform [03:04] as a product product owner uh lead [03:07] architect for an initiative that's kind [03:09] of looking at how we use modern platform [03:11] engineering practices across the bank to [03:14] provide managed hosting platforms and [03:16] services to our internal customers. I've [03:19] been building platforms for over 30 [03:21] years. Um, I'm also uh one of the [03:25] community leaders, community group [03:26] leaders for the CNCF platform [03:28] engineering community group. So, I talk [03:30] a lot about platform engineering. [03:34] >> Awesome. Well, yes, our panelists today [03:36] will talk a lot about their experiences [03:38] and their knowledge and their wisdom and [03:40] it'll be an insightful conversation on [03:42] all things platform engineering efforts. [03:44] I know a lot of them start with good [03:46] intentions to help other teams and users [03:50] um you know gain consistency, repeatable [03:53] patterns, reduce cognitive load and [03:55] sometimes between all of the enterprise [03:58] scale and evolution um platforms can be [04:01] hard to use and easy to bypass and [04:04] quietly resented. So this group of uh [04:07] panelists will be talking about that [04:09] today. I'd love to center the [04:11] conversation around anti-atterns since [04:14] that is the webinar title. Um I'd love [04:17] to hear from each of you like when [04:21] platform when platforms start doing the [04:24] opposite of what they're meant to do, [04:25] what can that look like in practice and [04:27] sort of in your day-to-day as well. [04:36] >> Who wants to go first? Hey, [04:39] Chris. [04:40] >> I I'll I'll bite you on this one. Um, so [04:42] I came back to the bank probably 2023. [04:45] Uh, I'd left about 2016, [04:49] just when the bank was starting its kind [04:51] of public cloud journey. And in that [04:53] time when I came back, the first thing I [04:55] found was that they they went down the [04:57] patterns approach, you know, the golden [04:58] path route that a lot of people talk [05:00] about in platform engineering. Uh, and I [05:03] came back and found hundreds of [05:04] patterns. We've talked about this [05:05] publicly before, right? I think I've [05:07] said back then it was about 135 or more [05:10] patterns. Found an awful lot of those [05:12] patterns were actually duplicates. You [05:15] know, they had originally started with [05:16] one pattern, one way of doing things, [05:18] standardizing. That's the golden path. [05:21] And then for whatever reason, [05:22] applications weren't changing. And so [05:25] they started to have -123. [05:29] You end up having lots of patterns that [05:31] are doing roughly the same thing but [05:33] with slight subtle changes. And that [05:35] customization becomes the enemy, right? [05:37] And I think what what you find is those [05:39] golden paths that that fast path through [05:42] governance, that fast approach to [05:44] getting things done. It maybe started [05:46] off like that, but over time they get [05:49] stuffed full of everyone's requirements, [05:52] processes, hoops and hurdles that you've [05:54] got to go through and eventually they're [05:57] no longer the fast path. And then you [06:00] start getting these other little [06:01] variants popping in. Right? So there's [06:03] there's some antiatterns there. You [06:05] know, don't stuff your your golden paths [06:08] with all these processes from all these [06:10] different teams. Don't create kind of [06:13] subtle sub patterns for all the [06:15] different applications. Try and find a [06:17] way that you can actually work on that [06:19] and make them not as rigid, you know, [06:22] open enough to change, but still do that [06:24] in a managed way or you'll end up with [06:27] lots and lots of different things that [06:28] you've got to maintain. And that's [06:30] really difficult, right? We all know how [06:31] hard that can be. [06:35] >> I love Chris, one of the things you [06:37] mentioned is like these little [06:38] variances. And in my experience, one of [06:42] the things I've seen is when teams work [06:44] with a platform, a lot of times they'll [06:47] accept little bits of friction and they [06:49] will just work around that friction. [06:50] Yeah. But it's it's so little for them [06:53] that they won't say anything. But if you [06:56] go and all of a sudden you talk to, you [06:58] know, four, five, six different teams [07:01] and you realize all of these teams are [07:03] doing the same workound and now you've [07:05] got a friction that's been multiplied [07:08] and amplified, right? So, I think it's [07:10] it's super important and something I [07:12] work um diligently to do is to tell [07:15] teams, hey, when you're doing little [07:17] workarounds and frictions, share those, [07:20] communicate those back to the platform [07:22] teams because other folks might be [07:24] experiencing them and if you don't speak [07:26] up, then that snowballs effects, you [07:29] know, into something where the platform [07:31] is being used in in a way it's it's not [07:33] intended. So, I love that call out of [07:35] things start with just little variances. [07:38] um and they get worse [07:39] >> and one or two can just keep on getting [07:42] compounded, right? You keep on adding [07:43] them up and suddenly if you're trying to [07:45] maintain that thing, you can end up [07:47] being spending more time maintaining [07:49] those variances than the actual product [07:52] that you actually really care about, [07:54] right? So, lots of different techniques [07:56] can help with that. I mean, Molly, you [07:58] mentioned, you know, getting them to [08:00] talk. That's probably one of the [08:02] greatest things you can do. a center [08:03] practice, community practice, special [08:06] interest group, whatever it is. If you [08:08] can get these people together and [08:10] talking about why they need the [08:11] variances and actually work through it, [08:15] in a lot of cases, you can actually get [08:17] rid of the need for that because you can [08:19] get them to come to the conclusion that [08:21] they do need to standardize. [08:25] Uh yeah I I I want to add uh a view from [08:28] the side of um the customer of the [08:30] platform from product engineering uh [08:33] what I've seen uh when platforms are not [08:36] working so well is that velocity will [08:39] drop you'll see that um you'll hear [08:41] about okay this project is blocked [08:44] because we're waiting on permissions [08:46] we're not following the golden path we [08:48] have some slight you know deviation for [08:50] our use case we're looking for approvals [08:53] or we have CI issues [08:55] And if you hear these often enough and [08:58] becomes a pattern, then then you know [09:00] you have you have to do something [09:02] because the platform isn't making things [09:04] e easier in in fact it's making things [09:06] harder. [09:08] >> Right. Right. And finding those common [09:11] things that people are saying this is a [09:13] problem. Those are actually what we want [09:15] to go after as platform engineers [09:16] anyway. Right. We want to solve those [09:18] problems for them in a kind of managed [09:21] platform way rather than them having to [09:22] do it themselves. [09:24] Yeah. And as product engineers, we [09:26] should be reporting these instead of [09:28] just quietly working around them as [09:29] Molly was saying. [09:34] >> Yes. Thanks panelists for sharing um [09:37] some thoughts around when workarounds [09:40] can become a sign of failure versus a [09:42] sign of flexibility. Um y'all chatted a [09:45] little bit about cognitive load as well [09:47] and some of the antiatterns. So that's [09:49] really helpful. Uh, I I want to remind [09:52] the p the attendees here that if you all [09:54] have any follow-up questions, just ask [09:56] them in the Q&A, we'll we'll pick them [09:58] up as we continue on the conversation. [10:01] I'd love to pivot a little bit more now [10:02] that we've named some of the [10:03] anti-atterns and what they can look like [10:05] in practice. And I'd love to chat a [10:07] little bit more about what happens to [10:09] platforms when things start to scale. [10:12] Um, so I I have two questions around [10:14] this. Uh let's let's first talk about um [10:17] platforms as approval gates at scale. [10:20] Platforms can often become approval [10:22] gates instead of enablers. How does that [10:24] happen and how do leaders accidentally [10:26] enforce that? [10:33] >> I can kick us off with this one. Um, I [10:36] think especially with uh with platforms, [10:40] you're always looking to strive to find [10:42] a balance between, I like to say, their [10:45] guard rails. You want guardrails on your [10:48] platform that encourage folks to do the [10:51] right thing, but at the same time also [10:54] allow that flexibility. So when you need [10:56] to do the workaround, maybe you're in a [10:59] an incident or something, you've got [11:01] that emergency situation, you want to [11:03] have that flexibility to be able to do [11:05] what you need to do. And that's it is a [11:08] hard um balance to find, but I I think [11:12] there's there's definitely a a balance [11:14] there. I think one of the things um that [11:17] I have seen is sometimes [11:20] platforms go too much towards too many [11:22] guard rails and then they become [11:24] inflexible and then that's when you know [11:26] as Chris mentioned those workarounds [11:27] then those workarounds start to show up [11:29] and so I think keeping a pulse on are [11:34] people doing these workarounds and using [11:36] that as a signal determine okay where [11:38] are we falling in this balance of guard [11:41] rails versus inflexibility [11:46] I love how you mentioned scale because [11:48] scale is the thing that seems to be my [11:50] word and my trigger in in the platform [11:52] engineering community. I talk about [11:53] scale. You know, I work for a a very old [11:56] bank, one of the top four in the UK and [11:58] we're massive, right? We've got over uh [12:00] I think it's over 66,000 staff now uh in [12:04] the organization. I think of India [12:06] alone. I just did a quick kind of AI [12:09] chat there to see how what it comes up [12:11] with as a number rather than logging in [12:13] and checking it. It says it's over [12:15] 17,000 just in our engineering division [12:17] alone. I mean Molly, how how many [12:19] engineers are in uh Netflix as an [12:22] example? Right. [12:24] >> Few thousand couple thousand. [12:26] >> Yeah. [12:26] >> Right. So our scale and our challenge is [12:29] very different and the complexity is [12:31] very different as well as an established [12:34] regulated organization. You know, we've [12:36] got lots of systems, lots of processes [12:38] that you've got to follow for regulation [12:41] purposes. That means you've got lots of [12:43] divisions and lots of teams in the [12:45] organization all trying to do things all [12:48] for their part of the organization that [12:50] contributes to the whole. And so the [12:52] size and scale of dealing with platform [12:54] engineering is is very very difficult [12:56] and and the challenges are very [12:58] different from an org that maybe has one [13:00] platform and does things one ways. We've [13:03] got many platforms used by hundreds of [13:07] thousands of people and so yes it's a [13:10] very very different model and you know [13:12] that the whole question about cognitive [13:13] load and you mentioned that earlier as [13:15] well I think when the cloud came along [13:18] public cloud we started to see the [13:21] requirement for a lot of these teams to [13:23] stand up their own platform engineering [13:24] teams we gave them their tools we gave [13:27] them knowledge we gave them terform [13:29] libraries and things like that we gave [13:31] them processes to follow that gave them [13:33] AWS accounts and they went off and did [13:35] wonderful work, right? But that [13:37] cognitive load just grew and grew and [13:40] grew. There's a great graph in um Max [13:43] Kobeer's platform uh architecture for [13:47] plat platform is it platform [13:49] architecture I think it's called I've [13:51] got it sitting over there. It's a [13:52] brilliant book and a good draft that [13:54] just shows over the rise of the 90s into [13:56] the kind of 2000s and into the 201s. It [13:59] really hits a peak that we're asking [14:01] people who previously were maybe Java [14:04] developers to suddenly know about [14:06] Terraform, AWS, Google, Azure, um all [14:10] these other things on top of what they [14:12] need to know for their subject matter [14:14] expert. Right? And we've seen the we've [14:17] seen a lot of the the kind of shift to [14:19] trying either to shift things more [14:21] things left. I don't really like that. [14:23] That's just adding more cognitive load. [14:25] So some people then start talking about [14:27] shift it down onto the platform team. In [14:29] a small org, you probably got one [14:31] platform team. In a big org, you might [14:34] have dozens or hundreds of platform [14:36] teams. And so you're you're you end [14:39] these anti patterns start coming in [14:40] about well does one team do that? Do you [14:43] spread that across all the teams? You [14:45] know, it's it's quite a different [14:46] challenge. We would say it's at scale. [14:50] >> Yeah. Um, that's a really good point and [14:52] something that's a really good segue [14:54] into one of the Q&A questions that we [14:56] got here, which is around how platform [14:59] engineers and platforms can evolve as [15:02] engineering orgs grow. So, I'd love uh [15:05] to answer this one live. Um, someone had [15:07] had asked how do you see a platform [15:10] engineer fitting into an organization as [15:12] an individual in embedded in teams or [15:15] some kind of combination? [15:22] I can take this one. So I think [15:27] as you mentioned as as an or as a [15:29] company grows how they're going to do [15:31] platform engineering maybe they never [15:33] did it and now they start to do it. I [15:35] think one of the keys is, you know, when [15:38] you're big enough, you you want that [15:40] central platform team, someone who can [15:42] deeply understand um and help build that [15:44] platform, but they always have to be [15:47] connected to the product teams that are [15:50] going to be using the platform. And so I [15:52] don't think you need that kind of [15:54] embedded model. Um that that is hard to [15:57] scale. You know, when we're talking [15:58] about scale and growing, that can be [15:59] very hard when you have individuals that [16:01] are off on all these teams. But I I do [16:04] think there is a lot of benefit [16:09] for those central platform engineers to [16:11] go out and spend time with the product [16:14] teams. I will say I'm part of an SRE [16:17] team and we do a embedded like a a fluid [16:21] embedded model where we go we spend time [16:24] with teams we start to understand their [16:26] challenges and then we bring that [16:27] information back to to our centralized [16:29] tooling. And so I think there's a huge [16:31] benefit um for platform engineers to [16:35] stay close to the the folks that are [16:37] going to be using using their tooling [16:38] and understanding them. [16:41] >> Totally. [16:42] >> I really like that uh Molly. Um yeah, [16:44] that makes a lot of sense. Uh one thing [16:47] I I feel like uh platform engineers uh [16:51] should gain empathy for uh what uh uh [16:54] product engineers are experiencing and [16:56] being doing this uh type of work with [16:59] them makes a lot of sense. And one other [17:02] alternative is to dog food uh the the [17:04] platform, right? Build things on top of [17:06] the platform so you you feel what other [17:09] engineers are feeling and then you can [17:11] see the problems where it need needs [17:13] more attention. [17:15] We call that drinking your own champagne [17:17] in Europe rather than dog food. But give [17:20] me [17:22] >> I support that more than dog food. [17:25] >> It's nicer, right? Um I I mean in our or [17:28] we we have the scale challenge, right? [17:30] And we've got lots of different platform [17:32] teams. So the model that we've started [17:34] moving to and I talk a lot about is [17:36] having those existing teams contribute [17:39] uh their components, right? They're [17:41] component platforms really and then we [17:43] create products that are composite of [17:45] many different teams components. Um [17:49] we've started calling it multiplayer [17:50] mode. If you think in the past platform [17:53] teams I'll just choose a random platform [17:56] open shift. You probably had an open [17:59] shift team that did everything to do [18:01] with that platform, right? They built [18:03] it, they ran it, they supported it, they [18:05] did updates, they had to release new [18:07] features. They had to work with the [18:09] customer on all customer requirements. [18:10] They did everything. And if that was [18:13] just one of your platforms and you had [18:15] 100 teams, 100 different teams pretty [18:17] much doing similar things, right? [18:20] Similar processes and things that they [18:22] to do. So in the model, we've kind of [18:24] decomposed that. We get those teams to [18:26] do the engineering, whether it's an [18:28] onboarding to their platform or stand up [18:31] an instance of their platform. There's [18:33] many different types of products, right? [18:35] But they comp they create their [18:36] component other teams have got [18:39] components and we've got reusable [18:41] components and then we build a product [18:42] out of that that we expose to the [18:44] customers and so you've got more scale [18:47] more people able to help you right it's [18:49] one of the ways of reducing the [18:51] cognitive load on one team and scaling [18:54] it out you get everyone to contribute [18:56] and the best thing about that model is [18:59] these other business unit teams I think [19:01] you used a different term for them Molly [19:03] I think you used [19:05] product teams uh because that's your [19:07] internal customers, right? But you can [19:09] actually get them to inner source [19:11] contribute to that model as well. You [19:13] know, if there's something that they've [19:14] been doing in their area, they've been [19:16] self-managing, self-engineering that, [19:18] they can actually turn that into part of [19:20] the managed product as well. So, you get [19:22] a good way that different whether it's [19:25] product engineering teams, whether it's [19:27] consumers can actually use inner [19:29] sourcing to contribute quite a lot to [19:31] that model. [19:37] I love it. I love the insight on how you [19:40] can approach building platforms in an [19:42] iterative man manner. We did get a um [19:46] question in the Slack channel and I see [19:49] it in the Q&A and I want to get to it. I [19:51] will get to everybody's questions as [19:53] well. I I think there's a particular [19:54] order here that we can go and approach [19:56] them, but there was a question on how to [20:00] um and you all can read it. It's the [20:01] last one. How do we avoid the big bang [20:03] migration anti-atterns for for more [20:05] mature apps or mature organizations? [20:08] Specifically, are there strategies that [20:10] allow teams to adopt certain platform [20:14] capabilities alakart versus doing like a [20:16] full painful replatforming or make this [20:20] big push to platform engineering. [20:23] >> Don't don't run multi-tenant platforms, [20:26] right? We've we've had a lot of [20:28] conversations about that uh in in the [20:30] community, you know, and um we've heard [20:32] from some of the hyperscalers as well [20:34] where they've seen people who run like [20:36] Kubernetes platforms. Originally, people [20:38] might have started with one Kubernetes [20:40] platform, they spent all their time [20:42] making a multi-tenant and they end up [20:44] having kind of this situation where all [20:46] eggs are in one basket and what happens [20:48] if one, you know, you got one egg that [20:50] breaks, right? It goes over all of them. [20:52] It's kind of the noisy noisy neighbor [20:55] type approach, right? that you you end [20:57] up having a problem and it affects [20:59] everyone. So they've they've talked [21:01] before about you know seeing people move [21:03] away from that one big platform to lots [21:06] of smaller platforms and managing the [21:10] creation of the platforms the onboarding [21:12] to those but it it it separates out your [21:15] kind of blast radius into much smaller [21:17] chunks and then you think about how you [21:20] manage that as a product and how you [21:23] start updating things as a fleet. So [21:25] instead of managing like snowflakes or [21:27] one particular thing, you've now got [21:29] into this kind of fleet managed approach [21:31] where you can manage your product and [21:33] the roll out of those features to the [21:35] entire fleet in a controlled way. Um [21:37] it's an evolving field. I'll be honest, [21:39] we're tipping our toes in that is that's [21:42] our our uh new model. We still have lots [21:44] of traditional multi-tenant platforms [21:47] where we do on boarding type products [21:50] onto those. Um and I think you'll always [21:52] get that mix, right? I mean some some [21:54] products like a paz platform by their [21:57] nature they're meant to be a [21:58] multi-tenant platform right and you just [22:01] have techniques of how you've got [22:02] multiple nodes and multiple instances [22:04] and dual deployments and cut across and [22:07] all these good techniques but yeah [22:10] there's no one one sizefits-all in our [22:12] industry right that's what keeps us in [22:14] the job for uh 30 years [22:21] >> awesome uh and Maybe uh Molly Eris, you [22:24] you all have more to share on this one, [22:27] but um there was a question about how [22:29] much platform [22:31] product comes from platform engineers [22:35] versus technical product managers or [22:38] more the inerial side. [22:44] That's a great question. I you know I [22:47] can't help but think that um [22:50] if your you know your TPMS or your your [22:54] product managers um are doing their jobs [22:58] I would I would assume that they are [23:00] very in tune with the needs of the [23:04] customers of the platform um and and [23:09] being able to help set that direction [23:13] alongside um engineer [23:16] So at at Netflix, you know, we're we [23:19] have a very collaborative environment [23:20] where you've got engineers, you've got [23:23] product managers, program managers, [23:25] everyone's really working together to [23:27] understand the customer needs for a [23:29] platform and then create that ideal [23:32] vision and and path forward. So [23:36] I think it's it's in the ideal world [23:38] it's a collaboration of all those folks [23:40] coming together using their different [23:42] vantage points um using that as input to [23:45] then you know come up with um the ideal [23:48] uh evolution for for a platform. [24:00] >> Thank you. Um, we also had uh we have a [24:04] lingering question here um around [24:06] evaluating platforms. Eris, uh maybe you [24:09] have some more to add to this one, but [24:11] are there obvious symptoms, signals uh [24:14] that can maybe be a big part of noticing [24:19] that maybe something's wrong with a [24:20] platform or something's maybe not quite [24:23] meeting expectations? [24:26] uh I if I see that it's a lot of check [24:30] boxes and gates um rather than [24:34] guidelines of that explain the why of [24:37] why we do things a certain way that kind [24:40] of worries me because then uh if people [24:44] don't know why something is important [24:46] they'll just want to check the box as [24:48] easily as possible rather than trying to [24:50] do the right thing. So if uh if if I see [24:54] that this is the kind of platform like [24:56] that doesn't explain then I I I I get [24:59] worried. [25:01] >> That's a good point and is a good segue [25:03] into um moving on from scale and talking [25:07] more about governance and access and how [25:09] do we onboard folks onto platforms. Uh [25:12] we had a question in the Q&A here around [25:16] um you know you all suggestions are [25:18] there ways to make platform [25:22] uh to make a platform open to [25:24] experimentation and discovery without it [25:26] becoming um open or prone to shadow IT. [25:31] >> So I think I can kind of segue into this [25:33] one. I wanted to build on um what Aris [25:35] is saying about GES and stuff. I think [25:38] one of the biggest kind of anti-atterns [25:41] that I have seen on a platform is when [25:43] it tries to abstract away too much. So [25:48] you try to take as much of that load off [25:50] of those product those those customers [25:52] using it. But in my experience what I've [25:55] seen is that you create then too much of [25:57] a black box. So those customers the [26:00] service owners using the platform can no [26:03] longer reason about their systems what [26:05] it's doing. And I have seen that, you [26:08] know, cause so many problems um in and [26:11] issues for teams. So I think being able [26:14] to give that insight into what the [26:17] platform is doing and kind of building [26:20] on to that last question about like how [26:22] do you kind of encourage that [26:23] experimentation [26:25] if you have a platform that yes it can [26:28] manage a lot for the users but at the [26:30] same time gives detailed visibility into [26:33] okay this is what I'm doing these are [26:35] the steps I'm taking that's going to [26:37] allow users to understand what's going [26:39] on and that's going to I think open up [26:41] those doors and and make it a more [26:43] inviting experience to maybe they want [26:46] to try something new, maybe they want to [26:48] experiment, maybe they want to make a [26:49] suggestion. So, I think really keeping [26:52] that platform visibility [26:54] even as you're abstracting things away, [26:56] always making sure those abstractions [26:58] are visible um and understandable to the [27:01] the users of the platform. [27:05] that depending on how big you are and [27:07] the number of platforms you've got, you [27:08] don't you don't necessarily need to [27:10] mandate the platform. You can let the [27:12] market decide kind of the approach [27:14] you're going to take. You know, we we're [27:16] again because we've been at this a long [27:18] time. We've got lots of different [27:19] platforms. We've kind of got three types [27:22] of consumer. We have the teams that want [27:25] to do self-manage and self-engineer [27:27] predominantly in public cloud. They can [27:30] do what they they really want to do [27:31] inside guide rails, right? And the guide [27:33] rails are regulatory. They're safety [27:36] security, but they're not, you know, [27:39] they're not kind of constraining their [27:40] creativity, right? They can literally [27:42] pick up some terform and do what they [27:44] like. Not every team's got that money. [27:46] Not every team's got the the skills and [27:49] the people to do that, right? So, you [27:51] also have teams that are really good at [27:53] just orchestrating things via requests, [27:55] what we used to call ticket ops, right? [27:57] where some other team provides those [28:00] things for them or some other platform [28:01] does it. You know, like give me two VMs, [28:04] give me a load balancer, here's the [28:05] firewall rules for that and I need a [28:07] database, right? And that's [28:08] predominantly the pattern. Their [28:10] creativity isn't so much in writing [28:12] Terraform or or doing that stuff. It's [28:15] more in the patterns and the way they [28:16] wire things together. And then you've [28:19] got this new world, kind of the [28:20] self-service world that a lot of us talk [28:22] about now in platform engineering where [28:24] we're kind of trying to reimagine all of [28:26] that stuff, trying to look at what's [28:28] most used and say, "Hang on a second. [28:31] We've got x amount of groups doing this. [28:34] Let's turn that into a managed product. [28:36] We've got x amount of people doing that. [28:38] Let's turn that into a managed product. [28:40] And let's encourage them to use that so [28:42] they can do other innovative innovative [28:45] stuff. So don't stop them having the [28:47] access to do the innovation but look at [28:50] what they're doing cherrypick the best [28:52] things and then make those common [28:54] products for them right that you can [28:56] then you essentially you've reduced that [28:58] cognitive load you've reduced the time [29:00] to delivery and the cost and the need [29:02] for lots of people to look at that [29:03] separately and you've centralized it in [29:06] some way right um that's where I think [29:09] we certainly talk about you know getting [29:11] the benefits from doing that uh so [29:13] you've got the kind of the best of all [29:14] these worlds right people can still have [29:16] the access to do what they need to do in [29:18] their own time scales, but it takes time [29:21] to take things and turn them into [29:22] products. So, it gives you a good [29:24] balance, I think. And the market can [29:27] decide, right? They can choose whether [29:28] they want to use that or just do it [29:30] themselves. [29:32] >> I love how you've divided your customers [29:34] and you you you deal with them in [29:36] different ways. What you know, what's [29:38] appropriate like how much level of [29:40] management you want to provide for them [29:42] at SC. Yeah, it's it's it's it's [29:45] not a like a division. It's more a [29:46] recognition that you've got these these [29:48] different types of consumers. I think [29:50] that's I think that's that's life, [29:52] right? Not everyone wants things done by [29:55] someone. They they they've got the real [29:57] creative that they want to go off and do [29:58] it themselves. And we should foster [30:00] that, right? We should encourage that. [30:02] Um because those sparks of creativity, [30:05] you know, never know what's going to be [30:06] there that might suddenly be a game [30:08] changer, right? Where did the I come [30:10] from, right? Was it just Azimov thinking [30:13] about that and writing about that way [30:15] back when? Right. That was a spark of [30:17] creativity. [30:22] >> Yes. And I appreciate the insight into [30:25] like how you all um help guide you know [30:29] like what standards, what concerns [30:33] should belong to certain things in the [30:34] platform, what goes around the platform. [30:37] Um, we had a question that was very in [30:40] in the lines of what Chris you were [30:42] sharing. Um, it comes from an anonymous [30:46] attendee. Do you still centrally [30:49] orchestrate the deployment of [30:50] infrastructure and hand it off to like [30:52] an ops subplatform team or do you have a [30:55] central platform kind of building blocks [30:57] team that's more focused on like [31:00] building your platform in each of your [31:02] areas? So, I guess you all can chime in. [31:04] >> Yeah, I'm sure that's someone in my or [31:06] right. I probably know who it is [31:08] the way they've asked that question. Um, [31:12] yes, we have we have a my team platforms [31:15] of products is is a central team in in [31:18] technology. Um, where we're trying to [31:20] build those those hosting platforms and [31:22] we act as that product management type [31:24] capability. We create the products and [31:26] we release the products. We work with [31:28] the customers on their requirements. We [31:30] then work on the other side with [31:32] enablement teams and with uh component [31:34] teams to create their components and we [31:37] bring all that together and release it [31:38] and then after that uh the you know the [31:41] the an S sur and we call them C function [31:45] would then support those running [31:47] instances and the component teams would [31:49] then continue with the engineering of [31:51] new features big updates but you know [31:54] the the actual day-to-day updates would [31:55] get done by kind of the S sur team uh [31:59] they would deal with kind customer [32:00] problems, right? And it would also then [32:02] have that feedback loop with the [32:04] customers as well that if these [32:07] incidents happen, they can then go in [32:09] and then they can fix those, but they [32:11] can contribute back to the code as well. [32:13] And the ultimate aim that I've talked [32:14] about a lot in the community is, you [32:17] know, it's probably a 5year journey to [32:19] get to a real true inner sourcing model. [32:22] You have to have some products there [32:24] first that people can touch, they can [32:26] consume, they can build up trust on [32:28] those before they start contributing to [32:30] those. And so it t it actually takes [32:33] longer than you think to get business [32:34] units to contribute. Um at the moment [32:37] most of our uh uh early adoption [32:40] customers and consumers, they're they're [32:43] providing requirements and feedback and [32:46] testing and ideas. [32:48] um not so much contributing the code [32:51] yet. I think that that code contribution [32:53] for them will come later. We have all [32:56] the other platform engineering teams [32:58] contributing code and doing it for their [32:59] components, but I've yet to see that [33:02] kind of ignition with the business units [33:03] starting to lean in. Um we do have some [33:06] not saying it doesn't happen. You know, [33:08] we've got a business unit that went off, [33:10] took uh a lot of Terraform, standardized [33:12] that, made it available for other [33:15] business units to consume, and we've [33:17] pulled elements of that back into the [33:19] central thing. That's what I was talking [33:20] about where, you know, you can see these [33:22] good things that people have done [33:23] creatively, and you can pull that into a [33:26] product, right? It takes time to do [33:28] that, to take it from one area and bring [33:30] it into another because you have [33:32] different opinions about how things are [33:35] done when it's a a managed product [33:37] versus when it's just for kind of one [33:39] vertical, right? You've got lots of [33:40] other things to consider. I'm sure that [33:43] was Alistister that asked that question. [33:47] Find out tomorrow. [33:54] Molly, Eris, anything to share on on [33:56] your side? [34:00] >> I think Chris uh really covered it. I I [34:03] will say um I think one of the things [34:05] you do have to be careful of when you're [34:06] kind of building a platform and then [34:08] maybe handing off operations um is [34:11] keeping those two functions as close as [34:14] possible. Um so that the people who are [34:18] operating it aren't necessarily the only [34:20] ones feeling the pain. And so I think [34:21] that's something to to watch out for. [34:23] And if you are kind of handing off those [34:25] operations um and then you know the [34:28] building like making sure those [34:29] functions are very close um so you've [34:31] got those great feedback loops in order [34:33] to improve. [34:35] Greg Gregor hope covers that very well [34:37] in his book about platform engineering [34:39] you know in his architecture elevator [34:42] series he uses analogy of a kind of car [34:45] manufacturer. If you ever read his [34:46] books, it's always about cars, right? [34:48] Um, and it's kind of, you know, car [34:52] manufacturers create the car, they sell [34:55] the car, people then use the car, but [34:58] they never take it back to the [34:59] manufacturer to get it fixed. You take [35:01] it to a dealership or an independent [35:03] garage. And you've got that kind of [35:06] recall feedback, right? If there's [35:07] something commonly wrong, it does go [35:10] back to engineering, you know, back to [35:12] the factory, right? To make factory [35:14] level changes. [35:15] But once it's out there in the in the [35:18] wild really, it's, you know, it's it's [35:20] another division that's dealing with the [35:22] the updates and and and dealing with the [35:24] consumers, right? It's a really really [35:26] powerful analogy. I think that kind of [35:28] talks about the model that we were [35:29] trying to implement. That's how they've [35:31] scaled and that's how you scale these [35:33] things out. Um, so it's yeah, it's [35:36] definitely a pattern. It's not the only [35:38] pattern, right? But it's it's it's a I [35:40] find it a good pattern. [35:42] >> Yeah. Thank you. Um, I know we talked a [35:45] lot about patterns and themes. Um, I'd [35:48] love to double down on some of the [35:50] conversations that we've had around [35:52] pioneering and creativity. Um, you know, [35:55] with a lot more [35:58] AI in the mix in our uh, organizations [36:00] and enterprises and in our platforms, [36:03] I'd love to hear from you all like what [36:05] role do AI agents play in the platforms [36:07] that you're working on and how should [36:09] leaders really be thinking about this? [36:16] I can get us started. Um I think because [36:20] of AI today, right, we want we have all [36:23] these agents that can do stuff for us. [36:26] We should be building in a way that um [36:29] not only humans can use our tools but [36:31] also a agents can use our tools. So that [36:34] means um we have to get our interfaces [36:37] right. We have to get our APIs very [36:39] clear, our documentation very clear. um [36:42] so that not only humans but people can [36:45] use their agents to automate things and [36:48] uh it's just very powerful time we are [36:50] in today. On top of that like [36:53] documentation should used to be the the [36:54] most difficult thing to keep updated [36:57] right but now we have AI it can do it [36:59] for us and we should should take [37:00] advantage of that. [37:05] I think with AI you've got kind of [37:08] another user base if you will right so [37:10] you've got your human who are [37:12] interacting with platform and now as RS [37:14] mentioned you have a you know agents [37:16] interacting with your platform and [37:18] sometimes doing so quite autonomously [37:21] and so again when you go back to [37:23] thinking about [37:26] or you know architecting a safe platform [37:29] you want to make sure those guardrails [37:31] those gates are kind of in place. So [37:33] depending on what kind of user is coming [37:35] into your platform, um they're set up to [37:38] succeed and and not gonna flip the wrong [37:41] switch that you didn't want them to to [37:42] flip. And so I think when you think AI, [37:45] that's like agents are another, you [37:47] know, new user base that we've got to [37:48] consider with platforms. [37:52] >> I I think 2026 is the year that platform [37:54] engineering teams start leaning into AI. [37:58] you know, in in certainly in big orgs um [38:01] for the last few years, the teams that [38:03] have been innovating and delving into AI [38:06] have predominantly been um you know, [38:09] they've been a dedicated team, right? [38:11] They've been mandated, you're the AI [38:12] experts for the orgs. You're going to go [38:14] off and investigate this. You're going [38:16] to come up with AI gateways. You're [38:17] going to come up with standards. You're [38:19] going to come up with patterns, [38:20] products, all that sort of stuff. I [38:22] mean, I think I'm right in saying our [38:24] Kora AI uh agent has a little chatbot. [38:29] Um it's probably 10 years old now and [38:31] it's evolved over time, right? That was [38:33] probably our first foray in AI. We've [38:35] got an entire division that looks after [38:37] AI, but my platform stuff doesn't yet do [38:41] much in the AI space. We've got business [38:43] units hugely successful, right? The one [38:45] the different types I talked about. Um [38:48] we're not yet using it in the platform [38:49] space. And we've talked about this, we [38:51] actually talked yesterday in the [38:52] community about some of this stuff. Um, [38:54] we put it up as one of the optional [38:56] questions for people to have a chat [38:57] about and they weren't too interested in [38:59] AI. There's still other priorities in [39:01] the platform engineering space that [39:03] people want to focus on. It's not part [39:06] of the CNCF platform maturity model, for [39:08] example, that came out two years ago, [39:11] and AI isn't isn't mentioned in it in [39:13] any of the levels, right? It's one of [39:15] the one of the many updates we want to [39:17] start working on on that model this [39:18] year. But we do we do feel that it's [39:20] that's kind of the direction that a lot [39:22] of again I've got to watch what I say. [39:24] I'm talking about hosting platforms. [39:27] There will be teams who do AI platforms [39:29] already probably in those business units [39:31] right that look after AI that are doing [39:34] this. But in general when we've talked [39:36] about in the community it's not it's not [39:38] the thing that people are doing yet like [39:40] you know using MCPs to uh build [39:43] platforms right but that we think that's [39:45] inevitable. We've seen some really [39:47] powerful stuff over the last 6 months. [39:50] Go back to CubeCon. Some fantastic demos [39:53] from people of what they've been doing. [39:55] And I think that's now seeping into all [39:57] the team's plans for 2026. I'm normally [40:00] called John Connor, you know, because [40:02] I'm just totally anti-AII and I'm an old [40:04] guy, right? Uh 80s reference there for [40:07] anyone who doesn't know the film. And um [40:10] I'm starting to embrace AI in a big way [40:12] and start using it and get involved and [40:15] you know start thinking about how we [40:16] apply that to platforms. So if the John [40:18] Connor of the world's doing that then [40:20] you know guaranteed the younger people [40:22] are going to be doing that for sure. [40:27] >> Yeah. It's one of the things that we're [40:29] doing as well at Yahoo. We have like two [40:32] new backend we call them squads but [40:34] they're really like teams. Um and they [40:36] kind of go hand inand right like the [40:38] plat with the platform play. We have one [40:40] that's centrally like for AI and one [40:43] that's also centrally for all things [40:45] content. U which is pretty interesting. [40:47] Um but yeah, some of the things that [40:48] we've seen here uh as well. [40:50] >> I I've got one of my customers who's in [40:52] in that organization that's that's you [40:55] know responsible for AI now leaning in [40:58] and co-creating with us and and talking [41:00] about kind of the the AI platform [41:02] enablement. They've done stuff. Now, how [41:04] do we bring that into we provide that as [41:06] a managed platform, right? Which is [41:07] really exciting. It's a completely new [41:09] language for a lot of us platform [41:11] people, you know, that are coming from a [41:13] kind of CISAM type background. And then [41:15] you look and see some of the chat [41:16] prompts, it's all like, you know, oh, [41:17] it's a command line. That's our world. [41:20] >> Yeah. [41:23] >> Good, good, good. I know we are almost [41:26] at time. I'd love to just ask I'd like [41:29] to just sneak in one more thing and then [41:30] we'll do closing statements. Um uh and [41:34] if we didn't get to any Q&A questions, [41:36] we we will in the Slack channel. Um I'd [41:38] love to just chat more about getting [41:40] back on track. So, you know, we we've [41:43] everybody on the panel here has shared [41:44] so many um wonderful wisdom and [41:47] insights, but like let's say you're in a [41:50] position where you have a platform [41:51] that's already lost trust. What are what [41:54] are some ways that you can win engineers [41:56] back or your users back uh to that [41:58] platform? maybe share a story or two on [42:00] on how you know you could like a true [42:02] comeback story. [42:05] >> I um I'm happy to share on this one. I [42:07] think uh you know I' I've had an [42:09] experience in my past where working with [42:12] a platform team that had lost a lot of [42:14] trust um from its users and they [42:17] actually decided they were going to lean [42:19] into [42:21] more visibility when the plat platform [42:23] broke. So they started leaning into [42:24] incidents and incidents in the open. So [42:27] every time something broke within the [42:29] platform, they made an incident for it [42:32] and out in the open they were triaging, [42:34] they were working on it and people [42:36] started seeing that and they're like, [42:37] "Wow, they they really care." So that [42:40] started building trust. Um, then this [42:43] team was able to use all of this data in [42:48] order to [42:50] advocate for a six-month feature freeze [42:53] so that they could just focus on the [42:56] platform and stability. And in that [42:59] time, they completely 180ied and turned [43:01] the platform around. So, I think when [43:04] you have a platform that's struggling, [43:07] um, one, work out in the open with your [43:09] stakeholders. Um, that's going to build [43:11] trust. They're going to see. Don't fail [43:13] in private. Fail out in the open. So [43:15] then people, ah, okay, they're on it. [43:16] And as soon as people see you're on it, [43:18] it's amazing. They just, they back off [43:20] because they're like, we're going to let [43:21] them do their work. And then use the [43:24] data. Use the data for the the toil it's [43:27] causing um, in order to advocate to your [43:30] leaders uh, when you need space um, and [43:32] take that space to do it. Otherwise, [43:34] you're just going to be in reactive mode [43:36] for the rest of the life of the [43:38] platform. and and that's no one as an [43:40] engineer wants to be in purely reactive [43:42] mode. So I think um yeah that's a a [43:45] tidbit from my experience I wanted to [43:46] share. [43:51] >> Uh I know we have a few minutes left. Um [43:54] so in closing I'd love for uh all the [43:57] panelists to to share some closing [43:59] statements. Um primarily to fill out [44:03] this sentence. A successful platform is [44:07] one that [44:10] and we can start with Chris. [44:11] >> Oh, I was just writing that down there. [44:13] Okay. Um, I'll follow on from what we're [44:16] saying about losing trust. I think takes [44:18] a long time. Sorry. A successful [44:20] platform is one which uh works with the [44:24] uh consumers of that platform and builds [44:26] that trust. Um, takes a long time to [44:29] build trust. Uh, it takes only a second [44:31] to lose it. Right. So just just [44:33] following on from what we were [44:34] discussing there, you know, you really [44:36] need to uh work with your consumers, [44:38] work hard, uh co-create, be responsive, [44:42] um keep some capacity in reserve for [44:45] when they come along with requirements, [44:47] and you know, they need things in a [44:49] hurry, and you're you're able to [44:50] demonstrate that you're responsive. I [44:52] think that responsiveness in a platform [44:55] team breaks all of those kind of um [45:00] visions that people have about platform [45:01] teams not being responsive, right? If [45:03] you can actually take a requirement and [45:05] turn it around really quickly, that's [45:07] what's going to build the trust with the [45:09] consumers, right? [45:13] >> I love that. I can go next. So a [45:15] successful platform is one that is safe [45:18] to operate because it makes it easy for [45:21] engineers to do the right thing. So [45:24] again like investing in those UIs, [45:26] making destructive actions, they've got [45:28] warnings, they got big red buttons, you [45:30] know, you're doing something that is, [45:32] you know, is is going to alter things. [45:35] So I think safe platforms um that make [45:38] engineers jobs easier. [45:42] Uh and on on my side, a successful [45:45] platform is one that just fades into the [45:47] background. It just works except for the [45:50] big big banners that that Molly said [45:52] that hey, you're doing something scary. [45:55] Um but if it just works, that's that's [45:57] the successful platform. [46:00] >> Wonderful. Well, thank you so much for [46:02] the good insights in today's panel. We [46:04] will now be heading over to the lead dev [46:07] Slack in the panel dash Q-N- [46:12] A channel. So, please sign us there. Our [46:16] wonderful panelists will answer the [46:18] remaining Q&A questions that we didn't [46:20] quite get to today. And if you know [46:23] there's anything that they said that [46:24] really inspired you, put it in the [46:26] channel. We'd love to see it. Uh thank [46:29] you all so much for joining and we hope [46:31] to see you next time. Thanks all. [46:33] >> Awesome. Punch. [46:46] Uh-huh.  📄 **Full text:** ![[Full Document Contents/Articles/How to Avoid Platform Engineering Anti-Patterns|How to Avoid Platform Engineering Anti-Patterns, YouTube]] ## Highlights - a lot about platform engineering. >> Awesome. Well, yes, our panelists today will talk a lot about their experiences and their knowledge and their wisdom and it'll be an insightful conversation on all things platform engineering efforts. I know a lot of them start with good intentions to help other teams and users um you know gain consistency, repeatable patterns, reduce cognitive load and sometimes between all of the enterprise scale and evolution um platforms can be ([View Highlight](https://read.readwise.io/read/01km99b3kwvbxcw10a45f6m46k)) - Tags: 👻 ai highlighted - you have you have to do something because the platform isn't making things e easier in in fact it's making things harder. >> Right. Right. And finding those common things that people are saying this is a problem. Those are actually what we want to go after as platform engineers anyway. Right. We want to solve those problems for them in a kind of managed platform way rather than them having to do it themselves. Yeah. And as product engineers, we should be reporting these instead of just quietly working around them as Molly was saying. ([View Highlight](https://read.readwise.io/read/01km99b3mnjp7m1thq3bnq9vwa)) - Tags: 👻 ai highlighted - are off on all these teams. But I I do think there is a lot of benefit for those central platform engineers to go out and spend time with the product teams. I will say I'm part of an SRE team and we do a embedded like a a fluid embedded model where we go we spend time with teams we start to understand their challenges and then we bring that information back to to our centralized tooling. And so I think there's a huge ([View Highlight](https://read.readwise.io/read/01km99b3qeygjepa26rfg7yjk8)) - Tags: 👻 ai highlighted - benefit um for platform engineers to stay close to the the folks that are going to be using using their tooling and understanding them. >> Totally. >> I really like that uh Molly. Um yeah, that makes a lot of sense. Uh one thing I I feel like uh platform engineers uh should gain empathy for uh what uh uh product engineers are experiencing and being doing this uh type of work with them makes a lot of sense. And one other ([View Highlight](https://read.readwise.io/read/01km99b3rsm0fk8gxfp79qcypm)) - Tags: 👻 ai highlighted - with that platform, right? They built it, they ran it, they supported it, they did updates, they had to release new features. They had to work with the customer on all customer requirements. They did everything. And if that was just one of your platforms and you had 100 teams, 100 different teams pretty much doing similar things, right? Similar processes and things that they to do. So in the model, we've kind of decomposed that. We get those teams to do the engineering, whether it's an onboarding to their platform or stand up ([View Highlight](https://read.readwise.io/read/01km99b3tf9k09r1g1jvermsqf)) - Tags: 👻 ai highlighted - service owners using the platform can no longer reason about their systems what it's doing. And I have seen that, you know, cause so many problems um in and issues for teams. So I think being able to give that insight into what the platform is doing and kind of building on to that last question about like how do you kind of encourage that experimentation if you have a platform that yes it can manage a lot for the users but at the ([View Highlight](https://read.readwise.io/read/01km99b3z5pef674s7t049wwz9)) - Tags: 👻 ai highlighted - building your platform in each of your areas? So, I guess you all can chime in. >> Yeah, I'm sure that's someone in my or right. I probably know who it is the way they've asked that question. Um, yes, we have we have a my team platforms of products is is a central team in in technology. Um, where we're trying to build those those hosting platforms and we act as that product management type capability. We create the products and we release the products. We work with the customers on their requirements. We ([View Highlight](https://read.readwise.io/read/01km99b42kfwzwnhmjevvb50hv)) - Tags: 👻 ai highlighted - visions that people have about platform teams not being responsive, right? If you can actually take a requirement and turn it around really quickly, that's what's going to build the trust with the consumers, right? >> I love that. I can go next. So a successful platform is one that is safe to operate because it makes it easy for engineers to do the right thing. So again like investing in those UIs, making destructive actions, they've got warnings, they got big red buttons, you ([View Highlight](https://read.readwise.io/read/01km99b48j48czqcm11n7qkght)) - Tags: 👻 ai highlighted