Serverless Craic from The Serverless Edge

Send us Fan MailAI and software development - the Real Problem with AI-Driven Software Engineering. AI is dramatically accelerating software delivery — but speed alone is not the answer.In this episode of Serverless CrAIc, we explore how AI is reshaping software engineering, platform engineering, architecture, and organisational design.As code generation becomes commoditised, the real differentiator is no longer how fast teams can build software — it’s whether they are building the right thing.We discuss:why clarity of purpose matters more than everhow AI amplifies both good and bad engineering practicesthe growing importance of socio-technical systemsplatform engineering and cognitive loadwhy North Star metrics still matterhow engineering leaders should think about AI adoptionthe risks of accelerating poor organisational decision makingIf your organisation is adopting AI into software delivery, this conversation is essential listening.Chapters00:00 Introduction01:42 AI is changing software engineering05:18 Why building faster is not enough09:34 The danger of accelerating bad decisions14:27 Why clarity of purpose matters18:40 AI as a commodity vs differentiator24:05 Platform engineering and cognitive load30:12 Socio-technical systems in the AI eraResources🌐 Website: The Serverless Edge https://theserverlessedge.com/📘 The Value Flywheel Effect: https://itrevolution.com/product/the-value-flywheel-effect/#o5a04b7992465🎧 Podcast Playlist: Serverless CrAIc Playlist https://open.spotify.com/show/5LvFaitkSkg2q5MWqKLrXu📰 Newsletter: The Serverless Edge on LinkedIN https://www.linkedin.com/build-relation/newsletter-follow?entityUrn=7066788643985596416Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailWhy Team Topologies Matters More Than Ever in the AI Era. Are AI agents changing how software teams should be structured?In this episode of Serverless CrAIc, David Anderson, Mark McCann, and Michael O’Reilly explore one of the biggest questions emerging in the AI era:👉 Does Team Topologies still matter when AI agents can generate code, tests, and workflows at incredible speed?The discussion dives deep into:Cognitive load in AI-driven engineering teamsSocio-technical systems and AI adoptionWhy human collaboration still mattersStream-aligned teams in an agentic worldThe evolving role of platform teamsWhy enabling teams are more important than everAI agents as “team members” — myth or reality?How engineering organisations scale safely with AIWhy guardrails, standards, and architecture matter more nowThe balance between autonomy and control in AI-enabled organisationsOne key theme runs throughout the conversation:AI may accelerate software delivery — but the human systems around software are still critical.As development speeds increase, organisations must rethink:collaborationcommunicationcognitive loadorganisational designengineering enablementplatform strategyoperational excellenceThis is a must-watch discussion for engineering leaders, architects, platform teams, and anyone building AI-enabled software organisations.Chapters00:00 – Introduction00:23 – AI, socio-technical systems, and Team Topologies01:02 – Why cognitive load matters more in the AI era02:07 – Drinking from the AI fire hose03:20 – Shifting cognition from code to outcomes04:32 – Why engineers are moving higher up the value chain05:48 – DP1 vs DP2 organisational design principles07:15 – Autonomy, mastery, and purpose in AI teams08:50 – Are AI agents team members?10:45 – Agent orchestration and organisational principles11:44 – Why AI is not truly a “team member”13:09 – Can you really pair program with AI?13:52 – Stream-aligned teams in an AI world15:34 – Jevons Paradox and accelerating software delivery17:11 – The changing role of platform teams18:46 – Security, governance, and AI platforms20:31 – Why platform teams must stay ahead21:08 – The critical role of enabling teams22:32 – Coaching engineers to work effectively with agents23:23 – AI anti-patterns and “We Jimmy” chaos engineering24:54 – Complicated subsystem teams and deep expertise27:20 – Does Team Topologies still matter?28:06 – Constraints, guardrails, and organisational design28:39 – Closing thoughtsResources & References📘 Books & Concepts MentionedTeam Topologies — Matthew Skelton & Manuel Pa

Send us Fan MailIs AI-generated code creating more value — or more liability?In this episode of Serverless Craic, David Anderson, Mark McCann, and Michael O’Reilly explore why one of software engineering’s oldest principles is suddenly more relevant than ever in the age of AI:“Code is a liability. The system is the asset.”As agentic AI and code generation tools accelerate development, teams are producing more code, more tests, and more complexity than ever before.But:Does more code actually mean better outcomes?Are organisations creating massive technical debt without realising it?What happens when AI accelerates poor engineering practices?And how do you maintain confidence, security, and quality in probabilistic systems?This episode explores:AI-generated code and technical debtValidation, verification, and testing strategiesObservability and evaluation frameworksSecurity vulnerabilities and unmanaged codeCritical thinking in modern software engineeringWhy “lines of code” ≠ business valueThe return of XP and foundational engineering principlesChapters00:00 – Introduction00:24 – Old engineering principles returning in the AI era00:51 – The return of Extreme Programming (XP)01:43 – “Code is a liability” explained02:46 – AI-generated code and growing technical debt03:32 – Why engineers must review AI-generated code carefully05:16 – The history of generated code and technical debt06:28 – Why more code doesn’t mean more value07:12 – AI hype, supply chains, and unmanaged complexity08:30 – AI accelerates weak engineering practices09:02 – Why teams still struggle with testing strategies10:39 – Observability and deploying with confidence11:54 – Evaluation frameworks for probabilistic systems12:55 – System boundaries and verification13:11 – Engineers are still accountable for AI-generated code13:50 – Critical thinking in probabilistic systems14:44 – Security vulnerabilities and unmanaged legacy code16:27 – Commodity systems vs unnecessary custom code17:25 – AI models finding security vulnerabilities18:38 – Exploration, testing, and security charters20:02 – Why code liability matters more than ever20:24 – Engineering excellence as competitive advantage20:44 – Final thoughtsResources & References📘 Concepts & People MentionedWard Cunningham — Technical DebtKent Beck — Extreme Programming (XP)Dave Farley — Continuous Delivery & modifiable systemsDan North — Engineering practices & architectureElizabeth Hendrickson — “Testing = Checking + Exploring”📚 Topics DiscussedTechnical debtAI-generated codeAgentic AI workflowsEvaluation frameworks (evals)Observ

Send us Fan MailPsychological Safety in the AI Era: AI is moving so fast it’s not just changing how we build software — it’s changing how teams think, learn, and work together.But there’s a problem no one is talking about enough:What happens to psychological safety when everything is changing at once?In this episode of Serverless CrAIc, Dave Anderson, Mark McCann, and Michael O’Reilly explore the human side of the AI revolution — from hype cycles and uncertainty to leadership, learning, and team dynamics.Because while AI is accelerating engineering, it’s also:Creating pressure to “keep up”Challenging confidence and expertiseShifting how teams collaborate and make decisionsAnd without psychological safety, teams won’t question, won’t challenge — and won’t build well.“It’s psychologically exhausting trying to keep up with the pace of change.”This is a conversation about what it really takes to build high-performing, resilient teams in the AI era.Chapters00:00 – Welcome to Serverless CrAIcAI hype, rapid change, and keeping up00:31 – Why psychological safety matters in the AI eraThe difficulty of challenging AI in organisations02:02 – The most aggressive hype cycle we’ve seen?Comparing AI to cloud and previous tech shifts03:25 – The turning point in AI capabilityFrom hype to real engineering impact04:17 – The psychological impact on engineersWhy the pace of change is exhausting04:49 – Innovation vs standardsWhy too much structure too early can slow teams down05:37 – The four stages of psychological safetyFrom inclusion to challenger safety07:01 – The capacity problemWhy senior engineers are struggling to mentor while learning themselves07:38 – Sense-making in fast-moving environmentsHow experienced engineers are adapting09:00 – What skills matter now?Growth mindset, experimentation, and adaptability10:45 – Bias for actionWhy experimenting with AI tools is critical11:59 – Vulnerability, empathy, and humilityKey leadership traits in uncertain times13:23 – Confidence in core engineering skillsWhy experience still matters13:58 – Demand isn’t slowing downWhy engineers are busier than ever15:15 – AI and engineering standardsApplying world-class practices faster than ever16:09 – Final thoughtsPsychological safety as a leadership priorityKey ThemesPsychological safety in high-change environmentsAI hype vs reality in engineering teamsThe impact of rapid change on confidence and learningLeadership challenges in AI-driven organisationsGrowth mindset, experimentation, and vulnerabilityApplying high engi

Send us Fan MailAI is dramatically increasing the speed at which teams can build software. But if you can ship features in hours instead of months, a new problem emerges:How do you know you’re building the right thing?In this episode of Serverless CrAIc, Dave Anderson, Mark McCann, and Michael O’Reilly explore why clarity of purpose and a strong North Star are more important than ever in an AI-accelerated world.As AI tools and agentic systems remove friction from development, teams can prototype, build, and deploy faster than ever before. But without clear direction, that speed can quickly turn into chaos, feature overload, and wasted effort.We discuss:Why the North Star framework still matters in the AI eraThe importance of leading vs lagging metricsHow observability and telemetry support decision-makingWhy product management and engineering roles are shiftingThe growing need for product-oriented engineering teamsIf AI increases your delivery velocity, your strategy and decision-making must evolve just as quickly.Chapters00:00 – Welcome to Serverless CraicAI everywhere and the coming singularity (maybe).00:31 – Does the North Star still matter in the AI era?Why clarity of purpose becomes even more critical when you can build faster.01:30 – Why speed without direction is dangerousHow AI can lead teams to build the wrong things faster.02:20 – Experience as an advantage in the AI eraWhy experienced engineers ask better questions of AI systems.03:06 – The first North Star question: What game are you playing?Defining your problem space before building anything.04:29 – Rapid experimentation with AI prototypesUsing AI-driven prototyping to discover meaningful product signals.05:41 – Observability hasn’t changedWhy understanding what to measure is still the hardest problem.06:32 – Leading vs lagging metricsHow telemetry and instrumentation help teams track progress.07:53 – The shift toward systems thinkingWhy engineers increasingly need a systems engineering mindset.08:29 – Product management pressure in the AI eraThe growing importance of solving real customer problems.09:27 – Wardley mapping, user needs, and rapid iterationWhy product strategy becomes more important as teams move faster.10:38 – The danger of overwhelming users with featuresUnderstanding organisational and user adoption limits.11:01 – Decision-making speed in large organisationsWhy strategic decisions must flow faster through organisations.11:55 – Engineering teams becoming product teamsAutonomy and product ownership in high-velocity environments.12:48 – Making good decisions against the North StarWhy strong leadership and judgement still matter.Resources & Refere

Send us Fan Mail🎙 AI: Commodity or Differentiator? | The Value Flywheel in 2026AI has taken a step change. Over the past few months, adoption has accelerated dramatically — but are organisations applying it with clarity, or just chasing hype?In this episode of The Serverless Edge, we unpack:AI as a commodity vs differentiatorWhy clarity of purpose matters more than everThe risks of “vibe coding” critical systemsSecurity, blast radius, and agent containmentAccelerating your Value Flywheel safely with AIWhy you cannot outsource critical thinking to an LLMIf you're a CTO, architect, or engineering leader trying to navigate AI adoption without introducing systemic risk — this conversation is for you.⏱ Chapter Markers00:00 – The AI Step Change: What Happened in Late 2025?02:00 – AI as Commodity vs Differentiator03:10 – The Cost of Building What’s Already a Commodity04:20 – Internal Acceleration vs Product Features05:30 – Training Data, Sovereignty & Enterprise Risk06:45 – Where AI Becomes Dangerous in Your Organisation08:00 – Agentic AI & Blast Radius: Why Containment Matters09:20 – Competing With the Platform Providers11:10 – SaaS Killed by AI? The AWS Reinvent Effect13:00 – “Vibe Coding” Core Business Systems (And Why That’s Madness)15:00 – Where You Shouldn’t Experiment With AI16:00 – Faster Feedback Loops & Engineering Throughput17:30 – Discipline, Metrics & the North Star18:20 – Using AI to Improve Your Own Thinking19:00 – Context Is Everything (And Harder Than You Think)20:10 – Organisational Design for Humans and Agents21:00 – Turning the Flywheel Before Adding AI21:50 – Why Sitting on the Sidelines Isn’t an Option🔎 Key Themes1. Clarity Before CapabilityMost organisations should consume AI, not build foundational models. The differentiator is rarely the LLM itself — it’s how clearly you understand:Your user needsYour value chainYour supply chain dependenciesYour regulatory boundariesWithout that clarity, AI simply accelerates confusion.2. Blast Radius & ContainmentAgentic systems introduce a new risk profile.If you deploy AI into:Poorly governed SDLC environmentsWeakly defined security domainsLegacy operational processesYou expand blast radius unintentionally.Think SaaS isolation. Think sandboxing. Think containment by design.3. Speed Changes EverythingIf AI compresses delivery cycles from weeks to hours:Your product discovery loop must accelerateDecision-making must tightenMetrics must be explicitEngineering must sit inside the feedback loopAI increases velocity — but velocity without direction is chaos.4. You Cannot Outsource Critic

Send us Fan MailAI Myths in Software Engineering. AI is colliding with software engineering at full speed — and a lot of myths are emerging along the way.In this episode of Serverless Craic, Dave Anderson, Mark McCann, and Michael O’Reilly unpack how AI, GenAI, and agentic systems intersect with the ideas behind The Value Flywheel Effect. Rather than hype or fear, this is a grounded engineering discussion about quality, responsibility and long-term value.We explore six common myths about AI and software engineering — and why good engineering judgement, domain knowledge, and clarity of purpose matter more than ever.If you care about building sustainable systems, not just shipping demos, this one’s for you.Chapters00:00 – Welcome & contextWhy AI + serverless + the Value Flywheel is colliding right now01:50 – Myth 1: “Software engineering is dead”Why engineering skills are more valuable, not less07:06 – Myth 2: “My skills will become irrelevant”Moving up the value chain, domain expertise, and growth mindset13:40 – Myth 3: “The quality isn’t good enough”Standards, constraints, and why worst it’ll ever be is today18:44 – Myth 4: “The model understands the problem”Pattern matching vs understanding, context, and critical thinking24:20 – Myth 5: “I’ll be forced to use AI”Workflows, guardrails, security, and excessive privileges31:54 – Myth 6: “We’ll need fewer engineers”Jevons Paradox, lowered barriers, and the coming demand explosion34:22 – Closing thoughtsAI, velocity, and the future of sustainable software engineeringKey Themes DiscussedAI as an abstraction layer, not a replacement for engineeringWhy standards, constraints, and operability still matterDomain-Driven Design as AI-amplifying, not obsoleteAgentic systems, skills, prompts, and containmentSecurity risks: excessive privileges & supply-chain concernsVelocity vs sustainability in AI-assisted developmentResources & ReferencesThe Value Flywheel Effect – principles referenced throughoutWardley Mapping & situational awarenessDomain-Driven Design (DDD)OWASP Top 10 for LLMs (excessive privileges, agent risks)Jevons Paradox (efficiency driving increased demand)Early cloud cost & governance parallelsThreat modelling for AI and agentic systemsServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on <a href='https://

Send us Fan MailIn the first Serverless Craic episode of 2026, Dave Anderson, Mark McCann, and Michael O’Reilly reflect on a five-year journey that began in early 2021 with the idea for The Value Flywheel Effect.This episode closes out the book series by looking back—warts and all—at what it really took to write, publish, promote, and apply the ideas in practice. The conversation spans writing fatigue, editing realities, imposter syndrome, enterprise adoption, and why the flywheel is arguably more relevant than ever in an AI-first world.If you care about modern software delivery, cloud strategy, serverless-first thinking, and leading technology change, this one is for you.⏱️ Chapters00:00 – Welcome & contextEpisode 79, first show of 2026, and closing out the book series 01:20 – How the book started (2021 → 2026)From an idea to a five-year journey01:35 – Did we enjoy writing the book?Ideation, Guinness-fuelled drafts, and the reality of writing02:30 – Shaping the narrativeWhy writing is harder than it looks, and why shared context doesn’t scale04:10 – Atomic essays & capturing thinking earlyGitHub, short-form writing, and building habits05:00 – Would this book have helped us 15 years ago?Modernisation gaps, agile limits, and why the flywheel mattered06:00 – The editing process (and thick skin)What professional editors really do to your manuscript07:40 – Feedback, criticism, and author psychologyWhy the one negative comment sticks09:15 – Has the book made an impact?Enterprises, conferences, and unexpected adoption stories12:40 – Applying the flywheel in real organisationsNorth Stars, Team Topologies, serverless-first in practice14:30 – The hardest part of the whole journeyFinishing, introductions, and the truth about selling a book17:30 – Promotion, modesty, and imposter syndromeWhy marketing a book is a full-time job19:00 – Influences & supportersKent Beck, Adrian Cockcroft, Simon Wardley, and standing on shoulders21:45 – Is the book still relevant in the age of GenAI?Why the flywheel + AI is a force multiplier23:00 – AI, context engineering, and agentic systemsUsing codified principles to guide AI effectively25:30 – Lowering the barrier to good practiceHow AI helps teams apply architecture, security, and governance29:00 – Business strategy vs technical strategyIs the divide finally disappearing?31:45 – The emerging “builder” personaShifting left, shifting right, and new SDLC realities34:50 – Closing thoughts & what’s nextAISDLCs, Brownfield challenges, and future episodes📚 Resources & Links📘 The Value Flywheel Effect — principles f

Send us Fan MailHow the BBC Built a Serverless-First Architecture: In this episode of Serverless Craic, Dave, Mark, and Michael explore one of the most compelling real-world examples of serverless at scale: the BBC’s serverless-first transformation.We break down how the BBC News engineering team delivers global, highly-spiky traffic, meets strict public-service constraints, reduces incidents, and accelerates delivery—all with a pragmatic serverless-first mindset.Expect insights on production readiness, architectural constraints, continuous delivery, problem prevention at scale, and how the BBC evolved a massive digital estate by keeping things intentionally simple.⏱️ Chapter Markers00:00 – Intro00:03 – Welcome to the episode00:21 – BBC case study overview02:11 – Complexity, scale and global distribution03:42 – User experience, design systems, and history of BBC transformation05:03 – Serverless-first and focusing on differentiating value05:47 – Spiky traffic, transcoding and pragmatic trade-offs06:42 – Constraints and why serverless works for the BBC07:59 – Team size, reducing maintenance load, and continuous delivery08:27 – Serverless-first, not serverless-only09:05 – BBC traffic levels and operational performance09:47 – Problem prevention, reliability and long-term value10:02 – Improvements in BBC Media Player and user experience10:06 – Evolution, complexity, and Gold’s Law11:01 – Closing thoughts and what’s coming next11:08 – Outro & Call to action🔧 Resources & MentionsBBC Article – Delivering BBC Online Using Serverless https://www.bbc.co.uk/articles/clynq1gyn1roThe Serverless Edge – The Value Flywheel Effect Frameworkhttps://theserverlessedge.com/12-key-tenets-of-the-value-flywheel-effect/Gall's Law – Complex systems evolving from simple systemshttps://en.wikipedia.org/wiki/John_Gall_(author)Adrian Cockcroft – Serverless constraints and production readinesshttps://medium.com/@adriancoAWS Serverless Best Practiceshttps://builder.aws.com/content/2pYmkuLReVaqZ29ew1P3Dn4iAvH/best-practices-for-serverless-technologies-in-awsServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on <a href='https://www.linkedin.com/company

Send us Fan MailIn this episode of The Serverless Craic, Dave, Mark, and Michael dive into Chapter 19: Mapping the Emerging Value from The Value Flywheel Effect. This chapter explores how leaders can use Wardley Mapping to uncover long-term strategic opportunities, align product thinking, and identify “land grab” moments that unlock future business value.The conversation covers:How mindset, purpose, and cloud strategy form organisational pipelinesThe three major value chains: sustainable operations, long-term goals, and land-grab opportunitiesHow emerging capabilities, product thinking, and situational awareness combine to create competitive advantagePractical leadership behaviours and gameplay patterns from Wardley MappingExamples from AI, cloud evolution, open source, and platform teamsWhy high-performing engineering organisations create the conditions for long-term innovationThis is a deep dive for technology leaders who want to create adaptive, strategically aligned organisations capable of sensing and seizing new market opportunities.📍 Chapters00:00 – Intro00:12 – Setting the context: Chapter 1901:00 – Why long-term value isn’t just architecture01:50 – The future CEO as an anchor for the map02:25 – The three organisational pipelines03:30 – Sustainable operations value chain04:40 – Long-term goals and product mindset06:33 – Psychological safety, experimentation & ambition07:30 – Run → Grow → Transform09:05 – Ineffective innovation & product debt11:32 – The “land grab” and adjacent market opportunities12:51 – Cloud, customer obsession & competitive advantage13:57 – Revisiting the map15:13 – Wardley Mapping gameplay patterns16:20 – FUD and competitive games18:01 – Open source as an accelerator18:33 – Market enablement in the AI era19:07 – Toxicity, constraints & real-world leadership20:14 – Sensing engines, co-creation & alliances21:03 – Competitive moves: talent raids & fast-followers22:11 – Wrapping up & next steps🔗 Resources & Links📘 The Value Flywheel Effect Bookhttps://itrevolution.com/the-value-flywheel-effect/🌍 Learn Wardley Mappinghttps://learnwardleymapping.com/🎙️ The Serverless Craic Podcast & Bloghttps://theserverlessedge.com/📚 Escape Velocity – Geoffrey Moorehttps://www.goodreads.com/book/show/11103017-escape-velocity🧭 Wardley Mapping Community Resourceshttps://wardleypedia.org/👥 About The Serverless CraicWe explore modern cloud, serverless-first engineering, Wardley Mapping, the Value Flywheel, and high-performance technology leadership — with practical insights you can apply in your organisation today.If you want resilient systems, rap

Send us Fan MailSustainability & Innovation in Modern Cloud: In this episode of Serverless Craic, Dave, Mark, and Michael dive into Chapter 18 of The Value Flywheel Effect — Sustainability and Space for Innovation.We explore why sustainable architectures, well-designed domains, situational awareness, and the innovate–leverage–commoditise cycle are essential for modern cloud leaders navigating long-term value.From Wardley Mapping to domain-driven design, serverless sustainability to AI-driven development shifts, this chapter brings together multiple strands of modern engineering strategy.If you’re leading engineering teams, shaping cloud strategy, or building adaptive systems, this one’s packed with value.📌 Chapters00:00 – Intro: dark evenings & winter vibes00:30 – Chapter 18 overview: Sustainability & Space for Innovation01:46 – Short-term thinking vs long-term clarity of purpose02:18 – Misusing “lean”: why not everything is a Toyota Production System candidate03:04 – Innovate → Leverage → Commoditise cycle: using the right mode at the right time04:48 – The “difficult second album”: letting go as contexts evolve05:26 – Anti-patterns: commoditising too early and sunk-cost fallacies06:43 – Domain-driven design & business domain discovery07:56 – Understanding your customer & real problem spaces08:38 – Observability, metrics & sensing your organisation09:24 – Why blind operation kills innovation10:25 – Resilience as the ability to respond to threat & opportunity11:30 – Stability & security before layering in AI12:02 – Adaptation: AI disrupting SDLCs13:38 – Architecting for extensibility & flow14:27 – Evolving systems & leveraging cloud innovations15:05 – True agility vs theatre15:57 – Situational awareness & proactive leadership17:31 – Frictionless developer experience & cognitive load reduction18:41 – Cognitive load, boundaries, and mission clarity20:26 – Sustainability: carbon, cost, and efficient architectures21:04 – Wasteful compute & why sustainable design matters21:29 – Green software & the Well-Architected Framework22:08 – Takeaways: well-architected → sustainable → resilient → innovative22:41 – Wrap-up & subscribe🔗 Resources Mentioned📘 Books & FrameworksThe Value Flywheel Effect – Anderson, McCann & O’ReillyTeam Topologies (2nd Edition) – Skelton & PaisFrictionless – Dr Nicole ForsgrenAccelerate – Forsgren, Humble & KimWardley Mapping – Simon Wardley🛠 AWS & CloudAWS Well-Architected Framework (incl. Sustainability Pillar)AWS Carbon Footprint ToolServerless First principles & guidance (The Serverless Edge)🧭 Techniques & ConceptsInnovate → Leverage → Commoditise (ILC) CycleDomain-Driven Design (DDD)Observabi

Send us Fan MailHow to Build a Problem Prevention Culture (AWS Well-Architected Explained)Stop firefighting — start preventing problems.In this episode of Serverless Craic, Dave Anderson, Mark McCann, and Michael O’Reilly explore how engineering teams can create a problem prevention culture using the AWS Well-Architected Framework.They unpack lessons from Chapter 17 of The Value Flywheel Effect, showing how high-performing cloud teams use SCORP reviews (Security, Cost, Operational Resilience, Performance) to operationalise engineering excellence.Learn how to:✅ Shift from reactive to proactive problem solving✅ Build dashboards that actually drive team learning✅ Scale architecture reviews across hundreds of teams✅ Foster psychological safety and positive peer pressure✅ Future-proof your organisation for the AI-driven cloud era⏱️ Chapters00:00 – Intro and setup00:40 – What is a problem prevention culture?02:20 – Recognising unseen engineering work04:30 – Balancing delivery and engineering excellence05:40 – Defining “good architecture”07:00 – The AWS Well-Architected Framework08:40 – From theory to practice: SCORP sessions10:30 – Scaling Well-Architected reviews13:50 – Using dashboards for insight and improvement15:00 – Building trust and psychological safety17:00 – Peer learning and positive pressure19:00 – Continuous improvement in real teams21:00 – Measuring long-term maturity22:30 – Looking forward to AI-driven cloud operations25:00 – Outro and what’s next🔗 Resources📘 The Value Flywheel Effect → https://theserverlessedge.com/the-value-flywheel-effect🧭 AWS Well-Architected Framework → https://aws.amazon.com/architecture/well-architected🧩 SCORP Process & Templates → https://theserverlessedge.com/scorp-process-cycle🎙️ Serverless Craic Podcast → https://theserverlessedge.com/podcast💡 Follow The Serverless Edge on LinkedIn and YouTubeServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailIn this episode of Serverless Craic, Dave Anderson, Mark McCann, and Michael O’Reilly share key takeaways from two major events — AWS Community Summit Manchester 2025 and AWS Cloud Day Dublin 2025.From psychological safety in engineering teams to serverless adoption patterns, event-driven architecture, and the rise of AI agents with Amazon Bedrock AgentCore, the discussion highlights what’s shaping cloud-native development today.If you’re a software engineer, cloud architect, or tech leader interested in modernisation, AI in the enterprise, serverless-first strategies, and community-led learning, this episode is for you.⏱ Chapters00:00 – Intro & catching up00:55 – AWS Community Summit Manchester highlights02:10 – Psychological safety in engineering teams05:30 – AI hype, misuses & team impact07:10 – Women in Tech track & allyship08:30 – Event-driven architecture & domain-driven design10:45 – Modernisation talks & API boundaries12:00 – The reality of AI adoption in enterprises14:55 – Serverless adoption patterns & challenges15:53 – AWS Cloud Day Dublin highlights17:45 – AI agents and Amazon Bedrock AgentCore19:14 – Challenges of agentic user experiences20:15 – Securing and testing AI systems (OWASP LLM Top 10)21:00 – Well-Architected Framework (SCORP) talk21:39 – Power of community learning22:22 – Wrap up & next episode preview🔗 Resources & MentionsThe Serverless Edge Website: https://theserverlessedge.comFollow us on LinkedIn: https://www.linkedin.com/company/the-serverless-edge/The Serverless Edge GitHub – SCORP: https://github.com/ServerlessEdge/SCORPAmazon Bedrock & AgentCore: https://aws.amazon.com/bedrock/Event Catalogue: https://eventcatalog.dev/Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailIn this episode Dave Anderson, Mark McCann, and Michael O’Reilly revisit their time at Liberty Mutual, exploring how one of the world’s largest insurers transformed from legacy systems and SOA to cloud-native architectures and serverless-first strategies.Discover how Wardley Mapping, empowered engineering teams, and a strong cultural foundation enabled Liberty Mutual to modernise at scale and deliver business value faster.We cover:Moving from mainframes and monoliths to microservices and serverlessBuilding agile, product-led teams that own security, testing, and operationsUsing Wardley Mapping to make strategic technology betsLessons on cloud adoption, change management, and leadership in a Fortune 100 enterprise👉 If you’re a CTO, software architect, or engineering leader, this case study is packed with insights on modernisation and enterprise cloud transformation.⏱️ Chapter Markers0:00 – Introduction0:34 – Liberty Mutual in Belfast: tackling hard problems2:21 – Strategic mindset of a mutual insurance company3:49 – Early SOA systems and first encounters with cloud4:49 – Microservices before it was mainstream6:14 – Enter serverless: below the line vs above the line8:38 – Technology manifesto and cultural change10:25 – Learning from world-class infrastructure engineers13:53 – Wardley Mapping and spotting key enablers16:08 – CDK, BDD, and shifting left18:20 – Security, threat modelling, and shifting responsibilities19:58 – Product thinking and “next best action”21:31 – Working with auditors and external stakeholders22:18 – Upskilling, conferences, and internal evangelism24:08 – Business impact and scaling during COVID25:39 – Change management: it takes a village26:45 – External evangelism and organisational support27:22 – Next episode teaser: Problem Prevention Culture📚 Resources & Links🌐 The Serverless Edge https://theserverlessedge.com – Thought leadership on modern cloud🎧 Podcast on Spotify🎥 More episodes on YouTube📖 The Value Flywheel Effect – by David Anderson, Mark McCann & Michael O’Reilly https://thevalueflywheeleffect.comServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailIn this episode of Serverless Craic, Dave Anderson, Mark McCann, and Michael O’Reilly explore Chapter 15 of The Value Flywheel Effect — Map Your Solution. They discuss how Wardley Mapping and tech stack mapping create situational awareness, reduce friction between teams, and guide better architectural decisions.If you’re a software engineer, architect, or tech leader aiming to evolve your systems with serverless and cloud-native thinking, this conversation shows practical techniques to uncover bottlenecks, reduce technical debt, and align teams on strategic improvements.⏱️ Chapters00:00 – Intro: jumping from summer to winter01:00 – Mapping your solution: why it matters02:20 – Tech stack mapping in practice03:50 – Situational awareness and collaboration05:50 – Funding priorities and bottlenecks07:20 – Cloud services, serverless options, and evolution paths09:30 – Custom build vs buy vs adopt cloud-native11:00 – Organisational insights from mapping12:00 – Duplication and domain-driven design issues13:00 – Team Topologies and independent service heuristic14:20 – Total cost of ownership and well-architected lens15:50 – Target architecture and business impact16:50 – Using mapping for strategy and incentives17:40 – Context switching and leadership effectiveness18:10 – Takeaways: evolutionary architecture🔗 Resources📖 The Value Flywheel Effect Book – https://thevalueflywheeleffect.com🎥 Wardley Mapping 101 – https://www.youtube.com/watch?v=uP9Rl26Xeag🎧 Podcast: Wardley Mapping is a Game-Changer – https://open.spotify.com/episode/5cUQgQFBeIkOBWUe35rDRUServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailIn this episode, Dave Anderson, Mark McCann, and Michael O’Reilly dive deep into The Value Flywheel Effect (Chapter 14) — discussing frictionless developer experience, sense checking, feedback culture, AI in software engineering, DevOps, platform engineering, and marginal gain.We explore how AI and LLMs are shaping engineering practices, the importance of psychological safety, continuous improvement, and why code is always a liability. If you’re interested in serverless, DevOps, or building resilient modern software teams, this conversation is packed with insights.Chapters00:00 – Introduction & Belfast heatwave 🌞00:18 – Revisiting *The Value Flywheel Effect* (Chapter 14)01:11 – Sense checking & psychological safety in teams02:37 – Leadership, listening, and feedback loops04:12 – RFCs, well-architected reviews & threat modelling05:14 – Trusting AI feedback vs human feedback07:59 – Documenting engineering standards for AI09:33 – Human in the loop & cadence of reviews11:42 – Traceability, accountability & marginal gains13:56 – Scaling teams & expanding the “full stack”14:29 – Infrastructure as code, DevOps origins & AI parallels17:13 – Deployment pipelines & frictionless production18:01 – Platform engineering & hardened building blocks19:40 – Code as liability & avoiding bloat20:20 – Well-architected standards & AI context21:32 – Shifting security left & automated governance22:33 – Isolation, zero trust & resilience23:18 – Platforms as standards & consolidation25:23 – Less code, better docs, and evolving patterns27:06 – Avoiding command & control in engineering culture28:22 – Empowerment, enabling environments & AI’s role28:50 – Developer experience & future of AI in softwareServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailIn this episode Dave Anderson, Mark McCann, and Michael O’Reilly continue their deep dive tackling Chapter 14: The Frictionless Developer Experience.The crew explore whether the principles of engineering excellence, developer enablement, and team topologies still stand strong in a world increasingly powered by AI and agentic systems. From **managing cognitive load** to **code as a liability**, they unpack how AI changes (and doesn’t change) the fundamentals of building high-quality software.📌 Topics include:Does AI really make development frictionless?Maintaining engineering excellence in an AI-driven worldEnabling constraints and team autonomyRevisiting the four team types in *Team Topologies*The enduring importance of DORA metrics and stabilityWhy code is a liability—and how AI impacts thisThe rise of specifications, contracts, and stronger test practices⏱ Chapters00:00 – Intro & recent travels01:20 – Go To Service Bangalore & serverless momentum02:40 – Frictionless developer experience in an AI world04:50 – Cognitive load & enabling constraints06:20 – Engineering excellence: still relevant?08:10 – Three characteristics of great software creation10:25 – Principles, context, and best practices in the AI era12:40 – Goal-driven frameworks & outcome-based leadership14:00 – Challenging teams with the right questions15:35 – AI as an enabler for strong engineers17:20 – Democratising knowledge & rapid learning18:40 – Team Topologies in the AI landscape20:45 – Socio-technical changes & enabling teams22:15 – Will teams be smaller or just better?23:30 – Autonomy, mastery, and purpose25:05 – Engineers’ mastery in the age of AI26:00 – DORA metrics: throughput & stability28:00 – Code as a liability & maintainability concerns29:20 – Specifications, contracts, and test-driven approaches31:00 – Shared outcomes & embracing AI in delivery🔗 Resources & Links📚 Team Topologies: https://teamtopologies.com by Matthew Skelton & Manuel Pais📖 Accelerate by Nicole Forsgren, Jez Humble & Gene Kim🌐 The Serverless Edge https://theserverlessedge.com)– Blog & resourcesServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailServerless myths debunked for modern cloud teams: In this episode, we dive into the second part of Chapter 13 The Serverless First Edge from The Value Flywheel Effect book. We explore common serverless myths, how relevant they still are in 2025, and what’s changed since the early days of serverless adoption.From cold starts and testing challenges to cloud lock-in and the rise of AI, we reflect on the evolution of the landscape — and the mindset shifts still needed across engineering and leadership teams.💥 Packed with practical insights and real-world experiences, this is a must-watch for anyone navigating modern cloud architecture, serverless patterns, or leading engineering teams in the age of AI.⏱ Chapters:00:00 - Intro & weather chat00:34 - Chapter 13 overview: "The Serverless First Age"01:17 - Cold start problems: Still a myth?05:11 - Serverless is hard to test? Solved with cloud-native testing09:34 - Observability: You can't see what's happening?12:48 - Serverless isn’t the next big thing? The AI distraction16:23 - Vendor lock-in fears & multi-cloud myths20:00 - “We’re different” & custom standards fallacy23:02 - Serverless is more expensive?25:26 - Engineers won’t do what I tell them26:23 - Engineers are disconnected from the business27:24 - “This worked last time, let’s use it again”28:02 - “We only work on the cool stuff”28:27 - Organisational myths: “We’re under capacity”29:54 - Security is blocking serverless?30:41 - Finance myths: OPEX model resistance30:54 - Sunk cost fallacy in cloud transformation31:37 - Outsourcing strategy to consultancies32:47 - Wrap-up & what’s still relevant🔗 Links & Mentions:The Value Flywheel Effect book ServerlessDays BelfastTalks by Jeremy Daly, Yan Cui , Adrian CockcroftBizTech Evolution by Ivan Krnić Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailServerless First: Focus, Not FunctionalityIn this episode, Dave Anderson, Mark McCann and Michael O’Reilly dive into Chapter 13 of the Value Flywheel Effect—focusing on the concept of “Serverless First” and what it really means for engineering teams and product leaders today.🔍 Topics include:Why code is a liability and how to identify what to build—and more importantly, what not to.Embracing a frictionless developer experience to enable speed and innovation.The shift from legacy cloud to modern cloud and the pitfalls of lift-and-shift thinking.Understanding core vs. supporting domains through DDD and how that informs what to offload.The enduring value of good architecture*and how modern cloud constraints can be enabling.A powerful reminder that the point of serverless isn’t tech—it’s focus.🚀 Whether you're navigating cloud migration, modernising your stack, or wondering how to leverage AI without drowning in infrastructure, this conversation will help you elevate your thinking.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan Mail🎙️ Serverless Craic: Chapter 12 – The Workgrid Case StudyIn this episode, Dave Anderson, Mark McCann, and Michael O’Reilly dive deep into Chapter 12 of The Value Flywheel Effect — the Workgrid case study.This episode explores the early days of Workgrid, a startup founded in 2017 with Gillian McCann. As one of the first companies to adopt a “serverless-first” philosophy, Workgrid’s journey offers valuable lessons in building modern digital employee experiences under real-world startup constraints.💡 Topics Covered:The importance of a pragmatic, serverless-first architectureManaged services vs. infrastructure-heavy approachesStartup pressures: speed, cost, and time to marketCreating an “environment for success” in engineering teamsReal-world examples of modular design, cost awareness, and evolving architecturesBuilding secure, compliant, multi-tenant SaaS on serverlessThe value of partnering with cloud providers like AWSLessons in team growth, hiring for mindset over tech stack🔥 Quote of the episode:"I never said serverless was easier. I said it was better." – Gillian McCannWhether you’re in a startup or enterprise, this episode will inspire you to rethink your architectural strategy and team dynamics for building scalable, cost-effective cloud-native systems.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailMapping Your Org Capability | Chapter 11 Breakdown of The Value Flywheel EffectIn this episode, Dave Anderson, Mark McCann, and Michael O’Reilly dive into Chapter 11 of The Value Flywheel Effect — "Map Your Organisational Capability".We unpack how to use mapping techniques, such as Wardley Mapping, to assess and visualise your organisation’s capabilities across areas like security, cloud-native development, and emerging tech like GenAI. The discussion covers:🔹 Why individual expertise ≠ organisational capability🔹 Mapping techniques using industry standards and evolutionary stages🔹 How to use mapping for strategic clarity and identifying capability gaps🔹 Lessons from applying security and cloud-native capability maps in real organisations🔹 Using mapping as a lightweight but powerful tool for technology leadership and investment planningThis episode is full of practical insights for tech leaders seeking clarity, situational awareness, and better strategic decisions.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan Mail🎙️ Serverless Craic: Exploring Socio-Technical Systems for ChangeWelcome back to Serverless Craic! In this episode, the team dives into Chapter 10: Challenge – A Socio-Technical System for Change from the book, The Value Flywheel Effect. This thought-provoking conversation unpacks how organisations can effectively bridge the gap between people and technology to foster meaningful, sustainable change.🔍 Topics Covered:What makes socio-technical change so difficultThe importance of flow, team design, and time to valueLessons from Team Topologies and Drive by Daniel PinkFrameworks like Cynefin and Wardley MappingDemocratising AI and enabling change through feedback loopsWhy architecture alone won't save you🤔 Whether you're a tech leader, architect, or engineer, this episode offers valuable insights on how to navigate complexity, decentralise expertise, and embed purpose and autonomy at every level of your organisation.📚 Referenced:Team Topologies Drive by Daniel Pink:Cynefin Framework (Dave Snowden)Wardley MappingFred Emery’s Design PrinciplesServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan Mail🎙️ Environment for Success & Psychological SafetyWelcome back to another episode of Serverless Craic! After a short hiatus (thanks, ServerlessDays Belfast!), Dave Anderson and Mark McCann return to dive deep into one of the most critical – and timely – topics in modern software delivery: creating the right Environment for Success.In this episode, we unpack Chapter 9 from The Value Flywheel Effect and explore the fundamentals that enable high-performing teams, including:🔹 Psychological safety and why it’s the foundation of great engineering cultures🔹 The danger of hero anti-patterns and the myth of the “rock star” developer🔹 Challenging assumptions safely – using artefacts, not egos🔹 Simon Wardley’s doctrine and Dr. Ron Westrum’s organisational culture model🔹 How aligned autonomy and clarity of purpose help teams focus on what matters🔹 Why generative, learning organisations adapt best to AI-driven changeWhether you’re a tech leader, architect, or engineer, this conversation is a masterclass in building sustainable, modern digital organisations.🧭 Referenced resources:The Value Flywheel Effect by us!The Fearless Organisation by Amy EdmondsonAccelerate by Nicole ForsgrenSimon Wardley’s DoctrineDr. Ron Westrum’s organisational modelsServerless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailIn this episode of Serverless Craic, Map the Market and A Cloud Guru Case Study, we dive into Chapters 7 and 8 of the book The Value Flywheel Effect. The discussion focuses on "Mapping the Market" and a fascinating case study on clarity of purpose, featuring the story of A Cloud Guru.Discover how mapping the value chain helps companies identify their place in the market, understand competitors, and predict strategic moves. Learn about the transformative impact of a laser-focused North Star and how serverless-first approaches powered scalability and success. The episode includes insightful anecdotes, practical mapping techniques, and lessons from real-world examples like Tesla and A Cloud Guru.🎯 Key Topics Covered:- Mapping the market and competition.- Understanding and leveraging the value chain.- Insights from A Cloud Guru’s journey to a $2 billion acquisition.- Practical tips for mapping your strategy effectively.💬 Join the conversation! Share your thoughts and subscribe for more discussions on engineering, strategy, and innovation. Thanks for tuning in, and see you in the next episode, where we’ll explore "Challenging the Environment" in the Value Flywheel framework! 🚀Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailWelcome to the latest episode of Serverless Craic! 🎙️ Today, we're diving back into our series on The Value Flywheel Effect, focusing on Chapter 6: "Obsess Over Time to Value." Join us as we explore the significance of delivering value quickly and efficiently in tech organisations. We discuss the concept of "Time to Value" over "Time to Market," reflecting on how innovation labs and agile structures can help companies pivot, react, and respond to both threats and opportunities.In this episode, we touch on key topics like:- The importance of creating a feedback loop to see real user value- The challenges of organisational inertia and how it can inhibit innovation- Real-life examples of experimentation and pivoting, including building "trap doors" to validate product assumptions- The role of situational awareness in overcoming barriers to changeWe also delve into how high-performing teams can increase an organisation’s "rate of turn," making it more adaptable in a rapidly evolving market. Whether you're dealing with big projects or experimenting with new technologies, empowering teams to focus on value, rather than just speed, can transform your business outcomes.If you enjoyed this discussion, don’t forget to subscribe, like, and share. Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailThis episode centres on Chapter Five of the book "The Value Flywheel Effect," focusing on the North Star framework. We explain how this framework helps teams align their work with a clear, meaningful metric (North Star) and its related leading and lagging metrics.  North Star Framework OverviewWe explain the North Star framework, emphasising its use in helping teams coalesce behind a mission or purpose with a visual, collaborative tool. And the importance of leading metrics and lagging metrics, explaining how the North Star framework helps teams reverse engineer leading metrics from lagging ones.Application of North Star FrameworkWe look at the usefulness of the North Star framework at both the small startup level and the enterprise level, where it helps link lead measures back to overall business impact.The North Star framework is powerful for team and individual morale by making work meaningful and aligning it with organisational objectives.We reference Dan Pink's "mastery, autonomy, sense of purpose" to emphasise the importance of knowing what you are doing and why.The North Star framework is complementary to mapping for strategy, helping to narrow down on value and focus conversations.Challenges and Benefits of North Star FrameworkIt is valuable to ask teams about their metrics and how their work influences them, leading to valuable conversations about measurement and alignment.We look at the importance of measurement, referencing Grace Hopper's quote about the power of accurate measurement.Having data and clear alignment to organisational strategy helps teams advocate for change more effectively.The North Star framework can sometimes reveal that teams are not aligned or that the overall strategy is flawed, likening it to the emperor's new clothes.Connecting North Star to Business ValueA structured North Star often reveals disconnects in the work being done and its impact on business value, serving as a corrective measure.We compare the North Star framework to impact mapping, both helping to create a compelling narrative and understand the story of what the team is working on.It is challenging to craft the North Star for behind-the-scenes teams, but the framework helps align value delivery with business goals.We discuss Amazon's working backwards process and its similarities with the North Star framework, emphasising the importance of understanding the customer's need and working backwards from there.Critical Thinking and LeadershipThese frameworks are enablers of critical thinking, challenging teams and organizations to question their assumptions and goals.North Star metrics and key input metrics make it easier to write a compelling press release that aligns with the company's

Send us Fan MailIn this insightful discussion, we explore mapping techniques from Chapter 3 of our book The Value Flywheel Effect and their applications in organisations. Key topics include:Anatomy of a Worldly Map: Breaking down the components of a map, including visible, aware, and invisible items in the value chain.Mapping Teams and Tech Stacks: How mapping helps in identifying team roles and modernising technology stacks.Starting with Maps and Collaboration: Tips for overcoming the blank canvas fear and leveraging tools like GitHub's "Awesome Worldly Maps" and VS Code extensions for map annotations.Open Space Collaboration: The value of engaging everyone in discussions and validating inputs.Mapping the Stack, Organisation, and Market: Using mapping for situational awareness, aligning teams with core domains, and understanding market dynamics to respond effectively to opportunities and threats.This conversation provides practical insights into using mapping for better organizational awareness and strategic decision-making.- Learn more about The ServerlessEdge - see link below- Explore GitHub's Awesome Worldly Maps for useful mapping tools.Don't miss this deep dive into mapping strategies to enhance your organisation’s situational awareness and tech evolution!Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailWardley mapping is a strategic tool to visualise the evolution of products or services. The two axes of a Wardley Map are visibility and evolutionary stage. Products and technologies evolve through four stages: Genesis, Custom build, Product or rental, and Commodity or utility. Understanding context and phase of adoption is crucial in the business world, especially with AI and LLMs. Identifying and moving commodities versus custom-built solutions is important, and optimizing organizational structure for autonomy involves concepts like movement, time planning, and sub-maps. We explain the anatomy of a Wardley map, starting with the anchor (customer) and emphasising the importance of understanding the map's axis and how space and position have meaning.Evolution of technology from Genesis to Commodity, with stages of Custom Build and Product.Product evolution from Genesis to Custom, Commodity, and ubiquity, tailored to specific contexts.We explain the evolution of products through usage and competition and product evolution is context-dependent.Leveraging AI and LLMs in business contexts.We highlight the varying perceptions of LLM and Gen AI across different contexts and note that DBT is marketed as a product or consumer depending on the context. We discuss the importance of understanding user needs and dependencies in designing a successful product.Mapping components to move from custom-built to commodity products.We look at the importance of mapping components to move a business forward and identify inertia as a challenge in moving components, and discuss ways to overcome it.The conversation highlights the importance of leveraging commodities and building a database in 2024. We discuss the evolution of AI, from its early stages to its current utility, and the importance of having the right team types, including explorers, settlers, and time planners. We emphasise the need for all three team types, as each one plays a crucial role in the AI development process, and spikes in team performance can be identified and addressed accordingly.Mapping for autonomous organisations, including optimisation, movement, and sub-maps.We look at the importance of optimising for movement in engineering teams, with different strategies for 'pioneers', 'settlers', and 'villagers'. And the need for organisation-wide alignment and the use of mixed methods within Wardley Mapping, with a focus on stacking boxes when necessary.We look at the importance of mapping in software development, highlighting different types of maps and their uses.And we provide tips for creating effective maps, including using sub-maps for detailed areas and avoiding too many components on the map.Wardley Mapping Resou

Send us Fan MailWe discuss facilitating effective collaborative mapping workshops and creating Wardley maps for strategic planning in businesses. We look at the importance of creating a safe environment, effective facilitation techniques, and involving all stakeholders in the mapping process. We also highlight the benefits of embracing diversity and respecting different opinions. And we share various approaches to creating and utilising Wardley maps, including Miro and Lucid, and learning more about the technique through Ben Mosior LearnWardleyMapping.com resources.Wardley Mapping techniques and anti-patterns.Dave Anderson and Mark McCann discussed anti-patterns in Wardley mapping, including "gaming the system" (Dave Anderson).The speakers shared their experiences and insights on how to avoid common mistakes in Wardley Mapping (Dave Anderson, Michael O'Reilly).Collaboration is key in mapping exercises, as it helps to identify blind spots and improve the overall quality of the map.It's important to strike a balance between mapping by yourself and collaborating with others to ensure a richer feedback loop and improved map quality.Michael O'Reilly suggests mapping a subject matter to identify blind spots and derive questions to ask (0:05:10)Dave Anderson advises against re-creating architecture diagrams and instead focuses on higher-level abstraction (0:06:27)Software development, components, and abstraction.Dave Anderson and Mark McCann discuss the challenges of defining and understanding components in software development.Experience and wisdom are key to summarising complex conversations and determining the appropriate level of abstraction for components.Dave Anderson and Michael O'Reilly discuss the importance of context in understanding a Wardley map, with examples from their own experiences.They emphasize the need to introduce new people to a shared conversation gradually, rather than expecting them to pick it up quickly.Facilitating workshops, mapping, and collaboration.Michael O'Reilly and Dave Anderson discuss the importance of mapping in strategy development, highlighting its ability to shake out key elements and dependencies.Mark McCann emphasises the value of psychological safety in a top-down environment, where managers must create a safe space for team members to share their thoughts and ideas.Dave Anderson and Mark McCann emphasise the importance of creating a safe environment where participants feel comfortable sharing their opinions and asking questions.Facilitators should be open and non-forced in their approach, allowing participants to take the lead and challenge each other's perspectives.Using Wardley mapping to understand user needs and dependencies.Dave Anderson and Mark McCann discuss the import

Send us Fan MailDave, Michael, and Mark discussed the application of Wardley Mapping in understanding movement and making strategic decisions. They share their experiences with the method, emphasising its ability to visualise and track changes in tech stacks and capabilities. They also discussed the importance of context, user needs, and facilitating meaningful conversations through mapping. Additionally, they highlighted the benefits of mapping for challenging each other's thinking and fostering creative dialogue. Later, they discussed the importance of understanding user needs during agile transformations, including the value of having a shared representation of collective experiences and strategies for removing barriers to change in an organization.OutlineUsing Wardley mapping to improve understanding of complex systems and software development.Dave Anderson and Mark McCann discuss the history of Wardley mapping, including when they first learned about it and how it has evolved over time.The hosts emphasise the importance of mapping movement and tracking progress in the context of technology and capability, citing examples from their own experiences.Mark McCann: Focusing on user needs in Agile transformations helped teams understand why they were delivering code.Michael O'Reilly: Participating in mapping sessions helped him understand technical nuances and communicate with non-technical stakeholders.Mark McCann: Identified value chain visibility as key to success Dave Anderson: Custom skill sets and implementations were hindering progress Challenging inertia points in team decision-making.Dave Anderson and Mark McCann discussed the importance of mapping out problems and inviting team members to contribute their perspectives.The team used a structured approach to thinking deeply about problems and coming up with solutions, which helped to challenge assumptions and identify areas for improvement.Identifying and addressing inertia points is crucial for strategic maneuvering.Leadership principles, including courage, collaboration, empathy, and narrative.Dave Anderson and Michael O'Reilly discussed the importance of courage and collaboration in tackling complex problems.They emphasised the need for shared understanding and mapping with other teams to make better decisions.The importance of context in mapping: Understanding the user's needs and perspective is crucial for effective mapping.Empathy and narrative: Mapping can facilitate empathy and storytelling, but it's important to show the map to the right audience.Principles of Wardley mapping for strategic planning.Michael O'Reilly and Mark McCann discuss the importance of simplifying complex systems through Wardley mapping, focusing on the principles of abstraction and dialogue.<br/

Send us Fan MailThe Value Flywheel Effect is a pattern seen in organisations where business strategy and technology strategy align, leading to more sales and growth.The hosts discuss the concept of the value flywheel effect, its origins, and how it applies to creating software for customers.Dave Anderson and Mark McCann discuss the four phases of the value flywheel process, with three principles for each phase, aimed at building momentum and sustainability in organizations and teams.Clarity of purpose is the first principle, visualised as a data-informed Northstar, helping teams understand their core user needs and improve situational awareness.Software development principles, including focus, clarity, and understanding the market.Michael O'Reilly and Dave Anderson discuss the importance of aligning individual and team goals with the overall organisational Northstar.They emphasise the need for a clear problem statement and direction to focus attention and achieve success.Michael O'Reilly and Dave Anderson discuss the importance of focusing on time to value in product discovery, rather than just time to market.They emphasise the need to map the market and clarify the business's purpose, rather than just focusing on individual silos or software pieces.Dave Anderson looks at the importance of understanding a company's strategy and market position, even for software engineering teams.Mark McCann suggests that junior engineers can gain valuable insights by analysing a company's website, LinkedIn, job postings, and press releases to understand their competitors and industry landscape.Engineering team structure, process, and enablement.Michael O'Reilly: Embrace diverse teams for success, learn from failures.Mark McCann: Socio-technical systems crucial for successful teams.Michael O'Reilly and Dave Anderson discuss the importance of enabling and empowering engineers in High Performance Engineering, including creating a generative environment and mapping the organisation for enablement.Mark McCann adds that removing friction points and impediments is crucial, including developer enablement, handoffs, and carving off certain things to encourage smaller approaches. Prioritising tech stack, offloading non-differentiating tasks, and mapping solutions to customer needs.Focus on delivering value, not just building code.Dave Anderson emphasises the importance of prioritizing tech stack and deciding what to move to the right, while Michael O'Reilly and Mark McCann discuss the benefits of mapping out the tech stack and identifying key differentiators for the business.Modernising software development and delivery using AWS Well-Architected Framework.Dave Anderson looks at the importance of preventing problems before they occur in software deve

Send us Fan MailWe discuss why we wrote 'The Value Flywheel Effect,' emphasising our desire to give back to the community and help others who have contributed to their success. We share our experiences and insights on navigating the cloud transformation journey, highlighting the importance of luck, collaboration, and upskilling in overcoming challenges. We also discuss modernising engineering practices, prioritising meaningful outcomes, and providing insights on change leadership and decision-making techniques.Modernising software development and delivery in the cloud.Michael O'Reilly and Dave Anderson share their experiences working together in the cloud industry, mentioning luck and serendipity as key factors in their success.They emphasise the importance of being high up the value chain and delivering meaningful outcomes, even in the face of economic ups and downs.Michael O'Reilly and Dave Anderson discuss the shift towards modernisation in engineering, with a focus on agility and speed.They emphasise the importance of thinking differently and acting collectively to drive change in the industry.Modernising software development and embracing new technologies.Organisations must adapt to changing industry expectations and evolving technologies to remain competitive.Dave Anderson and Mark McCann discuss their book on modern software development, with Dave crediting Mark for encouraging them to write it.Mark McCann recounts how they met and shared ideas before writing the book, with Dave describing it as a "big confidence boost."Modernisation strategies for technology and business.Dave Anderson and Michael O'Reilly praise Simon Wardley's mapping technique and strategic thinking, citing his ability to make complex decisions and decompose things down.Simon Wardley's 2015/2016 talk on serverless computing is highlighted as a standout moment, with Dave Anderson calling it "super important" and Michael O'Reilly praising his ability to entertain and carry a message.Dave Anderson and Mark McCann discuss modernisation in organisations, emphasising the importance of leadership and decision-making.They suggest a framework for driving modernisation, including techniques like event storming and Northstars.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailAWS Serverless Developer Advocate Team news is breaking. We discuss this and the importance of community events and fostering a culture of curiosity and collaboration in the tech industry. We emphasise the value of attending events like ServerlessDays Belfast and looking outside one's own silo to drive enterprise transformation. We also discuss the significance of developer advocacy in promoting AWS adoption and we look at the challenges of quantifying the impact of advocacy work and the importance of learning about new technologies and driving change within companies.OutlineServerless development and engineering history in Belfast.ServerlessDays Belfast provided a great opportunity for attendees to engage in meaningful conversations with both beginner and seasoned experts in the field.Serverless technology and its impact on software development.We emphasise the importance of applying new ideas and learning from others in the tech industry.Jeremy Daly's keynote at the event inspires attendees with his innovative approach to serverless computing at AMP.We praise the AWS Developer Relations team for their helpfulness and unbiased opinions.The team has been a valuable resource for learning and validation, with their content and opinions shaping the field.Leveraging serverless technology and its benefits in modernisation and migration efforts.We credit the DAs with breathing life into the serverless movement and discuss how serverless technology can help modernize enterprises by leveraging existing work and tailoring it to specific contexts.Developer advocacy and its impact on the tech industry.We highlight the valuable insights and expertise of various serverless experts, including Julian Wood, Eric Johnson, David Boyne, Marcia Villalba, and Chris Munns.We recommend reading the ServerlessLand site as a go-to resource for understanding serverless technology and strategies.We discuss the impact of their developer advocacy work on AWS, highlighting the need for continued investment in Dev Rel.We emphasise the difficulty in measuring the impact of their work but noted anecdotal evidence of significant change driven by their efforts.Modern cloud solutions and their evolution.We discuss the evolution of developer advocacy at AWS, highlighting the importance of feedback loops and professionalism.And emphasise the value of connecting customers with the product team to address feature requests and shape product direction.We discuss the evolution of cloud services, including the term "next gen" and the importance of situational awareness.And reflect on their favorite team and thank engineers for their work, encouraging listeners to follow TheServerlessEdge.com website and channels.Serverless Craic from

Send us Fan MailWe use the Cynefin Framework in our cloud modernisation work. Dave Snowden created the Cynefin framework. Cynefin, pronounced "ku-nev-in," is a Welsh word that translates as "place" or "habitat." However, it can also be used to describe the elements of our situation and personal history that influence our thoughts and decisions in ways we don't understand.It's a sense making framework. As architects, we find that the Cynefin framework is a good thinking model.In the Cynefin framework there are four domains and a fifth disorder domain. The first four domains are: 1. Clear, when something is well understood, 2. Complicated, it's understood by few, 3. Complex, where there are a lot of unknowns. 4. Chaos, when you don't know what's happening. The 5th domain in the middle is called Confused. If you understand which domain you're in, you can assess where you're at, and if you're not aware of where you are, you're just confused. When you deal with situations and teams, it's sometimes easy to see the problem or situation. It falls under one of the domains and there are a bunch of practices to apply. When something's well understood and clear, the practices are different than for something that's complex. There are different ways for you to handle situations. And if you're a manager, there are different ways to manage.  A chaotic project needs different practices to a project that you know well and when know what to do. We explain each of the domains and we apply them to Software Development.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailServerlessDays Belfast 2024. ServerlessDays Belfast is back at Titanic Hotel Belfast on Thursday 23rd May 2024Our theme is 'Building Beyond Boundaries: ServerlessDays Belfast celebrates the spirit of Innovation'. Find out why you should come to the birthplace of Titanic and what you can expect from this year's ServerlessDays Belfast.From the 100-year-old Drawing Offices at Titanic Hotel Belfast, we will celebrate how the Serverless Mindset enables engineers and organisations to break barriers and build like never before. We ask our speakers to speak of the courage, ambition and resiliency needed to build big. We will showcase international and local speakers, attracting interest across Europe and the US. Most importantly, we want to inspire Engineers in Ireland, the UK and the local tech community.  Serverless has transcended technology and is now a synonym for Digital Transformation. Engineers working for large and small organisations need a dedicated space to hear and share innovation stories, with Serverless First as the enabler. Senior executives sense that Serverless is at the intersection of technology and business. Everyone needs a network to access the playbook for the Modern Cloud. Everyone is welcome, especially:Engineers who are curious by nature are excited to explore new technologies and ways of working.Leaders seeking the latest solutions and innovations, including product managers, programme directors, and CTOs.This event is a dedicated space for you to network, share, learn and become inspired about Serverless and Modern Cloud. We look forward to seeing you there!What’s on offerFood and BeveragesServerlessDays Speaker Agenda: Listen to renowned experts on ServerlessNetwork with fellow attendeesServerlessDays Belfast 2024 Call for PapersWe’re looking for speakers who can share their stories about how serverless technology has helped them achieve amazing things.The theme for this year’s event is “Building Beyond Boundaries”. We want to celebrate the spirit of Innovation and share stories of real change. Tell us about something incredible that happened, how you felt and how the tech helped out.If you’re interested in speaking, submit your talk by March 31st! We will cover travel and accommodation expenses for speakers living outside commuting distance.Take advantage of this opportunity to share your knowledge and experience with the serverless community on the island of Ireland.Learn more and submit your talk on Sessionize.  serverlessdaysbelfast.com/twitter.com/BFSServerless<a href='http://linkedin.com/company/serverlessdays

Send us Fan MailThe Software Development Lifecycle - how does it apply to modern cloud?We are kicking off this episode with the term modern SDLC. The software development lifecycle (SDLC) is changing. When you get into this new way of working, you start differently. It's no longer a straight waterfall/ABCD, or starting with an established system like SCRUM and iterating. So how do you get into a fast flow state? We have discovered a lot of things over the past couple of years. In this episode, we talk you through the phases of the modern software development lifecycle.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailWe talk about what we would like to see announced at this years AWS re:Invent 2023 looking at Observability, Generative AI, PartyRock, Developer Experience to name a few.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailTeam Engineering with SCORP - there are practices we do like SCORP, which is our agile way of doing well-architected in every sprint with teams. Our practices are connected to engineering excellence, looking at what you're doing and constantly improving. And HP (high performing engineering), as a way of capturing key metrics to define good engineering or architecture, and then talk about it as a team.Even though the practices are out there, it's really just a mindset.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailThere were a few stories in the news about working remotely from another country. We talk about the pros and cons of working remotely versus returning to work. We work remotely and are globally distributed, but we've worked for many years in the office to, so we have experience of both to make a fair analysis.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailDeveloper Productivity and discussions on developers and productivity have never gone away. You heard people talking about this in the 80s and the idea of paying developers by lines of code. And it was even rubbished in the 80s as a foolish thing to do. There's a famous story about developers removing bad code from the code base and having negative numbers by the end of the week and then asking if they have to pay the company back money. It's never been a good idea. It strikes me as strange that in 2023, we are having the same discussion.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailHow important is Resilience Hub, Chaos Testing and Well-Architected?We attended the AWS Resilience Day at the Titanic Hotel. We were sitting in the same room where the ill-fated Titanic was designed and drawn! We discuss what we learned. Including the tools and strategies that help software engineers build resilience that were not available for the Titanic engineers. And we talk about the fact that it isn't just one thing that leads to disaster for ships or workloads.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailBringing mapping to your org. We are doing a wee series on Wardley Mapping, with some practical items. The last two episodes were: 'Wardley Mapping 101' and 'Can Wardley Maps Predict the Future?'. So I thought it would be good to answer a common question: 'That's a cool technique, but how would I do that in my work?'. If you follow Simon Wardley, on Twitter, and you've started experimenting with Wardley Mapping, we tell you how you to bring Wardley Mapping to your place of work.We talk about using the Northstar exercise to facilitate mapping. And about finding like-minded people to sit and practice with. There is a way of talking about mapping. You're better to start with the outcomes. And then see if people are interested to get back into the map, as a way of sensemaking complicated areas. It's great to make sense of something and share that thinking with peers. And once you get into that language, you open up a common way of thinking and the idea of evolution to access things you want to talk about it.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailCan Wardley Maps predict the future, is our topic this week.In our last episode, we talked about Wardley Mapping. We did a 101 last time, explaining the basics.One of the things that we say is that Wardley Mapping is a superpower that helps you predict the future. What do we mean by that? It's like a fortune teller. But it doesn't tell you when exactly something's going to happen. It's the state of mind that it puts you in. We run through a couple of examples, to demonstrate how we've done it in the past.Conversational ProgrammingGenerative AIWell-ArchitectedServerlessCDK (Cloud Development Kit)If you have good situational awareness, you can wait until the appropriate time. You don't have to go off and waste energy, cycles and money trying custom build something. Wait three months and you'll get what you're trying to achieve.When you map this stuff out, you can start to think about how your sensing engine can get intel on whether these things are going to happen or not. There are lots of different ways you can do that. Like following Twitter feeds and looking at blogs. And looking at who they're hiring and following the industry experts. They're points of information that can help you see how things will evolve. To predict the way things are going to go. There are multiple levels of maturity in your map and how you think it's going move and where the evolution is going to happen.Wardley Mapping can be used to predict the future but it's not going to give you an exact date. What it can do is give you an example of this is what it will look like if it happens. So you prepare yourself for when it does. And then when the press release comes out, you're like, boom, we're ready. We saw that coming. So it's the no 'surprise approach' to building situational awareness. Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on LinkedIn Subscribe on YouTube

Send us Fan MailWardley Mapping is a core part of our book: 'The Value Flywheel Effect'. And it's a topic that people always ask about it. It's a difficult thing to learn. We've spent many years thinking about it, stumbling around, and then practicing. So we figured we would do a quick series on Wardley Mapping.We have spent almost 10 years mapping, give or take. For me, it has been an absolute game-changer. One thing that's come along recently is the Wardley Mapping canvas by Ben Mosior @hiredthought. It's a nice canvas with six steps on how to map. Before I started using the canvas, I used to find that maps could get big and go off in 60 different directions.Purpose and scope are the first two steps. And then the third one is users. The fourth one is user needs. And then the fifth step is the value chain. It can be difficult to keep things abstract. And not go too deep. But it is good to be as abstract and high-level as possible, even just to start to get something down.Once you have the value chain of the user, a need, and a couple of dependencies, that's when you then bring it across to the map. And I would usually put them in the middle of the map. Drop them all into Product, to get you started. So you've got them all in a vertical line on your map and canvas. You start moving different components from left to right. And you might work out that one of the dependencies is Commodity or Custom. And you can see how that interaction goes. That's when you start to add in dependencies because you've got more room in the map.This is where the conversation really starts to kick into gear. And this is where people start to challenge each other's context and think about where that component belongs or what's missing from the map. So it makes for a very collaborative exercise.If you are planning a mapping session, you need to be a good facilitator. If a participant feels something is in the wrong place. Don't say no, you're wrong. It's in the right place. You want the individual to explain why they think so. If it is something that's blatantly just them for raising the challenge. The last thing you want is an unsafe environment where nobody wants to speak.It doesn't need to be too fancy. You might map for an hour. And if you're facilitating, five or 10 minutes off the hour, you take a couple of notes, If someone says we should move that component from x to y that's an observation, You're not committing to do it but just taking a few observations. Always just keep it simple.So here are a couple of really good links. We talked about Ben Mosier @hiredthought. He's got a brilliant site called LearnWardleyMapping.com. Ben created the Wardley Mapping C

Send us Fan MailServerlessDays Belfast was on the 28th of February. It's a volunteer, community, and not-for-profit event.We had a bunch of sponsors: AWS, Bazaarvoice, EverQuote, G-P, Instil and LibertyIT.Our organizers are me, Gillian Armstrong, Garth Gilmour, Peter Farrell, Julie Sherlock, and Treasa Anderson. We had 12 speakers, and over 260 attendees from over 40 companies. But most excitingly we had it at the Game of Thrones Studios Tour.The theme was 'The Reality and Fantasy of Serverless, Building Serverless Teams and Making it Real'.Phil Le-Brun, who is the Director of the Enterprise Strategy Team for AWS launched the event. And give us a perspective of what he sees when he is speaking to the leaders of the industry.IT Revolution was very generous to sponsor and provide 250 of 'The Value Flyweel Effect' books.Julian Wood gave the Keynote. Even though he works for AWS as a Serverless Developer Advocate, he gave his opinion on where he sees the industry. I thought that paired really nicely with Mattie Wilson from Instil. He gave a brilliant talk on an engineering team going through the journey from a cloud application to a serverless application.Sheen Brisals from The LEGO Group, as ever, gave an absolutely brilliant talk about Lego's journey. Going Serverless to EDA and the team topologies of an event-driven organisation. Sheen is an absolute master.Jonah Andersson did a talk on the .NET stack. And Conall Bennett and Roger Moore did a talk on CME Group's move to a Google tech stack. Craig McCarter talked about large-scale serverless. And I took comfort from hearing about a team that's doing something financially significant at a massive scale. And they're pushing those limits.I really enjoyed the talk by Anna Carlin and Emma Patton from Aflac Northern Ireland. They called their talk: 'A rookie journey of discovery and learning'. So they came in as grads and basically built a serverless system. And Chintan Parmar's Dunelm story was really interesting about Dunelm's e-commerce site because it's quite an unknown story. Most people had no idea that they had a whole big serverless ecommerce site.Ben Ellerby from Aleios closed out with his Serverless Staircase Framework. I've been a fan of Ben's for many years. He's an AWS Hero. He's brilliant and very experienced. And he's worked on a lot of serverless projects. That is what his company does. So he's got lots of war stories from doing this with real customers.Serverless CrAIc from The Serverless EdgeCheck out our book The Value Flywheel Effect Follow us on X @ServerlessEdgeFollow us on Link

Send us Fan MailWe've been talking about AWS re:Invent over the last few episodes. But one thing that we haven't talked about is Serverless Espresso.Serverless Espresso is a pop up coffee shop that allows you to order coffee from your phone. In the Expo Hall at the AWS Summit, they have a Barista setup. And you walk up to a QR code with a screen in the background. So you scan the QR code and enter in your email address. And up pops a menu. If you select an americano, espresso or other type of coffee, it kicks off an event driven flow. It uses an event driven service under the hood and pops up in the screen as a number. And then the Barista takes the number makes your coffee and gives it to you.But what's happening in the background is a whole load of orchestration and choreography run events. And as they've been using it as a way to explain serverless event driven architecture. Event driven architecture can be hard for people to conceptually wrap their heads around. So making it real through ordering coffee. And showing how to tie a coffee process and an event driven coffee ordering system makes it real. It stitches together a lot of stuff that we've been advocating for, in a way that makes sense. By using AWS Step Functions, EventBridge, Lambda, API Gateway, S3, DynamoDB and Cognito.There are two myths in this space that AWS are trying to dispel. We first started talking about event driven architecture 13 years ago. We had the idea of doing something but back then it was really difficult, because we didn't have a lot of support. So we had hard problems to solve technically, because the foundations weren't there. That is the first myth of being a hard thing to do.The second myth is that people think of serverless as just writing code and functions. It's actually more like an event driven architecture. It's events firing off activity and not a call stack. So it's a lot easier to build full event of architecture than it would have been years ago. The technical challenge is not as bad as you think it is.What I like about Serverless Espresso is the simple interactions. You order, it goes to the barista who makes the coffee, and he gives it back to you. There's one interaction. Normally when ordering a coffee, you talk to a waiter, the waiter talks to the barista, and the barista talks to someone about milk etc. There can be six or seven people in that flow. It causes confusion. In a company, if a business process is owned by six or seven teams, even across two or three departments, it gets messy. If a single team builds for the customer directly and there's no one else, it's usually pretty clean. Serverless Espresso Lab is good, because the opinions are out there and you add on your bit, which is your business process flow. It goes back to our book The Value Flywheel Effect. And the first phase of the value flywheel

Send us Fan MailAWS, What's New? We are post AWS re:Invent. To sum up, it was about the next generation of cloud focused on delivering value quickly by removing barriers to business adoption and enablement. On Day 1 SiliconAngle published an article called "AWS chief Adam Selipsky hints at the next-gen cloud". He looks at classic cloud versus next-gen cloud. Classic cloud is infrastructure as a service and the platform of the cloud. And next-gen is looking at ISVs and true cloud. It's about using the cloud to power you business journey. Which is exactly what we talk about in The Value Flywheel Effect!AWS are market leading for low level cloud primitives. If you want compute, get it from AWS. It has been this way for the last 15 years. But next generation cloud is about business capability. When you do Wardley mapping correctly, cloud primitives are pushed to the right to become commodities. You then look for the business capability you need. That's exactly what the value flywheel effect is. AWS are consolidating core primitives and opening up the solution space to help customers do interesting things with them. There has been a lot of criticism of AWS in previous years with regards to their developer experience. Code catalyst is a big move from AWS to try to make that more seamless. It stitches together a number of things that have evolved over the last while. It's an accelerator for teams coming on to the cloud or into serverless. And it is frictionless developer experience. In our book, it's the next best action phase of the value flywheel.Well architected featured heavily at AWS re:Invent. AWS are continuing to develop well architected and build it into things. Security also featured with verified permissions. It's out in pilot at the moment but it has potential to make a big impact on managing fine grained permissions and doing identity authorization properly, especially if you have a custom app. Most companies of a certain scale have their own custom built version of this. But you need to acknowledge that you are ahead of the curve. And have the courage to delete your custom built solution. There's a bunch of step function stuff out. I particularly like SnapStart which gives you the ability to drop large java applications into lambda. And performance time is through the roof. You can draw up an average Spring Boot application into lambda and you will get similar performance but it's way cheaper to run.  It's addressing the myths around cold starts and using lambda for high performance workloads. It's also interesting from the perspective of having large framework oriented services and leveraging those for femoral compute.<p

Send us Fan MailAWS reInvent announcements In this episode we are talking about what we would like to see at AWS re:Invent. What would you like to see?Serverless ServicesAn increase to the enhancement and evolution of service development capabilities and the ecosystem in general. So more serverless services coming online for items that aren't serverless and iterating to be more serverless. There's a bunch of things that people are almost afraid of like observability, deployment patterns and some of the frameworks.API GatewaysIn service development, Private API gateways are interesting, but they could be more developer friendly, in terms of setting up, naming and managing. We are seeing more enhancements around eventing capability like SNS filtering, SQS and X ray. These are things that make the serverless experience more rich and all encompassing.Developer EnablementYou need to think about developer enablement and time to value. Can you get a developer up and running with a productive IDE in the cloud? And can they start delivering value rapidly? We're seeing steps around Cloud IDE starting to emerge. I want to see what AWS does around their Cloud9 offering. Well ArchitectedOver the last year, we've seen good announcements on well architected capabilities, systems and services. I want to see a continued evolution of that. And more well architected thinking and characteristics baked into everything.  All the way from developer advocates to patterns and code samples.  Some of the basic primitives are moving up a level to something more like a pattern.It's about fast feedback and dare I say the value flywheel. Can the pipeline's tell us how well architected the chains that we made are. And can our IDE tell us how well architected we are? Stitching that together in a compelling way with fast feedback for the developers would raise the bar on what developers deliver into production.That's effectively platform heuristics. I remember back in the IBM mainframe days, it was a mature platform. And you knew it so well, that they started to bake in heuristics. When you start to analyse your code there would be a heuristics to say this might be wrong. Here's what you need to do to fix it.We're starting to see some of these elements emerge already with Security Hub, Reliability Hub and Fault Injection Simulator. It's about stitching those together like factory mode for workloads in your accounts. Tell me we're not well architected, and tell me how to fix it. SustainabilityMore fine grained analysis of carbon scores would be useful when teams are designing and building their workloads. And getting faster feedback on a particular service and how much it is going to cost you in carbon.What's the wacky stuff you woul

Send us Fan MailIt began with the forging of the Great Maps and Simon Wardley We've been talking this week about Wardley mapping. Where did you first hear about Wardley Mapping? I first heard Simon Wardley talking at cloud conferences about early cloud. I remember an open source conference and a 20 minute video. When he presented it came across as common sense. Like, why would you do anything else? The bigger question is why were we looking for this type of stuff? Or why did it resonate with us? I think we were at a certain point in our careers. We had been engineers for a while. And we thought there's got to be a bigger picture here that we're not quite grasping. Simon Wardley started writing his book in 2016. I went to Lean Agile Scotland in October 2016. And he did the talk in person. I had seen his talk a couple of times, but it didn't really click until I sat and watched it in real life. Remember, there was a time when we said we need to stop using PowerPoint! We need to get people into rooms to have conversations and working sessions. I refined and improved my ability to do Wardley Maps through teaching. There were people who hadn't experienced mapping. There's another important step. You move from doing it yourself to doing it in a group environment. When you are looking at a map you are figuring it out. When you do it in a group environment, the group will ask about this and that. And that's when it really starts to click. For me, the two big things are: 1. Start with a customer need. I remember a team were stuck for six months because they didn't know who the customer was. 2. The four phases of evolution or access (Genesis, Custom Built, Product, Commodity). Get your head around that concept. One of the other pitfalls we fell into was mapping too much detail. We went too low level. And then someone came along and zoomed us out, by saying 'you don't need those five components. Here's just one!'.  Another important lesson is that senior people just want to hear what you are going to do. They don't want to know how you figured it out. If they say why are you doing that? You can go through the map in your head and say that you've thought about it. If you say this is what we are going to do and here's the outcome, you don't need to show them all your work. When we started mapping there wasn't much about apart from the odd presentation. Now there's lots of material out there. The community is growing. You can google and look up YouTube. And there's online conferences as well like Map Camp. For resources look at Simon Wardley on Twitter @swardley and his pinned tweet. Simon has a book: 'Wardley mapping'. He is on Medi

Send us Fan MailWhat is Engineering Excellence?Few companies say they don't want good engineering.  But they don't define what good looks like. And secondly,engineers are expected to write lots of code. For me, engineering excellence is not writing loads of code. It's about getting into code reliability, feedback loops and how well engineering is functioning. And how your team is performing and meeting bigger goals. I love to say 'slow is smooth and smooth is fast'. So how do we set ourselves up for that? At the beginning, I like to go slowly to look at our process. To define engineering excellence, we use Dan Pink's motivation factors of autonomy, mastery, and purpose.  We translate those motivation factors to technical excellence, autonomy, and customer focus.Well architected is better defined than engineering excellence. But I find that a lot of people haven't heard the term well architected and they think you've just made it up! If you want to move fast, you've got to be empowered and know what good architecture looks like.  When you have guidance or patterns that are implemented in a well architected fashion, that sets you up for rapid delivery, moving with speed, and in an engineering excellence way. It's fast flow aimed to facilitate you moving fast, getting things out quicker and being more competitive.Teams are rapidly delivering product value multiple times a day. And they have a trail of evidence that they're going the right way because of these practices. They have dashboards, logs, alarms, alerts and the run books and the playbooks.  And the key business indicators (KPIs) at their fingertips. So any stakeholder can challenge them on what they are doing, how they are operating or what they are deploying.  If you arrive in an area that isn't well architected, you've got to spend three months trying to understand what went on before  or trying to understand the decision making. Or you've got 12 months of technical debt that should have been taken on board before you moved there. That very difficult from a personal perspective. There's a whole bunch of advantages. One is a problem prevention culture. But I don't think it exists in a lot of organisations. It hasn't really cut through. They're still on the feature, factory, server mindset. Deliver, deliver deliver. Feature, feature feature. And then they have a tipping point where everything grinds to a halt for months or maybe years. And it may never recover. But if you have a continuous improvement mindset and you are investing in fraud prevention, well architected, engineering excellence and continuous learning. And you are enabling and applying this to your teams, you get ahead of problems before they become problems. From a problem prevention perspective, do you want to spend all your time babysittin