Podcast appearances and mentions of manuel pais

In this episode of Le Podcast on Emerging Leadership, I had the privilege to speak with Manuel Pais, co-author of the influential book Team Topologies. We examined how modern organizations can refine their structures to optimize both value delivery and employee satisfaction.Find the key findings, the references, and the transcript of the episode in the companion blog post: https://alexis.monville.com/en/2025/06/02/unlocking-flow-and-effectiveness-a-conversation-with-manuel-pais-co-author-of-team-topologies/

In this episode of Book Overflow, Carter and Nathan discuss the second half of Team Topologies by Matthew Skelton and Manuel Pais. Join them as they discuss how teams evolve, when you can tell a team might be reaching its breaking point, and what a company needs beyond the team topologies!-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Team Topologies by Matthew Skelton and Manuel Paishttps://amzn.to/4kgfH3F (paid link)----------------00:00 Intro01:26 About the Book03:10 Thoughts on the Book09:20 Team Interaction Modes41:01 Changing Team Structures01:05:04 Final Thoughts----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this episode of Book Overflow, Carter and Nathan discuss the first half of Team Topologies by Matthew Skelton and Manuel Pais. Join them as they discuss the four main types of teams, what teams they've worked on in the past, remote work, and more!-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Team Topologies by Matthew Skelton and Manuel Paishttps://amzn.to/4kgfH3F (paid link)----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

The common refrain after an incident is “We could and should learn from this”. To me, that alludes to the need for a robust learning culture.We might think we already have a good learning culture because we talk about problems and deep-dive them into retrospectives.But how often do we explore the nuances of how we are learning?Sorrel Harriet is an expert in supporting software engineering teams to develop a stronger learning culture. She was a “Continuous Learning Lead” at Armakuni (software consultancy) and now does the same work under her own banner.Her work ties in well with the ideas shared by Manuel Pais in episode #45 about how enabling teams can support a continuous learning culture. We tackled issues like the value of certifications, comparing technical with non-technical skills, and more. You can ⁠connect with Sorrel via LinkedInLearn more about what Sorrel does via LaaS.consultingHere's a bonus section because you read all this way. It covers 5 public outages and how the affected teams could improve their learning culture: 1. Slack Outage (February 2023)Slack experienced a global outage disrupting communication for hours due to backend infrastructure issues. Perhaps the team could focus their learning on more robust infrastructure management and resilience improvement.2. Twitter Algorithm Glitch (April 2023)A glitch in Twitter's algorithm caused timeline issues, stemming from a problematic software update. Perhaps the team could focus their learning on thorough testing and game days to rectify critical system errors swiftly.3. Microsoft Azure AD Outage (March 2023)Azure Active Directory faced a significant outage due to an internal configuration change. Perhaps the team could focus their learning on the importance of rigorous change management and how to address misconfigurations quickly.4. Google Cloud Platform Networking Issue (May 2023)Google Cloud Platform experienced widespread service disruptions from a software bug in its networking infrastructure. Perhaps the team could focus their learning on the need for comprehensive testing and preventing disruptions.5. GitHub Outage (June 2023)GitHub suffered a major outage caused by a cascading failure in its storage infrastructure. Perhaps the team could focus their learning on robust fault-tolerance mechanisms and ways to address the root causes of failures. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit read.srepath.com

I continue my conversation with Manuel Pais, co-author of the seminal Team Topologies book about team topologies suitable for reliability teams.In this second part, we will talk about platform teams. A quick refresher on what platform teams doIn the team topologies context:Platform teams provide a curated set of self-service capabilities to enable stream-aligned teams (product or feature teams) to deliver work with greater speed and reduced complexity.They achieve this directive by abstracting away common infrastructure and operational concerns. By doing this, they aim to allow stream-aligned teams to focus on delivering business value.Here are the key takeaways from our conversation For those who don't have time to listen to this episode (but you're missing out on a great conversation):* Focus on User-Centric Design: Prioritize the user experience in platform development. Regularly collaborate with internal teams to ensure the platform meets their needs and reduces their pain points.* Build and Maintain Trust: Establish and nurture trust with your platform's users. Trust is crucial for platform adoption and can prevent resistance thus assuring sustained use.* Justify Platform Value: Continuously demonstrate the value of your platform to management and stakeholders, especially during economic downturns. Highlight its contributions to avoid cuts and maintain support.* Understand Adoption Lifecycle: Recognize that platforms go through different stages of adoption. Identify and support early adopters, and gradually bring in late adopters by showcasing successful use cases.* Enhance Collaboration: Foster open communication between platform teams and other teams. Avoid rigid roadmaps and be adaptable to changing needs to prevent barriers and build stronger internal relationships.* Manage Cognitive Load: Be mindful of the cognitive load on your teams. Simplify processes and reduce unnecessary complexities to enhance productivity and efficiency.* Use Tools to Measure Cognitive Load: Implement tools like Teamperature to assess the cognitive load on your teams regularly. Use the insights to identify and mitigate factors contributing to cognitive overload.* Leverage Experienced Product Managers: Ensure experienced product managers are part of your platform team. They can balance long-term goals with the flexibility needed to adapt to the evolving needs of internal users.I think the uncommon takeaway here is #9 in that platform teams should treat their platform as a product. Product Managers like and Marty Cagan are doing great work in laying out the roadmap for product management. Did you end up checking out the reliability workstreams map I published last week?It's free and can help you stay focused on the right priorities at work.Check it out via this link This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit read.srepath.com

I got the inside word from Manuel Pais, co-author of the seminal Team Topologies book, to explain in a 2-part series about 2 of the most relevant team topologies for reliability work. In this first part, we will talk about enabling teams.A quick refresher on what enabling teams doIn the team topologies context:Enabling teams help stream-aligned teams (product or feature teams) to overcome obstacles and improve their capabilities in specific areas.This kind of team is available to provide expertise, guidance, and support to other teams working to adopt new technologies, practices, or skills.In other news…This podcast has a new nameWhat more a fitting moment to announce renaming the SREpath podcast to “The Reliability Enablers” podcast?This name change reinforces our quest to demystify and enable reliability efforts so that more organizations successfully implement SRE principles and beyond. Before we get to the 8 takeawaysHere's something relevant to enabling reliability work — a reliability workflows map I've had in my private notes for years, now going public.What is a workstream?

My guest today is Manuel Pais.Manuel is the co-author of the masterpiece book "Team Topologies: organizing business and technology teams for fast flow".He's recognized by TechBeacon as a DevOps thought leader, and is today an independent consultant and trainer, focused on team interactions, delivery practices and accelerating flow.We covered a lot, including some questions and comments from Lyse and Shibsted (read the full case here):* Different types of teams and interaction modes, and why it's important to define them in your org* Differences between "streams" and "products", and the importance of having stream-aligned teams able to discover and deliver as independently as possible* Why team topologies should be seen as an ongoing model, with a mindset of experimentation, sensing, and responding (avoiding the "big reorg" antipattern)* Conway's law and why it matters* Navigating infrastructure changes and team topologies* How to identify your streams using independence service heuristics* How Shibsted organized itself in independent verticals and why value-stream thinking is important to achieve faster flow* Product Ops teams as Enabling Teams* Implementing and scaling enabling teams (with an example of data science teams)* Common antipatterns when adopting team topologiesI love Manuel and Mathew's work, and see it as one of the most important contributions to the tech industry in the past few years.I strongly recommend checking out the Shibsted case in combination with this episode, available at the Scandinavian Product Newsletter.I had the pleasure to sit down with Jostein and Hatice and hear more in detail about their use of Team Topologies and how it shaped their ongoing transformation as well as many of their lessons learned.Relevant links from the episode:Main website: http://teamtopologies.com/Tools & templates (includes ISH mentioned in the episode): https://github.com/teamtopologiesAcademy (where you can find the Effective Enabling Teams course mentioned in the episode): https://academy.teamtopologies.com/Teamperature (a breakthrough product for assessing and managing team cognitive load): http://teamperature.com/ This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit afonsofranco.substack.com

Este conteúdo é um corte do nosso episódio: “#200 - "Team Topologies": criando estruturas e times de alta confiança”. Nele, os crafters da dti digital Gabriel Naves, Arquiteto de Software e Angela Duarte, Tech Manager, explicam o conceito de “Topologia de Times” apresentado no livro “Team Topologies”, de Matthew Skelton e Manuel Pais. Essa, inclusive, é uma técnica bem utilizada que pode virar a chave de um negócio que não está caminhando bem com seus resultados. Ficou curioso? Então, dá o play! Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão na nossa página do Linkedin ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos! Nos acompanhe pelas redes sociais e assine a nossa newsletter que chega todo mês com os assuntos quentes do agilismo através do site.See omnystudio.com/listener for privacy information.

Enabling Teams bilden einen der vier grundlegenden Teamtypen innerhalb des Frameworks von 'Team Topologies'. Über diesen Teamtyp sprechen Anja und Sven mit Michael, der kürzlich das dazugehörige Buch von Matthew Skelton und Manuel Pais ins Deutsche übersetzt hat. Es geht darum, was Enabling Teams auszeichnet, welche spezifischen Aufgaben sie innerhalb von Organisationen erfüllen können und auf welche Schlüsselkompetenzen es bei den Enablern besonders ankommt, um andere Teams im Erlernen und der Anwendung neuer Fähigkeiten zu unterstützen.

Matthew Skelton is co-author of "Team Topologies: organizing business and technology teams for fast flow". He is Head of Consulting at Conflux and specialises in Continuous Delivery, operability, and organisation dynamics for modern software systems. In this conversation with Dave, he talks about the ecosystem necessary to build and nurture software, and the wide range of topics that impact on the effectiveness, and performance of development teams. The approach that his book "Team Topologies" describes is to use team structure as a tool, guided by the idea of managing the cognitive load of the team. This talk ranges from how to deal with the complex adaptive system that we inhabit when undertaking software development, to the structure of software development being more like an ant colony than an organised, predictable hierarchy.xx⭐ PATREON: Join the Continuous Delivery community and access extra perks & content!

En æra er slut. Katrine og Ole lukker døren til To Agility and Beyond. En podcast der har været så utroligt meget mere end bare en podcast. Dette er afsnittet, hvor vi tager afsked med et con-amoreprojekt, der har udviklet os ud over al fatteevne som fagpersoner, venner og mennesker. Der er ikke så meget andet at sige end TAK, TAK, TAK, fordi du lyttede med!· Monday I'm in Love med Thomas Karner-Gotfredsen og Camilla Linnemann: https://www.syndicate.dk/monday-im-in-love· Pivot Podcast m. Kara Swisher og Scott Galloway https://podcasts.apple.com/us/podcast/pivot/id1073226719· Hell Yeah or No – Derek Sivers https://www.saxo.com/dk/hell-yeah-or-no-whats-worth-doing_bog_9781988575971· Team Topologies – Matthew Skelton og Manuel Pais https://www.saxo.com/dk/team-topologies_matthew-skelton_paperback_9781942788812· Det handler ikke kun om dig podcast m. Niels Overgaard https://podcasts.apple.com/dk/podcast/det-handler-ikke-kun-om-dig-med-journalist-niels-overgaard/id1535182767?i=1000497011939&l=da· The Mini Model Thinker – Scott E Page https://www.saxo.com/dk/the-model-thinker_scott-e-page_paperback_9781541675711?gad_source=1&gclid=Cj0KCQiAj_CrBhD-ARIsAIiMxT_SF1QhcHYBq0ErZqVIfZzNEX8a-9CHFgtDmy96w0w5zT67sZJ-YBoaAh5gEALw_wcB Nævnte episoder:· Episode 1: Hånden i hvepseboet. Ja vi skal tale om skalering https://www.syndicate.dk/toagilityandbeyond/episode-1-handen-i-hvepseboet-ja-vi-skal-tale-om-skalering· Episode 3: Du er dit eget produkt. Udvikler du det? https://www.syndicate.dk/toagilityandbeyond/episode-3-du-er-dit-eget-produkt-udvikler-du-det· Episode 7: Gentag efter mig: Et team er ikke bare et team https://www.syndicate.dk/toagilityandbeyond/episode-7-gentag-efter-mig-et-team-er-ikke-bare-et-team· Episode 9: SHAPE UP! En provokerende og befriende måde at arbejde på https://www.syndicate.dk/toagilityandbeyond/episode-9-shape-up-en-provokerende-og-befriende-made-at-udvikle-pa· Episode 26: Dine øjenlåg bliver tunge. Fra nu af hyrer du kun fuldtids-Scrum Masters https://www.syndicate.dk/toagilityandbeyond/episode-26-dine-ojenlag-bliver-tunge-fra-nu-af-hyrer-du-kun-fuldtids-scrum-masters· Episode 38: Agile metrikker. Du får det, du måler https://www.syndicate.dk/toagilityandbeyond/episode-38-agile-metrikker-du-far-det-du-maler· Episode 39: Den søde produktkløe med Kresten Krab Thorup, CTO for Humio https://www.syndicate.dk/toagilityandbeyond/episode-39-den-sode-produktkloe-til-2-4-mia-interview-med-kresten-krab-thorup-cto-for-humio· Episode 42: True Crime-afsnittet. Hvorfor nedsmeltede Basecamp? https://www.syndicate.dk/toagilityandbeyond/episode-42-true-crime-afsnittet-hvorfor-nedsmeltede-basecamp· Episode 44: Fast og løst. Eller den med koppen (Det store merch-fuck-up) https://www.syndicate.dk/toagilityandbeyond/episode-44-fast-og-lost-eller-den-med-koppen· Episode 50: Hånden i hvepseboet 2: Vi bekender SAFe-kulør (Den med dildoen) https://www.syndicate.dk/toagilityandbeyond/episode-50-handen-i-hvepsereden-2· Episode 51: Marianne i regnskab har en diagnose. Du ved det bare ikke. Om neurodiversitet på arbejdspladsen https://www.syndicate.dk/toagilityandbeyond/om-neurodiversitet-pa-arbejdspladsen· Episode 61: Welcome to Flatland. Hvad skete der egentlig i Valve? https://www.syndicate.dk/toagilityandbeyond/episode-61-welcome-to-flatland-hvad-skete-der-egentlig-i-valve

Our recommended five books are:Software Engineering at Google: Lessons Learned from Programming Over Time (Titus Winters, Tom Manshreck and Hyrum Wright)An Elegant Puzzle: Systems of Engineering Management (Will Larson)Scaling People: Tactics for Management and Company Building (Claire Hughes Johnson)Build Better Products: A Modern Approach to Building Successful User-Centered Products (Laura Klein)Team Topologies: Organizing Business and Technology Teams for Fast Flow (Matthew Skelton and Manuel Pais) Software Engineering at Google: Lessons Learned from Programming Over Time (2020, 575 pages, Titus Winters, Tom Manshreck and Hyrum Wright)A fascinating insight into software engineering practices and tools used at technology leader Google. I love their definition of software engineering as programming integrated over time. The 25 in-depth chapters are written by Google domain experts and offer a glimpse into how scaling and sustainability are handled and traded against other concerns.The is a big book full of useful information, but the density of multiple authors limited to a chapter apiecedoes make it challenging to read at times. Definitely recommended, but be prepared to devote a chunk of your time to study the book and get the most out of it.An Elegant Puzzle: Systems of Engineering Management (2019, 288 pages, Will Larson)A beautifully presented hardback book containing engineering leader Will Larson's guidance on engineering management. There is a lot of strong and hard-won advice on organizations, tools, approaches, culture and careers. The content is practical and provides an unusual depth on engineering management in modern software organizations.The figures are sometimes obtuse and the last 71-page appendix and endnotes are mostly superfluous. I also did not enjoy some of the referencing out either where no information is given other than a single word and Q-code link. Regardless, this is a great book.Scaling People: Tactics for Management and Company Building (2023, 432 pages, Claire Hughes Johnson)Author Claire Hughes Johnson is a corporate officer and advisor at Stripe after spending seven years as COO while they rapidly scaled from 200 to over 7000 people. Before this, she spent 10 years at Google leading successful business teams. The book is beautifully presented, full of valuable guidance and provides practical advice of great leadership and pragmatic scaling. The examples are perfectly placed and insightful to demonstrate the advice around them.Build Better Products: A Modern Approach to Building Successful User-Centered Products (2016, 368 pages, Laura Klein)I am starting to love the Rosenfeld Media series — high-quality books, presented beautifully, edited expertly and eminently practical. Color is used intelligently throughout as you would expect from design-focused books.Lean startup expert and “What is Wrong with UX” podcaster Laura Klein writes a great book on how to build new products. This practical guide is organized around exercises with expert advice from experienced practitioners at the end of each chapter. Expect lots of strategy, design, analytics and empathy; heist teams are worth the price of admission on their own.Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019, 240 pages, Matthew Skelton and Manuel Pais)Pragmatic and informative guide to organization design from IT consultants Matthew Skelton and Manuel Pais. Building on their work on Team Topologies with real experience, the authors cover teams as a means of delivery, team topologies that work for flow, and evolving team interactions for innovation and rapid delivery. The book is well written with a good level of depth, with valuable illustrations and strong use of color and design throughout. I recommend this book to anyone interested in creating effective teams and high-performance workplaces. Peter Hyde is surely one of Gartner's most prolific readers and writers. He is an enterprise agile coach with deep experience in helping global organizations transform product development to achieve higher performance, increased quality, faster delivery and an outstanding customer experience.

In the most recent episode of The Remotely One Podcast, hosts Rick Haney and Kaleem Clarkson invite Manuel Pais, co-author of the book "Team Topologies," for a lively conversation that transcends the technical realm! This delightful discussion spans from Manuel's affection for cheesy 80s music to his intriguing background, originating from Lisbon, Portugal, and presently residing in Madrid, Spain.With a master's degree in computer science from Carnegie Mellon and a noteworthy stint as the former editor for InfoQ, Manuel's extensive career provides the backdrop for an insightful discussion. The exchange leads to a profound reflection on Manuel's experience, sharing valuable lessons learned as an editor and underscoring the significance of connecting with influential figures in the tech industry.A pivotal question arises regarding Manuel's transition from his established career to focusing on his co-authored book, "Team Topologies." Manuel's motivation behind the book addresses critical issues related to team dynamics, interactions, and leadership in a technical environment. Our guest emphasizes the importance of recognizing and resolving non-technical problems within teams for enhanced motivation and engagement.The conversation delves deep into the challenges faced by remote teams, particularly during the COVID-19 pandemic. Manuel discusses how the shift to remote work brought existing issues to the forefront, with teams grappling to collaborate effectively. He underscores the importance of intentionally addressing problems related to team interactions, dependencies, and communication in a remote environment.The animated trio also touches on the evolving attitudes toward remote work, workplace flexibility, and goal setting. Manuel reflects on the current trend of remote work and suggests rethinking the purpose of in-person meetings, focusing on goal alignment during face-to-face interactions, opening a space to discuss the broader landscape of remote work, touching on transparency, intentional communication, and knowledge sharing among teams.Venturing into more personal territory, Manuel shares insights into his journey as an author, highlighting the unexpected growth in his communication skills influenced by his work at InfoQ and participation in conference talks. Before concluding, Manuel introduces his latest project, a workbook on remote team interactions based on concepts from "Team Topologies." He elucidates the specific challenges of remote work and provides practical techniques and templates to help teams navigate these challenges.A comprehensive exploration encompassing Manuel Pais's background, his experiences at InfoQ, insights from "Team Topologies," and perspectives on the challenges and solutions for remote team collaboration. The engaging and informative discussion positions it as a valuable resource for professionals navigating the complexities of the remote work environment. Don't miss out and get ready to take notes, Manuel is spilling golden nuggets in this installment!Learn more about Manuel:LinkedIn: https://www.linkedin.com/in/manuelpais/TeamTopologies Webpage: https://teamtopologies.com/Get the Workbook: https://teamtopologies.com/workbook

Mon-Chaio gives a rundown of leadership books he's read in the past few months and pulls out interesting nuggets from each selection. References: Leaders Eat Last: Why Some Teams Pull Together and Others Don't by Simon Sinek The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever by Michael Bungay Stanier Team Topologies: Organizing Business and Technology Teams for Fast Flow by by Matthew Skelton, Manuel Pais, and Ruth Malan --- Send in a voice message: https://podcasters.spotify.com/pod/show/tactics-tech-leadership/message

This week we welcome to the show Manuel Pais who is the co-author of "Team Topologies: Organizing business and technology teams for fast flow". Manuel will walk us through some of the concepts that enable companies to deliver value more frequently and effectively to their customers by organizing their teams in an optimized way.

BONUS: The Surprising Costs Of Outsourcing Software Development, And Effective Outsourcing Strategies with Douglas Squirrel Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Squirrel delves into the misconception that outsourcing engineers overseas automatically leads to cost reduction in software organizations. He explains that while the salary expenses might be lower for offshore teams, other costs come into play.  He illustrates the situation with an example involving two tech teams, one located onshore in California, USA, and the other in India. The Indian team had one quarter the salary of the onshore team, prompting the question of why the more expensive US engineers are retained. The discussion highlights the importance of evaluating the genuine costs of offshoring beyond just salaries. Additionally, Squirrel raises the question of which team is more productive and points out the time zone difference as a significant factor impacting communication and coordination.  Surprisingly, when the overall costs are tallied, they often don't exhibit a substantial difference due to various expenses that often get ignored. The aspect of speed of delivery is also examined, and the suggestion is made to have a local representative support the outsourced team to facilitate smoother communication. Beyond the operational costs, we also talk about how difficult it is to maintain effective communication between teams, and the cost of frequent international travel.  Squirrel emphasizes the necessity of having experienced individuals in the offshore team, highlighting that it's even more important to hire very senior people in offshore teams. We also discuss how hard it is to find accommodation for senior engineers that move to the offshore locations. Effective Offshoring Patterns Squirrel delves into the patterns that can enhance the effectiveness of offshoring. The concept of near shoring is introduced, especially when there are significant challenges in finding talent close to the headquarters.  The discussion then pivots to the importance of team organization for offshoring success. The idea of cross-functional teams or feature teams is introduced as an effective approach. Squirrel references FeatureTeams.org, emphasizing that these teams possess the flexibility to work on any feature, thereby minimizing communication dependencies.  A strategy to integrate feature teams across regions is presented through the "ambassador pattern," which involves designated individuals who bridge the communication gaps between teams in different locations. Optimizing Communication and Resources for Remote Teams We also discuss how to optimize communication and resources for remote teams. Squirrel introduces the notion that outsourcing and offshoring may be a possible solution to solve the talent problem by tapping into global talent pools. He offers practical tips, such as conducting all meetings online and making it a rule to always include offshore team members. Creating opportunities for "osmotic communication" – the exchange of information through casual interactions – is suggested as a means to foster team cohesion across distances. Recommended Resources The episode concludes with a list of recommended resources for further exploration. These include Stack Overflow's own experience about fully remote work, Squirrel's own website (DouglasSquirrel.com), Team Topologies (a topic which has been presented on the podcast by its authors Matthew Skelton and Manuel Pais), the FeatureTeams.org website, and the virtual office platform Sococo. Throughout the conversation, Squirrel provides insights into the complexities of offshoring, shedding light on the multifaceted considerations that impact its success. From cost evaluation to effective team organization and communication strategies, the episode offers a comprehensive overview of the nuances surrounding offshore software development teams. About Douglas Squirrel Squirrel has been coding for more than forty years and has led software teams for twenty. He uses the power of conversations to create dramatic productivity gains in technology organisations of all sizes. Squirrel's experience includes growing software teams as a CTO in startups from fintech to biotech to music, and everything in between. He lives in Frogholt, England, in a timber-framed cottage built in the year 1450. You can link with Douglas Squirrel on LinkedIn and connect with Douglas Squirrel on his website. 

Manuel Pais is co-author of the book Team Topologies and Eduardo da Silva is a Team Topologies Valued Practitioner. Both are helping organizations improve their ways of working by applying Team Topologies principles. An important part of Team Topologies are Enabling teams. What are Enabling teams? What kind of people do you need in them? What is the ROI on Enabling teams? How do you start with Enabling teams in an organization? Find out in my conversation with Manuel and Eduardo and note that they're offering a summer discount for all Team Topologies Academy courses.Subscribe to 0800-DEVOPS newsletter here.This interview is featured in 0800-DEVOPS #49 - Enabling teams with Manuel Pais and Eduardo da Silva.[Check out podcast chapters if available on your podcast platform or use links below](0:01)Introduction (1:05)What are Enabling teams? (3:27)Increasing our chances of Enabling teams improving our organization (12:08)Relationship between Enabling teams and the organization (21:27)Understanding where the organization needs help (29:24)ROI of Enabling teams(39:39)How to sell the idea of Enabling teams

Matthew and Luke lead Extend's Developer Experience team, a team that has approached their work in a way that is more forward-thinking than most. In this episode, they cover how they deliver impact at multiple levels of the organization, their journey with productivity metrics, and how they've made DevEx a C-level concern. Discussion points: (1:40) How the DevEx team started and where it fits at Extend (5:08) Tradeoffs of DevEx reporting into Platform  (6:40) The mandate and tasks they focus on (12:07) The impact of learning and development efforts (16:33) How to drive team-level improvements  (18:44) Why developer experience is becoming more prevalent (26:17) How they made DevEx a C-level concern (30:27) Their journey with productivity metrics  (33:10) Advice for presenting DevEx data to executives  (34:52) The team's experience using git metrics tools (48:30) Being rigorous in leveraging metrics  Mentions and links: Connect with Matthew and Luke on LinkedInOther podcasts mentioned: Manuel Pais; Peloton's DevEx survey

Manuel Pais delves into one of the concepts covered in his book “Team Topologies”: platform and enabling work. Manuel shares how he views the strategy behind when and how to invest in platform or enabling work. This conversation also goes into each type of work in more detail, covering topics such as measuring cognitive load and where platform engineering may be heading in the future.  (2:13) How enabling teams and platform teams are different  (10:28) What it looks like for a team to own both platform and enabling work  (17:04) How to deliver enabling work in an organization (22:28) Whether enabling teams should be temporary (30:10) Platform team anti-patterns (47:10) Measuring cognitive load

Jessica Kerr (known to computers everywhere as @jessitron) is a software developer, speaker, and symmathecist. (A symmathesy is a learning system composed of learning parts. To her, each software team is a symmathesy composed of the people on the team, the running software, and all of their tools.) @jessitron is another of those people who apply ideas from outside software to software, including in her role as a developer advocate at Honeycomb, a company that aims to make the workings of software visible to its developers. Were she not engaging, personable, and enthusiastic, she'd be scarily like me. This conversation is about C. Thi Nguyen's book Games: Agency as Art, whose blurb starts, "Games are a unique art form. Game designers don't just create a world; they create who you will be in that world. They tell you what abilities to use and what goals to take on. In other words, games work in the medium of agency."Jessitron linksjessitron.com (symmathesy)MastodonTwitterHer calendar for observability office hoursReferencesC. Thi Nguyen, Games: Agency as Art, 2020Pandemic (cooperative board game), 2008Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, 2019John Kay, Obliquity: Why Our Goals Are Best Achieved Indirectly, 2010The "Farm to Tabor" podcast episode: "Donut science, cars, & grassfed beef", 2018James C. Scott, Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed, 1998In the podcast, I mentioned classic English country gardens. I riffed a bit on Tom Stoppard's play "Arcadia". It "explores the relationship between past and present, order and disorder, certainty and uncertainty. It has been praised by many critics as the finest play from 'one of the most significant contemporary playwrights' in the English language. In 2006, the Royal Institution of Great Britain named it one of the best science-related works ever written." I cut the riff out because – embarrassingly – I couldn't remember the names of either the play or its author. From personal experience, I can recommend this full cast performance for a road trip. On that trip, we also listened to the Alzabo Soup podcast's multi-episode commentary. Photo credit: me

A funny thing happened on the way to SPaMCAST 757. I was considering critical thinking when I ran into data that challenged a common agile belief - enter critical thinking. The idea is that constant collaboration, the goal of team rooms, and always-on communication software, is to create good ideas and decisions; good but not great. This week we also have a visit from Susan Parente who talks about her approach to personal kanban, something she calls kanban for one. Susan also takes us under the hood for a view into her busy, innovative world and how she keeps it under control. Re-Rread Saturday News This week we are back with Chapter 6 of   Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais.  The boundaries of teams are shaped by numerous pressures ranging from corporate politics and specialism to architectural structure. Inspecting the majority of teams it would seem that boundaries are the outcome of a random walk because they reflect all of these pressures over time. For more of a dive into the topic, check out the book and the whole re-read!  Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf  Week 3:  Conway's Law and Why It Matters - https://bit.ly/3muTVQE  Week 4: Team First Thinking - https://bit.ly/3H9xRSC  Week 5: Static Team Topologies - https://bit.ly/40Q6eF2  Week 6: The Four Fundamental Team Topologies (Part 1) - https://bit.ly/3VUI7EB  Week 7: The Four Fundamental Team Topologies (Part 2) - https://bit.ly/3I70dxa  Week 8: Choose Team-First Boundaries - https://bit.ly/43i8W8A  Next SPaMCAST  SPaMCAST 758 will feature our discussion with Jeffery Miller. We will discuss the idea of tribal knowledge and playbooks. Teams generate a lot of information and knowledge - capturing that knowledge is not as easy as wishful thinking or waving a magic wand.   

SPaMCAST 756 welcomes back Paul Gibbons. In this visit, we discuss his new book Change Myths: The Professional's Guide to Separating Sense from Nonsense which he co-authored with Tricia Kennedy. I have described Paul's new book as a Trojan horse. While it dispels myths it more importantly provides the tools for critical thinking which will allow you to tackle new myths as they appear. Pau's bio: Paul Gibbons is an author, academic, speaker, and business consultant He has authored numerous books, including Change Myths: The Professional's Guide to Separating Sense from Nonsense and The Science of Successful Organizational Change, He lives in the Denver area with his two sons and enjoys playing poker, chess, and other mind sports.  Paul's Website:  www.paulgibbons.net Email: Paul@paulgibbons.net Facebook – Paul Gibbons (author) Twitter – @paulggibbons YouTube – Philosophyfirst LinkedIn – Paul G Gibbons The interview with Paul was huge, so no Re-read Saturday News this week. We will be back next week.  In the interim, buy a copy and catch up.  Use the link to buy a copy of  Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais.  Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf  Week 3:  Conway's Law and Why It Matters - https://bit.ly/3muTVQE  Week 4: Team First Thinking - https://bit.ly/3H9xRSC  Week 5: Static Team Topologies - https://bit.ly/40Q6eF2  Week 6: The Four Fundamental Team Topologies (Part 1) - https://bit.ly/3VUI7EB  Week 7: The Four Fundamental Team Topologies (Part 2) - https://bit.ly/3I70dxa  Next SPaMCAST  SPaMCAST 757 will begin an arc on critical thinking. The interview in this week's podcast has caused me to begin to explore critical thinking and why the idea is important for agile coaches.  We will also have a visit from Susan Parente who brings her Not A Scrumdamentalist column to the podcast.  

SPaMCAST 755 features an essay on the relationship between engagement, hierarchy, and fatalism based on a discussion of the topic between the SPaMCAST Columnists. The ideas of hierarchy, engagement, and fatalism struck a nerve within the SPaMCAST family. To a person, the prevailing attitude is that hierarchy has value, but only to a point.  Jon M Quigley joins the cast in the second slot this week with a discussion about making mistakes. Learning from mistakes is important but making the same mistake over and over is not a sign that you are learning.  Re-read Saturday News! This week we finish the re-read Chapter 5 of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais. As noted last week, Chapter 5 is a powerhouse. This week, let's examine some of the behaviors that the four fundamental team topologies exhibit. Understanding how teams structured in this manner should behave will also be useful for understanding which team type delivers the most value to the organization in a specific context. Buy a copy and read along! - Team Topologies: Organizing Business And Technology Teams For Fast Flow Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf  Week 3:  Conway's Law and Why It Matters - https://bit.ly/3muTVQE  Week 4: Team First Thinking - https://bit.ly/3H9xRSC  Week 5: Static Team Topologies - https://bit.ly/40Q6eF2  Week 6: The Four Fundamental Team Topologies (Part 1) - https://bit.ly/3VUI7EB  Week 7: The Four Fundamental Team Topologies (Part 2) - https://bit.ly/3I70dxa  Next SPaMCAST  SPaMCAST 756 will welcome back Paul Gibbons. In this visit we discuss his new book Change Myths: The Professional's Guide to Separating Sense from Nonsense which he co-authored with Tricia Kennedy. The book gives you the tools to sort the sense from the nonsense -- and there is a lot of nonsense in the change management field. 

Today I would like to introduce you to the Software Process and Measurement Cast's newest columnist,  Keis Kostaqi. Keis is a scrum master and coach. She will bring a Scrumban flavor to the podcast. Keis has experience with teams with complicated work input patterns. Today we get to know Keis - and get some interesting ideas along the way.   Keis Kostaqi is a passionate Agile Coach with years of experience in healthcare, information services, and technology. Currently serving as a Program Manager for the Agile Transformation Team at Northwestern Medicine, she enables individuals and teams to be successful through continual learning and growth and facilitates self-managed continuous improvement. Keis serves at the Greater Illinois Chapter of HIMSS Board of Directors as an Educational Programs Director, where she plans and implements the chapter's programs and educational activities. She is also a Woman in Agile member focused on building mentor-mentee relationships that help the Women in Agile community unlock their full potential. She holds an MBA and is also a Certified Scrum Master and Product Owner. Other interests include traveling, food lover, writing novels, volunteering, and binge-watching TV shows.  Contact Information: linkedin.com/in/keiskostaqi Re-read Saturday News! This week we re-read Chapter 5 of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais. Chapter 5 is a powerhouse. This chapter lays out the four fundamental team topologies with examples. I read this chapter twice during my first read of the book and I read it twice this week. We will approach thinking through the re-read over two weeks. This week we start with a little practice identifying the four basic team topologies. Buy a copy and read along! - Team Topologies: Organizing Business And Technology Teams For Fast Flow Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf  Week 3:  Conway's Law and Why It Matters - https://bit.ly/3muTVQE  Week 4: Team First Thinking - https://bit.ly/3H9xRSC  Week 5: Static Team Topologies - https://bit.ly/40Q6eF2  Week 6: The Four Fundamental Team Topologies (Part 1) - https://bit.ly/3VUI7EB  Next SPaMCAST  SPaMCAST 755 will feature an essay on the relationship between team design, flow, and behavior. Organizations passionately espouse the need for increasing productivity and process improvement but rarely tackle the problem of team design. Let's look that scary idea straight in the eye. We will also have a visit from Jon M Quigley who will regale us with wisdom in his Alpha and Omega of product development column.   

Wytwarzanie oprogramowania, zwłaszcza tego złożonego, to gra zespołowa. A gdy w projekcie udział bierze wiele zespołów, musimy zatroszczyć się choćby o komunikację pomiędzy nimi, czy przypisanie właściwych odpowiedzialności w projekcie.Dziś moim gościem jest Piotr Kacała, CTO i członek zarządu Displate, a rozmawiać będziemy o podejściu zwanym Team Topologies. W myśl Manuela Paisa i Matthew Sheltona, autorów książki Team Topologies, w organizacji produktowej poszczególnym zespołom można przypisać bardzo jasno określone role, co z kolei pozwala określić modele komunikacji pomiędzy nimi. Na koniec dnia, nie każdy rodzaj komunikacji w organizacji jest pomocny i właściwy...W tym odcinku rozmawiamy m.in. o:o tym, co tworzy dobry zespół,idei Team Topologies,modelach współpracy pomiędzy zespołami i rolami samych zespołów,realiach zespołowych przy rozwoju projektu Displate.Materiały dodatkowe:Team Topologies, książka autorstwa Manuela Paisa i Matthew Skeltona, 2019Empowered: Ordinary People, Extraordinary Products, Marty Cagan, Chris Jones, 2020Product Blocks, rozwijany przez Piotra katalog "klocków", narzędzi i technich pomocnych przy zarządzaniu zespołami, który mocno polecam

SPaMCAST 753 features our essay on the impact of hierarchies on engagement and fatalism. Like most things in life, the relationship is not straightforward. Hierarchies giveth and taketh away. If you don't get the balance right you can say goodbye to engagement, innovation, and fun at work. We also have a visit from Tony Timbol who brings his insights on the life cycle of user stories to the podcast in his To Tell A Story column. In this installment, we talk about the “Wall of Confusion.” When stories are created and then tossed over the wall to another team even high-performing teams slip into the slow lane. Re-read Saturday News! This week we re-read Chapter 4 of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais. The title of Chapter 4 is Static Team Topologies. One of the underlying messages in the chapter is that team topologies should not be static. However, not being static isn't the same as playing musical chairs. Buy a copy and read along! - Team Topologies: Organizing Business And Technology Teams For Fast Flow Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf  Week 3:  Conway's Law and Why It Matters - https://bit.ly/3muTVQE  Week 4: Team First Thinking - https://bit.ly/3H9xRSC  Week 5: Static Team Topologies - https://bit.ly/40Q6eF2    Next SPaMCAST  SPaMCAST 754 introduces Keis Kostaqi. Keis is a scrum master and coach. She will bring a Scrumban flavor to the podcast with a column on agile teams with complicated work input patterns. Keis begins her column with a bit of an introduction and a bucket load of experienced-based advice.

SPaMCAST 752 features our interview with Laura Bell Main. We discuss the confluence of fast-growing companies and security. Maybe I should say collision instead of confluence. Note: Laura provides an incredible amount of wisdom in the interview; however, due to a user error (mine) I lost the first minute of the interview. The abrupt start of the interview means we hit the ground running with very little preamble. Laura Bell Main specializes in securing some of Australia and New Zealand's fastest-growing organizations. She has over twenty years of experience in software development and information security. It's her mission and passion to bring security into organizations of every shape and size.  Laura is the founder and CEO of SafeStack Academy, an online education platform offering flexible, high-quality, and people-focused, secure development training for fast-moving companies, with a focus on building security skills, practices, and culture across the entire engineering team. SafeStack is a value's driven company on a mission to make cybersecurity accessible for everyone and any organization.  “To protect each one of us, we must protect all of us” Connect With Laura Bell Main: www.Laurabellmain.com   www.safestack.io/   mobile.twitter.com/lady_nerd  www.nz.linkedin.com/in/lauradbel l    Re-read Saturday News! Chapter 3 of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais is titled Team First Thinking. Using teams to get work done in all walks of life is undeniable. Whether the idea of “team” emerged a century ago or last week is less important. What is important is the knowledge that very little work happens without teams. Team-first thinking makes simple sense.   Buy a copy and read along! - Team Topologies: Organizing Business And Technology Teams For Fast Flow Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf  Week 3:  Conway's Law and Why It Matters - https://bit.ly/3muTVQE  Week 4: Team First Thinking - https://bit.ly/3H9xRSC  Next SPaMCAST  In SPaMCAST 753 we will return to our discussion of fatalism to examine the relationship between hierarchy, fatalism, and engagement.  We will also have a visit from Tony Timbol who will bring his To Tell A Story column to the podcast. 

I have been considering the relationship between privilege and fatalism. Boiling down the impact of privilege to a single word, we find power. Whether it is the ability to make decisions about the work you will do, the power to direct others to do work, or even just to be heard, privilege is power. That power can generate fatalism in those without the power privilege delivers. In SPaMCAST 751 we discuss! Jeremy Berriault brings his QA Corner to the podcast. Mr. Berriault and I discuss why continuous improvement is important. Our discussion ties neatly into the essay on privilege and fatalism. We all have to commit to getting better every day or risk becoming irrelevant. Re-read Saturday News! Chapter 2 of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais is a deep dive into Conway's Law both forward and backward (the Reverse Conway Manuver). Conway's Law states simply: the way people are organized influences software architecture. Buy a copy and upgrade your coaching skills - Team Topologies: Organizing Business And Technology Teams For Fast Flow Previous Installments: Week 1: Front Matter and Logistics – http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts – https://bit.ly/3zGGyQf  Week 3  Conway's Law and Why It Matters - https://bit.ly/3muTVQE  Next SPaMCAST  SPaMCAST 752 features our interview with Laura Bell Main. We will discuss the confluence of fast-growing companies and security. Maybe I should say collision instead of confluence. 

SPaMCAST 750 marks the return of Evan Leybourn to the podcast. Evan and I discuss the different domains of business agility, the relationship between behavior and culture, and whether Taylorism still has a place in the world.  Evan is the co-founder of the Business Agility Institute; an international membership body to both champion and support the next generation of organizations. Companies that are agile, innovative, and dynamic - perfectly designed to thrive in today's unpredictable markets. Evan is also the author of Directing the Agile Organisation (2012) and #noprojects; a culture of continuous value (2018). Website: https://businessagility.institute/ Re-read Saturday News! This week we tackle Chapter 1 of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais. The authors open Chapter 1 with a quote from Naomi Stafford, Guide to Organizational Design. “Organizations should be viewed as complex and adaptive organizations rather than mechanistic and linear systems”   The quotes set the tone for Team Topologies: Organizing Business And Technology Teams For Fast Flow. Chapter 1 is titled The Problem With Org Charts. In this chapter, the authors point out problems in how organizations describe and organize themselves.  Buy a copy and upgrade your coaching skills - Team Topologies: Organizing Business And Technology Teams For Fast Flow Previous Installments: Week 1: Front Matter and Logistics - http://bit.ly/3nHGkW4  Week 2: The Problem With Org Charts - https://bit.ly/3zGGyQf  Next SPaMCAST  SPaMCAST 751 will feature an essay on the collision of fatalism and privilege. Let's just say…it isn't pretty. Jeremy Berriault will bring his QA Corner to the podcast. Mr. Berriault and I will discuss testing, Quality, and evolving behavior.   

I den siste delen av denne Masterclass serien går Silvija og Torbjørn gjennom Lørn som case der de foregående eksemplene og verktøyene blir brukt som grunnlag. I all hovedsak blir forretningsstrategi og implementering drøftet.-“Vi trenger å spenne ut lerretet, for så å løse de mindre problemene”Dette LØRNER du:Caseoppgave ForretningsstrategiAnbefalt litteratur: EDGE - Values-Driven Digital Transformation, Jim Highsmith et alTeam Topologies: Organizing Business and Technology Teams for Fast Flow, Manuel Pais and Matthew SkeltonAccelerate, Nicole Forsgren, Jez Humble, Gene KimReinventing Organizations, Frederic Laloux Hosted on Acast. See acast.com/privacy for more information.

I denne Masterclass serien møter vi Torbjørn Larsen som er daglig leder i eget firma, Agile Enterprises. Han har blant annet bakgrunn fra NAV der han spilte en sentral rolle som IT-leder i deres digitaliseringsprosess. I del en av denne firedelte serien snakker Silvija og Torbjørn blant annet om IT-ledelse i offentlig sektor, digitalisering og nødvendige endringer for at dette skal fungere i praksis.-“Det er ikke flaks at Norge har et av verdens mest avanserte ligningssystemer”Dette LØRNER du: Smidighet i organisasjonerLedelse i offentlig sektor DigitaliseringsprosesserKreativitet på arbeidsplassenOmstillingstrykk i en mer og mer kompleks og utforutsigbar verdenAnbefalt litteraturEDGE - Values-Driven Digital Transformation, Jim Highsmith et alTeam Topologies: Organizing Business and Technology Teams for Fast Flow, Manuel Pais and Matthew SkeltonAccelerate, Nicole Forsgren, Jez Humble, Gene KimReinventing Organizations, Frederic Laloux Hosted on Acast. See acast.com/privacy for more information.

I del to av denne Masterclass serien vil vi høre om noen av Torbjørn sine favoritt-eksempler. Det første og mest åpenbare eksempelet for Torbjørn er NAV, men han forteller også om eksempler fra privat sektor. Du vil blant annet lære om Mikke-Mus IT, hvordan Norge har gjort NAV og Altinn til suksesser og hvordan fremtiden kan se ut.-“Det er god grunn til å begynne å automatisere rutineoppgaver”Dette LØRNER du: Eksempler fra offentlig og privat sektorStruktur i organisasjoner Store omstillinger i organisasjoner og bransjer ForretningsutviklingTverrfaglig utvikling Kundebaserte forretninger Nye forretningsmodellerAnbefalt litteratur:EDGE - Values-Driven Digital Transformation, Jim Highsmith et alTeam Topologies: Organizing Business and Technology Teams for Fast Flow, Manuel Pais and Matthew SkeltonAccelerate, Nicole Forsgren, Jez Humble, Gene KimReinventing Organizations, Frederic Laloux Hosted on Acast. See acast.com/privacy for more information.

I del tre av denne Masterclass serien snakker Torbjørn om sine favorittverktøy han har benyttet seg av i sitt arbeid. Her blir det blant annet snakket om hvordan koder i moderne tid blir skrevet for videreutvikling, samarbeidsverktøy og andre verktøy for smidige organisasjoner.-“Ikke undervurder endringene som har skjedd under panseret”Dette LØRNER du: SoftwareHvordan moderne koder blir skrevetVerktøy for smidige organisasjonerDevOpsAnbefalt litteratur:EDGE - Values-Driven Digital Transformation, Jim Highsmith et alTeam Topologies: Organizing Business and Technology Teams for Fast Flow, Manuel Pais and Matthew SkeltonAccelerate, Nicole Forsgren, Jez Humble, Gene KimReinventing Organizations, Frederic Laloux Hosted on Acast. See acast.com/privacy for more information.

Oguz Ozyurt: Helping Scrum Teams by Establishing Trust and Shared Understanding with Product Owners Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this segment, guest Oz emphasizes that we all work in a complex environment and are change agents. Oz shares a story about a team that faced problems with its product owner, who would add stories to the sprint backlog without refinement and interrupt the team even on the last day of the iteration. As a result, the team lost trust in the PO. To address this challenge, Oz recommends making sure the team has an agreement on how to bring new stories into an ongoing sprint and discussing the team agreement with the PO. Oz also suggests bringing up the topic in the retrospective when the PO introduces a surprise story. Oz acknowledges that these conversations can be difficult, especially when the PO is a good friend of the team's manager, but emphasizes the importance of building trust and ensuring shared understanding. Featured Book of the Week: Leading Change by John Kotter In this segment, Oz recommends "Leading Change" by John Kotter, which outlines eight steps for organizational transformation and is useful for anyone looking to apply these steps to a change process. Oz also suggests "Start with Why" by Simon Sinek for its insights on inspiring others and finding the purpose behind the work. Finally, Oz recommends "Team Topologies" which provides guidance on building and managing modern teams, a key responsibility for Scrum Masters. The authors of Team Topologies, Matthew Skelton and Manuel Pais, have been previous guests on the podcast.   About Oguz Ozyurt Oz came from a technical background, and has worked across multiple industries, applying agile practices toward the technical and non-technical areas. He is passionate about agile, he has leveraged his passion for delivery value and agile practices by coaching, teaching, mentoring many teams to transform from traditional software development life cycle to Agile principles and practices. You can link with Oguz Ozyurt on LinkedIn.

In SPaMCAST 749, we discuss the attributes of good work input/entry. There is no perfect approach to bringing work into an organization or team. Arguably since people are involved, perfect may not be something that can exist in the real world but instead, there are good approaches. There are nine key concepts for good work entry. Good work entry requires that these nine have to be present in some form regardless of whether you are using Scrum, Kanban waterfall, or some mix of frameworks. We want to be crystal clear, deciding to forego any of these characteristics other than for the briefest moment will set you on the path to the ninth circle of work entry hell. We also have a visit from Susan Parente who brings her Not A Scrumdamentalist column to the podcast. Susan and I diagnose why some organizations think that a product owner can also be a scrum master.  Re-read Saturday News! Today we begin the re-read of Team Topologies: Organizing Business And Technology Teams For Fast Flow by Matthew Skelton and Manuel Pais. The book contains front matter, including a foreword and preface (22 pages), 8 chapters, a conclusion (190 pages), and end matter (glossary, recommended reading, references, notes, index, acknowledgments, and about the authors). Today we tackle the approach to the re-read and the front matter.  Buy a copy and upgrade your coaching skills - Team Topologies: Organizing Business And Technology Teams For Fast Flow Previous Installments: Week 1: Front Matter and Logistics - http://bit.ly/3nHGkW4  Next SPaMCAST  SPaMCAST 750 will mark the return of Evan Leybourn to the podcast. Evan and I discuss the different domains of business agility and whether Taylorism still has a place in the world.  

Effective software teams are essential for any organization to deliver value continuously and sustainably. But how do you build the best team organization for your specific goals, culture, and needs?That's the question posed by authors Matthew Skelton and Manuel Pais in their highly-acclaimed book, Team Topologies: Organizing Business and Technology Teams for Fast Flow.On this week's episode of Dev Interrupted, we revisit Dan's 2021 conversation with Matthew and Manuel. Since first airing, their book has received broad recognition for its step-by-step advice, approach to team patterns and interactions, and compelling analysis of the communication pathways that lead to organizational success. We think this episode is as relevant today as it was when it was released - and we hope you agree!Show Notes:Learn more at teamtopologies.comCheck out the Team Topologies Academy: https://academy.teamtopologies.comRegister for the Dev Interrupted Live Stream on April 4th and 5th. Support the show: Subscribe to our Substack Follow us on YouTube Review us on Apple Podcasts or Spotify Follow us on Twitter or LinkedIn Offers: Learn about Continuous Merge with gitStream Want to try LinearB? Book a Demo & use discount code "Dev Interrupted Podcast"

In this episode I talk to Manuel Pais discussing Team topologies, Fast flow and adoption patterns. This is round 2 of Manuel appearing on the podcast and we follow up this time on how Team topologies has taken the industry by storm, its adoption challenges and anti-patterns. Manuel also talked about ideas that he is thinking about in 2023 to build high performing teams.

In this episode, Mike and Matt talk to Matthew Skelton and Manuel Pais, authors of the landmark book Team Topologies. They cover the primary constraints of Team Topologies, as well as how they are being used in practice by countless organizations around the globe. For more information on Team Topologies... Website: https://teamtopologies.com/ Academy: https://academy.teamtopologies.com/ Upcoming book by Susanne Kaiser: https://www.pearson.com/en-ca/subject-catalog/p/adaptive-systems-with-domain-driven-design-wardley-mapping-and-team-topologies-architecture-for-flow/P200000000359/9780137393039

DETROIT — Are we still shifting left? Is it realistic to expect developers to take on the burdens of security and infrastructure provisioning, as well as writing their applications? Is platform engineering the answer to saving the DevOps dream? Bottom line: Do Devs and Ops really talk to each other — or just passive-aggressively swap Jira tickets? These are some of the topics explored by a panel, “Devs and Ops People: It's Time for Some Kubernetes Couples Therapy,” convened by The New Stack at KubeCon + CloudNativeCon North America, here in the Motor City, on Thursday. Panelists included Saad Malik, chief technology officer and co-founder of Spectro Cloud; Viktor Farcic, developer advocate at Upbound; Liz Rice, chief open source officer at Isolalent, and Aeris Stewart, community manager at Humanitec. The latest TNS pancake breakfast was hosted by Alex Williams, The New Stack's founder and publisher, with Heather Joslyn, TNS features editor, fielding questions from the audience. The event was sponsored by Spectro Cloud. Alleviating Cognitive Load for Devs A big pain point in the DevOps structure — the marriage of frontend and backend in cross-functional teams — is that all devs aren't necessarily willing or able to take on all the additional responsibilities demanded of them. A lot of organizations have “copy-pasted this one size fits all approach to DevOps,” said Stewart. “If you look at the tooling landscape, it is rapidly growing not just in terms of the volume of tools, but also the complexity of the tools themselves,” they said. “And developers are in parallel expected to take over an increasing amount of the software delivery process. And all of this, together, is too much cognitive load for them.” This situation also has an impact on operations engineers, who must help alleviate developers' burdens. “It's causing a lot of inefficiencies of these organizations,” they added, “and a lot of the same inefficiencies that DevOps was supposed to get rid of.” Platform engineering — in which operations engineers provide devs with an internal developer platform that abstracts away some of the complexity — is “a sign of hope,” Stewart said, for organizations for whom DevOps is proving tough to implement. The concept behind DevOps is “about making teams self-sufficient, so they have full control of their application, right from the idea until it is running in production,” said Farcic. But, he added, “you cannot expect them to have 17 years of experience in Kubernetes, and AWS and whatnot. And that's where platforms come in. That's how other teams, who have certain expertise, provide services so that those  … developers and operators can actually do the work that they're supposed to do, just as operators today are using services from AWS to do their work. So what AWS for Ops is to Ops, to me, that's what internal developer platforms are to application developers.” Consistency vs. Innovation Platform engineering has been a hot topic in DevOps circles (and at KubeCon) but the definition remains a bit fuzzy, the panelists acknowledged. (“In a lot of organizations, ‘platform engineering' is just a fancy new way of saying ‘Ops,'” said Rice.) The audience served up questions to the panel about the limits of the DevOps model and how platform engineering fits into that discussion. One audience member asked about balancing the need to provide a consistent platform to an organization's developers while also allowing devs to customize and innovate. Malik said that both consistency and innovation are possible in a platform engineering structure.   “An organization will decide where they want to be able to provide that abstraction,” he said, adding, “When they think about where they want to be as a whole, they could think about, Hey, when we provide our platform, we're going to be providing everything from security to CI/CD from GitHub, from repository management, this is what you will get if you use our IDP or platform itself. But “there are going to be unique use cases,” Malik added, such as developers who are building a new blockchain technology or running WebAssembly. “I think it's okay to give those development teams the ability to run their own platform, as long as you tell them, these are the areas that you have to be responsible for,” he said. “ You're responsible for your own security, your own backup, your own retention capabilities.” One audience member mentioned “Team Topologies,” a 2019 engineering management book by Manuel Pais and Matthew Skelton, and asked the panel if platform engineering is related to DevOps in that it's more of an approach to engineering management than a destination. “Platform engineering is in the budding stage of its evolution,” said Stewart. “And right now, it's really focused on addressing the problems that organizations ran into when they were implementing DevOps. They added, “I think as we see the community come together more and get more best practices about how to develop platform, you will see it become more than just a different approach to DevOps and become something more distinct. But I don't think it's there quite yet.” Check out the full panel discussion to hear more from our DevOps “counseling session.”

Para desenvolver uma boa solução digital, necessitamos de times de confiança, mas como podemos organizar estas equipes? No episódio de hoje, contamos com Angela Duarte e Bernardo Costa, Tech Managers, juntamente com Gabriel Naves, Arquiteto na dti. Eles vieram responder essas e outras perguntas, tendo como base o livro "Team Topologies", dos autores Matthew Skelton e Manuel Pais. Quer saber como criar uma estrutura habilitadora para o desenvolvimento de times independentes e confiáveis? Dá o play! Quer conversar com Os Agilistas? É só mandar sua dúvida/sugestão para @osagilistas no Instagram ou pelo e-mail osagilistas@dtidigital.com.br que nós responderemos em um de nossos conteúdos!See omnystudio.com/listener for privacy information.

David Anderson currently works at Bazaarvoice as Technical Fellow. Before that, he was CTO leading an organizational transformation at Liberty Mutual aimed at generating more value for the clients by using serverless architectures and better ways of working. David shared his experience and lessons learned in the book "The Value Flywheel Effect" and I got the chance to hear it first-hand.Subscribe to 0800-DEVOPS newsletter here.Show notes:- This interview is featured in 0800-DEVOPS #39 - The Value Flywheel Effect with David Anderson- Dave's recommendations: Simon Wardley (On industrialization: a technology-driven path to next generation organization), Matthew Skelton, Manuel Pais, Nick Tune, Susanne Kaiser, Jonathan Allen (Reaching Cloud Velocity), Gregor Hohpe (The Software Architect Elevator), Adrian Cockroft- The Serverless Edge - content for engineers, architects, tech leaders, students and business leaders who are interested in adopting serverless.

Ian Miell is a partner at consultancy Container Solutions, and an author of books on Bash, Git, Terraform and Docker. He explains to Craig how writing - whether runbooks, blog posts, training courses, or “real” books, can help you learn and make your team more effective. Do you have something cool to share? Some questions? Let us know: web: kubernetespodcast.com mail: kubernetespodcast@google.com twitter: @kubernetespod Chatter of the week Hot hot hot Small pools and larger pools News of the week Gateway API goes to Beta Episode 104, with Bowei Du Istio support for Gateway API SMI community gets behind Gateway API Kyverno and Keptn move to incubation Episode 119, with Alois Reitbauer Tau T2A Arm VMs now on Google Compute Engine GKE support for Tau T2A Arm nodes Kubeshop acquires BotKube Exploiting Authentication in AWS IAM Authenticator for Kubernetes by Gafnit Amiga New Vulnerabilities in Kubernetes NGINX Ingress Controller CNCF sponsors audit of KubeEdge KubeEdge security threat model Audit report Red Hat announces new CEO Google Cloud announces new Distinguished Engineer Episode 185, with Clayton Coleman Links from the interview Zwischenzugs Business Value, Soccer Canteens, Engineer Retention, and the Bricklayer Fallacy Zwischenzug and zugzwang in chess Ian’s books: Learn Bash The Hard Way Learn Git The Hard Way Learn Terraform The Hard Way All three in a bundle Docker in Practice Tcl Why are enterprises so slow? Erlang Episode 164, with Daniel Walsh ‘AWS vs K8s' is the new ‘Windows vs Linux' The Runbooks Project ITIL Consultancy: Episode 183, with Steve Wade Why it’s great to be a consultant Container Solutions Finance topologies: Team Topologies by Manuel Pais and Matthew Skelton If You Want To Transform IT, Start With Finance Conway’s Law Ian Miell on Twitter

On this episode, Product Manager Brian Orlando pitches Enterprise Agile Coach Om Patel on the team optimization suggestions from the book, Team Topologies: Organizing Business and Technology Teams for Fast Flow (2019), by Matthew Skelton and Manuel Pais.Team Topologies Website0:00 Topic Intro: Team Topologies1:58 Stream-Aligned Teams3:50 Why this Book?7:25 Cognitive Load12:46 4 Fundamental Topologies20:22 Platform Teams22:47 Arguing on Team Topologies25:16 3 Core Interaction Modes30:30 Case Studies31:21 Om's First Reaction33:16 Re-summarizing the Book35:40 Ratios39:05 Teams' Responsibility for Commercial Viability43:02 What We Learned51:18 Riffing on Non-Development Teams55:31 Why It's Worth Reading= = = = = = = = = = = =Watch it on YoutubePlease Subscribe to our YouTube Channel= = = = = = = = = = = =Or Listen to us on: Apple Podcasts, Google Podcasts, Spotify, Amazon Music, Stitcher= = = = = = = = = = = = AA67 - Team Topologies: Organizing Business and Technology Teams for Fast Flow

In SPaMCAST 707 Susan Parente and I discuss the difference between leadership and management in her Not A Scrumdamentalist column. These two concepts are related but not the same.  The votes are in!  The next three books for Re-read Saturday are: Coaching Agile Teams by Lyssa Arkins https://amzn.to/38G0ZD3  Extraordinarily Badass Agile Coaching by Bob Galen https://amzn.to/3wJsbtS  Team Topologies by Matthew Skelton, Manuel Pais, and Ruth Malan https://amzn.to/3yXINzo  Re-read Saturday  News This week, we are revisiting (and re-editing) the conclusion of the first re-read to tide you over to the completion of Why Limit WIP.  I have been backpacking, glamping, and visiting my father for the past eight days. That in its own right would not have precluded completing our re-read, but I also forgot the power cord for my laptop.  Next week we will conclude our re-read of Why Limit WIP: We Are Drowning In Work. Remember to buy a copy and read along.  Amazon Affiliate LInk:  https://amzn.to/36Rq3p5  Previous Entries Week 1: Preface, Foreword, Introduction, and Logistics – https://bit.ly/3iDezbp Week 2: Processing and Memory – https://bit.ly/3qYR4yg  Week 3: Completion - https://bit.ly/3usMiLm Week 4: Multitasking - https://bit.ly/37hUh5z  Week 5: Context Switching - https://bit.ly/3K8KADF  Week 6: Creating An Economy -  https://bit.ly/3F1XKkZ  Week 7: Healthy Constraints - https://bit.ly/3kM8xqh  Week 8: Focus - https://bit.ly/3PkE0hg  Week 9: Awareness - https://bit.ly/3LBZfIl  Week 10: Communication - https://bit.ly/39Tji7Q  Week 11: Learning - https://bit.ly/38HQNtJ  Next SPaMCAST  Brian Weaver returns to the Software Process and Measurement Cast to discuss the impact of AI on business, leadership, and development. 

Charles Humble talks to Team Topologies co-author Manuel Pais. They discuss how the rapid adoption of Team Topologies may be being driven by companies seeking a new competitive advantage as DevOps and Cloud become ubiquitous; applying software engineering thinking to organisational design; the challenges of cross-team collaboration in a remote context; and using Team Topologies patterns for remote working.

In this episode I want to continue the talk about the team structures discussed on https://web.devopstopologies.com/ - with a focus this week on the topologies are shown to work. The devopstopologies.com website is based on the work by Matthew Skelton & Manuel Pais. I introduced Matthew and Manual as authors of the Team Topologies book in the last episode. The work is a pre-cursor to the Team Topologies book - and work that I feel stands on its own two feet - with a specific look into how teams should work together to gain benefits from DevOps. ----- Find this episodes show notes at: https://red-folder.com/podcasts/134 Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

In this episode I want to talk about the team structures discussed on https://web.devopstopologies.com/ - with a focus this week on the anti-types. The devopstopologies.com website is based on the work by Matthew Skelton & Manuel Pais. I introduced Matthew and Manual as authors of the Team Topologies book in the last episode. The work is a pre-cursor to the Team Topologies book - and work that I feel stands on its own two feet - with a specific look into how teams should work together to gain benefits from DevOps. ----- Find this episodes show notes at: https://red-folder.com/podcasts/133 Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

To help you become an awesome software architect, we have picked out our top four books to make 12 in total. We are looking at engineering books have influenced both ourselves and 'The Flywheel Effect' book. 1. 'Continuous Delivery' came out in 2011. And it has been massively influential in how high performing teams deliver their software today. It is still as fresh as it was when it was written. And a lot of teams would do well to actually read it again. 2. 'Domain Driven Design' is a good book on how to describe a domain, good domain models and the importance of collaboration, communication and shared understanding, including their chapter on ubiquitous languages. You can be in different types of stacks or scenarios, but the knowledge is abstract so it's broadly applicable. 3. The Simon Wardley Book I have got a print copy of it. And I find myself always coming back to it. I think it was out in 2011. It's chunky and quite academic. So it's not exactly an easy read. But it's as deep as well, as they say. So I'm a big fan and I always go back to it. I don't take every word of it literally. But it's definitely a good read and will challenge your thinking still to this day. 4. 'Accelerate' by Nicole Forsgren, Jez Humble, and Gene Kim. This is a game changer. I think everyone the industry understands that. It distills down and captures (with scientific backing) all of the things that we were trying to articulate or were trying to push or evolve in our ecosystem.The capabilities to drive improvement, the scientific backing and little snippets of good advice and guidance. It is one of the best. 5. 'Extreme Ownership' by Jocko Willink. There's some cracking guidance on how to own something and lead. One that sticks out is centralised command and leading up and down the line. It's a well thought out and structured book on how to think, modern leadership and how to motivate people to be successful. I enjoy reading about how to think through systems, particularly in a leadership position, in technical orbs and stuff like that. It helps you to think like a leader. 6. 'Team Topologies' by Matthew Skelton and Manuel Pais. It's such a powerful question to ask 'what type of team are you?' And the response is: 'what do you mean?'. The answer is that you're a platform team, an enablement team, a value stream team or you're not anything. And all the techniques are in it with different tools and team API's and stuff. I think it's really practical. You can pick it up and implement tomorrow. 7. 'Reaching Cloud Velocity' It covers how to succeed in the cloud. In other words what are the principles and tenets that you should apply. What are the cultural and organisational things you should think about as you're starting to move to the cloud. It looks at the architectural approaches and patterns you should adopt. And how to do security and governance. It also looks at what's your business strategy, now that you're in the cloud. 8. 'Designing Data Intensive Applications' is almost a bible for anything data related such as streaming, different types of databases and why you make decisions on certain types of databases. You get into the design and the nuance of it. And understanding the landscape. It's broken into 2 to 3 minute blocks. So you can get straight into it and get perspective or context. 9. 'Creativity Inc', by Ed Catmull. The book is about Pixar, who went up against Disney by direct selling films. The full title of the book is 'Overcoming the Unseen Forces That Stand in the Way of True Inspiration' . They talk about the inspiration of creating and then actually making it. And how they structured the company and all the challenges they had. 10. 'Working Backwards' by Colin Bryar and Bill Carr. We see Amazon from the outside eg. amazon.com, Amazon Prime, deliveries and Alexa. But how do they actually do it? How can they be so successful and set themselves up for success? What way are their leadership structured? 'Working Backwards' distils down and gives insight into how Amazon operates at that sort of scale. It looks at how they have remained successful despite their growth. 11. 'Ask Your Developer' by Jeff Lawson, looking at the developer centric approach at Twilio. There's a lot of good content on how to inspire great individuals and teams to be creative. There's a good chapter on developer experience, their golden path and off roading. And how they've organised around developer experience. 12. 'The Software Architect Elevator', by Gregor Hohpe. I love his concept of an architect riding the elevator to talk to the executive in the penthouse, going down to the basement to write code and then all the floors in between. He talks about the how an architect can behave and operate to be successful in a company. Gregor is the 'architect's architect'. Serverless Craic from The Serverless Edge theserverlessedge.com @ServerlessEdge

No episódio de hoje vamos falar sobre times habilitadores com base no livro Team Topologies de Matthew Skelton e Manuel Pais. Você já ouviu falar em times capacitadores? Já trabalhou com um time habilitador? Sabe como funciona? Para responder essas perguntas e trazer exemplos práticos chamamos Pedro Alves e Petrus de Melo para essa conversa! Apresentação:Felipe Chagas, Fernanda Vieira e Lucas CampregherPessoas convidadas:Pedro Alves e Petrus de MeloVocê pode nos acompanhar em www.instagram.com/entre.chaves ou mandar a sua pergunta/dúvida no email entrechaves@dtidigital.com.brInstagram: @entre.chaves

Après avoir travaillé pour Mediapart, CondéNast ou encore 20Minutes, Nicolas Silberman est désormais le CTO et le CPO de Unify Group, entité digitale du groupe TF1 et co-fondateur du podcast Tech Rocks. Dans cet épisode, on évoque : # La tech, qui occupe une place centrale dans la vie d'une entreprise, et qui peut la challenger en apportant des réponses et des innovations. # La nécessité de bien travailler son SEO, intégré à la stratégie de la société, pour tous les contenus digitaux. # La tendance “bien-être” qui inonde les contenus et influence les différentes fonctionnalités sur Internet et les réseaux sociaux. # L'importance de communiquer les études de Médiamétrie, en externe comme en interne, pour orienter au mieux son positionnement et optimiser la collaboration avec des partenaires. # Les enjeux, comme l'uniformisation, soulevés par la stratégie de Unify, fondée uniquement sur des acquisitions. # La répartition inégale des audiences entre site web et application. # Le marché du web, très challengé au niveau du référencement, car il est régi par les règles et les algorithmes de Google. # Les différences SEO entre le contenu froid et le contenu chaud. # La commercialisation de données ciblées et pertinentes aux annonceurs. # Les dernières évolutions tech - des outils sont apparus pour faciliter l'expérience utilisateur et des métiers se sont développés : les développeurs front jouent un rôle de plus en plus important. # Le choix des annonceurs, qui se fait en fonction de leur impact carbone, l'écologie étant plus que jamais un enjeu essentiel du digital. Pour aller plus loin : # Découvrez Tech Rocks, co-fondé par Nicolas Silberman, Francis Nappez, Dimitri Baeli et Cyril Pierre de Geyer, pour permettre aux leaders tech de prendre la parole, d'échanger et de grandir ensemble. # (Re)découvrez les marques qui sont dans le périmètre d'action de notre invité : Aufeminin, Marmiton et Doctissimo. # Le truc cool de l'invité : Remote Team Interactions Workbook : Using Team Topologies Patterns for Remote Working de Matthew Skelton et Manuel Pais, édition IT Revolution, 2022 # Team Topologies : Organizing Business and Technology Teams for Fast Flow de Matthew Skelton et Manuel Pais, édition IT Revolution, 2019 # Trouvez votre place dans la population mondiale sur Population.io # Bonus : la vidéo Mission 404 : Internet doit rester vivant. Retrouvez notre invité sur ses différents réseaux sociaux : LinkedIn Twitter Pour découvrir tout ça, c'est par ici si vous préférez Apple Podcast, par là si vous préférez Deezer, ici si vous préférez Google Podcast, ou encore là si vous préférez Spotify. Et n'oubliez pas de laisser 5 étoiles et un commentaire sympa sur Apple Podcast si l'épisode vous a plu. Mediarama est un podcast du label Orso Media produit par CosaVostra. Pour découvrir tout ça, c'est par ici ! Apple Podcasts Spotify Deezer

Team Topologies e altri modelli organizzativi: An Evening With Alessandro Giardina, Francesca Carta e Luca CioriaCosa è Team Topologies? Se n'è sentito parlare molto negli ultimi anni, complice il successo del libro omonimo di Manuel Pais e Matthew Skelton.In poche parole, si tratta di una modalità di configurazione dei team e i loro meccanismi di interazione all'interno di organizzazioni che si occupano di sviluppo software.L'anno scorso abbiamo avuto il piacere di ospitare proprio Manuel Pais per un corso introduttivo su Team Topologies e ne parliamo con alcuni ospiti che hanno avuto modo di sperimentare con questo approccio, seguendone alcuni principi, e proponendolo all'interno delle loro aziende o con dei clienti.Faremo una chiacchierata in puro stile Avanscoperta, cercando di capire in modo non dogmatico come alcuni principi di Team Topologies vengono adottati all'interno delle aziende dei nostri speaker (cosa funziona e cosa no, e quali mosse vengono fatte per adottarne alcuni principi), quali i suoi benefici, dove è più utile e cosa si è imparato, in ottica di condivisione dell'esperienza fatta finora.Gli ospiti del nostro panel sono Alessandro Giardina (Intré), Francesca Carta (Mia-Platform) e Luca Cioria (buildo).

Team Topologies e altri modelli organizzativi: An Evening With Alessandro Giardina, Francesca Carta e Luca CioriaCosa è Team Topologies? Se n'è sentito parlare molto negli ultimi anni, complice il successo del libro omonimo di Manuel Pais e Matthew Skelton.In poche parole, si tratta di una modalità di configurazione dei team e i loro meccanismi di interazione all'interno di organizzazioni che si occupano di sviluppo software.L'anno scorso abbiamo avuto il piacere di ospitare proprio Manuel Pais per un corso introduttivo su Team Topologies e ne parliamo con alcuni ospiti che hanno avuto modo di sperimentare con questo approccio, seguendone alcuni principi, e proponendolo all'interno delle loro aziende o con dei clienti.Faremo una chiacchierata in puro stile Avanscoperta, cercando di capire in modo non dogmatico come alcuni principi di Team Topologies vengono adottati all'interno delle aziende dei nostri speaker (cosa funziona e cosa no, e quali mosse vengono fatte per adottarne alcuni principi), quali i suoi benefici, dove è più utile e cosa si è imparato, in ottica di condivisione dell'esperienza fatta finora.Gli ospiti del nostro panel sono Alessandro Giardina (Intré), Francesca Carta (Mia-Platform) e Luca Cioria (buildo).

This week we convene a panel to discuss the book Team Topologies by Matthew Skelton and Manuel Pais.  We review the team types outlined, the different interaction modes, how cognitive load figures into team size and layout, and even the Inverse Conway.  Enjoy! References: Robin Dunbar on the Jim Rutt Show Promise Theory with Mark Burgess If you enjoyed this episode, please give us a review, a rating, or leave comments on iTunes, Stitcher or your podcasting platform of choice. It really helps others find us.  Much thanks to the artist Krebs from Machine Man Records who provided us our outro music free-of-charge!  If you like what you heard, check out these links to find more music you might enjoy! If you'd like to join the discussion and share your stories,  please jump into the fray at our Discord Server! We at the Agile Uprising are committed to being totally free.  However, if you'd like to contribute and help us defray hosting and production costs we do have a Patreon.  Who knows, you might even get some surprises in the mail!    

Discussion includes motivation for writing the Team Topologies book. How can TT approach help to build software that is more secure? Techniques, challenges, recommendations when adopting TT.Matthew Skelton is co-author of Team Topologies: organizing business and technology teams for fast flow. Recognised by TechBeacon in 2018, 2019, and 2020 as one of the top 100 people to follow in DevOps, Matthew curates the well-known DevOps team topologies patterns at devopstopologies.com. He is Head of Consulting at Conflux and specialises in Continuous Delivery, operability, and organisation dynamics for modern software systems. Manuel Pais is co-author of Team Topologies: organizing business and technology teams for fast flow. Recognized by TechBeacon as a DevOps thought leader, Manuel is an independent IT organizational consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is also a LinkedIn instructor on Continuous Delivery.For more books on Domain-Driven Design and the Vaughn Vernon signature series go here. Hosted on Acast. See acast.com/privacy for more information.

EP62 - [TTOP] - Team Topologies, una Visión General, con Carlos GilHoy comenzamos un ciclo (no consecutivo) de episodios sobre Team Topologies, el Libro de Matthew Skelton y Manuel Pais (de 2019), y que ha estado revolucionando el concepto de constitución de equipos en organizaciones.En este primer episodio platicamos en forma general sobre conceptos fundamentales que Mathew y Manuel incluyen en libro: La Ley de Conway, El Concepto de Equipo, Las Topologías Fundamentales, Relaciones Entre Equipos, etc. Revisando la esencia de estos conceptos y cómo estos resuenan con la experiencia de nuestras hormigas y de nuestro invitado Carlos Gil.En este episodio participan las siguientes hormigas del hormiguero: Dore Peña, Yohan Paez, Arturo Robles Maloof y Rodrigo Burgos Noceti.Además puedes conocer las referencias de mencionadas en este capitulo y material complementario en http://hormigasagilistas.orgEsperamos contar con otros interesantes invitados en futuros episodios del "Universo Team Topologies", en donde (si todo resulta bien) nos detendremos a analizar con mayor profundidad algunos conceptos y topologías.#HormigasAgilistas #QueVivaLaAgilidad #TeamTopologis #CarlosGil

Sven Johann talks with Manuel Pais about the challenges of development teams being asked to be responsible for many topics like their problem domain, technology/programming languages, security, infrastructure and operations, UX, etc. Manuel explains what cognitive load is, which types of cognitive load exist and where it can be reduced and where not. They then discuss the four fundamental team topologies stream-aligned, enabling, platform and complicated subsystem: their benefit, how you should run those teams and which obstacles you need to overcome to be successful.

Manuel Pais is co-author of the book "Team Topologies: organizing business and technology teams for fast flow". He started the Team Topologies Academy to help organizations scale learning around modern team dynamics and fast flow. He is also recognized by TechBeacon as a DevOps thought leader. Manuel is an independent IT organizational consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is also a LinkedIn instructor on accelerating Continuous Delivery in the enterprise. In the podcast, we talk about the process of writing, team design, organization sensing and leaving legacy as an author. I am super excited to have this episode shared with all of you. You can reach Manuel on Twitter at https://twitter.com/manupaisable You can find more about Team Topologies here: https://teamtopologies.com/examples and learn about Team Topologies Academy here : https://academy.teamtopologies.com/ The full episode is also available on the podcast page - http://www.inurshoes.com/ This is the Season 2 of the In Your Shoes podcast. The podcast aims to get into the shoes of a person like you and me, and learn about their career stories and experiences. Through this conversation, we will uncover insights and pearls of wisdom which will hopefully inspire you and expand your thinking. We are doing something different this season. Apart from the full length show, we will also expand on topics of interest that emerge during the conversation. These will be distributed as special episodes which are short, targeted and provide you with the context when you are short on time. To get all episodes, find it here : http://www.inurshoes.com/ Please provide feedback about this podcast : https://forms.gle/erPEmn1uWooxphmBA CONNECT: - Subscribe to the YouTube channel - https://www.youtube.com/channel/UCJtUA1Qw_PZPsbczvF7PVNQ Twitter: https://twitter.com/get_inyourshoes LinkedIn: https://www.linkedin.com/in/geekcloud/ Instagram: https://www.instagram.com/inyourshoes #teamtopologies #devops #architecture #teams #autonomy #writing #author #podcast

Brandon Linton is passionate about helping teams create amazing customer experiences through cloud architecture, lean software development, and product discovery. He specializes in the principles and practices that make for continuous delivery and software platforms that drive innovation. Episode 25 covers Enterprise Architecture; helping teams achieve speed, quality, and better culture through living out DevOps principles; and so much more. Connect with Brandon: Website, LinkedIn, Twitter Episode Links: CarMax Shadow Price Team Topologies, Manuel Pais and Matthew Skelton Accelerate, Nicole Forsgren Ph.D., Jez Humble, and Gene Kim Continuous Delivery, Jez Humble and David Farley The Logic of Failure, Dietrich Dorner Martin Fowler Building Microservices, Sam Newman API Intersection Stoplight Podcast How Do Companies Invent? Melvin Conway

Dan is joined on the Dev Interrupted podcast by Manuel Pais and Matthew Skelton the writers of the book Team Toplogies: Organizing Business and Technology Teams for Fast Flow for an in-depth discussion of how software teams are organized and how to optimize and streamline them for best effect. Learn more about our  September 30th INTERACT Conference: devinterrupted.com/interactJoin our Discord Community ►► discord.gg/devinterruptedOur Website ►► devinterrupted.com/Want to try LinearB?  ►► Book a LinearB DemoHave 60 seconds? Review the show on Apple PodcastsCheck out the Team Toplogies Academy: http://academy.teamtopologies.com/

Dan is joined on the Dev Interrupted podcast by Manuel Pais and Matthew Skelton the writers of the book Team Toplogies: Organizing Business and Technology Teams for Fast Flow for an in-depth discussion of how software teams are organized and how to optimize and streamline them for best effect.  Join our Discord Community ►► discord.gg/devinterruptedOur Website ►► devinterrupted.com/Want to try LinearB?  ►► Book a LinearB DemoHave 60 seconds? Review the show on Apple PodcastsCheck out the Team Toplogies Academy: http://academy.teamtopologies.com/

About NigelNigel Kersten's day job is Field CTO at Puppet where he leads a group of engineers who work with Puppet's largest customers on cultural and organizational changes necessary for large-scale DevOps implementations - among other things. He's a co-author of the industry-leading State Of DevOps Report and likes to evenly talk about what went right with DevOps and what went wrong based on this research and his experience in the field. He's held multiple positions at Puppet across product and engineering and came to Puppet from the Google SRE organization, where he was responsible for one of the largest Puppet deployments in the world.  Nigel is passionate about behavioral economics, electronic music, synthesizers, and Test cricket. Ask him about late-stage capitalism, and shoes.Links: Puppet: https://puppet.com 2020 State of DevOps Report: https://puppet.com/resources/report/2020-state-of-devops-report/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: Your company might be stuck in the middle of a DevOps revolution without even realizing it. Lucky you! Does your company culture discourage risk? Are you willing to admit it? Does your team have clear responsibilities? Depends on who you ask. Are you struggling to get buy in on DevOps practices? Well, download the 2021 State of DevOps report brought to you annually by Puppet since 2011 to explore the trends and blockers keeping evolution firms stuck in the middle of their DevOps evolution. Because they fail to evolve or die like dinosaurs. The significance of organizational buy in, and oh it is significant indeed, and why team identities and interaction models matter. Not to mention weither the use of automation and the cloud translate to DevOps success. All that and more awaits you. Visit: www.puppet.com to download your copy of the report now!Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This promoted episode is sponsored by a long time… I wouldn't even say friends so much as antagonist slash protagonist slash symbiotic company with things I have done as I have staggered through the ecosystem. There's a lot of fingers of blame that I can point throughout the course of my career at different instances, different companies, different clients, et cetera, et cetera, that have shaped me into the monstrosity than I am today. But far and away, the company that has the most impact on the way that I speak publicly, is Puppet.Here to accept the recrimination for what I become and how it's played out is Nigel Kersten, a field CTO at Puppet—or the field CTO; I don't know how many of them they have. Nigel, welcome to the show, and how unique are you?Nigel: Thank you, Corey. Well, I—you know, reasonably unique. I think that you get used to being one of the few Australians living in Portland who's decided to move away from the sunny beaches and live in the gray wilderness of the Pacific Northwest.Corey: So, to give a little context into that ridiculous intro, I was a traveling contract trainer for the Puppet fundamentals course for an entire summer back in I want to say 2014, but don't hold me to it. And it turns out that when you're teaching a whole bunch of students who have paid in many cases, a couple thousand dollars out of pocket to learn a new software where, in some cases, they feel like it's taking their job away because they view their job, rightly or wrongly, is writing the same script again and again. And then the demo breaks and people are angry, and if you don't get a good enough rating, you're not invited to continue, and then the company you're contracting through hits you with a stick, it teaches you to improvise super quickly. So, I wasn't kidding when I said that Puppet was in many ways responsible for the way that I give talks now. So, what do you have to say for yourself?Nigel: Well, I have to say, congratulations for surviving, opinionated defensive nerds who think not only you but your entire product you're demoing could be replaced by a shell script. It's a tough crowd.Corey: It was an experience. And some of these were community-based, and some of them were internal to a specific company. And if people have heard more than one episode of this show, I'm sure they can imagine how that went. I gave a training at Comcast once and set a personal challenge for myself of how many times could I use the word ‘comcastic' in a three-day training. And I would work it in and talk about things like the schedule parameter in Puppet where it doesn't guarantee something's going to execute in a time window; it's the only time it may happen.If it doesn't fire off, and then it isn't going to happen. It's like a Comcast service appointment. And then they just all kind of stared at me for a while and, credit where due, that was the best user rating I ever got from people sitting through one of my training. So, thanks for teaching me how to improve at, basically, could have been a very expensive mistake on Puppet's part. It accidentally worked out for everyone.Nigel: Brilliant, brilliant. Yes, you would have survived teaching the spaceship operator to that sort of a crowd.Corey: Oh, I mostly avoided that thing. That was an advanced Puppet-ism, and this was Puppet fundamentals because I just need to be topically good at things, not deep-dive good at things. But let's dig into that a little bit. For those who have not had the pleasure of working with Puppet, what is it?Nigel: Sure? So, Puppet is a pretty simple DSL. You know, DSLs aren't necessarily in favor these days.Corey: Domain-specific language, for those who have not—Nigel: Yep.Corey: —caught up on that acronym. Yes.Nigel: So, a programming language designed for a specific task. And, you know, instead, we've decided that the world will rest on YAML. And we've absorbed a fair bit of YAML into our ecosystem, but there are things that I will still stand by are just better to do in a programming language. ‘if x then y,' for example, it's just easier to express when you have actual syntax around you and you're not, sort of, forcing everything to be in a data specification language. So, Puppet's pretty simple in that it's a language that lets you describe the state that infrastructure should be.And you can do this in a modular and composable way. So, I can build a little chunk of automation code; hand it to Corey; Corey can build something slightly bigger with it; hand it to someone else. And really, this sort of collaboration is one of the reasons why Puppet's, sort of, being at the center of the DevOps movement, which at its core is not really about tools. It's about reducing friction between different groups.Corey: Back when I was doing my traveling training shtick, I found that I had to figure out a way to describe what Puppet did to folks who were not deep in the space, and the analogy that I came up with that I was particularly partial to was, imagine you get a brand new laptop. Well, what do you do with it? You install your user account and go through the setup; you install the programs that you use, some which have licenses on it; you copy your data onto it; you make sure that certain programs always run on startup because that's the way that you work with these things; you install Firefox because that's the browser of choice that you go with, et cetera, et cetera. Now, imagine having to do that for, instead of one computer, a thousand of them, and instead of a laptop, they're servers. And that is directionally what Puppet does.Nigel: Absolutely. This is the one I use for my mother as well. Like, I was working around Puppet for years before—and the way I explained it was, “You know when you get a new iPad, you've got to set up your Facebook account and your email. Imagine you had ten thousand of these.” And she was like—I was like, “You know, companies like Google, company like big banks, they all have lots and lots and lots of computers.” And she was like, “They run all those things on iPads.” And I was like, “This is not really where my analogy was going.” But.Corey: Right. And increasingly, though, it seems like the world has shifted in some direction where, when you explain that to your mother and she comes back with, “Well, wouldn't they just put the application into Docker and be done with it?” Oh, dear. But that seems to be in many ways that the direction that the zeitgeist has moved in, whether or not that is the reality in many environments, where when you're just deploying containers everywhere—through the miracle of Kubernetes—if you'll pardon the dismissive scorn there, that you just package up your application, shove into a container, and then hurl it from the application team over the operations team, like a dead dog cast into your neighbor's yard for him to worry about. And then it sort of takes up the space of you don't have to manage state anymore because everything is mostly stateless in theory. How have you seen it play out in practice in the last five years?Nigel: I mean, that's a real trend. And, you know, the size of a container should be [laugh] smaller than an operating system. And the reality is, I'm a sysadmin; I love operating systems, I nerded out on operating systems. They're a necessary evil, they're terrible, terrible things: registry keys, config files, they're a pain in the neck to deal with. And if you look at, I think what a lot of operations folks missed about Docker when it started was that it didn't make their life better. It was worse.It was, like, this actual, sort of, terrible toolchain where you sort of tied together all these different things. But really importantly, what it did is it put control into the hands of the developers, and it was the developers who were trying to do stuff who were trying to shift into applications. And I think Docker was a really great technology, in the sense of, you know, developers could ship value on their own. And that was the huge, huge leveling up. It wasn't the interface, it wasn't the user experience, it wasn't all these things, it was just that the control got taken away from the IT trolls in their basement going, “No, don't touch my servers,” and instead given straight to the developers. And that's huge because it let us ship things faster. And that's ultimately the whole goal of things.Corey: The thing that really struck me the most from conducting the trainings that I did was meeting a whole bunch of people across the country, in different technological areas of specialty, in different states of their evolution as technologists, and something that struck me was just how much people wound up identifying with the technology that they worked on. When someone is the AIX admin, and the AIX machines are getting replaced with Linux boxes, there's this tendency to fight against that and rebel, rather than learning Linux. And I get it; I'm as subject to this as anyone is. And in many cases, that was the actual pushback that I saw against adopting something like Puppet. If I identify my job as being the person that runs all these carefully curated scripts that I've spent five years building, and now that all gets replaced with something that is more of a global solution to my local problem, then it feels like a thing that made me special is eroding.And we see that with the migration to cloud as well. When you're the storage admin, and it just becomes an API call to S3, that's kind of a scary thing. And when you're one of the server hugger types—and again, as guilty as anyone of this—and you start to see cloud coming in as, like, a rising tide that eats up what it was that you became known for, it's scary and it becomes a foundational shift in how you view yourself. What I really had a lot of sympathy for was the folks who've been doing this for 20 years. They were, in some cases, a few years away from retirement, and they've been doing basically the same set of tasks every year for 25 years.It's one year of experience repeated 25 times. And they don't have that much time left in their career, intentionally, so they want to retire, but they also don't really want to learn a whole bunch of new technologies just to get through those last few years. I feel for them. But at the same time—Nigel: No, me too, totally. But what are you going to do? But without sounding too dismissive there, I think it's a natural tendency for us to identify with the technology if that's what you're around all the time. You know, mechanics do this, truck drivers with brands of trucks, people, like, to build attachments to the technology they work with because we fit them into this bigger techno-social system. But I have a lot of empathy for the people in enterprise jobs who are being asked to change radically because the cycle of progress is speeding up faster and faster.And as you say, they might be a few years away from retirement. I think I used to feel more differently about this when I was really hot-headed and much more of a tech enthusiast, and that's what I identified with. In terms of, it's okay for a job to just be a job for people. It's okay for someone to be doing a job because they get good health care and good benefits and it's feeding their family. That's an important thing. You can't expect everyone to always be incredibly passionate about technology choices in the same way that I think many of us who live on Twitter and hanging out in this space are.Corey: Oh, I have no problem whatsoever with people who want to show up for 40 hours a week-ish, work on their job, and then go home and have lives and not think about computers at all. There's this dark mass of developers out there that basically never show up on Twitter, they aren't on IRC, they don't go to conferences, and that's fine. I have no problem with that, and I hope I don't come across as being overly dismissive of those folks. I honestly wish I could be content like that. I just don't hold still very well.Nigel: [laugh]. Yeah, so I think you touched on a few interesting things there. And some of those we sort of cover in the State of DevOps Report, which is coming out in the next few weeks.Corey: Indeed, and the State of DevOps Report started off at Puppet, and they've now done it for, what, 10 years?Nigel: This is the 10th year, which is completely crazy. So, I was looking at the stats as I was writing it, and it's 10 years of State of DevOps Reports; I think it's 11 years of DevOps Weekly, Gareth Rushgrove's newsletter; it's 12 or 13 years of DevOpsDays that have been going on. This is longer than I spent in primary and high school put together. It's kind of crazy that the DevOps movement is still, kind of, chugging along, even if it's not necessarily the coolest kid on the block, now that GitOps, SRE flavor of the month, various kinds of permutations of how we work with technology, have perhaps got a little bit cooler. But it's still very, very relevant to a lot of enterprises out there.Corey: Yeah. As I frequently say, legacy is a condescending engineering term for ‘it makes money,' and there's an awful lot of that out there. Forget cloud, there are still companies wrestling with do we explore this virtualization thing? And that was something I was very against back in 2006, let's be very honest. I am very bad at predicting the future of technology.And, “I can see this for small niche edge workload cases, where you have a bunch of idle servers, but for the most part, who's really going to use this in production?” Well, basically everyone because that, in turn, is what the cloud runs on. Yeah, I think we can safely say I got that one hilariously wrong. But hey, if you're aren't going to make predictions, then what's it matter?Nigel: But the industry pushes you in these directions. So, there was this massive bank in Asia who I've been working with for a long time and they were always resistant to adopting virtualization. And then it was only four or five years ago that I visited them; they're like, “Right. Okay. It's time. We're rolling out VMware.” And I was like, “So, I'm really curious. What exactly changed in the last year or two in, like, 2014, 2015 that you decided virtualization was the key?” And I'm like—Corey: Oh, there was this jackwagon who conducted this training? Yeah, no, no, sorry. I can't take credit for that one.Nigel: They couldn't order one rack unit servers with CD drives anymore because their whole process was actually provisioning with CDs before that point.Corey: Welcome to the brave new world of PXE booting, which is kind of hard, so yeah, virtualization is easier. You know, sometimes people have to be dragged into various ways of technological advancement. Which gets to the real thing I want to cover, since this is a promoted episode, where you're talking about the State of DevOps Report, I'm almost less interested in what this year's has to say specifically, than what you've seen over the last decade. What's changed? What was true 10 years ago that is very much not true now? Bonus points if you can answer that without using the word Kubernetes more than twice.Nigel: So, I think one of the big things was the—we've definitely passed peak DevOps team, if you may remember, there was a lot of arguments and there's still regular, is DevOps a job title? Is it a team title? Is it a [crosstalk 00:14:33]—Corey: Oh, I was much on the no side until I saw how much more I would get paid as a DevOps engineer instead of a systems administrator for the exact same job. So, you know, I shut up and I took the money. I figured that the semantic arguments are great, but yeah.Nigel: And that's exactly what we've written in the report. And I think it's great. The sysadmins, we were unloved. You know, we were in the basement, we weren't paid as much as programmers. The running joke used to be for developers, DevOps meant, “I don't need ops anymore.” But for ops people, it was, “I can get paid like a developer.”Corey: In many cases, “Oh, well, systems administrators don't want to learn how to code.” It's, yeah, you're remembering a relatively narrow slice of time between the modern era, where systems administrator types need to be able to write in the lingua franca of everything—which is, of course, YAML, as far as programming languages go—and before that, to be a competent systems administrator, you needed to have a functional grasp of C. And—Nigel: Yeah.Corey: —there is only a limited window in which a bunch of bash scripts and maybe a smidgen of Perl would have carried you through. But the deeper understanding is absolutely necessary, and I would argue, always has been.Nigel: And this is great because you've just linked up with one of the things we found really interesting about the report is that you know when we talk about legacy we don't actually mean the oldest shit. Because the oldest shit is the mainframes; it's a lot of bare metal applications. A lot of that in big enterprises—Corey: We're still waiting for an AWS/400 to replace some of that.Nigel: Well, it's administered by real systems engineers, you know, like, the people who wrote C, who wrote kernel extensions, who could debug things. What we actually mean by legacy is we mean late '90s to late 2000s, early 2010s. Stuff that was put together by kids who, like me, happened to get a job because you grew up with a computer, and then the dotcom explosion happened. You weren't necessarily particularly skilled, and a lot of people, they didn't go through the apprenticeships that mainframe folks and systems engineers actually went through. And everyone just held this stuff together with, you know, duct tape and dental floss. And then now we're paying the price of it all, like, way back down the track. So, the legacy is really just a certain slice of rapid growth in applications and infrastructure, that's sort of an unmanageable mess now.Corey: Oh, here in San Francisco, legacy is anything prior to last night's nightly build. It's turned into something a little ridiculous. I feel like the real power move as a developer now is to get a job, go in on day one, rebase everything in the Git repository to a single commit with a message, ‘legacy code' and then force push it to the main branch. And that's the power move, and that's how it works, and that's also the attitude we wind up encountering in a lot of places. And I don't think it serves anyone particularly well to tie themselves so tightly to that particular vision.Nigel: Yep, absolutely. This is a real problem in this space. And one of the things we found in the State of DevOps Report is that—let me back up a little and give a little bit of methodology of what we actually do. We survey people about their performance metrics, you know, like how quickly can you do deploys? What's your mean time to recovery? Those sorts of things, and what practices do you actually employ?And we essentially go through and do statistical analysis on this, and everyone tends to end up in three cohorts, they separate pretty easily, of low, medium, and high evolution. And so one of the things we found is that everyone at the low level has all sorts of problems. They have issues with what does my team do? What does the team next to me do? How do I talk to the team next to me?How do I actually share anything? How do I even know what my goals are? Like, fundamental company problems. But everyone at all levels of evolution is stuck on two big things: not being able to find enough people with the right skills for what they need, and their legacy infrastructure holding them back.Corey: The thing that I find the most compelling is the idea of not being able to find enough people with the skills that they need. And I'm going to break my own rule and mentioned Kubernetes as a prime example of this. If you are effective at managing Kubernetes in production, you will make a very comfortable living in any geographical location on the planet because it is incredibly complex. And every time we've seen this in previous trends, where you need to get more and more complexity, and more and more expertise just to run something, it looks like a sawtooth curve, where at some point that complexity, it gets abstracted away and compressed down into something that is basically a single line somewhere, or it happens below the surface level of awareness. My argument has been that Kubernetes is something no one's going to care about in roughly three years from now, not because we're not using it anymore, but because it's below the level of awareness that we have to think about, in the same way that there aren't a whole lot of people on the planet these days who have to think about the Linux virtual memory management subsystem. It's there and a few people really care about it, but for the rest of us, we don't have to think about that. That is the infrastructure underneath our infrastructure.Nigel: Absolutely. I used to make a living—and it's ridiculous looking back at this—for a year or two, doing high-performance custom compiled Apaches for people. Like, I was really really good at this.Corey: Well yeah, Apache is a great example of this, where back in the '90s, to get a web server up and running you needed to have three days to spare, an in-depth knowledge of GCC compiler flags, and hope for the best. And then RPM came out and then, okay, then YUM or other things like that—Nigel: Exactly.Corey: —on top of it. And then things like Puppet started showing up, and we saw, all right now, [unintelligible 00:20:01] installed. Great. And then we had—it took a step beyond that, and it was, “Oh, now it's just a Docker-run whatever it is,” and these days, yeah, it's a checkbox in S3.Nigel: So, let me get your Kubernetes prediction down, right. So, you're predicting Kubernetes is going to go away like Apache and highly successful things. It's not an OpenStack failure state; it's Apache invisibility state?Corey: Absolutely. My timeline is a bit questionable, let's be fair, but—it's a little on the aggressive side, but yeah, I think that Kubernetes is inherently too complex for most people to have to wind up thinking about it in that way. And we're not talking small companies; we're talking big ones where you're not in a position, if you're a giant blue-chip Fortune 50, to hire 2000 people who all know Kubernetes super well, and you shouldn't have to. There needs to be some flattening of all of that high level of complexity. Without the management tools, though, with things like Puppet and the things that came before and a bunch of different ways, we would all not be able to get anything done because we'd be too busy writing in assembly. There's always going to be those abstractions on top abstractions on top abstractions, and very few people understand how it works all the way down. But that's, in many cases, okay.Nigel: That's civilization, you know? Do you understand what happens when you plug in something to your electricity socket? I don't want to know; I just want light.Corey: And more to the point, whenever you flip the switch, you don't have that doubt in your mind that the light is going to come on. So, if it doesn't, that's notable, and your first thought is, “Oh, the light bulb is out,” not, “The utility company is down.” And we talk about the cloud being utility computing.Nigel: Has someone put a Kubernetes operator in this light switch that may break this process?Corey: Well, okay, IoT does throw a little bit of a crimp into those works. But yeah. So, let's talk more about the State of DevOps Report. What notable findings were there this year?Nigel: So, one of the big things that we've seen for the last couple of years has been that most companies are stuck in the middle of the evolutionary progress. And anyone who deals with large enterprises knows this is true. Whatever they've adopted in terms of technology, in terms of working methods, you know, agile, various different things, most companies don't tend to advance to the high levels; most places stay mired in mediocrity. So, we wanted to dive into that and try and work out why most companies actually stuck like this when they hit a certain size. And it turns out, the problems aren't technology or DevOps, they really fundamental problems like, “We don't have clear goals. I don't understand what the teams next to me do.”We did a bunch of qualitative interviews as well as the quantitative work in the survey with this report, and we talked to one group of folks at a pretty large financial services company who are like, “Our teams have all been renamed so many times, if I need to go and ask someone for something, I literally page up and down through ServiceNow, trying to find out where to put the change request.” And they're like, “How do I know where to put a network port opening request for this particular service when there are 20 different teams that might be named the right thing, and some are obsolete, and I get no feedback whether I've sent it off to the right thing or to a black hole of enterprise despair?”Corey: I really love installing, upgrading, and fixing security agents in my cloud estate! Why do I say that? Because I sell things, because I sell things for a company that deploys an agent, there's no other reason. Because let's face it. Agents can be a real headache. Well, now Orca Security gives you a single tool that detects basically every risk in your cloud environment -- and that's as easy to install and maintain as a smartphone app. It is agentless, or my intro would've gotten me into trouble here, but  it can still see deep into your AWS workloads, while guaranteeing 100% coverage. With Orca Security, there are no overlooked assets, no DevOps headaches, and believe me you will hear from those people if you cause them headaches. and no performance hits on live environments. Connect your first cloud account in minutes and see for yourself at orca.security. Thats “Orca” as in whale, “dot” security as in that things you company claims to care about but doesn't until right after it really should have.Corey: That doesn't get better with a lot of modernization. I mean, I feel like half of my job—and I'm not exaggerating—is introducing Amazonians to one another. Corporate communication between departments and different groups is very far from a solved problem. I think the tooling can help but I've never been a big believer in solving political problems with technology. It doesn't work. People don't work that way.Nigel: Absolutely. One of my earliest times working at Puppet doing, sort of, higher-level sales and services and support, huge national telco walk in there; we've got the development team, the QA team, the infrastructure team. In the course of this conversation, one of them makes a comment about using apt-get, and the others were like, “What do you mean? We're on RHEL.” And it turned out, production was running on RHEL, the QA team running on CentOS and the developers were all building everything on Ubuntu. And because it was Java wraps, they almost didn't have to care. But write once, debug everywhere.Corey: History doesn't repeat, but it rhymes; before Docker, so much of development in startup-land was how do I make my MacBook Pro look a lot more like an EC2 Linux instance? And it turns out that there's an awful lot of work that goes into that maybe isn't the best use of people's time. And we start to see these breakthroughs and these revelations in a bunch of different ways. I have to ask. This is the tenth year that you've done the State of DevOps Report. At this point, why keep doing it? Is it inertia? Are you still discovering new insights every year on top of it? Or is it one of those things where well someone in marketing says we have to do it, so here we are?Nigel: No, actually, it's not that at all. So definitely, we're going to take stock after this year because ten years feels like a really good point to, sort of—it's a nice round number in certain kind of number system. Mainly the reason is, a lot of my job is going and helping big enterprises just get better at using technology. And it's funny how often I just get folks going, “Oh, I read this thing,” like people who aren't on the bleeding edge, constantly discussing these things on Twitter or whatever, but the State of DevOps Report makes its way to them, and they're like, “Oh, I read a thing there about how much better it is if we standardized on one operating system. And that made a really huge difference to what we were actually doing because you had all this data in there showing that that is better.”And honestly, that's the biggest reason why I ended up doing it. It's the fact that it seems to be a tool that has made its way through to very hard to penetrate enterprise folks. And they'll read it and managers will read things that are like, “If you set clear goals for your team and get them to focus on optimizing the legacy environment, you will see returns on it.” And I'm being a little bit facetious in the tone that I'm saying because a lot of this stuff does feel obvious if you're constantly swimming in this stuff day-to-day, but it's not just the practitioners who it's just a job for in a lot of big companies. It's true, a lot of the management chain as well. They're not necessarily going out and reading up on modern agile IT management practices day-to-day, for fun; they go home and do something else.Corey: One of my favorite conferences is Gene Kim's DevOps Enterprise Summit, and the specific reason behind that is, these are very large companies that go beyond companies, in some cases, to institutions, where you have the US Air Force as a presenter one year and very large banks that are 200 years old. And every other conference, it seems, more or less involves people getting on stage, deliver conference-ware and tell stories that make people at those companies feel bad about themselves. Where it's, “We're Twitter for Pets, and this is how we deploy software,” or the ever-popular, “This is how Netflix does stuff.” Yeah, Netflix has basically no budget constraints as far as hiring engineering folks go, and lest we forget, their failure mode is someone can't watch a movie right now. It's not exactly the same thing as the ATM starts spitting out the wrong balance in the streets.And I think that there's an awful lot of discussion where people look at the stories people tell on conference stages and come away feeling bad from it. Very often, I'll see someone from a notable tech companies talk about how they do things. And, “Wow, I wish my group did things like that.” And the person next to me says, “Yeah, me too.” And I check and they work at the same company.And the stories we tell are not necessarily the stories that we live. And it's very easy to come away discouraged from these things. And that goes triply so for large enterprises that are regulated, that have significant downside risk if the technology fails them. And I love watching people getting a chance to tell those stories.Nigel: Let me jump in on that really quickly because—Corey: Please, by all means.Nigel: —one is, you know, having done four years at Google, things are a shitshow internally there, too—Corey: You're talking about it like it's prison. I like it.Nigel: —you know. [laugh]. People get horrified when they turn up and they're like, “Oh, what it's not all gleaming, perfect software artifacts, delivered from the hand of Urs.” But I think what Gene has done with DevOps Enterprise Summit is fantastic in how people share more openly their failure states, but even there—and this is an interesting result we found from a few years ago, State of DevOps Report—even those executives are being more optimistic because it's so beaten into you as the senior executive; you're putting on a public face, and even when they're trying to share the warts-and-all story, they can't help but put a little bit of a positive spin on it. Because I've had exactly the same experience there where someone's up there telling a war story, and then I look, turn to the person next to me, and they work at that same 300-year-old bank, and they're like, “Actually, it's much, much worse than this, and we didn't fix it quite as well as that.” So, I think the big tech companies have terrible inside unless they're Netflix, and the big enterprises are also terrible. But they're also—Corey: No, no, I've talked to Netflix people, too. They do terrible things internally there, too. No one talks about the fact that their internal environments are always tire fires, and there are two stories: the stories we tell publicly, and the reality. And if you don't believe me on that, look at any company in the world's billing system. As much as we all talk about agile and various implementations thereof when it comes to things that charge customers money, we're all doing waterfall.Nigel: Absolutely. [laugh].Corey: Because mistakes show when you triple-charge someone's credit card for the cost of a small country's GDP. It's a problem. I want to normalize those sorts of things more. I'm looking forward to reading this year's report, just because it's interesting to see how folks who are in environments that differ from the ones that I get to see experience in this stuff and how they talk about it.Nigel: Yeah. And so one of the big results I think there for big companies that's really interesting is that one of the, sort of, anti-patterns is having lots of different types of teams. And I kind of touched on this before about having confusing team titles being a real problem. And not being able to cross organizational boundaries quickly is really, really—you know, it's a huge inhibitor and cause, source of friction. But turns out the pattern that is actually really great is one that the Team Topologies guys have discovered.If you've been following what Matthew Skelton and Manuel Pais have been doing for a while, they've basically been documenting a pattern in software organizations of a small number of team types, of a platform team, value stream teams, complicated subtest system teams, and enabling teams. And so we worked with Manuel and Matt on this year's report and asked a whole bunch of questions to try and validate the Team Topologies model, and the results came back and they were just incredibly strong. Because I think this speaks to some of the stuff you mentioned before that no one can afford to hire an army of Kubernetes developers, and whatever the hottest technology is in five years, most big companies can't hire an army of those people either. And so the way you get scale internally before those things become commoditized is you build a small team and create the situation where they can have outsized leverage inside their organization, like get rid of all the blockers to fast flow and make their focus self-service to other people. Because if you're making all of your developers learn distributed systems operations arcane knowledge, that's not a good use of their time, either.Corey: It's really not. And I think that's something that gets lost a lot is, I've never yet seen a company beyond the very early startup stage, where the AWS bill exceeded the cost of the people working on the AWS bill. Payroll is always a larger expense than infrastructure unless you're doing something incredibly strange. And, oh, I want to save some money on the cloud bill is very often offset by the sheer amount of time that you're going to have to pay people to work on that because, contrary to what we believe as engineering hobbyists, people's time is very far from free. And it's also the opportunity cost of if you're going to work on this thing instead of something else, well, is that really the best choice? It comes down to contextualizing what technology is doing as well as with what's happening over in the world of business strategy. And without having a bridge between those, it doesn't seem to work very well.Nigel: Absolutely. It's insane. It's literally insane that, as an industry, we will optimize 5%, 3% of our infrastructure bill or application workload and yet not actually reexamine business processes that are causing your people to spend 10% of their time in synchronous meetings. You can save so much more money and achieve so much more by actually optimizing for fast flow, and getting out of the way of the people who cost lots of money.Corey: So, one last topic that I want to cover before we call it an episode. You talk to an awful lot of folks, and it's easy to point at the aspirational stories of folks doing things the right way. But let's dish for a minute. What are you seeing in terms of people not using the cloud properly? I feel like you might have a story or two on that one.Nigel: I do have a few stories. So, in this year's report, one of the things we wanted to find out of, like, are people using the cloud in the way we think of cloud; you know, elastic, consumption-based, all of these sorts of things. We use the NIST metrics, which I recognize can be a little controversial, but I think you've got to start somewhere as a certain foundation. It turns out just about everyone is using the public cloud. And when I say cloud, I'm not really talking about people's internal VMware that they rebadged as cloud; I'm talking about the public cloud providers.Everyone's using it, but almost no one is taking advantage of the functionality of the cloud. They're instead treating it like an on-premise VMware installation from the mid-2000s, they're taking six weeks to provision instances, they're importing all of their existing processes, they keep these things running for a long time if they fall over, one person is tasked with, “Hey, do you know how pet number 45 is actually doing here?” They're not really treating any of these things in the way that they're actually meant to. And I think we forget about this a lot of the time when we talk about cloud because we jump straight to cloud-native, you know, the sort of bleeding edge of folks in serverless, highly orchestrated containers. I think if you look at the actual numbers, the vast majority of cloud usage, it's still things like EC2 instances on AWS. And there's a reason: because it's a familiar paradigm for people. We're definitely going to progress past there, but I think it's easy to leave the people in the middle behind when we're talking about cloud and how to improve the ecosystem that they all operate in.Corey: Part of the problem, too, is that whenever we look at how folks are misusing cloud, it's easy to lose sight of context. People don't generally wake up and decide I'm going to do a terrible job today unless they work in, you know, Facebook's ethics department or something. Instead, it's very much a people are shaped by the constraints they're laboring under from a bunch of different angles, and they're trying to do the best with what they have. Very often, the reason that a practice or a policy exists is because, once upon a time, there was a constraint that may or may not still be there, and going forward the way that they have seemed like the best option at the time. I found that the default assumption that people are generally smart and doing the right thing with the information they have carries you a lot further, in many respects than what I did is a terrible junior consultant, which is, “Oh, what moron built this?” Invariably to said moron, and then the rest of the engagement rapidly goes downhill from there. Try and assume good faith, and if you see something that makes no sense, ask, “Why is it like this?” Rather than, “Why is it like this?” Tone counts for a lot.Nigel: It's the fundamental attribution bias. It's why we think all other drivers on the road are terrible, but we actually had a good reason for swerving into that lane.Corey: “This isn't how I would have built it. So, it's awful.”Nigel: Yeah, exactly.Corey: Yeah. And in some cases, though, there are choices that are objectively bad, but I tried to understand where they came from there. Company policy, historically, around things like data centers, trying to map one-to-one to cloud often miss some nuances. But hey, there's a reason it's called the digital transformation, not a project that we did.Nigel: [laugh]. And I think you've got to always have empathy for the people on the ground. I quite often have talked to folks who've got, like, a terrible cloud architecture with the deployment and I'm like, “Well, what happened here?” And they went, “Well, we were prepared to deploy this whole thing on AWS, but then Microsoft's salespeople got to the CTO and we got told at the last minute we're redeploying everything on Azure.” And so these people were often—you know, you're given a week or two to pivot around the decision that doesn't necessarily make any sense to them.And there may have been a perfectly good reason for the CTO to do this: they got given really good kickbacks in terms of bonuses for, like, how much they were spending on the infrastructure—I mean, discounts—but people on the ground are generally doing the best with what they can do. If they end up building crap, it's because our system, society, capitalism, everything else is at fault.Corey: [laugh]. I have to say, I'm really looking forward to seeing the observations that you wound up putting into this report as soon as it drops. I'm hoping that I get a chance to speak with you again about the findings, and then I can belligerently tell you to justify yourself. Those are my favorite follow-ups.Nigel: [unintelligible 00:37:05].Corey: If people want to get a copy of the report for themselves or learn more about you, where can they find you?Nigel: Just head straight to puppet.com, and it will be on the banner on the front of the site.Corey: Excellent. And will, of course, put a link to that in the show notes, if people can't remember puppet.com. Thank you so much for taking the time to speak with me. I really appreciate it.Nigel: Awesome. No worries. It was good to catch up.Corey: Nigel Kersten, field CTO at Puppet. I'm Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice as well as an insulting comment telling me that ‘comcastic' isn't a funny word, and tell me where you work, though we already know.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

“Practices and principles are necessary and useful, but they should be informed by what the constraints are in the first place. We need to acknowledge the constraints, and then build and decide on practices and principles based on that." Manuel Pais is the co-author of “Team Topologies” and a DevOps thought leader, focusing on team interactions, delivery practices, and accelerating flow. In this episode, Manuel shared great insights from his book “Team Topologies”, starting from highlighting some constraints that organizations typically face, such as Conway's Law and cognitive load. Manuel then explained the 4 fundamental team topologies and how they are addressing those constraints. Manuel also shared about the Team API concept as well the 3 core interaction modes, which inform how teams should interact with each other in order to improve the overall flow within the business. Finally, Manuel shared some advice on how leaders can start implementing these ideas within their organizations. Listen out for: Career Journey - [00:04:47] Team Topologies - [00:07:00] Challenges with Organization Chart - [00:08:58] Measuring Flow - [00:11:54] Conway's Law - [00:14:57] How to Use Conway's Law - [00:18:10] Breaking Monolith into Microservices - [00:21:15] Cognitive Load - [00:23:57] 4 Fundamental Team Topologies - [00:27:33] Team API - [00:34:55] 3 Interaction Modes - [00:37:57] Advice to Align with Team Topologies - [00:42:41] 3 Tech Lead Wisdom - [00:48:13] _____ Manuel Pais's Bio Manuel Pais is the co-author of “Team Topologies: organizing business and technology teams for fast flow”. Recognized by TechBeacon as a DevOps thought leader, Manuel is an independent IT organizational consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is also a LinkedIn instructor on Continuous Delivery. Follow Manuel: Twitter – https://twitter.com/manupaisable LinkedIn – https://www.linkedin.com/in/manuelpais/ Team Topologies – https://teamtopologies.com/ Team Topologies Academy – https://academy.teamtopologies.com/ Our Sponsor Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags by visiting https://techleadjournal.dev/shop. Like this episode? Subscribe on your favorite podcast app and submit your feedback. Follow @techleadjournal on LinkedIn, Twitter, and Instagram. Pledge your support by becoming a patron. For more info about the episode (including quotes and transcript), visit techleadjournal.dev/episodes/44.

It's undeniable that the role of software in any modern organisation is essential – untangling software from the organization is almost impossible today. With new solutions emerging as part of the low-code or no-code movement, what's the best way to organise around software effectively? Why is it so important to remove hand-offs between teams and to ensure that self-directed teams can be enabled by platforms? What are the overlaps between the world of DevOps and the work we're doing at Boundaryless around ecosystemic, and entrepreneurial organizations? To better understand these questions, we bring on Matthew Skelton, co-author with Manuel Pais of ‘Team Topologies: organizing business and technology teams for fast flow'. It's a seminal text that speaks about how to build the best team structure around the role that software has for your specific organisation. Matthew is recognised by TechBeacon in 2018, 2019, and 2020 as one of the top 100 people to follow in DevOps. He curates the well-known DevOps team topologies patterns at devopstopologies.com. He is also Head of Consulting at Conflux and specialises in continuous delivery, operability, and organisation dynamics for modern software systems.  In this conversation, Matthew helps highlight the real impact of digital transformation on companies, and what it means for team coordination. Join us as we explore key insights from his and Manuel's book ‘Team Topologies', low-code development platforms, API-drivenness, observability, and the impact of market validation and software-centric ways of organizing. Remember that you can always find transcripts and key highlights of the episode on our Medium publication: https://platformdesigntoolkit.com/podcast-S2E20-Matthew-Skelton    To find out more about Matthew's work: > Website: https://teamtopologies.com/  > LinkedIn: https://www.linkedin.com/in/matthewskelton/  > Team Topologies Academy: https://academy.teamtopologies.com/  > Team Topologies Partner Program: https://teamtopologies.com/partner-program    Other references and mentions: > Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, 2019: https://www.amazon.com/Team-Topologies-Organizing-Business-Technology/dp/1942788819   > IT Revolution: https://itrevolution.com/  > Domain Driven Design Community: https://www.dddcommunity.org/ > Core Domain Charts: https://github.com/ddd-crew/core-domain-charts > Conway's Law: https://en.wikipedia.org/wiki/Conway%27s_law  > “Building Extensible Platforms”, Shopify case study: https://m.youtube.com/watch?v=GqGNA8GnOOE&feature=youtu.be    Find out more about the show and the research at Boundaryless at www.platformdesigntoolkit.com/podcast   Thanks for the ad-hoc music to Liosound / Walter Mobilio. Find his portfolio here: www.platformdesigntoolkit.com/music Recorded on 7 June 2021.

Joekub is taking a break from their trips around the world to sit down with Manuel Pais, co-author of the influential book "Team Topologies". Manuel is kind enough to answer a barrage of questions from Jakub and Joe around why he and Matthew (the other author) decided to write the book, how they've been received, and some of the more deeper thinking around why he thinks the book has gotten people excited in the world of agile. In addition to the amazing insights and glimpses into Team Topologies, you'll get to hear Joe giggle with delight and Jakub squee with joy as these two fellas get to talk to the co-creator of one of their favourite books. If you'd like to get intouch with Manuel, you can look him up on LinkedIn or go to the Team Topologies website to see what they are up to: https://teamtopologies.com/ and if you're interested in apply for there academy you can go here: http://academy.teamtopologies.com --- Send in a voice message: https://anchor.fm/joekub/message

Introducing Team Topologies with nonetheless than one of his creators: Manuel Pais.Manuel joins us for a chat with our very own Alberto Brandolini as the two unveil the power behind Team Topologies, a clear, easy-to-follow approach to modern software delivery with an emphasis on optimizing team interactions for flow.

Wie gestaltet man Team-Strukturen optimal und passt sie aktuellen Gegebenheiten an? Dieser Fragestellung gehen Matthew Skelton, Manuel Pais in ihrem Buch Team Topologies: Organizing Business and Technology Teams for Fast Flow nach. Grundlage ihrer Gedanken sind die Erkenntnisse, die Conway bereits 1968 hatte: „Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“

This week Manuel Pais is our guest. We challenge him with the pattern “Internal Evangelism” from the Cloud Native Patterns repository (https://www.cnpatterns.org/organization-culture/internal-evangelism). How the different Team Topologies archetypes and their relationship with this pattern. Our conversation goes into the necessary skills to be an influential evangelist, what a team should do from an evangelism point of view, and also to the management traits.  Manuel recommends: Team Topologies Book: https://teamtopologies.com/book  Thoughtworks enabling team case study: Chapter 5, Page 88 IBM enabling team case study: Chapter 7, Page 146 Platform internal "evangelism" at HelloFresh: https://engineering.hellofresh.com/advocating-for-a-product-mindset-within-platform-teams-and-how-we-do-it-at-hellotech-part-1-fc1fbf8ae015 Platform branding example from NAV's platform team: https://nais.io/ Manuel Pais (@manupaisable) is co-author of Team Topologies: organising business and technology teams for fast flow. Recognised by TechBeacon as a DevOps thought leader, Manuel is an independent IT organisational consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is also a LinkedIn instructor on Accelerating Continuous Delivery in the Enterprise.

Recorded at the 2019 annual SEACON conference in London, Mik has two special guests, Matthew Skelton and Manuel Pais, authors of Team Topologies: Organizing Business and Technology Teams for Fast Flow. This episode of Mik + One discusses: - Insights into the patterns and anti-patterns of how teams are structured and evolve, and why it's important to focus on the cognitive load of teams - Team specialization, the need for platform teams and how to manage the crucial dependencies between teams - The need for a product value stream that's supported by multiple teams, and the importance of flow in an organization's software systems architecture - Learnings on how to successfully organize teams of teams and if there is a perfect number of team members for an organization - Advice for organizations on how to successfully structure teams based on cognitive load Subscribe to the Mik + One podcast today so you never miss an episode and don't forget to leave your review. Follow Mik on Twitter: @mik_kersten #MikPlusOne www.tasktop.com For more information about Manuel Pais and Matthew Skelton, visit: https://projecttoproduct.org/podcast/team-topologies/

In this episode, host Jessica Kerr is joined by guests Matthew Skelton and Manuel Pais to discuss their book, Team Topologies.