Often we're focused on what are the good practices or best practices? And what's the best way to do things? Practices and principles are obviously necessary and useful, but they should be informed by. What are the constraints in the first place? Constraints are usually things. We cannot really change. So limits on cognitive load limits on trust between groups of teams. Conway's law are things, we
cannot really change. So we need to acknowledge them and then build and decide on practices and principles based on that. Because if we don't, then we might be be fighting this constraints rather than understanding and leveraging them in our advantage. Hey everyone. My name is Henry Surya be Robin.
And you're listening to the tekhelet Juno, the show will be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello to all of you my listeners. It's great to be back here again with another new episode of the
tackling Journal podcast. Thanks for spending your time with me today, listening to this episode. If you haven't, please subscribe to technology, you know on your favorite podcast apps and also follow technology. No social media channels on LinkedIn, Twitter and Instagram. And you can also make some contribution to the show and support the creation of this podcast by subscribing, as a patron at package, you know, dot f / Patron. And help me towards producing great content every week for
today's episode. I'm very happy to share my conversation with manual Pysch manual is the co-author of the team topologies book. A devops thought leader, and an independent, it organizational consultant focusing on. Team interactions delivery practices and accelerating flow effective software. Teams are essential for any organization to deliver value, continuously and sustainably.
But how do you actually build the best team Organization for your specific goals culture, and needs in the book? Team topologies manual and his co-author Matthew skeleton. Share secrets of successful team patterns and interactions to help it organizations choose and evolve the right team patterns to ensure success making sure to keep the software healthy and to optimize for Value streams. In this episode manual, shared
great insights from his book. Team topologies starting from highlighting some constraints that organizations, typically, face such as Conway's law and cognitive load manual, then explain the four fundamental team topologies, and how they can help to address those constraints. He also shared about the team API concept, as well as the three call interaction modes, which inform how teams should interact with each other in order to improve the overall
flow within the business. Finally manual. Shared some advice on how we can. All start implementing these ideas within our organizations. I personally really enjoyed this conversation and I hope you will enjoy this episode to consider helping the show by living it.
The rating review or comment on your podcast app and social media channels those reviews and comments are one of the best ways to help me get this podcast to reach more listeners and hopefully they can also benefit from all the contents in this podcast. So let's get this episode started right? After our sponsor message. Are you looking for a new cool swag. Technology, you know. Now offers you some swags that
you can purchase online. These wax are printed on demand based on your preference and will be delivered safely to you all over the world where shipping is available. Check out all the cool swag is available by visiting technology, you know, the dev slash shop and don't forget to break yourself. Once you receive any of those tracks. Hey, everyone. Good to see you again. Today. We have a new episode of the package.
You know, I have someone who I admired as the co-author of a book that has a rave Review called team topologies organizing Business and Technology teams for fast flow. So if you have a heard about the book or maybe already read the book, you know, what kind of things that I'm talking about. This person is Manuel, piyush, is actually one of the calls.
The, and I'm really looking forward today to learn more about teams, apologies, how we actually should structure a Or maybe some of the anti patterns that we should avoid when organizing team and also within a company. So thanks again manual for agreeing to this conversation. So looking forward to have a chat with you. Thanks for having me. Great to be here. Someone. Well before we start talking about teams, apologies and all that may be for you to introduce
yourself. Maybe telling about your career background and highlights and turning points. Sure. So I have a background in computer science. As does my co-author Matthew skeleton. I've had a number of different roles from Developers. To tester build engineer team lead, keyway Etc. That kind of gave me a broader perspective within the software delivery environment of different roles, dependencies between different teams, different skills that are needed.
Especially when devops and continuous delivery kind of came about ten years ago or so. It struck a chord with me that yes, this is very much what we need to think about the flow of development of software as well as the production and the life support. Port. And we need better ways for teams to communicate to each other. Understand dependencies between them because before that was very much based on specializing by skills and by competencies each team trying to be a
specialized as possible. We've seen that doesn't work, especially if we don't think about the ecosystem of teams, right? One of these teams, you know, isolation cannot do the work. That is needed to get the actual software product, or service available to customers. So, basically, I embraced devops Good news delivery. I became lead editor for info Q around devops as well. It's been a great journey of meeting really amazing people with great. Insights since 2015.
Then I started doing consulting. And so, working with different clients around the world. Understanding, what are the obstacles for them to basically accelerate being able to respond faster to the customers? And also to changes in market and adapting to new situations. Obviously, it's always that mix of Technology people and processes.
These. But with team topologies in particular, we're trying to both raise awareness of certain constraints and certain kind of human focused aspects that are important to understand, for organizations, to be able to accelerate or become higher performing, as well as providing some tools. And some ways of thinking that can help guide this organizations to a better operating model. If you like that is more team focused. So, maybe let's go into that topic itself out team topologies.
So, in the first place, You wrote this book, what exactly the core message of principle or even the problems that you for. Seeing during that time that lets you into writing this book. We did a lot of Consulting around devops and continuous delivery. Many clients wanted help with some new tool set adopting some better practices and that's all good and well and it helps to some extent.
But in many organizations, they're not looking at the elephant in the room where teams are not communicating in an effective way. Teams don't even know sometimes who they have to ask for certain things. You have that, what I mentioned, very strict separation of concerns and responsibilities, which means you introduce a lot of dependencies to get any sort of value to customers out. The door means it has to go through many teams doing small things. And so that's not conducive to
fast flow. You can have the best tool set in the market and that's only going to help you to some extent. When you have the combination of do flow of work in the team's, it flows. Well, Because the team has sufficient autonomy. And they understand their dependencies. We avoid that sort of blocking dependencies where one team has to wait for another team to do something.
Once we achieve that sort of faster flow with more autonomy than yes, the tools can then hyphen even more this sort of fast flow, get better data, get better automation, Etc. But if we just start with Automation and tooling, we quickly run against challenges in terms of Team structures and communication. So that's what we were saying, recurrently with clients. We thought that some point. We had seen enough patterns that work and patterns that didn't
work. Also a lot of learning from the devops Enterprise Summit this conference. That happens every year from the Publishers of the book as well. It Revolution. So a lot of stories that were being shared by different organizations on some of the patterns that work and we didn't work. So we sort of brought all that together into the book. So I think, what I hear you say is that a lot of teams this day, they will definitely start with tools and Technologies,
probably, right? Thing about how to implement those, but actually, without looking necessarily to what the team structure or even the rock structure at that point in time within the company, you mentioned, interestingly in the book. Actually. The first problem is with the org charts itself. Why do you think typically of chart is maybe the first problem? We're all this may be a barrier to fast flow. Maybe barrier into dependencies
blockage and things like that. So maybe you can explain a little bit around that sure. So let me say the org chart is not a problem per se. It's not that we shouldn't have or shorts. They have important benefits in terms of understanding how we are. Organized special in large organizations. It helps with reporting and hopefully also helps with kind of top-down alignment of strategic goals for the
organization. So everyone understands, how are we related and how does our work relates to the goals that the organization is trying to achieve? So that's all fine. The problem that tends to happen is when in a way, we give too much importance to the org chart. In the sense that People started looking at it as specifying, all the decision, making lines and specifying with home. Should we interact or not? If this team is in another department and we shouldn't talk
to them directly. We need to go up to Yaar Ki and then down the arrow key to get the team. Those sort of things is where it starts to become a challenge to fast flow because with the complexity of modern software delivery and operations, you can do that, but you won't achieve fast flow because there's too many steps and too much redirection in a way through the They are key to get to the actual work getting done. So we want to favor for fast
flow. You want to favor, local decisions and having teams interact with the right things at the right time. And so, when you introduce those sort of blockers with the arrow key and decision-making, having to be top down, then we're not allowing the people who are doing the work and closer to the customer to, actually make the best decisions. That's where really the org chart can become a problem where people see it as imposing the communication, lines and imposing Making lines between
teams. That's the key issue there where it becomes an obstacle to fast flow. If we misinterpret the org chart as dictating, all these things. Unfortunately, in many organizations that tends to happen. It also is coupled with the problem that in some organizations. The worth of the managers senior managers is linked to how many people report to them and that kind of feeds into this narrative that you need to go up the hierarchy for any kind of
decision making. So that we Can show proof that the value of the senior managers? Hopefully, with Team topologies. This sort of approach is being replaced or move away from that to more. How do we enable the people and the teams who are under our year, key to actually be able to make better decisions, more autonomously and not depend on the are key. So if I get the sense that fast flow is actually of course, it's like the main objective that we want to achieve.
But let's say, if we are currently working in a team or in a company, how do we actually Identify whether we have a good flow, fast flow, slow flow is any exercises? Then guidance on how to actually find out where we are at this point in time. Yeah. So a couple of things. Well, first, there's a very straightforward metric called flow efficiency, which is essentially looking at how long it takes from the moment.
We have an idea for a new feature or new service until it's actually available to the customer. So the full kind of lead time from idea to production. And from that overall, elapsed time how much have we actually spent working on this feature service versus how much was wait time? So it turns out that in many organizations. The actual work time is about 15
percent or less. So that means out of 100 days, maybe that it takes to get a feature out, 15 days, where actually work days and 85 days were waiting for someone else or another team to have availability or someone to approve or make a decision. When you look at that metric, which in a way, Very simple, then you can sort of, like, starting to unfold the flow problems, right? You can start looking at. Okay, if we spent all this weight time, where exactly did we spend this?
Wait time? We spend maybe a week or two weeks, waiting for some infrastructure to be available, or we waited one week for some approval to start digging into that. And you start seeing where are the, wait times, that we want to reduce if we want to achieve faster delivery. So that's one thing. Also, the nice thing about that is you can then look at the
flow. Efficiency at different levels, you can look within the cycle time since we start coding until if we deploy or you can look at the broader picture of since we started since we approve this idea until it's actually start to be used by customers. So you can start wherever it makes more sense. Sometimes teams don't have a global view of all the steps in the process and they might want to look at their own domain of responsibility and understand.
Where are we kind of slowing down, but obviously, at some point you want to have a more systemvue. Do you want to see? Because a lot of people say that about agile some organizations have successfully sort of adopted agile principles. They have accelerated the speed of the agile teams, but when you look at the big picture, how long it takes between an idea actually being approved and going to production. Maybe there are a lot more teams involved. Maybe you need financial
approval. You need product, team, product owner, or product manager approval. A lot of different steps. Might be required to actually get until the agile team starts working on this. So yeah, flow efficiency and then obviously also value stream mapping. So that's the technique for actually looking at the overall process and looking at dependencies between teams, looking at where their cues were work. Piles up for some teams.
That's more kind of visualizing this whole process, but in terms of metric, then the flow efficiencies is quite helpful. So I think also another anti pattern that normally I heard a lot then it is mentioned a lot of times in the book as well, which is about Conway's law. Maybe, can you explain a little bit on that? What do you mean by Conway's law for people who are not familiar with it?
Yeah, so I'd like to see it as a constraint, not necessarily anti-pattern, just something that we should be aware. Especially in software driven. Organizations is Conway's law. That means is from a paper by Amell Conway, which was published in 1968. So it's been around for a long time, but it got more traction with the rise of micro services and people started seeing in practice how this is actually happening. Basically. It says one of the corollaries in that paper that became known
as Conway's law. Says that the structures that your organization has and the communication paths between teams strongly influences, the system architecture that we can achieve. So that means we might have wonderful architecture that we've designed and that's what we're trying to build for customers. But then if the team structures are very different and we don't have the necessary communication paths in place to achieve that system architecture, either. We will end up with something.
In quite different on the system architecture or it's going to cost us a lot more. There's going to be a lot more challenges because of poor communication responsibilities that are not aligned to the responsibilities that we expect in different parts of the system and so on. So we should see this as a constraint. It has been validated across different Industries, Conway's
law. And like I said, with microservices, people started to see these more because unfortunately, in many places, they thought, well, yeah, this is the right, architectures, going to lie. Allow us to go faster, but then they forgot the alignment of the team structures and communication paths. And so they ended up with still needing any kind of non trivial change or feature to require coordination between multiple
teams. The when with microservices the expectation was that each team will be able to evolve more independently. And so that's the idea of Conway's law. So if we are aware of that we can then make better decisions. We can apply what people call reverse Conway, maneuver, where it means.
Okay, we can design Our kind of Ideal system architecture that we think, is going to be a better fit for the requirements of the customers, and also the non-functional requirements and then let's look at our team structures and Communications and maybe adapt them to be more aligned with the system
architecture. There's also a great quote from Michael Nygaard, who wrote the book, release it, where he says, when you ship a product, you're also shipping the organization structures with it. So basically he's talking about Conway's law and the fact that you get this mirroring effect in the system of the actual structures you have in the organization just to add to that, another corollary from that paper from Canal. Conway was that if you have a
very rigid organization structure, and we go back to your previous question about organization chart if that's very static and regions, and it doesn't change easily even at the team level, that means we're effectively constraining the kind of solutions. We're able to find for our systems. There might be a range of solutions that we don't even think about just because of the Teams are set up, especially if they're very rigid and it's hard
to change. So, one related, question that I have does it necessarily have to start from the system architecture, or the ideal architecture that we have because in a company or business, there are so many other departments, for example, from Finance from business, from a bi-product. Does it always necessarily have to start from product architecture? Like maybe from technology point of view, or do you actually also has a lineman with the product team first?
Like, okay, based on how the business do the business model? Also aligned with the strategy with the technology team on it. Then you come up with a team strategy, maybe a little bit clarification here. Yeah. That's a really good question. So, two things first.
Let me say there are many decisions being made in organization outside it that actually, because of Conway's law can end up having an influence on the system architecture, if team composition and team structures are decided, for example, by a jar, and there's no sort of input from the technical side on, how does this impact to the work? We're able to do on the system
and the software. Then it jarred some extent is making decisions on that architecture because we're limiting the possibilities that we can achieve because of Conway's law. So that's definitely impact from other parts of the organization in terms of what we can achieve.
Even if you think about now that we're in this remote or hybrid world the way you set up your communication tools, your slack, or Microsoft teams, or what have you, and might actually have some influence in the way that teams communicate. Because if any team that depends on another Team that's in another slack. That I don't have easy way to communicate with them. That's actually going to restrict our capacity to decide together based on our dependencies. The other thing I wanted to
mention. I think you're absolutely right that this decisions doesn't start only at the system architecture level. So especially if we want to have teams that are more autonomous that can deliver and have more ownership over a slice of a larger product, which tends to be the case in many organizations that we have larger products or services. Customs, have a limited number of team members, then we need to break down this larger product into smaller chunks. And that's another problem.
We've seen often is that even on the business model side, if you like there is sometimes monolith organizations that grew over time and because they were successful and they delivered useful products and services, but things started to get a little bit messy and we don't have Clarity anymore on. What exactly are the different sort of business lines or the different value that we provide to customers. Is it becomes blurred and you get this software monolith?
Yes, but also model is on the business model side at the same time because we just build on top of what we had before and now it's very hard also to decouple the teams. And so when we want to do that, we need to start with actually the business model, understand. Okay, what are the different value streams going back to that as well? What are the business value streams?
What are the things that customers pay for or are interested to that we provide so that we can then Have better understanding what are the independent lines of business that we can then align teams and have those teams deliver value more independently. So yes, it basically starts. They're speaking about monolith, since you mentioned about it, many teams, probably currently work with the Monopoly system, supporting multi lines of businesses and business models.
And of course, the biggest topic everyone wants to talk about is how to break monolith into microservices. Is there any good practice from the team topologies point of view? How to actually conduct? This exercise. Yeah, so we tend to recommend that you take a step back before going into microservices. It can be very helpful. But before we go to that sort of level of granularity, if you look at the monolith, what we talk about in the book are fracture planes.
Look at the ways that we can split the monolith that are effective and that will allow teams to align to this different smaller pieces. Microservices tend to be from a more technical perspective. How do we split? Listen to into different parts, but actually there are different fracture planes. You can think about obviously what we just discussed before about the business value streams. That would be the main kind of way that we would split the monolith in the language of
domain-driven design. This would be your sort of bounded context that you understand, this more or less independent from other contacts of business, but then, there are other ways. So, we might even be splitting monolith to some extent based on the location of teams on the
time zone. Owns of teams because if you have two teams that almost have no overlap in terms of their time zone or the working hours because of their time zone, then it's probably a good idea that they're working on very different parts of the same system. So they're not working on things that might cause dependencies between them because it will be very hard to communicate between those two teams. And we talked about other ideas.
You might have some performance or regulatory requirements on some parts of the system, which means it makes sense that this is split from the rest. Stand the sign to one team or a few teams to take care of. So usually you will need a combination of fracture planes, especially the larger, the monolith to actually make sense of that. And so I think that's the sort of slightly higher level
perspective to start with. Then the microservices, you do, this more coarse-grained split of the monolith and then you might look into more fine-grained split with microservices. I think the other aspect to consider is the cognitive load on teams that we talk about in the book. We also want to split and be mindful of what is the capacity of a single team. Do we need to split further some larger pieces of the system.
So that actually the smaller pieces fit the capacity of the different teams, or does this look like it's reasonable size for a single team to own and to end and we're still talking about hopefully vertical slices of the original Monmouth. So these cognitive load seems to be like a key concept within team topologies. Maybe can you share a little bit? What do you mean by? Cognitive load and how do we actually measure whether the current team really has a good enough?
Cognitive load capacity or is it like too much of it or maybe even less than it? So maybe can you explain? What is cognitive load in this sense? Yeah. So cognitive load is another sort of constraint on how much we can achieve and how can we get teams to be high-performing? If we don't like Conway's law, if we're not aware of the limits of cognitive load or cognitive capacity on teams, then we're probably gonna not, Be able to
achieve high performance. So cognitive load theory is actually based on individuals and it's how much of our working memory is being used at the moment in time. So that's four individual. So this comes from field of psychology. This was coined by John sweller. But what we did with him topology is actually understand this applies at the team level as well.
It's not a scientifically defined term if you like the actually research going on by John swallow and others on group cognitive load, so, It's actually an emerging area. What we identified is that there is a limit to the capacity of
the team. Again, if the team has too many responsibilities or responsible for two large size of the system that are not able to fully understand and grasp how this code Works how this relates to other parts of the system, because it's too much for our capacity or we have too many responsibilities. And basically we're always running around trying to just respond to requests in the sort of firefighting mode and context switching.
All the time. That's not going to be conducive to better performance, more autonomy and more ownership in those teams. Then cognitive load also can be split in different types. So we start to understand better. Yes, the overall idea that teams have a finite capacity of what they can understand and be comfortable with. But also, there are different
types of cognitive load. The things we want to maximize have to do with understanding the business and the standing, the customers understanding, obviously the system, the code itself, how it Listen how we improve it? All those are more related to what is called the germane cognitive load, everything related, to this solution to the
problem and the solution space. But there are other types of cognitive load, like extraneous and intrinsic extraneous is related to all the tasks that we need to do to deliver our work. How do I deploy my application? How do I run the tests? How do I access the test database? All these things that need to happen, but are not directly related to the problem and the value. We're providing to the customers and So that's where we should focus in terms of minimizing that cognitive load.
That's why we introduced the four types of teams and the Three core interaction modes, which are meant to provide a sort of ecosystem of teams where you have the teams focused on the services, but we call streamline teams aligned to the business value streams. How do we minimize their cognitive load by providing useful services in a platform for example abstractions that help these teams go faster and deploy without worrying about all the details.
Or monitor our service without having to install all the infrastructure and the tooling. If that can be provided by platform services that are focused on the experience, on minimizing the effort for the Streamline teams to understand how to do these things. With good abstractions and good developer experience. Then we help them minimize cognitive load the extraneous kind. So they have more sort of mental space to understand the business
as well as the code itself. So they can better evolve and support it. So I think this is enough. Oh, the good segue to actually describe. What are the four fundamental team topologies? You mentioned in the book. So you have mentioned like streamline team and platform, maybe a brief description of all the for for the audience here to listen. So we start with streamline teams. So this would be teams with end-to-end ownership.
Obviously. There are other terms that are similar like product teams cross-functional teams. We call them streamline teams because we thought the provided a more specific definition, because sometimes you have streams of work that are not necessarily. Product or a part of a larger product. So that's the starting point. So, ideally in organization you have, mostly streamline teams that are providing value to customers and have end-to-end ownership.
But because of cognitive load, that means this might introduce a lot of Demand on this team because we're saying, well, you need to understand the customer problems. You need to understand then how to build a solution with software. You need to understand how to deploy, how to run the solution to minimize that sort of cognitive load with an have platform that I mentioned
earlier. Layer where you have platform teams that are focused on. Providing the Streamline teams are their customers their focus on providing value to our internal teams, but also in this product Focus way where we need to understand our own internal customers and what do they really need? So we don't go off and build everything that we think they need but actually we talk to them, we get quick prototypes, we get fast, validation of, is this what's going to really help you?
And then we have two more types of teams supporting and helping reduce cognitive load. One of them is enabling teams. This teams don't usually build any service. They are sort of experts in some domain. What they do is help the Streamline teams in particular, but maybe also platform teams, increase their awareness, and their understanding around different domains. Then this might be more technical understanding about
test automation. For example, monitoring or can be more kind of product domains understanding more about user experience. And understanding more about regulations, perhaps in certain industries. These teams are usually small team of experts in the enabling team that are going and helping upskill the Streamline teams so that they have the necessary knowledge to do their work more
autonomously. Not that we, we need everyone to become an expert in these domains, but at least have a sort of working knowledge that we can do the common tasks in the lifecycle. And finally, we have complicated subsystem teams, which are optional, we realize in some cases you do need these teams again because of cognitive load. So if you have a streamline team where Out of their service includes. For example, face recognition
functionality nowadays. There are many sort of solutions, but I actually worked on some systems like that about 10 years ago where they weren't. Well, the third party offerings that exist today. It was actually you needed someone with a PhD to understand the algorithm and the stand how to make changes how to test in those cases. It makes sense to have a complicated subsystem team where you say, there's a part of a larger service that really requires, very specialized knowledge.
PhD. Type of knowledge, usually, not technology specialization, although in some particular cases might be the case where this team exists because they are helping reduce cognitive load on the Streamline team. So you could have one complicated subsystem team that only exists to help one streamline team. Maybe that's the only customer of this complicated subsystem, but it still makes sense because we reduce their cognitive load.
They wouldn't be able to have end-to-end ownership of a service where there's one part that is super complicated, but In general, we find this should only be needed in very particular case. So most organizations probably shouldn't have any complicated subsystem teams and in some cases, they might need one or two maximum. So you mentioned that the last one the complicated subsystem team actually is an optional thing.
But how about the other three? The Streamline team, the enabling team and the platform team, that's a company need to have all of them because now these days the way I think of it enabling team, probably a Consulting team can come in and help too. Enable teams. And also platform. We are talking about Cloud platforms. And so many platform as a service providers. That's the company need to necessarily have these three teams that you mentioned in the
beginning. So it's not necessarily that you need two teams. I would say any organization will be in a better place if they have the thinking around this types of teams. So platform thinking enabling thinking. So what do I mean with that? Well to some extreme because we get this question often. If we're a small start-up we can't have all these different teams. So if Start from that, sort of
extreme. And yes, you won't be able to have stream teams platform team plus enabling, but you can have the thinking's. So, the platform might be something as simple as, okay. We use, let's say awas, and we use some other sauce providers, but the platform, maybe it's just a Wiki page, that helps teams. Understand. How do we use that provide some useful, kind of default some useful recommendations on use serverless for this types of tasks.
And this is how you can get started or use other services. Visas for other types of work. In a way, you can define a platform as just a Wiki page, helping guide teams and basically building in the shared knowledge of what works and what doesn't even if we're a start-up and the same for enabling teams understanding that. First of all, we know that technology is always evolving and new practices are coming up 10 years ago was developed and five years ago. I think. Was that sorry started.
That's not going to change that. Sort of evolution is going to continue to be aware of. How do we help teams? Evolve in a way that doesn't depend on their free time or depend on people having the willingness to learn outside of work. We shouldn't expect that from people. We should find ways and enabling
teams or dignity. This enabling thinking is a way of allowing teams to grow, and to gain new capabilities over time, but you might not have a team, you might have a couple of people, for example, in a start-up who have been there longer, maybe are more senior. And so, maybe they dedicate part of their time to facilitate knowledge to others. Yes, or maybe even between more Senior Team and more junior
team. If the startup is growing, where one team is helping facilitate the other, they're not fully dedicated. But at least you start having thus enabling thinking. And then at some sort of size. It starts to make sense that you have platform teams because if you have many streamline teams, you started want to have ways to embed good practices in the platform while considering also the specific needs of different teams.
So starts to make sense to have platform teams and perhaps, Seems that depends also a lot on the domain. Like I said, you might have some Consultants helping so we have one example in the book. Exactly like that where an enabling team was set up with some external Consultants that brought sort of the knowledge around continuous delivery and modern practices for software delivery. And then you had some internal people who had the application,
the system knowledge. So these people together made for a good enabling team that helped accelerate their delivery setup, some good practices and then expired in a way that the team cuz they had achieved their goals. There are other domains where you might need a more long-term enabling team, for example, P user experience or other areas where there's a constant need to evolve the learning and the skills of different teams. So it really depends.
But the thinking of why we need this type of approach is what really matters at any scale. Thanks for that clarification. So when we have these teams, for example, let's say we have a streamline team and also platform team or even multiple streamline teams. In the company, you can have multiple products and business lines. I think in the book, you mentioned this concept called team API how the team should interact with each other.
I mean, a lot of software developers understands about API, like software apis, but what about team API? What is actually team API? So it's a bit of a techie term, right? So apis, application programming interface is defining the way that you interact with some system or service through this API. Basically, it's an interface. So what we're saying is the team API is the interface to the Team the objective of the team apis for a team to clarify two other teams.
How do we work? How do we like to communicate and interact with other teams? What are the practices that we follow? Also? What is our sort of roadmap? What are we working on? What's coming next? It's very much focused on what other teams need to know about us. What's going to be helpful for other teams to interact and understand what we do. So it's bit different from, for example. Team working agreement, that tends to be internal to the team where Say okay.
This is how we work together inside the team. This is how we follow scrum or we follow TD or what practices do we do internally? And so there might be some overlap but the intent is quite different. So the team API is actually making it easier for others to interface with us as a team. So that we have more clarity and less ambiguity on how other teams should interact with us. So maybe, can you share with us? What are some of the good practices for team apis? Maybe for us to implement?
Until within our daily working life. Yeah, it's really thinking about the other team's perspective. So it's a little bit of having that empathy as well to understand. If other teams might be frustrated in terms of their interactions with us, or they don't understand what we do. Okay, how can we make that better? How can we clarify that through the team API, perhaps what? I usually recommend two teams is the team API, should not be a static artifact.
You should evolve it over time as you realize that Problems or awkward interactions have happened with other teams. So if for example, we often get slack messages from other teams asking similar questions with this something that we could actually make visible in the API. Maybe there's some documentation that just people don't know how to access it. So, with the team API, is a sort of single entry point to our team. That's where we should. Then make it clear?
This sort of questions. Look at this document and you'll find the answer, probably in, if not contact us. So we make that That sort of communication easier and we also reduce the overload on our team on some things that maybe we didn't expect to get questions because we have documentation, but actually it's not visible. It's not easy to access. You can't expect other teams to know where all of your documentation is or we'll all of your practices are.
It's really providing this single entry point to help other teams interact with us. And this is also related to the tree interaction modes that you mentioned in the book, right? So maybe you can share a little bit. What are the Interaction modes that you mentioned. Yes. So besides the four fundamental types of teams we talked about, then we have the Three core interaction modes, which helped these teams understand what are some useful ways for us to interact.
What are the expected behaviors from us as a team when we're doing this interaction, with other teams in many organizations. There is this sort of naive expectation that well. We just collaborate whenever we need but that's very Loosely defined. Find, right. What does that actually mean? What is the purpose of this collaboration? And so many teams, actually, when they're talking about cooperation with other teams. It's actually more.
The relationship they have with other teams, the dependency they have. They're not actually having specific concrete ways of interacting specifically what we described in the book that we found to be the three key interactions our first collaboration but in a well-defined way, so we're talking about two teams working together for a period of time to achieve. Of a specific outcome. So the more specific this outcome is the better. We'll be able to identify if
we've achieved it or not. So maybe we're working together to understand how we automate some deployment of some Services if the outcome is. Well defined. And once we have one automated deployment in the pipeline, then we can say the collaboration is done. Yes or no. Is the collaboration finished. And we also set the expectation on how long we expect this to last. So it's not an open-ended
collaboration. Ian which like I said can lead to actually more of a relationship and the dependency between teams where every time we need to deploy, we need to ask this other team to help us. For example, that's not the collaboration. We're talking about, that's a dependency and it's actually a blocking dependency. We cannot do anything unless this other team has the time to help us. We want to move away from that with kind of specific ways that teams should interact to help
them achieve a certain outcomes. So collaboration is one of them then we have facilitating as another core interaction mode. Specially for enabling teams. They are facilitating knowledge to others. So you're typically not actually building anything or working on some service where you're maybe pairing or running some workshops or helping teams understand improve their knowledge around. Some aspects of either the business or the technical side or practices that we use in the organization.
So that's the facilitating again should be framed in terms of what's the expected duration. What do we want to achieve? What should you know? After we've facilitated for this period of time and finally, we have acts as a service. So that's very much based on things like infrastructure as a service or software as a service where especially for the platform we're saying. At some point.
We want to have services in a platform that are mature enough and stable and provide a good developer experience with the right documentation, right? Level of reliability. So that teams can consume without actual interaction. So it's the lack of interaction. As we have this service in a way that is easy enough to understand to consume independently. So have one team, providing a service and then one or more teams consuming the service, very much. Like you consume AWS Services,
right? You don't expect to have to talk to AWS Engineers to run their services. They've done the work. Hopefully, there are degrees around this where sometimes the service needs some improvements and the documentation needs Improvement, but, in general, they're at mature enough state, where other Ins consume them independently, we did Three core interaction mode.
You can then help teams have more focused, interactions understand when, and how they should interact with others, instead of that kind of blurry, everyone. Collaborates with everyone just to finalize. We shouldn't expect this interaction, so long. These three modes to always go perfectly and smoothly, there will be issues and situations where we thought this was going to take two weeks. It took two months. Those are great opportunities to actually reflect on.
Why did it take so long? Was that something that wasn't clear? Maybe we wanted to collaborate. The one of the team's actually needs to be facilitated first to improve their understanding of some domain. Let's say about infrastructure as code. They need to better understand it before they can collaborate with another team that has more experience. So that the actually makes sense to collaborate. Otherwise the collaboration becomes a facilitating mode.
We're not saying that it's all going to go nice and smoothly, but it provides a better framing to Actually learn. And then understand when some interaction goes wrong or awkward. How can we learn from that and course, correct? So having all these knowledge that we just discussed. I know that various teams are in different stages. Some are more mature, some more messy than the other so to speak. So maybe one key takeaway from you among all these situation.
Of course, it's quite tough to Define. What will be the key? Takeaway of key message that you want to give to the listeners, hear? What can they do in order to improve their team? The Structural maybe the way of collaboration within their team in order to become much better aligned to the team topologies. Just one, I could be many up to you, looking back at our conversation. I would say for engineering
managers, in general. Obviously, you have different responsibilities and different organizations, but in general, start by acknowledging this constraints that we talked about like Conway's law, cognitive load. Also trust boundaries that we didn't talk about, but the fact that we are conditioned as Owens in certain ways and specifically in software delivery. Also things like Conway's law. So acknowledge that this constraints exist.
Often, we're focused on what are the good practices or best practices? And what's the best way to do things? Practices and principles are obviously necessary and useful, but they should be informed by. What are the constraints in the first place? Constraints are usually things. We cannot really change. So limits on cognitive load limits on trust between groups of teams. Conway's law are things Cannot
really change. So we need to acknowledge them and then build and decide on practices and principles based on that. Because if we don't, then we might be fighting these constraints rather than understanding and leveraging them in our advantage. So I would say that's the first thing, the other thing with Team topologies. Hopefully, we're not just clarifying the ways that teams can interact and their mission
of different types of teams. But also we're hopefully helping teams become more motivated with feeling more autonomous that I have more ownership of their service or the things they provide and that they're becoming more competent. So these are the key drivers of intrinsic motivation. Daniel pink wrote about in his book drive. So we think Tim topology is also helps teams, become more
autonomous have more ownership. And so the role of the engineering manager, ideally starts to move away from managing the team per se and and making decisions for the team to actually making less decisions. Let the teams have more kind of local decision-making and so if you're sort of getting Out of the way of the teams, providing them what they need to become more autonomous in terms of skills competences and support. Then you can look more into how do we help even if we're a
manager of one team? How do we help this team? Understand how to deal with other teams in a more productive way? How we help this team. Our team remove blocking dependencies on other teams. That's not easy for a team that there's already quite busy with their day-to-day work and their goals as a team. It's I think we're managers can actually help a lot is start helping address the blocking dependencies problem. This is unfamiliar for many teams to deal with is, how do we
deal with this? We can apply the interaction patterns. Let's have some collaboration so that we don't depend on you anymore to do the deployments. For example, how do we collaborate? So we understand how to automate our own deployments. For example, the managers can have a very strong I think input on that helping team navigate their dependencies on others. Can we actually Move or minimize blocking dependencies in particular. And finally, one last thing.
Sorry, if it's too much, just one last thing is start. Also thinking about alignment of purpose, between the team and individuals with a fundamental types of teams. We now have ability to be more clear on what is the mission of this team of a streamline team is different from enabling team or platform team. We have more clarity of. Why does our team exists. What are we trying to achieve? Who are customers, but then there's also the individual All-purpose. Right.
Every person has their own individual goals and individual motivation and often we don't consider the two together. We think. Well, the team purpose and everyone aligns to the team purpose again. It's not really how things work people have their own goals and what they want to achieve, we can Surface those conversations, understand someone who is really focused on technical side and the standing the technology and keeping up to date on that.
Maybe it's not a great fit for a streamline team where you want more. He's shaped or more. General is people that are actually more focused on end-to-end delivery. So maybe that person is a better fit for a platform or even perhaps enabling team. And so helping understand what are the individual purpose and
how they align. Which types of teams often is a mixed, where you need people to align their individual Purpose with the team, but also be willing to learn and improve on some areas that they don't have as much experience yet. So even for platform, team, for example, you might have people who are more focused on understanding the technology and the technical side, but they still need to understand. How do we deal with internal customers?
How do we get much better insights on what they need? How our platform is helping or not getting metrics and getting the right interactions with those teams in short, understand your constraints, first. Get out of the way of teams as much as possible. Let them make more decisions on their own increase their autonomy and ownership help teams deal with dependencies between them, especially
blocking the pain. Is help them navigate those and hopefully minimize those so we can have faster flow and finally help align individual purpose and in purpose. Thanks for all the tips. So I know that we arrived to the end of our conversation, but I have one last question that normally I ask for all my guests which is called the tree technical leadership wisdom. So maybe manual. Can you share with the audience here? What are your three technical leadership wisdom?
So it's basically what I just said, I think from a team topologies perspective understanding In this constraints that we have, then understanding that we'll be able to achieve more productivity and more faster flow. If we have teams with more autonomy. And finally, if we help reduce dependencies between teams, especially blocking dependencies, which again involves a lot of the things we talked about understanding your
value streams. Understanding where is the wait time, where are the dependencies the handovers of work between teams that we might need to deal with. And then how do we increase the skills of Our streamline teams with enabling aspects and also reduce their cognitive load with platform. So I would say those three things, understand constraints, like Conway's law cognitive load responder. He's looking for ways to improve the autonomy and the ownership of the Streamline teams and
other types of teams. Help teams navigate sort of the ecosystem and navigate and reduce blocking dependencies between them. Thanks so much man. Well, so for people who wants to follow you online. Is there a place for them to follow you? Yes, so there are two main places. First. We have our website team topologies.com. So in there, you can find new industry examples and case studies that came out after the
book was published. The book was published late 2019. So since then, we've learned also new patterns, and we have new examples. So all of that is available at team topologies.com. And then we have started an academy called team topologies academy. So that's at academy.com topologies.com., What we're trying to do is Have video based on demand courses that help people learn about the key ideas of topologies, sort of more condensed way.
So we have a first course called team topologies distilled and then we'll be adding more courses where we bring our latest insights around team topologies things that work. Well, things that maybe in certain situations don't work as well, and also new patterns that we find and new knowledge. So that's all kind of come in the next months and years for the Academy. So, thanks my love for you. Time is really great to have a talk with you today, and thanks
for sharing your knowledge. Thank you very much. Thank you for listening to this episode and for staying right till the end. If you highly enjoyed, please share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It really, really helps me a lot in order to grow this podcast
better. You can also find the full show notes of this conversation on the episode page at technology. No, the death. Including the full transcript interesting quotes, and links to the resources and mentions from the conversation. And lastly make sure to subscribe to the show's mailing list on pecola journal. The deaf to get notified for any future episodes. Stay tuned for the next technique Journal episode. And until then. Goodbye.