Olivia: Alright Jackson, I'm going to say a phrase, and you give me the first image that pops into your head. Ready? "Corporate Org Chart." Jackson: Oh, easy. It's a beautiful, laminated work of fiction that has absolutely no bearing on how anyone actually talks to each other to get work done. Olivia: That is the perfect, and I mean perfect, entry point for today's book, Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais. Jackson: Team Topologies. It sounds a bit like landscape gardening for the office. You’re trying to make sure the paths are in the right place so people don't just cut across the grass. Olivia: That's a brilliant analogy! And the authors, Skelton and Pais, are the master gardeners. What's so compelling is that they aren't academics in an ivory tower. They're consultants who spent years in the trenches of major companies—we're talking the London Stock Exchange, global pharma companies, major media outlets—watching these "fictional" org charts cause very real-world chaos. This book was their answer to that chaos. Jackson: So they saw the trampled grass and decided to write the manual on where the sidewalks should have been all along. I'm in. Because I think we’ve all lived in organizations where the official map is useless, and you only survive by knowing the secret, unwritten one. Olivia: Exactly. And that secret, unwritten map has a name. It’s a force of nature in organizations, and it’s called Conway’s Law.

Jackson: Okay, Conway's Law. That sounds a little ominous, like something out of a sci-fi movie. Is this a real, proven thing, or more like a tech-world horoscope? Olivia: It's very real, and it's been around since 1968. Mel Conway, a computer scientist, made this profound observation. He said that any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure. Jackson: Hold on. So you’re saying the software we build ends up looking like our company's internal meeting schedule? Olivia: In a nutshell, yes! Think about it. The book gives a simple, perfect example. Imagine you have four teams, and they all need to make changes to a database. But the company has a single, centralized Database Administrator, or DBA, that they all have to go through. What kind of software architecture do you think they'll naturally build? Jackson: Well, I guess they’d all build their own separate things, but they would all have to connect to one giant, central database because that’s where the one guy they can talk to lives. It becomes the bottleneck, the central hub. Olivia: Precisely. The software architecture mirrors the communication bottleneck. The organization’s structure forced the technology into a specific shape, whether it was the best shape or not. The org chart, the communication paths, won. This is the ghost in the machine, constantly shaping our work without us even realizing it. Jackson: That is… unsettlingly familiar. It explains so many projects I've seen where the final product felt clunky and weirdly stitched together, because that’s exactly how the teams were. But what’s the actual harm? So the software is a bit awkward. Does it really matter? Olivia: It matters immensely, because of the human cost. This leads to the second critical concept in the book: cognitive load. Jackson: Okay, "cognitive load" sounds like a fancy, scientific term for just being really, really busy. Is there more to it? Olivia: There is. It’s the total amount of mental effort being used in your working memory. The authors break it down into three types, which is so helpful. First, there's intrinsic load—the core complexity of the problem you're solving. Like, 'how do we do this complex financial calculation?' That's the good stuff. Jackson: Right, the actual job. Olivia: Then there's germane load. That’s the effort of learning and getting better at your job—new skills, deeper domain knowledge. Also good. But the killer is the third one: extraneous cognitive load. This is all the other junk. The confusing deployment process, the poorly documented tool, figuring out which of the five different teams you need to talk to for a simple approval. It’s the mental energy you waste just trying to do the work. Jackson: It’s having 50 tabs open in your brain, and 45 of them have nothing to do with the actual problem you’re trying to solve. It’s the bureaucracy of thinking. Olivia: The bureaucracy of thinking! I love that. And when that extraneous load gets too high, teams break. The book tells this incredible story about a company called OutSystems. They had an "Engineering Productivity" team that was supposed to help everyone else be more efficient. Jackson: I feel a dark twist coming. Olivia: You bet. The team was a victim of its own success. They kept getting more and more responsibilities. Build systems, testing infrastructure, deployment pipelines, you name it. Soon, this eight-person team was responsible for so many different, complex domains that their cognitive load went through the roof. Jackson: So the team designed to fix bottlenecks became the biggest bottleneck of all. Olivia: Exactly. Their planning meetings became chaotic. They were context-switching constantly. Motivation plummeted. They couldn't master any one area because they were spread so thin across everything. They were drowning in extraneous load, and the flow of work for the entire company ground to a halt because of it. Jackson: Wow. That’s a powerful story because it’s not about bad people or a lack of effort. They were trying to do the right thing. The system itself, the way their responsibilities were structured, set them up to fail. It overloaded their brains. Olivia: And that is the core problem Team Topologies sets out to solve. If the old maps—the org charts—are wrong, and the human cost of ignoring these forces is burnout and gridlock, then we need a new map. We need a new language for designing teams that respects the reality of Conway's Law and the limits of human cognition.

Jackson: Okay, I'm sold on the problem. My brain feels overloaded just thinking about their overload. So if the old maps are wrong, what does the new map look like? What are the blueprints? Olivia: This is where the book becomes so practical and, honestly, elegant. The authors propose that for most modern software organizations, you only need four fundamental types of teams. Four "topologies." It’s a simplified language to design your organization. Jackson: Only four? That sounds… suspiciously simple. What are they? Olivia: The first, and most important, is the Stream-Aligned Team. Think of them as the heroes of the story. They are aligned to a single, continuous stream of work that delivers value to a customer or user. This could be a product, a service, a user journey—whatever it is, they own it end-to-end. Jackson: So this is the team that builds the feature, ships it, and sees how users react. They're on the front lines. Olivia: Exactly. And the other three team types exist purely to support them, to reduce their cognitive load so they can go faster. The second type is the Platform Team. Jackson: Let me guess. This is the team that builds the roads and bridges for the Stream-Aligned teams to drive on? Olivia: Perfect analogy. They provide the internal services and tools—the platform—that the stream-aligned teams consume "as a service." This could be the deployment pipeline, the monitoring dashboard, the cloud infrastructure. Their job is to make all that underlying complexity disappear, so the stream-aligned team doesn't have to worry about it. They are the Q to James Bond, providing the gadgets that just work. Jackson: Okay, I like that. So we have the heroes and the gadget-makers. What's the third? Olivia: The third is the Complicated-Subsystem Team. This is for those rare cases where a part of the system is so incredibly complex that it requires deep, specialized expertise. Think of a video-processing algorithm, a financial modeling engine, or the physics engine in a video game. Jackson: So this is the specialist squad you call in when you need brainiacs who have PhDs in something most of us can't even pronounce. Olivia: You've got it. Their job is to hide that complexity from the stream-aligned teams. They build and maintain that one, tricky component, so the heroes can just plug it in and not have to get a PhD themselves. It’s a cognitive load shield. Jackson: Makes sense. And the last one? Olivia: The fourth is the Enabling Team. These are specialists, like coaches or mentors. Their goal is to help stream-aligned teams acquire new capabilities. They might be experts in a new technology, or in a practice like test automation. They work with a stream-aligned team for a short period, help them level up, and then move on. Their goal is to make themselves redundant. Jackson: So they're like the traveling sensei, teaching the village how to defend itself and then riding off into the sunset. Olivia: I love that! A traveling sensei. That’s exactly it. And with just those four team types, you can design a whole organization. The book gives this incredible case study of Adidas. In the early 2010s, their IT department was seen as a slow, expensive cost center. They decided to use these principles, driven by Conway's Law, to completely re-architect their teams. Jackson: What happened? Olivia: They created stream-aligned teams focused on business needs and a central platform team to support them. The result? They increased the release frequency of their digital products sixty-fold. From one release every few months to multiple releases a day. Jackson: Sixty-fold? That's not an improvement; that's a different reality. That’s moving at the speed of thought. Olivia: It is. And it shows that this isn't just theory. When you align your teams to the flow of work and manage their cognitive load, you unlock incredible speed. Jackson: This reminds me of the famous "Spotify Model" with its squads and tribes. A lot of companies tried to copy-paste that and failed spectacularly. How is this different? Olivia: That's a fantastic question, and the book addresses it directly. The authors argue that people copied the labels from Spotify—squads, chapters, guilds—without understanding the underlying principles. They copied the static org chart, not the dynamic interactions. Team Topologies gives you the fundamental building blocks and interaction modes—Collaboration, X-as-a-Service, and Facilitating—so you can design a system that works for your context, not just copy someone else's. Jackson: That makes sense. It’s the difference between getting a recipe and understanding the chemistry of cooking. But I have to ask the skeptical question. I’ve seen some reviews from people deep in the industry who say this is all a bit obvious. That it's just putting fancy names on common sense. What's your take on that? Olivia: I think that's a fair critique from a certain perspective. But the power here isn't necessarily in inventing brand new, unheard-of concepts. The power is in creating a simple, shared, and explicit language to talk about these things. Most organizations suffer because these decisions are implicit, accidental. By giving us terms like "stream-aligned" or "cognitive load," the book allows a manager in finance and an engineer on the front lines to have a strategic conversation about team design. It makes the invisible visible. That shared vocabulary is the real game-changer.

Jackson: Okay, so if I'm boiling this all down, it feels like the big shift is moving from thinking about an organization as a static machine, like a clock, to thinking of it as a living thing, like a garden. Olivia: That's a beautiful way to put it. You don't design a garden once and walk away. You tend it. You understand how the different plants interact, what needs sun, what needs support. You're not designing a fixed structure; you're designing the conditions for growth and flow. Jackson: And the four team types are like knowing you need your fruit-bearing trees, your pollinator-attracting flowers, your soil-enriching ground cover, and maybe a specialist to handle that one weird orchid that's hard to keep alive. Olivia: Yes! And the interaction modes are about knowing when to let them be, when to water them, and when to bring in the sensei to teach them a new trick. The goal isn't to create a perfect, final org chart that will last forever. The goal is to build an organization that is constantly sensing and adapting. The friction between teams isn't a problem to be squashed; it's a signal. It's the plant telling you it needs more light. Jackson: I love that. So for anyone listening right now who feels like their team is drowning, that their cognitive load is maxed out, what's the first, smallest step they can take based on this book? They can't just go to their boss and say "we need to become a stream-aligned team!" Olivia: The first step is just to start a conversation using this new language. You don't need a full re-org. Just ask your team in your next meeting: "On a scale of one to ten, what's our extraneous cognitive load like? What's the one piece of 'work bureaucracy' that's driving us crazy?" Or ask, "If we had a magic platform team, what's the one service they could provide that would make our lives dramatically easier?" You just need to start sensing the system. Jackson: Start sensing. That feels doable. It’s not about a revolution; it’s about turning up the volume on the signals that are already there. We'd love to hear what you all sense in your own teams. Drop us a line on our socials and share one thing that's causing friction or one thing that creates flow. Olivia: This is Aibrary, signing off.