Engineering Platforms Evolved
summary
Calls for treating internal platforms as products with clear ROI, not just tooling: use value‑stream mapping, quantify costs and projected break‑even, and prefer platform funded by tech exec over draining feature budgets. Start with white‑glove onboarding and early adopter teams to create evangelists; measure leading metrics (onboarding time, workloads/day, adoption rate) and radiate them via a portal (Backstage is a window not the platform). Runs experiments with DX surveys (90% response vs 18% Google Forms) and LLM‑assisted failure analysis of AWS architecture diagrams.
AI-written summary · about
chapters (10)
- 0:00Scott Shaw Intro - Why are we still talking about platforms in 2024
- 2:35Applying product management to internal platform - Thoughtworks Technology Radar
- 6:00Where are we now ?
- 8:10Component view of a typical engineering platform
- 10:55Pay attention to people and organisations throughout the lifecycle
- 14:50Value Modelling
- 17:54Build trust with early adopters
- 24:55Get the funding model right
- 30:37Can we really measure developer productivity ?
- 36:19We need a common platform language
related talks
40mInternal platforms in practice
33mWhy You Should Treat Your Platform as a Product
27mTurning Platform Engineering Work Into Business Value Leadership Understands
44mPlatform Engineering is All About Product
17mVertically Integrated in Platform Engineering
32mLessons Learned from 7 Years of Running Developer Platforms
31mNavigating the Platform Revolution: From Bottom-Up Innovation To Product Thinking
43mPlatform as a Product: Mindset, milestones, metrics