Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Team Topologies to Fix Communication Dead Zones
Transcript
- Lucas: So a few months ago I was talking to a CTO at a financial services company — about 200 engineers, growing fast — and she described a problem that I think a lot of leaders in this space will recognize. Luna: Let me guess: teams are stepping on each other, handoffs take forever, and nobody knows who owns what? Lucas: Exactly that. But specifically, she said they had what she called 'communication dead zones' — areas of the org where two teams needed to coordinate but literally had no structured way to do it. So they'd either over-communicate in huge meetings or under-communicate and ship the wrong thing. Luna: I've seen that. It's like the org chart has a gap that nobody drew. Lucas: Right. And the fix she applied was the Team Topologies framework — specifically the four fundamental team types from Matthew Skelton and Manuel Pais's book. And I think it's worth walking through because it's not just an academic taxonomy; it's a practical diagnostic tool. Luna: So what are the four types? Give me the cheat sheet. Lucas: Stream-aligned team — that's the main delivery team, aligned to a flow of work, like a feature or a customer journey. Enabling team — they help stream-aligned teams learn new skills or adopt new tools. Complicated-subsystem team — they own a piece of the system that requires deep expertise, like a pricing engine or a physics simulator. And platform team — they provide a self-service internal product that other teams consume. Luna: And before this framework, what were they? Just generic feature teams? Lucas: Mostly. They had teams organized by component — a database team, a front-end team, a services team — but the work was cross-cutting. So every feature required coordination across three or four teams, and the handoff latency was brutal. They measured it: average cycle time from idea to production was about eight weeks for a simple feature. Luna: Ouch. And after? Lucas: After they reorganized into stream-aligned teams — each owning a full slice of the system for a specific business capability — that cycle time dropped to about three weeks within six months. But the key was they didn't just shuffle boxes on the org chart. They also defined the interaction modes between teams. Luna: The three interaction modes from Team Topologies — collaboration, X-as-a-Service, and facilitating. Right? Lucas: Exactly. Collaboration is when two teams work closely together for a defined period on something novel. X-as-a-Service is when one team provides a service to another with a clear API or interface. Facilitating is when one team helps another learn something. And they made a conscious choice about which mode each pair of teams would use. Luna: Can you give me a concrete example from her org? Lucas: Sure. They had a payments team — stream-aligned, owns the checkout flow. And they had a fraud-detection team — complicated-subsystem, because fraud models are deep and specialized. Previously they would just schedule sync meetings every week and hope for the best. Under the new model, they explicitly chose X-as-a-Service: the fraud team exposed a clear API for risk scoring, and the payments team consumed it. No more meetings about how the model works — just the interface. Luna: That makes sense. But what about when the fraud team wanted to change the model and the payments team needed to understand the impact? Lucas: Good question. They used the collaboration mode temporarily — a two-week joint spike to redesign the API contract. But after that, back to X-as-a-Service. The key is the mode is not permanent; it can change based on the work phase. Luna: So how did they actually identify where the dead zones were? Lucas: They did a dependency mapping exercise. Every team listed the teams they depended on to deliver their top three features. Then they cross-referenced and looked for gaps — teams that were depended on but had no awareness of it. They found six dead zones where a team was a critical dependency for another team but had no formal interaction mode defined. Luna: So it's like a social network analysis for your org. Lucas: Exactly. And once they identified those, they could assign the right mode. One dead zone was between the data engineering team and the analytics team — data engineers were building pipelines the analysts needed, but there was no service interface. So they created a platform team that built a self-service data catalog, and that closed the dead zone. Luna: I love that. So they didn't just add more meetings — they changed the fundamental interaction. Lucas: Precisely. And the CTO told me the hardest part was convincing senior leadership that creating a platform team would actually reduce headcount in the long run, because it would eliminate duplicated work across stream-aligned teams. They needed a few months of data to prove it, but after six months, the platform team had eliminated about 30 percent of the ad-hoc data pipeline work that each stream team was doing independently. Luna: That's a strong ROI. But I imagine not every dead zone gets solved by a platform team. What about the ones where you need deep expertise? Lucas: Then you create a complicated-subsystem team. They had a team responsible for the core transaction processing engine — it's old, it's complex, and it's critical. They made that a complicated-subsystem team, and all other teams interacted with it through a well-defined API. That actually reduced the frequency of incidents because the surface area for mistakes shrank. Luna: So the key insight is that you have to name the type of team explicitly, so everyone knows what to expect from each other. Lucas: Right. And that clarity reduces cognitive load for everyone. One of the principles in the framework is that a team should be responsible for a bounded area of the system, with a clear boundary. That way, each team can hold that area in their heads without needing to understand the whole system. Luna: I want to go back to something you said earlier — the enabling team. When would you use that? Lucas: The enabling team is a temporary team that helps other teams build capability. In her org, they had a situation where all the stream-aligned teams were adopting a new event-driven architecture, but nobody had deep experience with Kafka. So they spun up a six-month enabling team of two senior engineers who coached the teams, wrote example code, and reviewed designs. After six months, the enabling team dissolved — because the capability was now distributed. Luna: That's smart. A lot of companies would just hire a platform team to build a Kafka abstraction layer, but that might over-abstract too early. Lucas: Exactly. The enabling team approach avoids the trap of building a platform before you understand the real pain points. It's a lighter-weight investment, and it builds internal expertise. She told me they actually tried the platform route first — built a common event bus library — and it failed because nobody used it. The abstraction didn't match how teams actually wanted to work. Luna: So the enabling team helped them discover the right abstraction before committing to a platform. Lucas: Yeah. And after those six months, they had enough knowledge to build a proper platform team with a clear API that the stream teams actually wanted. The platform team now maintains a self-service event schema registry, but they didn't start there. Luna: I like that progression: enable first, then platform. Lucas: It's a good pattern. And I think it's worth mentioning that this whole reorg wasn't a big bang. They piloted with one value stream — the payments domain — for three months. Learned a ton, adjusted, then rolled out to the next domain. The whole thing took about a year. Luna: So if a listener is sitting in their CTO office right now, thinking 'we have these dead zones too', what's the first step? Lucas: Do the dependency mapping exercise I described. Have each team write down their top three features and the teams they depend on. Then look for the gaps. That will give you a map of your dead zones. Then, for each dead zone, ask: what kind of team should own this? And what interaction mode makes sense? Luna: And if you're not a CTO but a team lead, you can still start the conversation by showing the map to your manager. Lucas: Absolutely. The framework is useful at any level. And the book is short — you can read it in an afternoon. But the real value is in the exercise, not just the taxonomy. Luna: You know, if today's conversation gave you something practical to try, I'll mention that the way we keep this show ad-free and focused on real tactics is listener support. If you found this useful, you can help at buy me a coffee dot com slash fexingo. Lucas: And we really mean it — no pressure, no perks, just a way for people who get value to keep the signal clean. We'll keep doing the episodes regardless. Luna: Alright, back to the topic. Lucas, you mentioned that one of the pitfalls is over-rotating on structure. Can you unpack that? Lucas: Sure. One thing the CTO warned about: teams are not machines. You can draw the perfect org chart, but if you ignore the interaction modes, you'll just create new dead zones. She said they initially assigned too many collaboration modes — every team was supposed to collaborate with every other team, which led to meeting overload. They had to pull back and be more deliberate about which pairs actually needed deep collaboration versus a simple API. Luna: So the interaction mode choice is as important as the team type. Lucas: Exactly. And the other pitfall is creating a platform team too early, before you understand the real needs. They did that — built a shared service that nobody adopted. The enabling team approach gave them the data they needed to build the right platform. Luna: Any other lessons from her journey? Lucas: One more: don't try to change all teams at once. They started with one stream, learned, iterated. That built credibility. When they rolled out to the next domain, other teams were actually asking to be reorganized because they saw the results. Luna: That's the dream — pull instead of push. Lucas: Yeah. And within a year, they had a clear map of all teams and their interaction modes. Dead zones were documented and assigned. They even started tracking a metric called 'interaction health' — a quarterly survey where each team rates the quality of their interactions with their key dependencies. That gives them leading indicators before a dead zone becomes a crisis. Luna: I love that. So it's not a one-time fix; it's an ongoing practice. Lucas: Exactly. Team Topologies gives you a language to talk about org design continuously. And in a fast-growing company, that's essential because the org chart is never static. Luna: Alright, I think we've given listeners a solid playbook. Thanks for walking through it. Lucas: My pleasure. If you try the dependency mapping, let us know how it goes — we love hearing real outcomes.