Podcasts about technology teams

Schickt uns euer Feedback zur EpisodeIn Episode 127 fragen wir uns (mal wieder) warum so viele digitale Transformationsprojekte scheitern. Björn Schotte, Mitgründer und Geschäftsführer der Mayflower GmbH, bringt in dieser Folge eine provokante These mit: “Organisation folgt Technologie, nicht umgekehrt.”Während viele Unternehmen zuerst Teams bilden und dann hoffen, dass “geile Software” entsteht, zeigt die Praxis, dass dieser Ansatz oft zum Scheitern verurteilt ist. Stattdessen sollten wir uns zunächst fragen: Welche Geschäftsanforderungen haben wir? Welche Softwarearchitektur brauchen wir dafür? Und erst dann: Wie müssen unsere Teams strukturiert sein, um diese Architektur optimal umzusetzen?Wir erkunden das faszinierende Conway's Law, das besagt, dass die Struktur einer Software die Kommunikationsstrukturen der Organisation widerspiegelt, und diskutieren moderne Ansätze wie Team Topologies. Diese bieten Frameworks, wie Teams in einer zunehmend komplexen Softwarewelt organisiert werden können, um sowohl Autonomie als auch Alignment zu gewährleisten.Doch die eigentliche Herausforderung liegt in der Transformation: Wie können wir in gewachsenen Strukturen mit informellen Netzwerken und mikropolitischen Interessen solche Veränderungen umsetzen? Und welchen Einfluss wird künstliche Intelligenz auf dieses Zusammenspiel haben? Werden Junior-Entwickler überflüssig oder verändert sich nur, wie wir zusammenarbeiten?Eine gedankenprovozierende Folge, die die Grenzen zwischen Technologie und Organisation neu auslotet und praktische Einblicke gibt, wie digitale Transformation wirklich gelingen kann.Shownotes:Manuel Pais und Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow, Buch

In this episode of the Product Thinking Podcast, I am thrilled to welcome Matthew Skelton, co-author of "Team Topologies: Organizing Business and Technology Teams for Fast Flow." We delve into the intricate intersections between team topology principles and product management, exploring how these frameworks can transform the way product teams work together to enhance collaboration and reduce cognitive load.If you're looking to refine your team's approach to delivering outstanding customer outcomes, this episode is a must-listen. Matthew Skelton joins me to discuss the revolutionary concepts within "Team Topologies," highlighting their impact on modern product management and operations. We uncover how organizing teams around flow and customer value can drastically improve product outcomes. Matthew shares practical examples of how these concepts are applied in various industries, providing invaluable insights for anyone involved in managing or organizing product teams.Curious about how team topologies can optimize your product processes? Tune in to hear Matthew Skelton's expert insights and discover practical strategies to enhance your team's workflow. Don't miss this opportunity to learn from a leading voice in the field of organizational design for software delivery.You'll hear us talk about: Product Managers in Regulated Spaces (28:30)We discuss the debate over whether product managers should be domain experts versus having deep product knowledge. Matthew provides insights into how teams can effectively leverage subject-matter experts without them managing the entire product line. Breaking Silos in Teams (14:21)Matthew and I explore how organizations can overcome internal silos, emphasizing the importance of collaboration across product management, development, marketing, and sales for cohesive product delivery. AI and Team Enablement (51:54)We dive into how AI is transforming team topologies and enabling teams, discussing the shift in AI enablement platforms and their potential in redefining team roles and productivity.Episode Resources: Matthew Skelton's Website: https://matthewskelton.com Conflux Website: https://confluxhq.com Team Topologies Information: https://teamtopologies.com Sign up for a free Liveblocks account: ⁠https://liveblocks.io/⁠Timestamps:00:00 Episode Preview00:56 Intro03:00 Dear Melissa08:35 Moving from Projects to Product14:45 Breaking Silos in Teams18:27 Mistakes in Product Models28:14 Product Managers in Regulated Spaces35:51 Product Ops at Scale42:17 SAFE and Big Batch Planning51:37 AI and Team Enablement

Organisational effectiveness isn't just about making team members more productive, but [roperly structuring teams and understanding how they work together.Small teams with high trust can make decisions quickly and maintain better context of what they're building, while being mindful of the cognitive load placed on members.Matthew Skelton is the author of Team Topologies. He developed patterns for team organisation and devops that were adopted by companies like Netflix and Accenture. His work focuses on how to structure teams effectively in organisations, particularly looking at concepts like team cognitive load and team interaction modes.Three reasons to listenLearn how small teams can achieve faster results and deliver value more effectively to usersUnderstand the principles behind Amazon's "two pizza team" approach, including how trust enables quick decision-making in small groupsDiscover how organisations often lack self-awareness and how this becomes a major obstacle to their successEpisode highlights[00:11:47] The road to Team Topologies[00:17:18] Why collaboration is not the only answer[00:22:05] Creating flow for small teams[00:23:34] Making work humane[00:28:10] The Uswith example[00:30:45] Alternative schools of thought[00:34:56] Impact on team leaders[00:37:31] Conway's law[00:40:48] Decoupling of teams and architecture[00:46:08] Matthew's media recommendations[00:48:59] Takeaways from Pia and DanLinksTeam Topologies: Organizing Business and Technology Teams for Fast Flow –Matthew's bookThe jazz ensemble: the ultimate team? – We Not MeTeam Topologies' Uswitch case studyConway's lawEmpowered Agile Transformation: Beyond the Framework, by Alexandra StokesArchitecture Modernization, by Nick TuneFrozen II (2019)Leave us a voice note

Новый выпуск подкаста с программным директором ПК DevOpsConf 2025. На пару с Дмитрием Зайцевым обсуждали DevOps и развитие инжиниринговых практик, инженерную зрелость. Обсуждали программу DevOpsConf и тизернули три крутых доклада. DevOpsConf 2025, 7-8 апреля 2025, Москва Александр Косицин — Enabling teams или «Инженер на час» Александр Коротков — Почему не взлетают внутренние платформы? Лев Николаев — Механизмы безопасности в Astra Linux Евгений Харченко — Как DevOps влияет на эффективность организации? Matthew Skelton, Manuel Pais — «Team Topologies: Organizing Business and Technology Teams for Fast Flow» Участники @golodnyj Дмитрий Зайцев Telegram канал VK группа Яндекс Музыка iTunes подкаст Поддержи подкаст

Today's guest is the one and only Christina Wodtke - Professor at Stanford and author of several bestsellers, including the famous book on OKRs “Radical Focus”.We covered:* Foundations and misconceptions about OKRs* Prerequisites for successfully use OKR* Why OKRs might not be for you* The importance of psychological safety and strategic context* Outcome-based key results vs. output-based results* Cross-functional team collaboration and shared objectives* Cadences and Principles* Exploratory OKRs* Challenges in large organizations with complex dependencies* And moreChristina is a legend and one of my biggest references.I hope you enjoy this conversation as much as I did!_References:Article: Why context and culture matter in leading with objectivesAligned: Stakeholder Management for Product LeadersTeam Topologies: Organizing Business and Technology Teams for Fast FlowThe Crux: How Leaders Become Strategists 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

To bring specialists into teams with different skill sets takes good communication and a knowledge of the history of the team you're integrating. Doing this well means everyone can point their skills at solving problems.Ash Winter is an experienced software tester who has a particular interest in how teams and organisations work. Ash has been a software tester for over 15 years, and has experience as a consultant, helping organisations improve their testing processes.In his role he's seen a wide range of team structures and sizes, and he's particularly focused on the challenges and opportunities of being a specialist within a team.Three reasons to listenUnderstand the unique challenges and opportunities of being a specialist in a cross-functional teamExplore the impact of team history and dynamics on integrating new specialistsLearn about the evolving role of software testers and their influence in modern development teamsEpisode highlights[00:09:14] Testing teams[00:14:29] The problem with "embedding" into a team[00:16:30] The Spotify model[00:19:48] Communities of practice[00:22:57] Agile methodologies with multidisciplinary teams[00:28:05] The benefits of a coaching qualification[00:30:19] Ash's book recommendation[00:31:42] Takeaways from Dan and PiaLinksConnect with Ash via LinkedInTeam Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton & Pais ManuelThe Five Dysfunctions of a Team: A Leadership Fable, by Patrick LencioniThe Goal: A Process of Ongoing Improvement, by Eliyahu GoldrattThe Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene KimLeave us a voice note

Immer häufiger trifft man auf Product Owner von einem Plattform Team. Schnell kommen dann die Fragen auf, ob und wie die Ideen eines klassischen Scrum Product Owners anwendbar sind. Was ist das Produkt? Was sind in diesem Fall die Kunden bzw. besser gesagt die Nutzer? Ganz offensichtlich ergeben sich aus solchen Rahmenbedingungen eine Reihe von ganz speziellen Herausforderungen. Daher nehmen sich Dominique Winter und Tim Klein in dieser Folge des Themas an. Entsprechend klären sich zunächst mal die Frage, was genau hinter dem Begriff des Plattform Teams steckt und wie es sich von den Experience Teams abgrenzt. Unter den besonderen Herausforderungen heben sie hervor, sich nicht in die Ecke eines internen Dienstleisters drängen zu lassen. Auch wenn man als ein solcher Product Owner keinen externen Marktzugang hat, ist der Aufbau eines echten Problemverständnisses der (internen) Nutzer aus den sog. Experience Teams sehr wichtig. Auch Stakeholder Management bekommt als Product Owner eines Plattform Teams eine besondere Bedeutung. In der Regel hat man ja mehrere andere Teams, dem eine solche Plattform zur Nutzung bereitgestellt wird. Schnell können dadurch unterschiedliche oder auch widersprüchliche Anforderungen herangetragen werden. Die eigene Plattform muss aber gemäß der eigenen Produktvision in eine geplante Richtung entwickelt werden. Die Gefahr, es jedem internen Stakeholder Recht zu machen und damit mit der Plattform zum Spielball der Kräfte zu werden, ist ansonsten sehr hoch. Es geht also letztlich darum, den Wert der eigenen Plattform als Lösung für die Probleme der Experience Teams im Blick zu behalten und die Plattform Lösung als gestaltende Product Ownerin zu führen. In dieser Folge wird auf diese Quellen referenziert: - Podcast-Folge: Vom Entwickler zum Product Owner - Buch: Manuel Pais und Matthew Skelton: "Team Topologies: Organizing Business and Technology Teams for Fast Flow" - Buch: Marty Cagan: "EMPOWERED" Bist du evtl. selber auch Product Owner in einem Plattform Team oder arbeitest du in bzw. mit einer solchen Teamkonstellation? Welche Herausforderungen erlebst du ähnlich, welche weiteren siehst du noch? Und hast du ergänzende Tipps für die Situation auf Basis deiner eigenen Erfahrung? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

En este episodio de Codurance Talks, nos sentamos con Angélica Lozano Álvarez, CTO de mlean, para conocer cómo la empresa ha implementado procesos de mejora continua para asegurar una satisfactoria Developer Experience mientras escala eficientemente su negocio. Explora la evolución del modelo organizativo interno de mlean a medida que han crecido, destacando la importancia de la conexión entre el negocio y la experiencia de su equipo. mlean es una destacada empresa en el ámbito del software de excelencia operativa, centrada en la digitalización de sistemas de producción para transformar los procesos de las fábricas. Actualmente, el mlean Production System (mPS) se encuentra implementado en más de 450 fábricas en más de 40 países, con una base de usuarios que supera los 100,000 en todo el mundo. Si te gustaría continuar esta conversación con Angélica, podrás contactarla a través de su perfil de LinkedIn o Twitter.  Material recomendado a lo largo de la sesión: Team Topologies: Organizing Business and Technology Teams for Fast Flow por Matthew Skelton. Episodios anteriores de nuestra serie sobre la Developer Experience: Mejorando la Developer Experience con Trunk-Based Development Developer's Experience and Psychological Safety with Markus Seebacher What is Developer Experience with Abi Noda  

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.

Anuj Rathi is the Chief Product and Marketing Officer at Jupiter Money, where he leads product management, marketing, design, growth, and analytics. Before Jupiter Money, Anuj served as the Senior Vice President of Revenue and Growth at Swiggy, VP of Product at SnapDeal, a Senior PM at Walmart Labs and the first-ever PM at Flipkart. He's also one of the most beloved and respected product leaders in India. In this episode, we discuss:• How product management is different in India• How to rethink your approach to new users• How Anuj operationalizes the “working backwards” framework• Why Anuj thinks PMs should be more full-stack than they are• How to use Anuj's “4BB” framework to get better at product strategy and prioritization• Advice on developing innovative roadmap ideas• The three essential skills of a successful PM• Three reasons why leadership fails• Why OKRs don't work in marketplaces—Brought to you by Sanity—The most customizable content layer to power your growth engine | Vanta—Automate compliance. Simplify security | Wix Studio—The web creation platform built for agencies—Find the transcript for this episode and all past episodes at: https://www.lennyspodcast.com/episodes/. Today's transcript will be live by 8 a.m. PT.—Where to find Anuj Rathi:• X: https://twitter.com/anujrathi• LinkedIn: https://www.linkedin.com/in/anujrathi1—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Anuj's background(04:28) How product differs in India (08:34) When modern product thinking started to gain traction in India(14:01) How Anuj thinks about new-user experiences(15:07) Scott Belsky's “lazy, vain, and selfish” framework (19:59) Why PMs must understand category consumers(22:30) Anuj's philosophy on the PM job(23:59) How Anuj applies the working-backwards framework(28:36) The importance of FAQs(30:10) The full-stack PM mindset(33:06) Anuj's “show don't tell” framework(36:19) How to use the show-don't-tell framework(39:14) The impact of using this framework(41:27) Anuj's “4BB framework” for product strategy(48:59) Contrarian corner(50:49) Anuj's “framework of 3” for great PMs(52:34) How to develop grit and influence(54:00) Three reasons why leaders fail (56:21) AI corner(57:51) Lessons from building a successful marketplace(1:02:19) How to balance and maintain stability on all sides of a marketplace(1:07:48) Lightning round—Referenced:• MakeMyTrip: https://www.makemytrip.com/• Shaadi.com: https://www.shaadi.com/• Bharat Matrimony: https://www.bharatmatrimony.com/• Flipkart: https://www.flipkart.com/• Ola: https://www.olacabs.com/mobile• Swiggy: https://www.swiggy.com/• Jio: https://www.jio.com/• UPI: http://cashlessindia.gov.in/upi.html• The First 15 Seconds by Scott Belsky: https://medium.com/positiveslope/the-first-15-seconds-9590d7dabc• Jupiter: https://jupiter.money/• How to get better at influence: https://www.lennysnewsletter.com/p/how-to-get-better-at-influence#• Working Backwards: https://www.workingbackwards.com/• Range: Why Generalists Triumph in a Specialized World: https://www.amazon.com/Range-Generalists-Triumph-Specialized-World/dp/0735214484• In Search of Greatness on Prime Video: https://www.amazon.com/Search-Greatness-Wayne-Gretzky/dp/B07P5X99P5• Team Topologies: Organizing Business and Technology Teams for Fast Flow: https://www.amazon.com/Team-Topologies-Organizing-Business-Technology/dp/1942788819• Conway's Law: https://www.atlassian.com/blog/teamwork/what-is-conways-law-acmi• Lessons from scaling Spotify: The science of product, taking risky bets, and how AI is already impacting the future of music | Gustav Söderström (Co-President, CPO, and CTO at Spotify): https://www.lennyspodcast.com/lessons-from-scaling-spotify-the-science-of-product-taking-risky-bets-and-how-ai-is-already-impac/• Taobao: https://world.taobao.com/• Alibaba: https://offer.alibaba.com/• Working Backwards: https://www.amazon.com/Working-Backwards-PB/dp/1529033845• How Brands Grow: What Marketers Don't Know: https://www.amazon.com/How-Brands-Grow-What-Marketers/dp/0195573560• The Luxury Strategy: Break the Rules of Marketing to Build Luxury Brands: https://www.amazon.com/Luxury-Strategy-Break-Marketing-Brands/dp/0749464917• The Office on Peacock: https://www.peacocktv.com/stream-tv/the-office• Rise: https://www.risescience.com/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

This week, Dan Neumann and his co-host Justin Thatil are joined by Hal Hogue, who has transitioned from an Agile Coach position to a Managing role and today shares the features of such a shift.   In this episode, Hal discusses his journey from working with managing engineers to becoming one of them. He mentions the particularities of both of these roles, the overlaps between them, and how these positions can work together to advocate for Agility and fast flow.   Key Takeaways What are Agile Coaches? The Agile Coach is a leader (just like the Manager). Agile Coaches are focused on letting others grow (individuals or Teams). Agile Coaches also serve as teachers. Coaches teach the true meaning of being Agile by living the values and principles specified in the Manifesto. Agile Coaches are change agents, helping organizations avoid becoming stagnant. The manager role is not defined in the Scrum Guide, but that does not mean it cannot exit. Manager accountabilities: A Manager's first responsibility is to know about the people part of the Team. A Manager needs to know what motivates the Team and their aspirations. It requires a lot of active listening and asking questions. A Manager should set clear expectations and roles for the Team. The Team should clearly know the reasons why they do their jobs. There is a critical relationship between the Engineering Manager and the Product Owner. These two roles need constant communication, aligning goals not only for the product but also around quality. A Manager should not decide things for the Team but should take essential matters to the Team and let them be part of designing the solution by giving them options and tools; this requires a lot of trust in both directions. Managers can help with impediment escalation or performance issues. The Engineering Manager and Product Owner is a critical relationship, as well as the Manager and Agile Coach or Scrum Master. A leader must be a coach and a servant leader for the Team but also for the Product Owner. A Coach can help a Manager understand what Agility is, its principles, and its values.   Mentioned in this Episode: Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

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 on The Home Builder Digital Marketing Podcast, Ty Brewer of HistoryMaker Homes joins Greg and Kevin to discuss how unifying home builder digital marketing and technology teams improve business. https://www.buildermarketingpodcast.com/episodes/180-unifying-marketing-and-technology-teams-ty-brewer

Leadership is an important if often-overlooked quality in the technology industry. However, it is also a complex and multi-faceted thing: it isn't a discrete set of skills, but rather an ability to respond and adapt to the needs of a situation, team or individual. In this episode of the Technology Podcast, Ricardo Cavalcanti (Caval) and Arturo Santos from Thoughtworks Brazil join hosts Alexey Boas and Scott Shaw to discuss their experiences of leadership and offer their perspective on the value of building a diverse repertoire of leadership styles.    

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

Accomplished C-Suite leader Atif Rafiq reflects on starting a bank in elementary school (spoiler, it didn't quite work), the power in the neutrality of raw curiosity, coming aboard AOL at the start of the internet boom, becoming the first Chief Digital Officer in the history of the Fortune 500, digitizing fast food, the creativity-killing hazard of "alignment before exploration", lessons learned from the CEOs of McDonalds, Volvo, and Amazon, and enjoying the luxury of focus.

In our latest Digital Lighthouse episode, Zoe Cunningham is joined by Anne Currie, Community co-Chair of the Green Software Foundation. Anne shares her experience and talks about the key pressing climate issues for the tech industry right now, the best things that tech teams can do to reduce their impact on the planet, and what research is saying about how the digital age has changed. Learn more by listening to the podcast or reading the full transcript at: https://www.softwire.com/insights/greening-your-digital-infrastructure-strategies-for-sustainable-technology-teams

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 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 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.

This week, Dan Neumann is joined by his colleague Mike Guiler to talk about Teams. Dan and Mike explore the four types of Team topologies and the three different types of interactions among them. They also dive deep into how to design effective Teams and how to help them grow so they can move at the speed of the customer.   Key Takeaways Why is a Team more than just a group of people? Sometimes you can see a collection of people, not really a Team. It is impossible for everyone to talk to everybody; the Team structure supports effective communication. A Team must have the power to make decisions, which is called bounded autonomy. A Team has autonomy and uses its expertise to decide the most appropriate decision at a given time. A Team can choose what it considers the right tool at a particular moment. Team Topologies: Four different types of Teams: Stream-aligned Team: aligned to a flow of work from (usually) a part of the business domain. This type of Team is a lot like a Scrum Team. Enabling Team: enables a Stream-aligned team to overcome impediments and can also notice missing capacities. This Team allows the stream-aligned Team to keep growing. Complicated Subsystem Team: where significant mathematics/calculation/technical expertise is required. Platform Team: a collection of other Team types which provide an exciting internal product to accelerate delivery by Stream-aligned Teams. Three different interaction modes between Teams: Collaboration: It is about working together for a designated time to discover new things (APIs, practices, technologies, etc.). X-as-a-Service: Defines the scenario when Team A provides, and Team B consumes something “as a Service.” Facilitation: It happens when a Team helps and mentors another Team.   Mentioned in this Episode: Team Topologies: Organizing Business and Technology Teams for Fast Flow, by Matthew Skelton and Manuel Pais “What is a Thinnest Viable Platform (TVP)?” User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton and Peter Economy   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!  

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"

This week, Dan Neumann is joined by his colleague Mike Guiler In this episode, they answer a listener's question about how they might approach joining a new company. Times of change are exciting and create new possibilities. The next question is: "how might I approach it?" Mentioned in this Episode: Team Topologies: Organizing Business and Technology Teams for Fast Flow  Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to Podcast@AgileThought.com or Tweet @AgileThought using #AgileThoughtPodcast!

Co czyta CTO? W tym odcinku, nagranym w trakcie wakacji podzielilśmy się swoją listą rekomendacji jeżeli chodzi o książki, rzeczy do słuchania i różne inne źródła. Słuchacze aktywnie dorzucili swoje pozycje. Przygotuj swoją biblioteczkę ... lista nie jest krótka. Warto zapisać link do tego odcinka i wracać do niego, gdy potrzebujesz czegoś do przeczytania! Link przyda się też jako ściąga do listy prezentów dla ludzi w "tech"!~ ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~  ~ ‼️Sharing is caring ‼️ Uważasz, że kogoś ten temat mógłby zainteresować, podziel się tym linkiem

Is development becoming obsolete? We invited Miku and Pauliina to talk about software engineering — how the roles have been shaping, what the current trends and challenges are, and how we can shape the future of our profession. Tune in and join our semi-practical, semi-philosophical conversation.GuestsPauliina started her career as a communications consultant, but slowly life took her back to her childhood hobby - coding. She moved all the way to Australia to study at a coding bootcamp and has now been working as a software developer for over 5 years. She still thinks it was the best decision of her life. What she loves most about coding is how tangible it feels to build software one piece at a time and how rewarding it is to solve problems with technology. In her free time,, you will find her on a yoga mat or wandering in a forest.With nearly 20 years of experience, Mikael is a passionate, future-oriented technology leader with a cultivated interest in cutting-edge technologies and the methodologies of creating exceptional digital products. While he currently has limited time to actually code at work, he still does it as a hobby. Mikael is a fan of functional programming and loves exploring new tech, surfing, and cooking.Mikael's core expertise and interests are the design of technology organizations, technology strategy, business, and digital strategy, innovation, software and enterprise architectures, modern process methodologies, modern leadership, self-organization, systems thinking, data, and AI.HostAnna Fröblom is a great programmer, problem-solver, hobby photographer, lego enthusiast, and simply a nice person.Guest HostRoss Langley is a human-centered designer from Reaktor Helsinki. He loves helping teams excel in challenging environments. Ross shines when he does concept modeling, validates ideas, or makes celebrity impressions. References:Malan, Pais, Skelton: Team Topologies: Organizing Business and Technology Teams for Fast FlowCagan: Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group)Forsgren, Humble, Kim: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology OrganizationsGoogle Cloud 2022: Announcing the 2022 Accelerate State of DevOps Report: A deep dive into securityAbout ReaktorFork Pull Merge Push is a podcast created for developers by developers. It's brought to you by Reaktor,  a creative technology partner for forward-thinking companies and societies, based in Helsinki, New York, Amsterdam, Stockholm, Lisbon, and Tokyo.We at Reaktor are looking for exceptional talent and new friends. Check our open positions and apply now!

Martin has vast experience in getting things done with technology teams. In this conversation he shares what he has learned from his background at Klarna and H&M and more.  We talk about the steps to structuring a productive, remote team Daily stand-ups; great communication; measuring the unsaid team sentiment and how to balance remote work for people's different environments and stages of life. (Think balancing your laptop on the end of your bed vs. a home office overlooking your own lake...). "Just because tech *can* do something, doesn't mean it should" combines with his learning point of being clear on what outcomes you want rather than focusing on the functionality you'd like. Find Martin here: https://www.linkedin.com/in/martin-ganeteg-5969842/   -------- Get First aid for new managers here: https://practical-leadership.academy  

Whether you're in engineering, working alongside engineering teams, or you're just looking to uplevel your career in tech - I have a treat for you this week, my love!  Today, I invite three extraordinary and powerful leaders in the tech industry to talk about their unique experiences building great engineering teams. Join us as Jossie, Kathryn & Sushma share their approaches to getting ahead as engineering leaders, and how to build better relationships with these important teams in your own organization.  Ready to learn more about how engineering interacts with the rest of the organization - and gain some powerful leadership tools along the way? Let's go to the show!  We dive into: How these incredible women became VPs of engineering - and why they do what they do! 4 key metrics you can use to highlight how engineering is moving towards company goals How to make sure the engineering team supports business strategy (even when the rest of the organization may not fully understand what they do!) One VITAL piece to building good communication between engineering and the rest of the organization Their BEST advice to help you on your path to VP! And so much more!   **Useful links** Book recommendations: Accelerate: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren, Jez Humble & Gene Kim Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton & Manuel Pais If you are ready to uplevel your career, and get a boost (and a salary bump) by shortcutting your way to success, find out more about Toni's Coaching at: https://tonicollis.com/workwithtoni  Alternatively, go straight ahead and book a free Discovery Call, to find out more and discuss the type of support you would most benefit from: https://bit.ly/DiscoverToni  Catch the show notes, and more details about today's episode here: https://tonicollis.com/episode121  Join the Leading Women in Tech community in Slack where we discuss all-the-things for women's tech leadership, covering everything from early-career leadership to C-level executives.

Já falamos bastante aqui no próprio BDUX sobre o crescimento do mercado, inclusive no Good Morning UX, mas além dos tiems crescerem começamos a ser pressionados, corretamente, a entregar valor real para a emrpesa e mercado. Com isso tem surgido uma infinidade de ferramentas, técnicas, métodos e cursos que nos ajudam a montar um time de design, fazer a tal entrega de valor, como construir o produto certo, resolver os problemas e dores dos usuários. A real é que temos algumas fontes que vem com foco em times ágeis, produto, etc. Organizar times, processos e garantir entregas com qualidade é um desafio em qualquer cenário. Isso tudo pode e deve ser utilizado. Além obviamente de livros e conteúdos de outros designers que já passaram pela experiência. Como recrutar? Como gerenciar? Como cobrar? Processos são importantes, mas eles não podem passar por cima da cultura. Aliás, nada que você for tentar pode ignorar a cultura da empresa e a maturidade dos times envolvidos. Fontes: http://blog.plataformatec.com.br/2019/04/como-estruturar-os-processos-e-as-praticas-de-times-ageis/ https://www.gupy.io/blog/como-organizar-times-de-startups https://itforum.com.br/noticias/4-passos-para-a-criacao-de-um-time-agil-de-sucesso/ https://designteam.com.br/bom_dia_ux_post/how-can-a-design-leader-design-an-org-peter-merholz-good-morning-ux/ https://designteam.com.br/bom_dia_ux_post/what-is-ux-strategy-and-how-apply-it-with-jared-spool/ Livros indicados: Fundamentos da Liderança em Design: Para quem quer liderar times de Design https://amzn.to/3ADl1cn Metricas Ágeis: Obtenha Melhores Resultados Em Sua Equipe https://amzn.to/3KbGLze First Designer In: From Just Hired to Minimum Viable Design Team in Five Weeks (English Edition) https://amzn.to/3Akybd8 The User Experience Team of One: A Research and Design Survival Guide (English Edition) https://amzn.to/3pz5QdN Org Design for Design Orgs: Building and Managing In-House Design Teams (English Edition) https://amzn.to/3RizErh Team Topologies: Organizing Business and Technology Teams for Fast Flow (English Edition) https://amzn.to/3AfJB1F Qual a sua opinião sobre isso? Esse é o Bom dia UX, um programa feito ao vivo no canal do youtube do Design Team, toda quarta-feira de manhã às 7 horas. * Acesse nosso site * http://www.designteam.com.br * Junte-se ao Telegram * https://bit.ly/3dOea2Y * Assine nosso podcast * https://anchor.fm/designteambr

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

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

Blaine Hurst has spent a career in executive leadership, including as CEO of Panera Bread and, before that, as President of Papa John's Pizza. He joined Matthew and Vivek on this episode to talk about his surprising path from an early career in computer science and technology into the food service industry, what he's learned about healthy teams, and why keeping the mission central is so vital.Links from this episode:Blaine Hurst (Panera Bread)@BlaineHurst (Twitter)Blaine Hurst (LinkedIn)The 4 Disciplines of Execution (Sean Covey)Review Leading Forward in Apple Podcasts and let us know what you think of the show.Keep up with the show on social media: Twitter // Facebook // Instagram

Discussing what might drives team structure in Enterprise IT.

Discussing what might drives team structure in Enterprise IT. The post HS016 Team Structure for Technology Teams appeared first on Packet Pushers.

Discussing what might drives team structure in Enterprise IT. The post HS016 Team Structure for Technology Teams appeared first on Packet Pushers.

Discussing what might drives team structure in Enterprise IT.

Discussing what might drives team structure in Enterprise IT. The post HS016 Team Structure for Technology Teams appeared first on Packet Pushers.

Discussing what might drives team structure in Enterprise IT.

Delegation not only gets work done, but it's also a strategy to be implemented for leading your team. * Without a delegation strategy, you will drift in your delegation methodology and in your leadership. * Without a delegation strategy, you will delegate to everyone the same way or you won't know how to delegate differently based on skill, experience, and motivation. * Without a delegation strategy, you will miss out on an effective tool to coach your team and increase their skills and experience. In today's episode, I share 3 Delegation Strategies for Leading Technology Teams.

The panel puts their heads together to talk about how to bring DevOps practices into a work situation based where they're not implemented. They discuss the various pro's and con's of specific practices and how to get people on board with adoption. Panel Charles Max WoodJillian RoweJonathan HallWill Button Sponsors Top End DevsRaygun | Click here to get started on your free 14-day trialCoaching | Top End Devs Picks Charles- Shadow Hunters | Board Game | BoardGameGeekCharles- CampfireJillian- DragonbreathJillian- Bath & Body WorksJonathan- Team Topologies: Organizing Business and Technology Teams for Fast FlowJonathan- LexxWill- Cracking the Coding Interview: 189 Programming Questions and SolutionsWill- DIY DevOps Projects to build DevOps skills NOW! - YouTube Contact Charles: Devchat.tvDevChat.tv | FacebookTwitter: DevChat.tv ( @devchattv ) Contact Jillian: GitHub: Jillian Rowe ( jerowe )LinkedIn: Jillian RoweTwitter: Jillian Rowe ( @jillianerowe ) Contact Jonathan: Jonathan HallGitHub: Jonathan Hall ( flimzy )Twitter: Jonathan Hall ( @TinyDevOps ) Contact Will: DevOps For Developers

Tribe Property Technologies CEO Joseph Nakhla joined Steve Darling from Proactive to share new the company has partnered with Pensio Global which is a credit risk management and rental income guarantee company, to deliver unique products for both landlords and tenants. Nakhla telling Proactive these products include lease co-guarantees that pay the rent to landlords for tenants who lose their job; as well as rent guarantee programs for newly built rental-purpose buildings, and landlords.

Are you building a tech startup without having a tech background or prior tech experience?Our guest, Nelly Yusupova, is a CTO with over 18 years' experience leading companies to technical excellence. A start-up tech advisor, outsourced CTO, and the creator of TechSpeak for Entrepreneurs, Nelly is on a mission to help entrepreneurs minimize technology mistakes.Through her online masterclass TechSpeak for Entrepreneurs, she provides the roadmap to successfully manage technology teams and projects, without being technical or knowing how to code.Just recently included in Fast Company's, “League of Extraordinary Women,” Nelly has been at the forefront of the women's online movement since 1999 and is a Wall Street Journal's “Woman on the IT Fast Track.”Nelly is a speaker and presenter for many organizations and major industry events including: Women's Enterprise Center, NY Entrepreneurs Business Network, Small Business Summit, BlogHer, Social Media Jungle, Mom 2.0, BlogWorld, and has been featured in INC Magazine, NBC Today Show, Fast Company Magazine, SmartMoney, TechRepublic and more.Nelly dives deep into what you need to know to successfully lead your tech team and tech projects even though you're a non-tech founder!To grab Nelly's generous 15% discount on her classes, visit: https://techspeak.co/classes and use code Startup15.To learn more about TechSpeak for Entrepreneurs, please visit: https://techspeak.coBe sure to follow and connect with Nelly on social media:Twitter: http://twitter.com/DigitalWomanInstagram: http://instagram.com/DigitalWoman LinkedIn: http://linkedin.com/in/DigitalWoman Facebook: https://facebook.com/digitalwoman 00:00 - meet Nelly!06:00 - how Nelly fell in love with tech (BTW: she didn't know how to turn the computer on in her first day of computer science class!)12:40 - the day Nelly fell in love with entrepreneurship15:55 - be brave enough to say YES - Stitch That On A Pillow!26:30 - ideal example of reiterating as a founder - Andelicious Moment30:00 - meet TechSpeak for Entrepreneurs41:20 - TechSpeak's 10 Step Process for creating a tech product47:20 - how to avoid scope creep48:44 - why you need to use agile product management vs. waterfall product management50:00 - the biggest mistake founders make when outsourcing tech product management 57:20 - outstanding Founder Advice: I will figure things outThank you for carving out time to improve your Founder Game - when you do better, your business will do better - cheers!Ande ♥Ande Lyonshttp://andelyons.comANDELICIOUS RESOURCES:JOIN STARTUP LIFE LIVE MEETUP GROUPGet an alert whenever I post a new show!https://bit.ly/StartupLifeLIVEAGORAPULSEMy favorite digital marketing dashboard is AGORAPULSE – it's the best platform to manage your social media posts and presence! Learn more here: http://www.agorapulse.com?via=ande17STARTUP DOX Do you need attorney reviewed legal documents for your startup? I'm a proud community partner of Startup Dox, a new service provided by Selvarajah Law PC which helps you draw out all the essential paperwork needed to kickstart your business in a super cost-effective way. All the legal you're looking for… only without confusion or frustration. EVERY filing and document comes with an attorney review. You will never do it alone. Visit https://www.thestartupdox.com/ and use my discount code ANDE10 to receive 10% off your order.SPONSORSHIPIf you resonate with the show's mission of amplifying diverse founder voices while serving first-time founders around the world, please reach out to me to learn more about making an impact through sponsoring the Startup Life LIVE Show! ande@andelyons.com.STREAMYARD OVERLAYS AND GRAPHIC DESIGNNicky Pasquierhttps://www.virtuosoassistant.co.uk/Visit Nicky's CANVA Playlist: https://www.youtube.com/playlist?list...Nicky's Canva Presentation Playlist: http://bit.ly/Canva_Present_PlaylistGET VIDEO/AUDIO TRANSCRIBED WITH OTTER.AIhttps://bit.ly/StartupLifeOtter CONNECT WITH ME ONLINE: https://andelyons.com https://twitter.com/AndeLyonshttps://www.facebook.com/StartupLifew... https://www.linkedin.com/in/andelyons/ https://www.instagram.com/ande_lyons/ https://www.pinterest.com/andelyons/ https://angel.co/andelyons TikTok: @andelyons

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/

Recording date: July 22, 2021John Papa @John_PapaWard Bell @WardBellDan Wahlin @DanWahlinCraig Shoemaker @craigshoemakerJem Young @JemYoungBrought to you byAG GridNarwhal Visit nx.dev to get the preeminent open-source toolkit for monorepo development, today. Resources:Front End Happy Hour podcastFront End Masters training coursesjQueryBackend for the FrontendNode.jsNetFlix tech blogThe Witcher TV seriesWeb AssemblyReactNetFlix Engineering on TwitterNext.jsRegression TestingGraphQLNode.js LTS and release version strategiesRyan Burgess on TwitterWorking in Developer Relations with Kim MaidaWhich department does DevRel belong in? By Kim MaidaTimejumps01:13 An award for subtitles04:05 Guest introduction05:25 Understanding modern technology07:28 Sponsor: Narwhal08:13 Working on the backend for the frontend13:14 How do you evaluate when to do betas?15:22 What's a way to incorporate new technology?21:02 Do you have challenges with managers?22:52 Who's behind the Netflix Engineering team on Twitter?24:19 How do you feel about developer relations?31:33 How should someone prep for an interview for a job?42:42 Sponsor: Ag Grid43:42 Course on Front End Masters45:54 Final thoughtsPodcast editing on this episode done by Chris Enns of Lemon Productions.

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/

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.

We catch up with the two co-authors of Team Topologies: Organizing Business and Technology Teams for Fast Flow to hear about their ideas on enabling enterprises to become more effective at software delivery — and the influence of Conway’s Law, team cognitive load and responsive organization evolution.

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.“

CEO, Rich Theil, joins Coruzant Technologies for the Digital Executive podcast. He shares his story on his journey to make businesses and processes better and smoother using his prior experience as a Chief Information Officer.

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/

Guest: Jenn Knight - Co-Founder & CTO @AgentSync (Formerly @Stripe, @Dropbox, @LinkedIn, @Bluewolf) Guest Background: Jenn has worked with hypergrowth businesses like LinkedIn, Dropbox, and Stripe. At LinkedIn (IPO 2011, Acquired by Microsoft for $27B in  2016) Jenn was the Manager of Solutions Architecture. After 3 years at LinkedIn, Jenn joined Dropbox (IPO in March 2018, $10.5B Valuation). She was there for 3.5 years where she was the Head of Business Technology, managing technical teams spanning financial systems, sales systems, web services (CMS), integrations, and business intelligence infrastructure. Over an 18 month period, she scaled her teams from 15 to 35 people. Jenn has since joined Stripe ($20 Valuation, $785M Raised) for the last 2 years as the Head of Internal Systems. Guest Links: LinkedIn Episode Summary: In this episode, we cover: - The Playbook for Building Business Systems, Tools, and Technology Teams - Mindset, Structure, Chronology, Methods, and Best Practices - The Internal Business Technology Team Superpowers @Stripe, @Dropbox, and @LinkedIn - How to be an End-to-End Process Thinker - Stakeholder Management Tips & Advice Full Interview Transcript: Naber:  Hello friends around the world. My name is Brandon Naber. Welcome to The Naberhood, where we have switched on, fun discussions with some of the most brilliant, successful, experienced, talented and highly skilled Sales and Marketing minds on the planet, from the world's fastest growing companies. Enjoy! Naber:  Hey everybody. We have Jenn Knight on the show today. Jenn has worked hypergrowth businesses like LinkedIn, Dropbox, and Stripe. At LinkedIn (who IPO'd in 2011 and was acquired by Microsoft in 2016), Jenn was the Manager of Solutions Architecture. After three years at LinkedIn, Jenn joined Dropbox (who IPO'd in March, 2018 and they have a valuation of $10.5 billion). She was there for three and a half years where she was the Head of Business Technology managing Technical Teams spanning Financial Systems, Sales Systems, Web Services, Integrations and Business Intelligent Infrastructure. Over an 18 month period, she scaled her teams from 15 to 35 people. Since Jenn has joined Stripe (who has a $20 billion valuation on $785 million capital raised). For the last two and a half years, Jenn's been at Stripe as the Head of Internal Systems. Here we go. Naber:  Jenn Knight. Awesome to have you on the show. How are you? Jennifer Knight: I'm doing well. Thank you for having me. Naber:  Awesome. Thank you for coming. It's amazing to have you. I'm excited for so many reasons. we know each other well and we've worked together in the past. But your brain, and getting to share that with people in the audience is really exciting for me. it's hard for me to contain some of the excitement with my emotions. But, I'm excited to go through some personal stuff today. So go through and dive into who Jenn is as a person. Start from where you grew up, and some stuff from your childhood. So people can get to know you a little better, like I do. And then, we'll hop into some professional stuff. Why don't we just get started. So, you grew up in San Francisco, you're smarty pants. Anyone that has met you for more than a minute knows that, but it's written in you DNA as well as your GPA, as well as your accolades. Walk us through, a few different things about what Jenn was like as a kiddo, and what it was like growing up with as Jenn Knight. Jennifer Knight: Well, I grew up north of San Francisco, in Sonoma County, in Petaluma, which was a ton of fun. It has changed a lot now, but in the early nineties, it was very rural still. Get on your bike, ride into a field, find some mice, hang out. I was a pretty nerdy little kid. I grew up in a house that didn't have a TV. My Dad is an engineer, so we were always puttering on things. He had a garage full of tools, and we're always being taught new things. I was always encouraged to be outside or around. Got a computer pretty early, which was neat. My brother and I, very nerdy, would love to do things like see how many files we could delete to destroy the operating system, and then rebuild the thing. Built a few computers growing up, but really enjoyed that part of life. Yeah, I was a kid who had a little bit of a different experience growing up just because of the nature of my house. And spent lot of time outside, and a lot of time building and poking on computers, and just hanging out. Naber:  Cool. Were you a particularly social kid? Jennifer Knight: That's a funny question. I always had good friends, a few good friends. I think I'm still that way. I'm someone who finds people that resonate with me and I keep a few close. I really enjoy the company of others, but I've always been someone who has had two or three really close friends, than whole big group. And growing up I had to change schools in middle school. And so at 12 years old I had to move across to a school across town. And that taught me one that you can make new friends but was pretty scary I think at the time. So you get close to people in elementary school and then didn't get a chance to stay friends with those people. I had to make new friends at 12, which was great in the sense of it taught me that you can, and you can survive. But it definitely meant that I had a few folks that I kept close. Naber:  Cool. I like it. A small, very close circle. And you said you were always building things, or tinkering, and having some nerdy fun. Tell us about a little bit of the nerdy, fun hobbies that had. Jennifer Knight: I think, I actually laugh when I look back on this...A very good example of this is my fourth grade science project was about different forms of energy, and it was about potential versus kinetic energy and the conversion. So my Dad had me worked with me to solder a little, wind mill thing that was powered by candles. That might give you a good picture of what my house is like. And then we did things like gardening. That was always fun in the summer. Petaluma was a great place to grow a garden in the backyard, so my parents did that. Just those kinds of projects. Those are the ones I remember the most, I think partially because you get pictures of them, and they're the stories that get told. But there were always a million little things we were playing around with. Naber:  Yeah. Cool. Love it. That's great. And let's see, quick stop on high school. What was high school like for you? Jennifer Knight: High School was a lot of fun. I wanted to get out of Petaluma. I knew that that wasn't where I wanted to be, and I knew I wanted to go somewhere for college. In my family education was really important. So, all growing up it was, you're going to go to school, you're going to do well. You're gonna learn a lot. You're capable of learning a lot. You're very smart. Put your head down and learn. Go get opportunity. So that was just the ethos of my growing up. One thing I will say is my parents were not obsessed with grades, they didn't push me to be perfect. I weirdly pushed myself, and at some point they were like, you need to calm down a bit. But high school was a lot of fun. I had a really close, like once again, handful of very close friends. We all encouraged each other to go after where we wanted to go next. Really great study groups. It was also for me a hard time. My Mom was sick when I was growing up, and she got really sick again when I was about 16. So that was hard at home. My parents dealt with it really well, but I had the mix of trying to be the kid who was studying and then dealing with some things at home. So I think once again, close knit group of friends is really important for me because they were people that I could lean on and really knew what was happening in my life at. And the rest of it, was just getting through it. Naber:  Interesting. Some things a lot of kids that age don't necessarily have to deal with obviously. So you wanted to get out of Petaluma, but you were trying to be perfect so you could have all the opportunities in the world to do that and chase your dreams. Your dreams brought you to Beantown Boston. So tell us about going to BU. Tell us about why, and what were like at BU. Jennifer Knight: Yeah, so, my parents had saved a bit for us to go to school, but couldn't go anywhere. So one of the reasons that studying was really important for me, was ultimately getting scholarships, and getting the opportunity to go to school. And I actually went to Boston site unseen. I'd never been there. I didn't know anything about the school. Yeah, it was funny. So they reached out to me, and they offered me a really amazing scholarship, and it actually brought the price of the college down to closer to what a UC would be for me. And so I was making a decision whether to stay in California, or go somewhere else, and my parents were very open to encouraging me to try something new. My Dad said...he always jokes that I was running away from them. He said to me, "Leave California now. If you don't like it, wherever you go, you can always come back. But if you don't leave now, you may never actually leave the state, and and you may not see what the rest of the world's like." So, I accepted to BU, and I had a choice for my parents to come with me for orientation or to help me move in. So my Dad came with me for orientation, and that was the first time I saw saw the school and saw Boston. Naber:  That's a very Jenn Knight thing to do. You're so adventurous and fearless. I love the courage and the fearlessness. It's cool. It's a good example. Jennifer Knight: Looking back on it, it's funny, I think I was mildly terrified. But I really wanted to study international relations, and or something along that, and the UC schools that I was looking at only had international economics, and I'm more interested in people problems than technical problems actually. So BU had an amazing international relations school, and that was ultimately what encouraged me to go. Naber:  Awesome. And international relations. And you also studied French in for a year in France, correct? Jennifer Knight: I did, yeah. So I was a international relations major. Foreign Policy and Security in the Middle East was the focus of my studies, but I also did a minor in French. Naber:  What was your experience like in France? Jennifer Knight: It was an amazing experience. Once again, it's a different time now. At that time there were cell phones, but not really. There was internet, but not really. I didn't have a laptop with me that could connect to the internet very often. So it was an interesting experience at 19 to get on a plane and fly all the way across the world, and then get a calling card and get on a pay phone at seven o'clock at night to call your family, to handle the time zone difference. I was ready in that I had studied French in high school. I was also not ready in that I had not studied it for a semester before I went. But I had an a pretty incredible experience on my way over there. Being from the West Coast, the program that my school ran didn't actually coordinate my flights because they coordinated everything for kids on the east coast. So once again, I was put on a plane, and my parents said good luck. And when I landed in Paris, I had no idea that Charles de Gaulle was kind of a mess. I was running through the airport. and I saw the group that I was eventually gonna study with being guided through the airport by an adult. And I was running for a gate, to miss my flight. But I got to the gate, and right behind me showed up a woman who's about my age, and she had actually been studying English and in the US during the summer. And I had no idea what to do. And she just grabbed ahold of me, and she took me to the ticket table, and she handled everything. And we went to a different airport, got on a flight together to Leon. And then her parents drove me to Grenoble with her because they were going home. And it was totally surreal experience, but also one that I think back on a lot that the world is actually a very generous place, and it's a very kind place often, if you're open to it. And I know it has its rough edges, but at a young age being able to travel over there and see that people are people across the world, and people are willing to help, was really incredible start to the journey. And that things don't always go perfectly, but they will end well, was something that was fun. And then it was a crash course in trying to navigate another culture, which I've always looked back on and really appreciated what the program gave me. So it was a fun year. Naber:  Very cool. Good story too. Good story. I always feel better when I talk to you, Jenn. You keep such an optimistic, positive light. So you studied at BU. Walk us through your first couple of gigs, up until before LinkedIn, so up through Bluewolf, and let's do some hops. Explain it. Typically we go through a few different things within those gigs. What I want to do is get to LinkedIn, Dropbox, and Stripe and talk through a couple of examples, and some of your superpowers, and we'll get there. But anyways, why don't you hop us through just so we have a good understanding of where you came from professionally. Hop us through some of those gigs and what you're up to. Maybe in like maybe like five, seven minutes. Jennifer Knight: Yeah. Seeing as I studied a bunch in high school, I actually entered college as a sophomore, finishing in three and a half years because I took a bit of extra time to go to France. So I graduated actually December 2006. For family reasons with my Mom being sick, and not being very clear how long she was going to be doing well, I decided I wanted to come back to the west coast. I had the most useless degree on earth to come back to the west coast. There, there is very little to do with international relations with a focus on the Middle East in San Francisco Bay Area. So I came back had to figure out what I was going to do. And I ended up just on craigslist looking at jobs. That was the way back then, that and the newspaper. Which was 2007, and it sounds crazy, but that's the truth. LinkedIn was, I suppose, kind of a thing, but it was very, very small, not really a thing. It's just starting out. Right. Naber:  It had volume of users, but not a lot of density and a lot of engagement. So it's just less useful at that point. Jennifer Knight: Yeah. So I just applied, I mean, toeverything I could. And then I ended up getting a job as an Office Manager at a solar company in Berkeley. And I, with my college degree, went and answered the phones and opened to the mail. But it was the thing that afforded to me to get my first apartment, and my first foray out into the world. It was a great community of people. It was an opportunity for me to be in an environment where I could just see how I could help. And so I learned as much as I possibly could. I had a lot of fun working with the outsourced IT guys who would come in and help with the servers. And then, we hired a Director of IT, and he was a bit overwhelmed and he asked me if I wanted to help him Administer Salesforce, and so I started doing that. I was there for two and a half years. The company's split, part of it was sold off - the residential was sold off, stayed with industrial side, learned Salesforce development. I was quite lucky in that I became a Salesforce Administrator right before Salesforce opened up as a platform. And then my boss at the time taught me how to program on the platform. It's very similar to Java. Apex is Salesforce is language. So I got to iteratively roll into this platform as it was growing. And I was one of the first 500 administrators certified, which is very...I look back on it, and it's a nerdy moment in that...but just a good timing moment. So I was doing that, but I was pretty stuck. And after two and a half years, I was pretty burned out actually. When the company split, I was the only person doing my role. And I enjoyed a lot of my coworkers. I have, actually, one of my best friends from that job. But I just wasn't loving it anymore, and I was too tired actually to really look for what was next and know what I wanted to do next. So I decided to take six months off, and this was in 2008-2009. So everyone thought I was out of my mind. But I did, and it was really fun. I moved to San Francisco. I worked in nonprofit, so I actually did nonprofit work at, Salesforce nonprofit, at a women's community clinic and at an urban garden. So the women's community clinic in San Francisco and at the place that does urban gardening in Oakland. Helped them set up their Salesforce instances. The urban garden one was amazing. We use Salesforce to track plants, and pests, and tools, and acreage, and all sorts of crazy stuff that you wouldn't imagine. Yeah. So I did that, and when I moved to San Francisco, Craigslist again, my craigslist roommates - one worked at Salesforce as a Sales rep and one worked at Bluewolf as a Sales rep. And my roommate Chris, who worked at Bluewolf said, hey, we're looking for developers. I don't think you want a full time job right now, but do you want to come contract with us, and check it out? ...did some contract work, and then after probably four months I decided to join full time. And that was the first time...and one of the reasons I did it, that was the first time I got to figure out if I was any good. And when you do something alone, you have a sense like I knew I could make things work, I knew I could solve the problem, but I had never been around other Salesforce developers where people with technical backgrounds, to find out if I was actually good at it or not. And I had an amazing group of people and an amazing support system at Bluewolf to help me grow and some great mentors there. So I couldn't be more thankful for them. They were extremely patient as I was plotting through things, and then also threw me at some really, really tough challenges. So I was doing a lot of the development for west coast projects, by the time I left. Did that for about a year and a half...um, I am not a consultant. I love the design. I didn't love flying in, building something, and then leaving it. I also didn't love being on a plane all the time. So I hadn't really known that I was going to do with myself, but I put my profile up on LinkedIn, and then LinkedIn found me on LinkedIn. And that's how I ended up at LinkedIn. Naber:  Nice. Awesome. Okay. We've got to LinkedIn. That's a really good story. You got to work on some, excellent cool projects, while you were trying to figure out your actual depth of your prowess around this new set of skills you were learning. But it's probably also really stimulating for you because you're such a smart person. You're also trying new things all the time, and wanting to build. So I'm going to guess that was really stimulating to learn this whole new world of technical bricks that you could build with. Jennifer Knight: It was, it was a lot of fun. It also taught me that that skill set around Salesforce is something it can be really can be used anywhere. And it's something I talk about with my teams now. It's quite fun, and I think a lot of skills in a lot of different areas of the business are transferable, but if you want if you want to work at a small company, if you want to work at a big company, if you want to work in nonprofit, if you want to consult, there's kind of a home anywhere. And that is pretty liberating because you get to go pick your family, and pick where you want to be. Naber:  Cool. Love it. All right. So, give us a quick chronology of what your responsibilities were, and what you're up to at LinkedIn. And then I have a couple of questions for you to follow-up and dig into your brilliant mind a little bit. Jennifer Knight: So I joined LinkedIn as the first Salesforce developer, joined the team that was in existence. There were five at the time, and the were two of us who joined, myself and a woman who was also doing Salesforce administration at the same time. So we grew to a team of seven. I still work with today, one woman from that team. I could not be more thankful once again for what they taught me in terms of how to approach an environment and how to approach work, just work. I was the youngest by far, and I was coming down from San Francisco, and I'd come from...Bluewolf was a really young environment as well. So that ethos of chaos, and running around, and experimenting, and trying new things, and to go from that to a place where people were far more measured, I hadn't seen that before. It was, yeah, we can do this. Like we're gonna think about it, we're gonna make a plan, and we're gonna go after it. It was really intense. We were building a ton, but it was very focused and measured. and it wasn't all over the map, and that was both due to the team that I had around me, and also a lot of the partners that we had at LinkedIn. So I joined as a developer, and then I helped grow out the Salesforce Technical Architecture and Development team over the course of my three years there. And so I was responsible at the end for our project work. We restructured the team, our lead structure the team as a Plan, Build, Run. So PMO, a business analyst doing the business requirements gathering, build was my responsibility - so those were the big project work, and then run was kind of the day to day administration, and keeping the lights on, minor enhancements, things like that. My team would do both technical development, but also if there was a administrative component of configuration, we might partner with an Admin to do that. Naber:  Nice. Very cool. One of the questions I have for you, and this is actually a good segue into that...you had a lot of experiences, at a lot of different teams, also built a lot of differe teams with LinkedIn, Dropbox, Stripe. You can go across those if you need to to pull experiences. But, is that the typical anatomy of a Internal Business Systems and Tools team? Or, if it's not, what is the typical anatomy, and can you give us a little bit of a breakdown? Jennifer Knight: Yeah. So those functions are the three behaviors that you see across the board. Alex, who's my Manager at Dropbox, said way back in the day...it's people, process, technology. And that is true always. So do you have the partner, does the partner know how their processes articulated? Do you understand how to reinforce, and support, or automate, or speed up, or whatever you're trying to achieve, that process with technology? And then there's the iterative, like, continuing to keep that alive and continuing to improve it. I think about the world in that framing all of the time now, that's how we approach it. And so our team is staffed for each of those areas. The plan side is always about, let's sit down with the people we're partnering with, and let's understand their process. Now that team on my team is responsible for really understanding the business partners' process, and then starting to think about who do we need to engage with from the technology side to support that process? Then the build side is the actual team that's saying, okay, now I've got the process. How do we empower this with the tools we have? Or what tools do we need to go buy? And run, of course, being the day to day maintenance. Those functions always exist. They are not always carved out as specific teams because depending on size, you just don't have the resources. When I joined LinkedIn, each one of us was a little mini plan, build, run. There were only seven of us, and we were supporting a lot. And so we would go sit down, and get the requirements, and then we would go off, and going to build something, and then you're the one who kept it alive. And and then eventually when you got a little bit burned out on that area, you'd switch it to one of your other team members. So I ended up with Sales Development work because April was done thinking about that problem...and then we've cycled through. But those, those pillars exist. They just evolve. And how you structure the team varies quite a bit. There is not a perfect way to do that. I think it depends a lot about where the organization is, what they're valuing at the time, and then who do you have on staff. But the core behaviors that remain the same across LinkedIn, Dropbox and Stripe. Naber:  Okay. That's awesome. That's a really good answer. Thank you so much. And while we're on LinkedIn, can you explain,what LinkedIn does extremely well from a Systems, Tools, Building leverage resources? And when you do that, could you lean into some of the things you do really well within the respect of Sales and Marketing? Because I think the audience is going to want to want to understand each one of these businesses, both what they were good at, why that's important, and how do they do it? Jennifer Knight: Yeah. So it's been a few years since I was there, so I'm sure it's evolved. But one of one of the overarching things that I remember from that time is actually just Focus. I think LinkedIn did very well...and as a partner to it, I appreciated it a lot after I left. There's always thrash. Nothing's perfect, the business evolves. Part of my responsibility is to be flexible enough to accommodate the fact that business has changed. They chart a course, but it's not like...Product Development is exactly the same way. Factors change and they can change fairly rapidly. And so the needs of the business can change fairly rapidly. That said, knowing more now and seeing, having seen different environments, in the face of that, I'd say LinkedIn did very well on remaining focused and what the core objectives that they were trying to enforce were. And then systematizing those. And maybe doing some experiments on the edges of other like creative things that we could potentially do to drive the business, but making sure that we were focused on being excellent at a few things, doing those very well, and those being backbone things for the business. So it was the first time that I had to work on some of the end to end workflows around Demand Gen. And how do you think about that, and how are you optimizing that? And not about a lot of bells and whistles and not always about crazy experimentation. It was first let's get it right. We have a core business objective, and the objective is not changing. It's reduce the time to touch. Okay, let's go like nail that one to the wall. And then once we get that one done, we'll be find the next one, and we'll like nail that one down. And those are the focus areas that don't change, right? Even if your approach changes, or your markets change, they're just really core parts of how you want to operate a business. So that was something LinkedIn did very well. One of the reasons that I left LinkedIn though, on the system side, is that at the time that I was there we were very silo'd. So we had a lot of autonomy in the space that we operated in, in partnership with our Sales ops partners. But some processes are actually cross business units. And some Systems work best when they're integrated across. A good example of this is a CRM to Oracle. A CRM to an ERP. So Salesforce to Oracle, or Salesforce to Netsuite, or I mean, no one uses anything besides Salesforce. That's not entirely true, but, Dynamics to SAP, any of those. Those flows were something that were interesting to me, and I didn't have the opportunity to work on as much. We could influence it. We could encourage. We couldn't work on it as much. When I got to Dropbox, that was the first place that I was able to think about end-to-end flows. And that was an area...because I had the autonomy to go own those. So that was an area...I think LinkedIn did very well on the focus, focus in depth in a particular system space. But we struggled a bit on the cross Systems, from where I was sitting. This is not a universal picture, but but from where I was sitting. So when I moved to Dropbox, I got the opportunity to think more cross platform, and that helped smooth some of the edges across teams, which was a lot of fun. At Dropbox we were in a bit of a different mode, so we were doing a lot of crazy growth. Naber:  Awesome. This is good. This is a good transition. So ell us what you're doing with Dropbox. Jennifer Knight: So I joined there to do Sales Systems. It was still really early days. We were still hiring out our Sales operations team. And so, I at that point, learned the importance of the people process part. When you put technology first, it it proves to be a bit of a challenge. That one was...I learned a lot more about meeting my business partners where they were. I actually leaned more into some of the operations and business analyst part of my role. That was not what I was doing at LinkedIn, but at Dropbox by necessity, you're saying there's these three functions, I was doing plan and build and run. And as I hired my team out, I hired them to do run first, and then started building from there, so that I could figure out what the needs of the business were, and then try to make some educated decisions around what we were going to invest in on the technology side. We had a ton of fun and we were building from scratch. There are things at LinkedIn, even by the time I was there, that had become so complicated that you kinda didn't want to touch them. When I got to Dropbox, it was the first time I got to build an order to cash process. And had amazing partner, who was also new. He had never built it before, and he was coming from the finance side. And he was really passionate about making this a really amazing experience for people. And so we just partnered really closely together to make that happen and thought about how we did it end to end. We ended up over the course of probably two years, building a flow that I'm still very proud of, but it was very focused on these business objectives again. We wanted the experience of someone who was buying Dropbox through a contract, from a provisioning perspective, to mirror the experience of someone who was buying with a credit card. And that was our goal. So we set that as our goal, and then we also set a goal that along the way that we had as smooth as possible process with the Sales team, so that there was a lot of transparency about what was happening. Contracting, as some of you know, can be very complicated from the Sales side because there are legal people coming in, there's financial approvals, there is these multistep processes, and it can feel like it's taking forever and you have no idea what's going on. And then maybe the thing is signed, and now you don't know why your customer hasn't been given the Product because it's fallen into another manual process where someone has to go into some backend system. Or in the case of, and this was happening when I got there, you as a Sales rep now have to go into some backend system that you maybe don't fully understand and punch a bunch of buttons, and then hope that everything works out, and that your customer gets the Product they want. So we started once again with that focus, and we were really successful there. And those kinds of activities were the things that made my team successful. When we could find those focus areas, through our rapid growth, those are long pull items. They take a long time to get right, and if we kept focused on it, we were able to drive impact. So we were really...I brought that from LinkedIn, that focus in our space. Naber:  Hey Jenn, can we pause there for a minute?0 So let's use the order to cash process that you built. Can you walk us through the phases you go through to build the case for it, plan out the project, resource and manage the project, you've got to have Internal buy-in, then you've got to have pull through for people, actually making sure that they do what they need to do in the field and the business? Can you walk us through using that as an example for number one, what the steps are? And number two, from a Sales and Marketing or just really from a stakeholder perspective, what are some of the best practices in working with your team so that we can be better at doing that? As you go through it. Jennifer Knight: Yeah, so, let's break it down. How do we approach it? So now, one of the things that I think a lot about when I'm approaching these types of projects is how do we think about, an ask, and it's end to end? So one of the things about working with a Systems team is that we're ultimately accountable for the overall health of the Systems. And it's an interesting process for us to understand what a business is asking for. And then trying to put that in the context of either another set of business asks or the platform on the whole. And we also have situations where, there are multiple stakeholders. And order to cash is a good example of one. Demand Gen flows is another good example of that. Where as a business owner, or as maybe a Sales Manager, you're saying, in your inner mind thinking, it's taking too long for my teams to get contracts out the door. And then on the other side, the finance Systems team is thinking, like, I need to be able to ensure that this contract has the correct margins, or is feeling good about that. And the legal team is sitting there thinking like, what are these contracts terms? Let's make sure that those make sense for the business. So when we get these asks, part of what we think about on the more complicated asks, but even on the smaller ones, is who are all the players in this ask? What is it in the context of the larger process flow? And what is it in the context of the larger Systems? And that's something that I've had the opportunity to do a lot, and something I quite enjoy is how do we put this in, frame it out, and where it wants to be. The other thing that we need to do on our side, is thinking about how we get from point A to point B? And can we do it in one shot, or to your point, does it have to be a multistep process? And some of these things are quite complex, and so we're not going to win it all at once. So for us, starting with that problem statement and then working through with our business partners to get an alignment on the overall problem statement, what we ultimately want to achieve, and then agreeing on how do we iteratively get there. So what are interim wins along the way, or something that we benefit from, and we benefit from that partnership. In terms of resourcing and implementing a thread...I'd say it varies wildly depending on your circumstances. And Systems tends to be lagging behind the business. I have yet to be an environment where we weren't coming in two, or three, or four, six years late. It's just the nature of it. I think SaaS has this sheen on top of it, where you're just oh, I can just get a Salesforce account and probably have one person manage it, and it's going to be okay. Like it's easy, right? And actually, that's not wrong for a period of growth. But then when you start to get into these more complicated asks , or you start to get into Architecture questions, or you start to need to do development, then that tool becomes something quite serious to take charge of, and you need a team that is dedicated to it and experienced. I talked to folks about this a lot, where there's a whole period of time where you really just go experiment, like try to find your way. You don't need to hire a technical architect, and a full team, and everything right out the gate. But as your business starts to take off, and you start to have those needs, having an experienced person, who's seen it before, come in can really help you figure out what you want to navigate over the course of the next two years. So I think the resourcing thing, it's very varied. But if you want to tackle a more complex workflow, or you want to really empower a part of your business, that's the point where you start to think about these dedicated resources. And that's when I'm looking at it...for my team, when I come in, I look...survey the landscape. What are our biggest challenges? What do we want to think about? And what are our business partners talking about? What aren't they talking about that is probably going to doom us anyway. And then how do we line those up, and what kinds of resources do I need? Do I need a lot of business analysts? I might need a lot of business analysts right out the gate because I may need to spend time helping the business articulate their ask. That actually is a weird one. Often I work with business partners, and they're like, where's where's the admin? And where's the developer? And I'm saying, well those are execution folks and you want a partner right now is going to help you think through your process, and then make sure that we're reinforcing the right behaviors. So I'm going to actually get business analysts to define that. And then once we have those definitions, we have a bunch of different levers we can pull in terms of execution. I personally enjoy building teams that are really dedicated to the business. So we always have a mix of technical and BA full time on the team. Most of our projects, the big ones take 12, 18, 24 months. So you really want someone who is excited about the end to end and will build the continuity. But there are amazing, I worked for one, they're amazing partners who will come in and help you with resourcing. And we also pull that lever a lot on our team. But we do it in the context of making sure that we have the business requirements anchored, and we know what we're going after. S to kind of rewind back to your question to how we approach these things. What's important for us is understanding what we're solving, and being able to really work with the business to understand what their objective is. And if it's a project where we know it's going to take more than a quarter of more than a month to go after, making sure that that objective is something that is very solid. And that's what I was talking about earlier. Your objective being speed to lead, your objective being speed to contract...there's those kinds of objectives where even as time passes, we're going to keep after that. So we feel successful together over the course of the year or two it takes, and that we can measure our progress against it. The failure modes that I've seen is when we don't know what we're solving for and instead we get the kind of partnership where it's, I need this field, I need this thing. I've already solved it for you, justt go build it. We can do that. The probability that it will ultimately build into the kind of system or process that we both want together, is not super high end. On the margin, it's okay. We'll put in a field, we''ll kind of get going. We are here to empower and enable the business. And that's something that I talk about with my teams quite a bit. Like, our responsibility is to empower the business, and so we should understand where they're coming from and then try to get them there. Ideally we do it in partnership, and process, and Solution design. Sometimes we just have to crank. Naber:  Cool. So that was awesome. That was an awesome answer. I love it. It's almost like you read it out of a book, so, and maybe you wrote the book. So, one more question, and then we'll move on to Stripe because you already gave an example with the order to cash and that was great. Actually, two more questions. You mentioned a couple things that Dropbox was doing well, but what's the one thing you think they do extremely well from a Business Systems, Internal Business Systems, Business Systems and tools, leverage resources that they're building, etc. What's one thing they do world-class? Why is it important? And how did they do it? Jennifer Knight: An interesting question. Naber:  I mean, LinkedIn was focus, if you had to say it in a few words, Dropbox is obviously world-class at a few things. Jennifer Knight: So what I would say, and it was very different in its approach. When I got there, like I said, I started to do Sales Systems, and I got to grow in my role and pick up other teams. And so that's where I learned about Finance Systems, and ended up taking that over and building that. I'd say, maybe the flip side of what I was experiencing in terms of rigidity at LinkedIn, Dropbox had an environment where if you wanted to go tackle a problem ,and you could rally your resources around it, and you could get get the team together, we can go tackle the problem. And that was super, super fun. Obviously from a system side, I think that was a strength there, where we had once again the autonomy to go try to solve these problems and could get sponsorship to go solve these problems. If you could find your partner on the other side, and shake hands, and go after it we could move ourselves forward. And there wasn't resistance to that. There is a push to, however we get to a better place, let's get to that better place. Not about who you are, or what team you're sitting in, or my priorities versus your priorities, and how our roadmaps, and all that fun stuff. It was hey, we have this problem, and yeah, it's going to involve like three or four teams. Let's go figure out how to do that, and we'll get together, and we'll go agree on the problem, and we'll go solve the problem. And so we got that was one of the things that helped us build some of this really cool stuff and these experiences. And I'm really proud of the teams that did that because we thought about not ourselves. We thought about what we wanted to achieve both for our customers, but also our external customer experience, and we were able to drive to that. Even when it wasn't easy, even when we weren't aligned on exactly how we planned, that was something that we did really well there. And I think the culture of the company of empowering people within the company to go tackle those kinds of problems made that successful. Naber:  Do you have any idea how they did that within the culture? Maybe it was like one or two things that empowered people to be able to go solve those problems, and have that autonomy? Jennifer Knight: Yeah. And it was that way pretty much from day one. I mean, so there's flip side. Anyone can buy anything, right? Which, on on the system side, is its own like special crazy. But there wasn't like a specific tenant that we followed. There wasn't anything like that. The one thing that, Dropbox also did well, and LinkedIn had this, but they stressed it in a different way, was this concept that we called cupcake there, which is let's have fun together in this. And so I think that that empowering you to go out and like build community, build team, and have fun with it, was something that Drew and Arash really instilled. But there's not a like phrase or a specific behavior other than encouraging an environment of community, and communication, and through that you could go find your people, and find your path. Naber:  Yeah. Yeah. It makes a lot of sense, and it's extremely empowering. I felt that when I was at Dropbox as well. But cupcake, it's a really good thing to add. Like having fun while we're doing it, and working on cool shit together That's pretty cool. And that's a good place to start for all the stuff you want to work on versus just what's necessary or having a less creative mindset around it or vantage point? Awesome. All right, let's move on to Stripe. So yyou're leaving Dropbox, you're heading to Stripe. Why do you make the jump to Stripe, and what are you up to there right now? Jennifer Knight: So, it's been a progression of scope actually. Something that I laugh...I love my job because I get to be incredibly nosy and learn everything about the back end operating of a world. So at LinkedIn I got to learn so much about how Sales and Marketing think, what they prioritize, personalities, what's top of mind, what are the pressures, what are the challenges? I mean I knew it because I actually interviewed for some Sales jobs. I will never be a Salesperson. That is a such a hard job. And being on the technical side, I also appreciate the challenges of a technical world. But having the opportunity to be in with Sales teams and Marketing teams, and see how they think was something that I got to do at LinkedIn. I got to Dropbox, it was doing that and then I got the opportunity to learn how accountants think because I took over finance Systems. But it dropped off, and it's totally different world. I took an introduction to financial accounting after sitting in our first CFO's staff meeting because, I was like, I literally understand none of the terms. And I had an amazing partner in our revenue accountant. She was Sarah, she was patient person. I took over the finance Systems team, and we were working on a project. And she was describing debits and credits, and she's walking everything through with me, and she's willing to repeat herself as I'm stumbling through it. And I got to really understand that the pressures in their world are really fundamentally different than the pressures in Sales and Marketing. And they have external pressures with GAAP, and all of these other requirements that they're marching to. And so it got to learn about that. At Dropbox though, there was no mandate when I was there for the Business Technology team, we were slowly picking up pieces. And that was a fun way, but it was also hard. Sometimes, I was picking them up and they were healthy, and sometimes I was picking them up, and they were in an interesting place. So I'm going through that, and we were getting pretty big, pretty stable as a team. And then through a friend, ended up chatting with the CFO at Stripe, and they were looking for someone to lead Internal Systems. And that would be Finance, Sales, Marketing Support, People, the whole set. And that's what ultimately pulled me there. Also the fact Stripe earlier reminded me, in tone and approach, to LinkedIn in the early days. There was just something about it that, frankly, just felt familiar. And so that was why I decided to take that opportunity. Naber:  It's amazing how often someone's tone and what they say...when you've been at a few different tech businesses, you understand what good culture looks like. And you walk into a place, and you're having all these conversations when you're going through the recruitment process. It's amazing how often it comes up where, some version of, it felt like I was coming home, or it felt like I was going to something that I already knew, and I could see like where the movie was going. I've seen this movie before. I've directed it. I like the culture because it feels like coming home. A few of those different things happen a lot when you're making your third, fourth, fifth jump into a lot of these businesses, you start to get a really good sense of the bullseye for what you want as well. Maybe I'm just ahead of my skis on that, but it sounds like that's you felt as well. Jennifer Knight: Yeah, I think it's very true. At some point...So, I think everywhere you go, you learn, right? Every situation you're in, you learn. And you learn what works for you, and what doesn't work for you. And it's not even a judgment call. It's just part of who we all are, and what makes us happy. We find our people, and we're successful with our people, and hopefully we get an opportunity to meet many, many people of many different approaches. But I think at the point that you're talking about, for me, I think about the fact that...Of all the three places that I've been, that are roughly similar shape, they all have the same problems. So you're actually solving the same base problems very frequently. Naber:  Can you run through some of these as you're thinking about them? Jennifer Knight: Yeah, so, actually the reason I talk about order to cash is that's a problem for everyone, everywhere. It's a really complicated, really tough flow. It's hard to get right. It's really frustrating when it's not supported. And that's one that I've seen everywhere as a challenge. Data models, everyone gets their Salesforce data model wrong, everyone - like, it just, it happens. One of my first projects at LinkedIn was fixing the data model. One of my first projects at Dropbox was fixing data model. That can be really hard to fix. You can be like, oh, like that sounds simple. But you put the wrong data model in place, and then you lock it in place with a bunch of integration, and a bunch of automation, and a bunch of tooling. So by the time you get to the point where you need to roll it back, you have to roll back a lot to get back to that place. Naber:  You're duct taped, and scotch taped, and glued everything together. Jennifer Knight: Yep. So in order to do some data model work at Dropbox, it took me 12 months to rewrite a piece of code that was running on a python script under someone's desk, so that we could unlock it. There's that kind of work. The exercising the capability and the muscle around planning, planning your Systems change. You're often in an environment where everything is moving extremely rapidly, and on the process side you're iterating, and you're iterating and iterating. And then Systems don't always benefit from that rapid of iteration. There's a point where you have to be able to experiment outside the system. And when you get closer, you don't have to be perfect, but when you get closer to your ideal process, then you want to systematize it. So when a team like mine comes in, one of the big challenges we face is not actually a technical challenge. It's working with our partners to say, I know this feels like we're slowing down. We're not saying no, we're not saying stop, but we have to take a step back, and we have to once again put this in context, and figure out how we rationalize this within the system. And so that muscle, it's a challenge for everyone. It's a challenge everywhere. So that's one we face. These problems are very similar. And to your point when I'm making a decision now about where I want to go, you're living with this community and in this environment for a pretty significant portion of your day or your life, over the course of time that you're at that company. And everyone that has worked in tech knows it's not nine to five. If you've managed to pull 9-5, you're lucky. So you're probably spending most of your waking hours for several years, in that environment, and that being one that you feel supported in, feel excited to go to, that resonates with who you are. And where you are in that moment in your career and your life, I think is incredibly important. You can't always get it right, and you're going to find an environment that isn't the perfectly resonant one, but that's okay because then you learn aspects of that. And I think even there, you can take aspects of those environments, and take them with you going forward. But I agree. Especially the third or fourth time around. I think it's true. We always try to find a place where we feel might be a bit more like home. Naber:  Cool. Good one. All right, Stripe. Two things - why don't we start first with an example of a major project you're working on, and maybe you could talk through as much as you can give us without giving confidential information obviously, but what are some of the really cool major projects or one major project even to give us an idea of the type of stuff you're doing at these different companies. So you've given really good examples so far. Give us a profile of Stripe and some of the things you're working on. Jennifer Knight: Yeah, I'd say actually I'll do a little bit of a different answer than a systems answer because I always loved the technical stuff. The project that I'm working on at Stripe, and that's been the thing that's so top of mind for me over the last two years, is actually establishing the team. And establishing a team that is proactive and not reactive. Understanding what our actual needs are. So to give you a sense, my team when I joined, there were a few people in the organization who were part time working on Systems. And so the Systems were pretty underfunded, and that was one of the reasons they asked me to join. But putting language around what it actually looks like to manage these Systems well, putting language around the fact that we have huge gaps right now, and with that language also still keeping my team motivated, is that dance of being able to say we're here, we're growing, we're here to support you, and in the same breadth, I appreciate and understand that there is a laundry list of things that we were not able to do. And keeping that dialogue going, and figuring out how we grow up into Stripe as an organization, and how we try to close that, as rapidly as possible, close that gap. Which on the surface frequently looks like we aren't moving fast enough because some of these things, I mean they're around hiring, they're around team structures, they're around normalizing as a team. They're around that the thing that I just mentioned about learning how to partner with our partners, helping our partners understand planning processes. The big project that I've, there's a bunch of technical projects, there's a bunch of these kinds of negotiations, but actually the big project that I've been working on at Stripe is around that area. How do we understand how to best serve the organization? How are we getting out of this proactive mode? How do we become, I think we always are a value add, but how do we really drive that value forward? And how do we become a team that is not a handful of people who are just heads down executing, and trying to like scramble to the next thing, and are more laying the foundations and partnering to lay the foundations with our business partners? Knowing that we're a couple of, frankly, we're a couple of years behind, so we have a lot to lot to catch up on. That's really been, if I look at it across all of my teams, and what my function is doing right now. We are working on technical projects, we're delivering things every day, we're trying to move those forward. Kind of core things, core capabilities that I've discussed before are projects that we're working on. But really more than anything right now, we're focused on - how do we partner? How do we partner for success? How do we understand what we should be investing in with our partners? And how do we really surface their underlying needs versus the rapid fire day to day? Naber:  So that is really interesting. I've got a question for that. So can you explain what the end result looks like? What does euphoria look like when you get to this place where...maybe not euphoria, you get what I'm saying though... you get to this place where you're being proactive, you're working with the business on the things you should be working on, and it is working like a smooth machine that is operating on all cylinders. What does that look like, and what do you guys accomplishing when that happens? Jennifer Knight: Yeah. So maybe I'll start with what it doesn't look like. There's no world in which we're done, and there's no world in which there's no backlog, and there's actually no world in which we are doing everything the business wants you...all 10 items, every sprint. That just, that has never happened in the course of my career, regardless of the team size or anything like that. There will always be needs. There will always be needs that we can't serve immediately today. And part of that is actually the right investment model for the business overall. So we're always looking at prioritization. I think when it's smoothly, the factors that I look at are..We have transparent and clear communication with our partners. They know what they're getting, and we're delivering that in the way that we've committed to delivery. They are actively engaged and partnering, and feel good about the prioritization. They know why. They know the business impact, because they're defining it. But there's a lot of really clear communications there. And then on our side, like I said, we're delivering on time or delivering in a way that is thoughtful and accountable to the rest of the ecosystem. So we're not breaking each other, and we're not breaking the system. That actually gets quite difficult at scale. If you have five developers on a platform, and sometimes they have overlap, you have to make sure that they're all developing the Product that is your CRM or the Product that is your Marketing automation platform in a way that is conscientious. So, we are, when we're operating smoothly, we are not blowing up each other's work. That's a pretty obvious one in my mind. I think when we're operating smoothly, we are responding to the right things, with the right urgency, in the right SLA's. So this is one of the reasons we end up with a Run function. Not every ask has to be treated like a project, but not every ask can be treated like a quick win. So you want to have varying SLA's and varying approaches, and when we're running smoothly we have an intake process that allows us to triage those, and be very quickly responsive where it's appropriate, and be thoughtful and measured in our approach, where that's appropriate. But not trying to do a one size fits all. Those are the core tenants that I look to when I think about how my team is running smoothly. I think that maybe one that we don't talk about with the business as much, is we also spend some time thinking about the technical foundations, and how those potentially need to evolve because our SaaS partners are evolving different features, and giving us different capabilities. So maybe we set up an integration one way four years ago because that was what Zendesk allowed us to do. And that might be really difficult for us to maintain and manage. And on the business side, it may look like it just works. And on our side, it may be a ton of toil and work to keep it alive. And Zendesk releases a new feature that simplifies that. How do we also continuously bring technical, underlying improvements, infrastructure improvements, into our roadmap. And then when we're working really well, socializing those up with our partners so they really appreciate why us doing that work actually improves their world and makes us more efficient together. Those are the high level things that I look for when I think about my team operating well. And like I said though, the work will never stop. It will always be there. Which is the exciting and fun part. So really it's about transparency, and process, and prioritization. Naber:  Nice. Awesome answer. Thanks so much, Jenn. So last question, and then we'll wrap. Okay. I've got one rapid fire question for you as well. So, one of your many superpowers, that you've alluded to a little bit, throughout your answers, but is...As you're going through every single one of these projects and all of your decisions, thinking as an end to end process thinker, where you're keeping the big picture in mind while you're able to zoom in and out of the details and the different requirements, and how do all these things stick together over an entire project over a sustained period of time. How do you bring stakeholders along with you in that journey? Because you're saying no a lot, you're saying yes a lot, you're saying no a lot more than you're saying yes. And you're also telling them, hey, please wait. Being a Sales and Marketing operator myself, I know that we could be inpatient every once in a while. So how do you bring stakeholders along in those conversations, and what are some of the best practices that you use for communicating with stakeholders? Because you're so good at that naturally, but that is not necessarily a Sales of Marketing operators forte as they're thinking about, just what they want to do for that quarter or that half of that year. Jennifer Knight: Yeah. Yeah. So I've had a couple of different approaches. I think once again, this is an interesting one...That you say it's a strength that I can think that way. And sometimes one of my weaknesses of getting it out of my mind, and onto a piece of paper. And so what I've gotten better at over time is making sure...everyone who knows me knows I love a whiteboard. I actually don't think that most people in these complex scenarios, there's a few of them that can, if you describe it with words, actually can follow along. I'm someone that, if someone starts, if I focus extremely hard and someone is describing something, I can usually think that I've understood. But sometimes when they put it on the board, I realized actually I didn't. So one of the techniques that I use, and I actually encourage everyone on my team to do, and I encourage our partners to do, is write on the board. Write your process on the board. On our side we will write then the system on the board. And let's all look at it, and then talk about the areas that we don't understand, or talk about the areas where we want clarification. In our side, when I start to think, okay, here's our end to end process, now you have all these Systems. Helping people come along, part of it is by laying out, here's the areas that maybe we're gonna be able to accelerate quickly, and here's the areas where I either don't have complete control - I'm going to have to negotiate with a partner, or is technically complex. So let's look at the whole thing end to end. But starting that visual from the process. And it doesn't have to be elegant. It doesn't have to follow all the fancy flowchart, actual diagrams. I do love that stuff sometimes, but get a pen out, sit down together, and make sure that you both are actually speaking the same language. And then that your priorities align. So I might get really passionate about some part of the process that somewhere else I've seen be really interesting, and that might not really be what you're passionate about. Or I might be able to bring some insight because I've seen this at a larger company. I can say, hey, two years, we don't have to face it today, but two years from now we're gonna need these kinds of controls. I'm telling you that I want to build this foundation in today because I'm looking forward. Do we agree that that's an okay thing to do? But even to get it out of your mind, get it onto a board. That's a huge one. Then, like I said, on the transparency side for our team, we have milestones. We are sending out sometimes weekly or biweekly updates on how we're progressing against those phases of the project. We're checking back in what has changed. Have our priorities changed? Have some more micro points within the plan, do we need to adjust? Have we learned something new that's going to shift something out? Those are the muscles that we exercise. But I think the first and most important thing is - can we all get in a room, and can we look at this thing end to end, and do we actually, are we speaking the same language? And I'm not going to say it verbally to you. I'm going to show you. And then pull out a pen, and mark it up, and tell me where it's crazy, or tell me where it doesn't work, or tell me where your world is different. And that way we on my side of the house, have the context of where you're coming from. And you on the business side, can understand how we're thinking about the approach. And no one is surprised. That would be the tactic that I think about a lot. Naber:  Man...I wish I could wrap that thought up and hug it because I loved it so much. You and I have a similar brain in some respects, and I'm loving that answer. Okay, last question. We're done with going through all these different examples, all this information. As you wearing like a tweed jacket and a hat right now, because you just professored everyone with all of your knowledge. So, one rapid fire question. So, I ask this to people on their birthdays every single year. It's not your birthday, but I'm asking anyways. Our audience has heard me say that a hundred times, apologies, but I'm explaining for the guests because they don't know. Maybe they've listened to all of them, nope they haven't. Most important learning or lesson you've acquired professionally in the last 12 months? Jennifer Knight: I would say, I've always been a patient person. But in the last 12 months, I've actually gotten much better at learning how to be both patient and persistent. Which is kind of a weird abstract learning, I'll give it that. But in environments where a lot of changes driven by influence or cross team collaboration, and everybody is under a lot of strainm under resourced in their own way...Figuring out how to navigate that in a way that continuously feels constructive, is not something that I would say was my strength in the past. I am definitely someone who likes to get things done, and I'm a bit principled in my approach. But same thing happens to my team. People are coming to me and saying, Jenn, can you do this thing? Can you do this thing? And I'm saying, no, we have to put it in this roadmap. Learning how to be the customer on that side. And how do I navigate that? And how do I continue to emphasize the importance of something or being respectful and patient of the process that I'm in? And being okay with that patient. Part of it is with my partners, and part of it for me is actually with myself. It's knowing that when