Webinar – Data, Explored #7 – Neue Perspektiven auf Teamtopologien

So first of all, a warm welcome, Manuel Pais, to Data Explored. Thank you. Thank you.

It's an honor to have you on. For the listeners, I can inform you or the people watching that you are a very seasoned keynote speaker. You're the co-inventor of the concept of Team Topologies, which is both a book and an academy.

So you're obviously the co-author also of "The Platform Manifesto" that you authored that also, and you're Fast Flow Thought Leader. And you speak Portuguese. I see- I do, but not on this webinar.

No. I wanted to say something in Portuguese, but I can't. I'm sorry.

But- It's okay ... it's a real pleasure to have you on, Manuel Pais. I've been enjoying your work quite a lot, followed you closely.

And we've set up this call to talk about the second edition of your book, "Team Topologies." And I know I have my background on, so I'm not sure I can... But I have both the first and the second edition- Nice ... because I read the...

Yeah. I have a habit now of not throwing out first editions of the books that I buy in the second edition because I find that sometimes I take notes and I think, and I kind of lose orientation if I can't go back and find that. I know I'm a geek, but anyway, that's just how I am.

But I read your book that you co-authored with Matthew Skelton. And so, basically, I have a lot of questions, and we also had the time to just go through some things before we went live, and maybe we will have time to talk about that during this call. We have about an hour.

And if anyone wants to ask questions, please use the Q&A and not the chat. But for this webinar, I suggest that we go ahead and talk about some of the things around the book in the beginning, and not in the book, but surrounding the book. Because obviously it's still a bit too early to talk about the second edition in terms of how it's done.

But the first edition, because it's just out, right? But the first edition- Yeah, September last year. Oh, September already.

Yes. Time passes so fast. Is it really September last year?

Yep. Oh, wow. Yeah.

There you go. But what I want to know is, the first edition have several thousand reviews on Amazon, and so don't give me a number. I don't think you should, but it's been doing well, that book, right?

So how does it feel to write a book that's been doing so well? Well, feels really good. But I wanted to say thank you for inviting me as well.

Obviously, I admire your work as an author as well, and you've done really good as well. And I've enjoyed our exchanges also about different topics. The book, so Team Topologies, came out in 2019, the first edition.

It did really well. I think, obviously, and we were talking a little bit about this before we started, for me, the book, and for Matthew as well, was not something that we said, "Oh, we have this great idea. Let's write about this." Was something that was solidified over many years of my experience and his experience, and I think there were multiple factors for the success.

I think the last numbers I remember was like 200,000 copies in the first five years, something like that. So that's pretty good.

Wow. I think it was a combination of factors, was our experiences, me and Matthew, combined really well. We wrote the book at the time when many companies, and we heard this time and time again, was like, "This is exactly what we needed," because we knew we had some organizational issues, but we didn't have a structured way to think about it.

It also built on me and Matthew worked several years consulting around DevOps, continuous delivery. So if you think about the principles behind that, they're very aligned to the principles of Team Topologies, except we're talking more on the organizational side rather than kind of the technical and practices side. And it was, I think, the right time to write that book.

We had done some work on what we call DevOps Topologies before. It was started by Matthew, and then I helped expand that, and that was a website. It is still online, if anyone wants to check DevOps Topologies.

And then we started to realize the patterns are broader than just DevOps, which was a big thing at the time. And what's really cool, now I'm going off track a bit, but you can always stop me. No.

But what's really cool to see now is that obviously everyone's talking about AI, right? When we think about the patterns we wrote in Team Topologies and the principles, which one of the things we try tomake stronger in the second edition, there's a new forward which is going more in-depth about what were the principles behind Team Topologies in the first edition, because we actually didn't write too much about that. We dived more straight into the patterns and the goals.

But there are a set of principles, and when you look at AI and from an organizational perspective, I would say almost everything we wrote in the first edition still applies in terms of managing cognitive load, how do you organize for fast flow when you give teams more agency, and all these things. Of course, when you put AI on top, that might accelerate certain things, but it also might slow down other things if you're not organized in a way that is focused on delivering value to customers. But anyway, I was going a bit off track there.

No, not at all.

And we can dive deeper into that, in fact, in a little while. But before we do so, there are so many things in the book that I like that are surprising. I guess a lot of people in tech have heard of Conway's Law because it mirrors so precisely the effect computer systems have on organizations.

So it's really interesting to discuss Conway's Law and the consequences and how do you avoid it and so forth. You also cite Conway's Law. But more than that, you cite a lot of other books and a lot of other perspectives.

And one of the books that you cite is this book you were inspired by called "Improving Performance: How to Manage the Whitespace on the Organization Chart." Yeah. And that's a really interesting observation right there. What is the potential that you see, that you saw, but I guess that you still see, obviously, in the white space of the org chart?

And to just set the stage a little bit for the people listening in, obviously, an organization diagram has boxes and arrows, and it has titles of business units and so forth. But right next to all of that, obviously, is the white space. But what you're saying is that there's something in the white space, there's a potential in that white space that has to unfold for organizations to become effective.

So what did you see in the white space, Manuel? Yeah. That was the really key concept from that book was this idea of the white space.

Because it crystallizes a lot of the, let's say, dysfunctions in organizations, which is we look at the org chart and it usually makes sense. We organize like this, the different areas and stuff. But then the white space is all the stuff that is not represented there, which happens day to day.

So it's almost like the things that are not intentionally declared and understood, and oftentimes has to do with interfaces between teams, between departments. Because then if you look at an org chart, like you said, it all boxes and arrows, and you see how you're organized. If you overlay how the work actually gets done, that's where the white space becomes, how should I say, more visible that there's a lot of stuff that's not clearly intentionally thought about, and that's where you start to see.

And this is interesting, a very simple exercise people can do in their own organization is think about some work that you delivered, maybe some new feature or something of value, and you start to draw a line through the org chart which departments and teams had to be involved, and you start to get into often this big mess. And it's interesting, even in the second edition of Team Topologies, there's one case study. So there are 10 new case studies in the second edition, because one of the goals of the second edition was to have cases that companies started by applying Team Topologies.

In the first edition, the cases were more focused on specific patterns. But now we're talking about companies, and big companies that really took the ideas and implement it. And so there's a company called Telenet in Belgium.

They're one of the main telecom operators. And in the case study, they saw the starting point was that they had all these tribes. So you look at just the organization by tribes, and it makes sense on paper.

Okay, there's a tribe for customer support, tribe for this and that. And then they drew the lines, like I was saying, when work actually happens, what are the dependencies?

And it just basically is lines all over the place. Mm-hmm. And that's where the white space that was before becomes, okay, now maybe we can call it dark space.

I don't know. It just becomes clear that there was a lot of things that were not working well. And then that case study is super interesting, by the way, because they actually applied some of the concepts and the types of teams we talk in Team Topologies at the tribe level.

So they're saying this tribe is focused on end customer, this tribe is a platform tribe to provide internal capabilities and so on. But yeah, from that point of view of the white space is those things that are not intentionally, clearly defined and they end upBecoming massive blockers to delivering value to our customers. Yes.

I see the white space as both a hidden maze and, at the same time, I see it as the way work actually gets done. Yeah. So it's both these things.

It's the hustle and bustle of everyday work that is not really represented in those very formal charts. And we'll get back to the case studies and the changes that you made in the second edition, because it's all really very worthwhile reading. And so we'll definitely get back to that.

But I guess, and I know that you have done this a bazillion times, so please don't fall off the chair by boredom, Manuel. This is like- But very, very briefly describe what are the teams that you suggest companies adopt? Yeah.

Sure. No problem. It's like a band playing their best hits, right?

Every night. Yes. No, but actually, like I was saying, when we wrote the first edition, I think that's one of the main differences to the second edition.

The first edition was very much like we had seen these patterns and this work, and we had, like I said, solidified a lot of these patterns and ideas from our work, and then we wanted to put it into the book. And so I used to kind of, okay, this is this type of team and that type of team. Today, I like to, and with you, I like to start from the why.

So Team Topologies is about achieving a fast flow of value to the customer. So that's already something to be mindful that we're not just saying, "Let's go fast and become a machine of delivering stuff." Its value is only realized when there's someone consuming what you're providing, and it helps them, and it helps your organization. That's where you get value delivered.

It's not delivering just features or AI slop or what have you. So if we want that, then to some extent, the types of teams we talk about in Team Topologies are meant as magnets in the sense this is what we should be aiming to get. And the first type is what we call stream-aligned teams.

So it's similar to cross-functional product teams. The reason why we wanted to make a distinction with streams is that products tend to be very complex, and so you can't have one team responsible for a whole product. So we need to think inside products, what are the different streams?

And the streams can be aligned to while there are different user personas for the same product. So we maybe need different teams focused on the more experienced personas, less experienced, or whatever the difference might be. Or we have different user journeys, obviously, inside the product, and maybe that's what makes sense as different streams.

Or sometimes it is a set of functionality or features that is fairly independent from each other, so that might be your streams. Often it's a combination of these different factors. And actually, that connects to what you were saying earlier about Conway's Law, where from a technical architecture point of view, we obviously moved from, well, monoliths are bad, they're big applications, and it's difficult to change and evolve.

And then microservices came and like, okay, if we have all this modularity and small services, we can evolve them faster. But then actually, we were missing something in the middle, which is kind of whatever you want to call it, macroservices or whatever services are a good match for one team. Because you probably don't want to have hundreds of small services that the same team has to deal with.

So that's where you have these stream-aligned teams ideally should be responsible for a service or part of a product that is mostly independent from the rest, that it can evolve independently, and provide value to customers. So it's not just a technical component, it's actually this is something that has a clear value, and we understand who are the users of this and what their needs are. Now, the difficulty with those kind of teams is that you are expecting in a fairly small team to have a lot of different competencies and skills.

And there's also a lot to do in terms of understanding your customers, doing discovery, and then actually translating that into actual software or the thing we need to build, and then delivering that to customers, and then analyzing if it's being used, if it's improving the business metrics and all this. Ideally, that's within the scope of the stream-aligned team. And so that's a lot to deal with, and that's the main reason why we include other types of teams.

So there are three other types of teams, which are enabling teams, and these tend to be experts in some domain. And their role is not to do the expert work, let's say. It's to help teams gain the knowledge so they can do the work.

And so that's a very important shift in traditional view of where you have some kind of shared experts. These are the only people who know how to do X. If those people work in an enabling wayThey will be providing, it's the old saying, "Don't give people the fish, teach them how to fish so they can be more self-sufficient." Mm-hmm.

So that's more on the competencies side. And then there are platform teams, which we clarified a bit in the second edition. But essentially teams that provide internal products, if you like to see them as products for the internal teams to use so that they have less to worry about.

They have less, what we call cognitive load, because we have an internal services that can help us. Often starts with a lot of the technical aspects, like doing deployments, monitoring, infrastructure. All of that can be done in ways that are automated, ideally by the platform, and easy to use.

And so it removes a lot of concerns from the stream-aligned team so that they can focus on the customer needs. And then we had complicated subsystem teams, which we kind of discussed a lot because if those are really needed, but there are occasional situations where you have a very complex algorithm or some subsystem, or some service even that does some complex processing or it has very high demanding kind of processing needs or computing needs. And sometimes you need a team dedicated to that service or subsystem because if you ask the stream-aligned team to do it, it's just going to explode their cognitive capacity.

And so those complicated subsystem teams can be seen almost like a kind of mini platform. It's just one kind of subsystem or service, but it should be provided in a way that's easy for the stream-aligned teams to consume. Yeah.

Thank you. So those are the four- Thank you ... types.

Yeah. Thank you. And thank you for taking the time.

That must have been time number, I don't know how many million times you've said this, but- I've lost count. Yeah. Sure.

But we kind of needed to establish this because basically the teams that you suggest, they work in topologies, right? That's the idea of team topologies. It's that these teams- Yeah ...

they work in specific constellations, in specific companies to do specific things, right? Yeah. And they evolve.

Or they should be evolving fairly continuously. So the topology is then a combination of different types of teams, and their interactions as well, right? To look at it as a system, where, again, ideally, if we had only stream-aligned teams with all the competencies and reasonable cognitive load on all of them, then that's all we would need.

Just have stream-aligned teams working in parallel, delivering value to customers. But we know that's not very realistic. So the topology, it's almost like this idea of the team of teams that work together effectively to deliver then the value to the customers.

But then it should evolve over time. Based on what challenges do we have today. If we think about today, maybe there are some gaps in teams adopting AI or understanding how to integrate AI in our workflows, in our products, in an ethical way.

And there's a lot of questions that maybe we need help from some experts or some enabling team that can help the stream-aligned teams figure out this stuff. Maybe we need some platform tooling that makes it easier to use some of these new approaches. So those might be the challenges today.

But maybe in one, two, three years, this stuff is more or less established in the organization. We kind of know what to use, and teams have enough knowledge, so maybe we don't need the same enabling teams, or maybe there's some new platform services because what used to be more experimental now has been established. This is a good way to do this, and we can sort of provide it as a platform service.

So it's very key to look at topologies as not a static thing. It's not a static, let's say, operating model.

It's what's working today to address the challenges we have, which are going to evolve in the next months, years. Yeah, and I like the flexibility of that. It's an organizational structure that is capable of adapting, changing, refocusing, and anyone that's been in tech knows that that needs to be possible for an organization to do.

Yeah. If not, you get these very, very heavy setups, with teams of high complexity and low- Mm ... value production, basically.

Guess we've all been there at some point in our career. And it's also interesting too, what I realize is a lot of companies invest quite heavily in not just tooling, but a lot of in tooling, in expertise, and having good practices. Obviously, now we're talking about AI, but that was beforeDevOps and CI/CD, if we're talking about more technical aspects, obviously you're in the data field, things like data mesh and all these things.

Of course, they require expertise and tools often, but they invest a lot in that, but they don't invest in the enabling part. So it's like we have really good stuff that we can use, but people are not taking advantage of them because the stream-aligned teams or product teams are busy in their day-to-day, and they have a lot of pressure to deliver, and no one has went to help them figure out how to do this stuff well, right? Often they might adopt some stuff because there's some pressure to, okay, we need to do DevOps or whatever.

But they often end up doing it in a haphazard way. So the enabling part is really interesting, and to me at least, is one of the things I'm more proud from Team Topologies. This is something which feels unfamiliar to many organizations, and when they see it happening, they can see the impact it has, but it's just as simple as teach people how to use these great tools and practices.

Don't just provide them and expect them to magically learn, right?

Because there's often not enough space to learn and really adopt things in practice. No, I guess I can admit that I'm a geek. But seeing enterprise technology actually working is just such a pleasure for me, and so I've experienced that many times myself.

Obviously, I think the failure rate of enterprise technology is dramatically high. When I worked in other roles, I saw that from time to time, right? These failed IT projects- Yeah ...

or those teams that were hired, and typically, those would be data scientists about 10 years back, right? And they would have enormous salaries, and they wouldn't do anything really, or very little, but be mathematical geniuses and how disappointing can that be, right? But anyway, and so that really touches on the flexibility and the usability of technical skill sets and people and technology and I guess this Team Topology, it's like the organizational dimension of these technological decentralizations that we've seen, data mesh, microservices.

How closely related are these, and how do you tend to think of this connection with these decentralization- Yeah ... movements of technology? Yeah, I would say if you take a 10,000 feet view, it's actually what you mentioned before.

Conway's Law talks about the impact of how we're organized and how we can communicate and the interfaces between teams and the kind of systems we're able to produce. But there's a third dimension to that, which is the actual business architecture, if you like. So different companies have different vocabulary, if you like, to talk about how their business is organized.

I like to talk about value streams. If companies have used things like domain-driven design, tend to talk about business domains, sub-domains. But at the end of the day, we're talking about the same, which is to understand your business architecture.

What value do you provide to which customers, and how is this organized? What's in different value streams or domains, et cetera. And so that business architecture, if it's aligned to your organizational architecture, the way you're structured and org chart, but also the communication channels and all that.

And if that's aligned to your technical architecture, then you have a really good advantage that these things are aligned. They're not fighting each other. So I think what has happened, I don't know if it's a bit, how you say, arrogant of me to say this, but I think until Team Topologies, there was kind of separation between, okay, there's the technical architecture, and that's where things like microservices and data mesh, to some extent, come in.

And those things are those patterns, those ideas are good and helpful, but they were not connected to the rest, to the organizational side. We were not seeing maybe as much the impact of if we just adopt microservices, like I was saying earlier, okay, if you end up with hundreds or thousands of microservices, you have a lot higher load on managing all those services. And often what then companies start to realize this is not actually helping us go faster.

We have more loads than before because they have all these small services, and often they were not broken or split by customer focus. We're more on a functional basis. And so I think that was the gap that was happening, that we adopt these good technical practices, but then they don't have the impact that we expected on the business and the ability to provide value quickly.

And that's why I thinkAt some point that's why we try to introduce also team topologies for teams to think or when you're thinking about the technical architecture, to think about what makes sense for one team of usually up to eight, nine people. What makes sense as a service or part of a product for one team to be able to handle and deliver value mostly independently on that specific service or stream. Right?

So it's kind of connecting the dots, if you like. Yeah. I guess I can be honest about this.

I don't know if I should be embarrassed about it or not, but I knew that Team Topologies was an important book before I read it. I just really didn't know why. And it took...

I read and I read, and then in the beginning, I still didn't understood why is this important. And then it clicked, right? That exact thing that you're mentioning just clicked that, okay, we're used to thinking of technologies as something that you need to break up.

You need to break up the data architectures. You need to break up the big ERP systems. Whatever it is, you need to unlock the monolith to unleash the potential of what it is you're dealing with.

And then it just struck me that, okay, this book is about the fact that you can do the same thing, or you need to do the same thing for your organization. That's also a monolith, and you can also break it up. And that's what this book is about.

And then I got it. At least I think I got it, but you tell me. But anyway.

Yeah, I think you do. Well, thank you. We got that on tape.

Thank you. If you connect that to what you were asking me before about why the success of the book, I think it's on one hand, a lot of people said, "I felt seen," like when we're talking about pain points and what you just said, if we're looking only in one dimension, then we're doing our best to improve, let's say, technical architecture and the way we work, and we're not seeing the impact on the other side. So people felt very identified with how we were describing the issues.

And then some people also said, and I would agree, the ideas we brought in terms of solution, let's say, or the patterns, they build on a lot that has been done in the past, DevOps movement, Agile to some extent, system thinking very important as well. So some people would say, "Well, there's nothing super novel about Team Topologies," but was how it was bringing those things together, giving it vocabulary. And like I said before, I think the enabling part is the one that maybe a lot of people hadn't thought about making that more intentional.

But a lot of the stuff, of course, is built on what we've known from the past, even the ideas like platform as a product. But it was bringing things together. I think at the end of the day, that's what Team Topologies did.

And maybe that's why you're saying it took a while to understand why is this important is it's connecting, I think, the dots of a lot of stuff that we've felt, we've known. There's something off here. Why aren't we seeing different results?

So I think that's to me, the power of Team Topologies is that bringing in a fairly short-ish book, bringing things together, and having an understanding of the organizational side and it's also very aligned to the technical principles of and the ideas behind DevOps and continuous delivery.

So it made sense for a lot of technical people, too. Absolutely. I felt seen by that book also, so as many other readers did.

Let's dive a little bit more into the second edition now. There are some changes, and you've already mentioned this a bit, but let's unpack it some more. Yeah.

I want to end the conversation with the case studies because there's so many, and they're so interesting, and they're so different. Right? So I want to keep that topic for a little later.

The first thing I think we should talk about, basically, and that's something that it's very close to my heart because I've worked the majority of my career. So let me just set the stage a bit here. This is a long introduction to a short question.

Please bear with me. But I've worked in the majority of my career in big enterprise as an internal employee but also as an external consultant, providing advice to many, and that took off basically with me becoming a tech author and what I wrote resonated. So I created my own consultancy company next to my internal job.

What I did and what I was confronted with a lot was these multiple identical technologies or technologies that did more or less the same thing, but perhaps not completely the same thing. Very much because of the study that I, or the direction that I took very much at the metadata layerThese technologies that I think of as being capable of being connected into a grid, a meta grid that I called it. But enough about me.

What I find so interesting is that you changed one particular team in the team topology setup which is the platform team. And it's based, and I guess your co-author, Matthew, he said that you actually discussed it during the writing of the first edition, but- Yes ... then it got lost in some Slack thread or something.

But you changed the setup, you changed the name from platform team to a platform grouping. Why is that? Yeah.

Why is it a platform grouping now? So if I may just to mention the second edition- Mm-hmm ... for people who have not seen it.

So the idea was we didn't sort of touch the first edition because like I said earlier everything that was in the first edition still stands, basically. Maybe we're not talking as much about DevOps as we were in 2019, but the ideas still stand. And then what we did was there's a new forward, which is mostly looking backwards in the five, six years since the first edition was published, and what were the things that also we got wrong or that were not clear enough in the first book, like what were the principles behind it, and then things like how the patterns were adopted in different ways by different companies like Telenet that I mentioned earlier, applying the types of teams, but at the tribe level.

So, and then there's a new afterword, which is kind of more connecting to where we are today and the next years with AI and how does that change or not, how we think about the organizational dynamics. And then there are 10 new case studies, and then there's that note about the platform grouping. So what happened the first edition is we wanted to keep it simple.

So the idea of the platform team, one hand to keep it simple, the platform team as another type of team because some people say, well, it's kind of a product team because it's an internal product. Yes, but we felt like there were enough differences because you have internal customers, not external, and often you're providing, often from a technical point of view complex services. We were talking about a lot of the kind of technical services.

So what we kind of missed, and maybe this is something I didn't realize at the time of the first edition, is how that idea of the platform team would be sort of misunderstood sometimes as in a single team that is responsible for a whole platform. And of course, over time, your internal platforms tend to grow. If they're successful, which is a good thing, they will tend to grow.

And so for me at least, it was, I guess one of those things that to me seemed kind of obvious that you would need multiple teams, and you would need for this bigger platform. If it's small and you have one or two teams, that's fine. But if you start having three, four, five, or you start having basically more than, I would say, 30 people working in the platform, you need to think what are the different streams inside the platform, right?

What are the different services so that you also organize the platform structure from a team perspective, similar way as you do for your products. We need to identify different streams if it's just customers are internal. And that's the part where in some organizations we would talk to them and realize they just had this massive platform team with dozens of people, and of course, they were extremely busy, extremely overloaded, running around trying to work on fixing stuff and trying to deliver new stuff, but it was all very ad hoc.

So that's why in the second edition, we try to make it much more clear that in fact, and maybe that's a better framing, is it's always a platform grouping. You're going to have set of teams, and they should have well-defined responsibilities and boundaries between them. Doesn't mean that they're totally independent all the time, but we should not have five teams that need to coordinate work all the time.

And so if you start to think from it's a platform grouping, but in some times it's only one team in that grouping, maybe that's a better way to think about it, which we missed in the first edition. On the other hand, because it was simpler when we talked about platform teams, it helped, I think, also organizations to understand difference between platform and streamline on the product side. But now it's hopefully clear.

Yeah, sure.

No, but I agree, and I obviously am thinking about similar things. I'm currently writing the second edition of my first book, "The Enterprise Data Catalog," and it's a little bit the same thing, right, in terms of the first edition talks about one data catalog in a company and one data catalog only.The reality is that in most cases, you will have a handful of data catalogs. Yeah.

And they will be rooted or located in various parts of the business. Some use just one cloud provider, some use just a specific data platform with their attached catalog. It's just like that is a very natural thing.

Yeah. And I guess it's the privilege of writing a second edition. There are not a lot of privileges in that.

It's hard work. But one of them is that you get to build on the established knowledge of the first edition, right? Yeah.

So, it would've been difficult, I would sense. Yeah. I would say it's actually a good indicator if you realize in the second edition there were some things in the first edition that were misunderstood.

It means that they were adopted, right, and organizations were applying the ideas. It's just maybe some things were not as clear as they could've been. But that's one of the things, as with developing products and services, you realize that this is what we thought was what made sense.

Actually, we need to adjust and course-correct.

So I kind of see the second edition as we're course-correcting or adding more context and adding more kind of insights to what was already there in the first edition. Mm-hmm. Absolutely.

And I want to go into details about, so specifically for the second edition, as you mentioned, there are a lot of case studies. And I think we should go into these case studies. I focused on two, but you're welcome to mention the third one.

But- Sure ... I think EBSCO, I believe is the... I'm getting a lot of notifications on a different platform, and I'm just shutting it off.

Just sorry. No worries. It's just a lot of noise.

Too many attention requests. Yeah, exactly. There we go.

So, there you are. Great. So basically, let's first talk about, what is the name, EBSCO, of the first use case.

Is it EBSCO, the company? Yeah, EBSCO. EBSCO.

The reason why I wanted to talk about that case, obviously it's a smaller one, I believe. But it's interesting that they have been working with a framework for setting up teams also, like Team Topologies. They have thought about building an organizational structure that could help them deliver more, and that is SafeAgile.

But in this case- Yeah ... they kind of ran out of potential with SafeAgile. And can you unfold why is that, and what did you do- Yeah ...

that changed their setup? So I didn't do work on that directly. And actually, most of the case studies, which is interesting, in the second edition, we were not involved directly.

It's not that we were doing the change for them. This was how the companies themselves thought about applying the ideas and how they change, and that's really cool. And then, by different means, we ended up finding out, or they came to us and talked about what they had done.

In some cases, we had done maybe some keynotes or some training. But often, in the case studies in the second edition, we were not directly involved. So I think that's pretty cool as well.

So EBSCO is one of those interesting ones where I'm guessing if you ask anyone in the audience here, I would guess almost no one heard about EBSCO. And then you realize, oh, this is actually a pretty big company. So they provide research databases and information for libraries, universities, et cetera.

So it's one of those businesses not something that's talked about very often. And what happened was they had been using Safe, I would say, fairly successful. Obviously, Safe is a framework that depending, in my view, if you're starting from a very chaotic organization where there's always delays and everyone's running around, and everyone's trying to get stuff done, but it's always big chaos.

Of course, I think Safe can help give you some structure and figure out how to do better planning, and it provides you a lot of clarity, I would say, on dependencies that you have between teams, between domains or value streams. The issue with Safe is that at some point, and we've seen this not just with EBSCO, with other companies, it kind of helps you move from that early stage of more chaotic and to something more structured, a bit more or a lot more predictable.But at some point, it kind of stops helping in the sense of it's very much about managing dependencies and not so much about removing them or dealing with the effects of those dependencies. Mm-hmm.

Basically, you start living with it. Okay, we know the dependencies. We know we need to do this planning so that we can have usually a quarterly plan for which teams are going to have to work on which initiatives or features, et cetera.

So depending, like I said, if you're starting from a point where everything was chaotic and all the deadlines were missed, then yes, that helps. But then you're kind of stopped there. And so what they did at EBSCO really well was that they had really good metrics, like slow metrics, and looking at where are the bottlenecks, where are the wait times to deliver the value to our customers or deliver changes to hopefully will be valuable to our customers.

And so they themselves started to realize, okay, we've improved a lot, but we're sort of stagnated, right? We got to, let's say, a peak of what SAFe can help us with. And so then they turned to team topologies to then start addressing, okay, let's not just live with the dependencies.

We actually need to be then using the patterns to remove blocking dependencies, provide internal capabilities that actually help accelerate teams. And because they had very good internal organizational telemetry, if you like, very good metrics. And that's part of why the case studies was interesting to us is that then they were able to see how using team topologies helped improve those metrics.

Yeah, exactly. And I guess if you are SAFe Agile certified like me and like many others, you can kind of sense that there's an upper limit as to how much it can deliver, right? Mm.

I've heard people call it a framework monolith. I don't know if you want to adapt that given that it's a competing framework. But if you take a look at it, on their webpage, there are a lot of boxes that you need to understand and how they relate in order to...

It's not a simple setup. It's a big upfront investment on one hand, and then to me, besides that kind of investment aspect, it seems to lead you... So we were talking earlier how we need to be adaptive and sort of continuously evolve, and I think, and I'm now no SAFe expert, but from what I've seen, is it seems to lead you to a point where you get this kind of, yeah, stable, monolithic framework, whatever which works within that scope, but then you're sort of not really thinking about what's the next step.

How do we continue to improve? And obviously there's the release trains and all this stuff which, yeah, I think, like you said, represents it well. It helps to some extent, but then there's an upper limit because we're coupled in these release trains and anyway, it was interesting.

At some point, SAFe took some ideas from team topologies, but not others, which to me... Mm. Yeah, so they took essentially the team types, which I think was a step forward.

But you're still not necessarily thinking about improving your flow just by adopting the team types. And if you still have those release trains, you're still coupling, at least temporally coupling a lot of the work, which tends to then manifest in coupling at the technical level as well, right? Because if we're going to do a release together anyway in, whatever, four weeks, why should I invest in making this more modular and can evolve more independently if at the end of the day, we have to integrate everything together?

Yeah. So change the end of this conversation a bit by simply admitting that I think SAFe Agile is a patchwork of methodologies. I actually didn't know that they took stuff from team topologies, but that's very typical of them, right?

They also took stuff from Lean and other principles, and so obviously if you believe in that, maybe it can provide a lot of value. I think it can at a basic level, but it gets very complicated. I wanted to ask you about another case study, but I think we're running out of time, and so instead, it's the Adidas case study.

I just find their platform, the digital platform architecture, really interesting, but we don't have time. It's too complicated- Yeah ... to go through in a couple of minutes.

So instead, I was thinking, we were talking a bit before we went live, and so instead, I want to ask another question, a more high-level one, is that you published these books at IT Revolution. It's just such a great publishing house. The home of "The Phoenix Project" and many other very influential books, even though they don't publish a lot of books.

How did you establish the work with them, and what's kind of theirLike the nature of that publishing house. Yeah. So they are very focused on essentially helping enterprise leaders.

And the books they publish, like you said, it only a handful of books per year. They're a small house, and they're really focused on publishing the books that are relevant and make sense for enterprise leaders. Obviously, different publishing companies have different strategies.

Some based on volume. Their focus is on quality of what they publish. And like you said, the reason why they had already published some seminal books, "Phoenix Project," "Accelerate," and "From Project to Product" from Mik Kersten as well.

So we felt that our book, which our intention on... We thought our target audience initially was going to be enterprise leaders, also business leaders and senior engineers and architects. And so it was a very good match with the IT Revolution audience.

I knew Gene Kim from before, from my work with DevOps, so yeah, it all just seemed to make sense. At least I wasn't actually at the time as familiar with kind of the publishing world and these different approaches to publishing and editing. So I think we were very lucky that they accepted, they saw the value of our proposal, and then they have a very thorough editorial process.

So if you would read the first draft of "Team Topologies," that was going to be hard because it was very much, as many people who never wrote a book before, sort of academic in structure and the editors at IT Revolution, shout out to them, they really helped us. "Okay, let's turn this into an actual narrative that people can consume, they can reference later," like you were saying about the first edition. Our goal was also a book that people can read it and then come back later.

"Oh, I remember something in chapter six that would be helpful for my current situation," so as a reference. So they really helped turn that first draft into way better version. And we trusted them because in the beginning, we're like, "They want to destroy our work." That's how it feels, right?

When someone's saying, "You need to rearrange a lot of the way you're talking about in the book." So yeah, that was sort of the story, and that made a huge difference, I think, also in success of the book, or I'm sure.

Yeah. And thank you for sharing that detail also. We're running out of time.

I discovered a question in the Q&A from Sabrina Sheila. We don't have time to go through it. I'll send it to you, and maybe we can answer it offline.

But Manuel, I want to take the time to thank you very much for being on here, Data Explored. I hope the listeners got a lot out of it. I certainly did.

I wish the second edition a fantastic life, and- Thank you ... that you will stay in touch. We will.

Thank you so much. It was my pleasure. Thank you.