Episode

Splitting without Splitting (Tsvetelina Plummer, Pricillia Gunawan)

Podcast
Software Architektur im Stream
Published
Mar 17, 2026
Processing state
not_requested
Canonical source
https://software-architektur.tv/2026/03/10/episode305.html
Audio
https://1evriw.podcaster.de/software-architektur-im-stream/media/Splitting_without_Splitting_from_AmA_Conference_-_Ohne_Intro.mp3
JSON
/v1/public/podcasts/software-architektur-im-stream-3090375/episodes/splitting-without-splitting-tsvetelina-plummer-pricillia-gunawan
Markdown
/podcast/software-architektur-im-stream-3090375/splitting-without-splitting-tsvetelina-plummer-pricillia-gunawan.md

Actions

  • POST https://stenobird.com/v1/public/podcasts/software-architektur-im-stream-3090375/episodes/splitting-without-splitting-tsvetelina-plummer-pricillia-gunawan/transcription-requests
    Idempotently request low-priority transcript generation for this episode.
  • GET https://stenobird.com/podcast/software-architektur-im-stream-3090375/splitting-without-splitting-tsvetelina-plummer-pricillia-gunawan.md
    Read the agent-friendly Markdown representation of this episode resource.

Summary

This episode was streamed live from Agile meets Architecture conference. We all know it - our team has become too big, meetings take too long, half of the conversations don’t apply to our work, and the sprint goal is now “finish all stories in the sprint”! The classic textbook and the chatbot are certain: The team should be split! And this is indeed the optimal solution. But real life isn’t a textbook, and our resources aren’t infinite. What if instead of slicing to be a-two-pizza-team, we asked the question: “What do we actually need to work well together?” After over 4 years working with several large data science and engineering teams that wrestled with multiple variations of the same problem, we’ve resisted the urge to split by the book. Instead of insisting on the one right way, we want to show you how tuning in, listening, and deliberately choosing the solution, can bring back the fun, ease and coveted efficiency we all are after. That could mean: changing who does what in the team, redrawing team boundaries, or combining pragmatic approaches of multiple organizational design systems like LeSS, Team Topologies, and Fluid Teams. The trick is to stop chasing the perfect model and start designing something that actually fits both the team’s culture and unique problem domain. Think of it like tailoring a suit: it has to fit the people wearing it, not just look good on a cover.