1 00:00:00,000 --> 00:00:03,000 Often we're focused on what are the good practices or best 2 00:00:03,000 --> 00:00:05,200 practices? And what's the best way to do 3 00:00:05,200 --> 00:00:07,700 things? Practices and principles are 4 00:00:07,700 --> 00:00:10,600 obviously necessary and useful, but they should be informed by. 5 00:00:10,600 --> 00:00:12,600 What are the constraints in the first place? 6 00:00:12,900 --> 00:00:15,700 Constraints are usually things. We cannot really change. 7 00:00:16,000 --> 00:00:19,800 So limits on cognitive load limits on trust between groups 8 00:00:19,800 --> 00:00:21,700 of teams. Conway's law are things, we 9 00:00:21,700 --> 00:00:24,300 cannot really change. So we need to acknowledge them 10 00:00:24,300 --> 00:00:27,500 and then build and decide on practices and principles based 11 00:00:27,500 --> 00:00:29,500 on that. Because if we don't, then we 12 00:00:29,500 --> 00:00:31,800 might be be fighting this constraints rather than 13 00:00:31,800 --> 00:00:34,400 understanding and leveraging them in our advantage. 14 00:00:38,800 --> 00:00:42,100 Hey everyone. My name is Henry Surya be Robin. 15 00:00:43,700 --> 00:00:47,500 And you're listening to the tekhelet Juno, the show will be 16 00:00:47,500 --> 00:00:50,900 bringing you the greatest technical leaders practitioners 17 00:00:51,100 --> 00:00:54,400 and thought leaders in the industry to discuss about their 18 00:00:54,400 --> 00:00:59,200 Journey ideas and practices that we all can learn and apply to 19 00:00:59,200 --> 00:01:02,200 build a highly performing technical team and to make an 20 00:01:02,200 --> 00:01:06,900 impact in your personal work. So let's dive into our Journal. 21 00:01:11,500 --> 00:01:13,300 Hello to all of you my listeners. 22 00:01:13,500 --> 00:01:16,200 It's great to be back here again with another new episode of the 23 00:01:16,200 --> 00:01:19,100 tackling Journal podcast. Thanks for spending your time 24 00:01:19,100 --> 00:01:21,300 with me today, listening to this episode. 25 00:01:21,600 --> 00:01:24,400 If you haven't, please subscribe to technology, you know on your 26 00:01:24,400 --> 00:01:27,000 favorite podcast apps and also follow technology. 27 00:01:27,000 --> 00:01:30,600 No social media channels on LinkedIn, Twitter and Instagram. 28 00:01:31,200 --> 00:01:33,600 And you can also make some contribution to the show and 29 00:01:33,600 --> 00:01:36,800 support the creation of this podcast by subscribing, as a 30 00:01:36,800 --> 00:01:39,900 patron at package, you know, dot f / Patron. 31 00:01:40,500 --> 00:01:44,600 And help me towards producing great content every week for 32 00:01:44,600 --> 00:01:47,400 today's episode. I'm very happy to share my 33 00:01:47,400 --> 00:01:52,000 conversation with manual Pysch manual is the co-author of the 34 00:01:52,000 --> 00:01:55,600 team topologies book. A devops thought leader, and an 35 00:01:55,600 --> 00:01:58,900 independent, it organizational consultant focusing on. 36 00:01:58,900 --> 00:02:02,900 Team interactions delivery practices and accelerating flow 37 00:02:03,700 --> 00:02:06,200 effective software. Teams are essential for any 38 00:02:06,200 --> 00:02:10,000 organization to deliver value, continuously and sustainably. 39 00:02:10,400 --> 00:02:13,700 But how do you actually build the best team Organization for 40 00:02:13,700 --> 00:02:17,000 your specific goals culture, and needs in the book? 41 00:02:17,000 --> 00:02:20,800 Team topologies manual and his co-author Matthew skeleton. 42 00:02:21,200 --> 00:02:25,300 Share secrets of successful team patterns and interactions to 43 00:02:25,300 --> 00:02:28,900 help it organizations choose and evolve the right team patterns 44 00:02:28,900 --> 00:02:32,800 to ensure success making sure to keep the software healthy and to 45 00:02:32,800 --> 00:02:37,500 optimize for Value streams. In this episode manual, shared 46 00:02:37,500 --> 00:02:40,700 great insights from his book. Team topologies starting from 47 00:02:40,700 --> 00:02:43,500 highlighting some constraints that organizations, typically, 48 00:02:43,500 --> 00:02:47,400 face such as Conway's law and cognitive load manual, then 49 00:02:47,400 --> 00:02:50,900 explain the four fundamental team topologies, and how they 50 00:02:50,900 --> 00:02:53,000 can help to address those constraints. 51 00:02:53,700 --> 00:02:56,500 He also shared about the team API concept, as well as the 52 00:02:56,500 --> 00:03:00,300 three call interaction modes, which inform how teams should 53 00:03:00,300 --> 00:03:03,300 interact with each other in order to improve the overall 54 00:03:03,300 --> 00:03:06,900 flow within the business. Finally manual. 55 00:03:06,900 --> 00:03:08,500 Shared some advice on how we can. 56 00:03:08,500 --> 00:03:12,000 All start implementing these ideas within our organizations. 57 00:03:12,900 --> 00:03:16,300 I personally really enjoyed this conversation and I hope you will 58 00:03:16,300 --> 00:03:19,900 enjoy this episode to consider helping the show by living it. 59 00:03:19,900 --> 00:03:23,300 The rating review or comment on your podcast app and social 60 00:03:23,300 --> 00:03:26,700 media channels those reviews and comments are one of the best 61 00:03:26,700 --> 00:03:30,700 ways to help me get this podcast to reach more listeners and 62 00:03:30,700 --> 00:03:34,200 hopefully they can also benefit from all the contents in this 63 00:03:34,200 --> 00:03:36,500 podcast. So let's get this episode 64 00:03:36,500 --> 00:03:39,000 started right? After our sponsor message. 65 00:03:39,200 --> 00:03:41,100 Are you looking for a new cool swag. 66 00:03:41,400 --> 00:03:44,000 Technology, you know. Now offers you some swags that 67 00:03:44,000 --> 00:03:47,800 you can purchase online. These wax are printed on demand 68 00:03:47,800 --> 00:03:51,200 based on your preference and will be delivered safely to you 69 00:03:51,300 --> 00:03:53,800 all over the world where shipping is available. 70 00:03:54,200 --> 00:03:56,800 Check out all the cool swag is available by visiting 71 00:03:56,800 --> 00:03:59,900 technology, you know, the dev slash shop and don't forget to 72 00:03:59,900 --> 00:04:02,400 break yourself. Once you receive any of those 73 00:04:02,400 --> 00:04:06,300 tracks. Hey, everyone. 74 00:04:06,300 --> 00:04:07,800 Good to see you again. Today. 75 00:04:07,800 --> 00:04:09,800 We have a new episode of the package. 76 00:04:09,800 --> 00:04:13,000 You know, I have someone who I admired as the co-author of a 77 00:04:13,000 --> 00:04:16,200 book that has a rave Review called team topologies 78 00:04:16,500 --> 00:04:19,300 organizing Business and Technology teams for fast flow. 79 00:04:19,800 --> 00:04:23,000 So if you have a heard about the book or maybe already read the 80 00:04:23,000 --> 00:04:25,600 book, you know, what kind of things that I'm talking about. 81 00:04:25,700 --> 00:04:29,100 This person is Manuel, piyush, is actually one of the calls. 82 00:04:29,100 --> 00:04:32,000 The, and I'm really looking forward today to learn more 83 00:04:32,000 --> 00:04:35,300 about teams, apologies, how we actually should structure a Or 84 00:04:35,300 --> 00:04:38,000 maybe some of the anti patterns that we should avoid when 85 00:04:38,000 --> 00:04:40,300 organizing team and also within a company. 86 00:04:40,600 --> 00:04:43,600 So thanks again manual for agreeing to this conversation. 87 00:04:43,600 --> 00:04:45,100 So looking forward to have a chat with you. 88 00:04:45,700 --> 00:04:47,200 Thanks for having me. Great to be here. 89 00:04:47,700 --> 00:04:49,000 Someone. Well before we start talking 90 00:04:49,000 --> 00:04:51,900 about teams, apologies and all that may be for you to introduce 91 00:04:51,900 --> 00:04:53,700 yourself. Maybe telling about your career 92 00:04:53,700 --> 00:04:56,100 background and highlights and turning points. 93 00:04:56,700 --> 00:04:58,700 Sure. So I have a background in 94 00:04:58,700 --> 00:05:01,300 computer science. As does my co-author Matthew 95 00:05:01,300 --> 00:05:03,400 skeleton. I've had a number of different 96 00:05:03,400 --> 00:05:08,100 roles from Developers. To tester build engineer team 97 00:05:08,100 --> 00:05:11,700 lead, keyway Etc. That kind of gave me a broader 98 00:05:11,700 --> 00:05:15,200 perspective within the software delivery environment of 99 00:05:15,200 --> 00:05:18,100 different roles, dependencies between different teams, 100 00:05:18,100 --> 00:05:19,900 different skills that are needed. 101 00:05:19,900 --> 00:05:22,800 Especially when devops and continuous delivery kind of came 102 00:05:22,800 --> 00:05:26,800 about ten years ago or so. It struck a chord with me that 103 00:05:26,800 --> 00:05:30,600 yes, this is very much what we need to think about the flow of 104 00:05:30,600 --> 00:05:34,900 development of software as well as the production and the life 105 00:05:34,900 --> 00:05:35,800 support. Port. 106 00:05:35,800 --> 00:05:38,500 And we need better ways for teams to communicate to each 107 00:05:38,500 --> 00:05:40,500 other. Understand dependencies between 108 00:05:40,500 --> 00:05:44,700 them because before that was very much based on specializing 109 00:05:44,700 --> 00:05:48,000 by skills and by competencies each team trying to be a 110 00:05:48,008 --> 00:05:51,300 specialized as possible. We've seen that doesn't work, 111 00:05:51,400 --> 00:05:54,600 especially if we don't think about the ecosystem of teams, 112 00:05:54,600 --> 00:05:56,300 right? One of these teams, you know, 113 00:05:56,300 --> 00:05:59,700 isolation cannot do the work. That is needed to get the actual 114 00:05:59,700 --> 00:06:02,500 software product, or service available to customers. 115 00:06:02,800 --> 00:06:06,100 So, basically, I embraced devops Good news delivery. 116 00:06:06,300 --> 00:06:09,900 I became lead editor for info Q around devops as well. 117 00:06:10,100 --> 00:06:13,200 It's been a great journey of meeting really amazing people 118 00:06:13,200 --> 00:06:16,300 with great. Insights since 2015. 119 00:06:16,300 --> 00:06:19,000 Then I started doing consulting. And so, working with different 120 00:06:19,000 --> 00:06:21,200 clients around the world. Understanding, what are the 121 00:06:21,200 --> 00:06:25,100 obstacles for them to basically accelerate being able to respond 122 00:06:25,100 --> 00:06:28,500 faster to the customers? And also to changes in market 123 00:06:28,500 --> 00:06:32,300 and adapting to new situations. Obviously, it's always that mix 124 00:06:32,300 --> 00:06:35,000 of Technology people and processes. 125 00:06:35,100 --> 00:06:37,300 These. But with team topologies in 126 00:06:37,300 --> 00:06:40,800 particular, we're trying to both raise awareness of certain 127 00:06:40,800 --> 00:06:45,100 constraints and certain kind of human focused aspects that are 128 00:06:45,100 --> 00:06:48,200 important to understand, for organizations, to be able to 129 00:06:48,200 --> 00:06:51,700 accelerate or become higher performing, as well as providing 130 00:06:51,700 --> 00:06:54,200 some tools. And some ways of thinking that 131 00:06:54,200 --> 00:06:56,800 can help guide this organizations to a better 132 00:06:56,900 --> 00:06:59,300 operating model. If you like that is more team 133 00:06:59,300 --> 00:07:01,900 focused. So, maybe let's go into that 134 00:07:01,900 --> 00:07:03,900 topic itself out team topologies. 135 00:07:04,100 --> 00:07:07,300 So, in the first place, You wrote this book, what exactly 136 00:07:07,300 --> 00:07:11,400 the core message of principle or even the problems that you for. 137 00:07:11,400 --> 00:07:14,600 Seeing during that time that lets you into writing this book. 138 00:07:15,300 --> 00:07:18,400 We did a lot of Consulting around devops and continuous 139 00:07:18,400 --> 00:07:21,300 delivery. Many clients wanted help with 140 00:07:21,300 --> 00:07:25,600 some new tool set adopting some better practices and that's all 141 00:07:25,600 --> 00:07:28,200 good and well and it helps to some extent. 142 00:07:28,200 --> 00:07:30,800 But in many organizations, they're not looking at the 143 00:07:30,808 --> 00:07:33,900 elephant in the room where teams are not communicating in an 144 00:07:33,900 --> 00:07:36,700 effective way. Teams don't even know sometimes 145 00:07:36,700 --> 00:07:39,000 who they have to ask for certain things. 146 00:07:39,200 --> 00:07:42,400 You have that, what I mentioned, very strict separation of 147 00:07:42,400 --> 00:07:45,500 concerns and responsibilities, which means you introduce a lot 148 00:07:45,500 --> 00:07:49,200 of dependencies to get any sort of value to customers out. 149 00:07:49,200 --> 00:07:52,800 The door means it has to go through many teams doing small 150 00:07:52,800 --> 00:07:55,200 things. And so that's not conducive to 151 00:07:55,200 --> 00:07:57,200 fast flow. You can have the best tool set 152 00:07:57,200 --> 00:07:59,900 in the market and that's only going to help you to some 153 00:07:59,900 --> 00:08:02,300 extent. When you have the combination of 154 00:08:02,300 --> 00:08:04,800 do flow of work in the team's, it flows. 155 00:08:04,800 --> 00:08:07,000 Well, Because the team has sufficient autonomy. 156 00:08:07,000 --> 00:08:08,800 And they understand their dependencies. 157 00:08:09,100 --> 00:08:12,200 We avoid that sort of blocking dependencies where one team has 158 00:08:12,200 --> 00:08:14,100 to wait for another team to do something. 159 00:08:14,500 --> 00:08:17,900 Once we achieve that sort of faster flow with more autonomy 160 00:08:17,900 --> 00:08:21,300 than yes, the tools can then hyphen even more this sort of 161 00:08:21,300 --> 00:08:24,800 fast flow, get better data, get better automation, Etc. 162 00:08:25,000 --> 00:08:27,700 But if we just start with Automation and tooling, we 163 00:08:27,700 --> 00:08:31,200 quickly run against challenges in terms of Team structures and 164 00:08:31,200 --> 00:08:33,000 communication. So that's what we were saying, 165 00:08:33,000 --> 00:08:36,400 recurrently with clients. We thought that some point. 166 00:08:36,400 --> 00:08:39,400 We had seen enough patterns that work and patterns that didn't 167 00:08:39,400 --> 00:08:42,100 work. Also a lot of learning from the 168 00:08:42,100 --> 00:08:44,200 devops Enterprise Summit this conference. 169 00:08:44,200 --> 00:08:47,800 That happens every year from the Publishers of the book as well. 170 00:08:47,800 --> 00:08:50,400 It Revolution. So a lot of stories that were 171 00:08:50,400 --> 00:08:52,800 being shared by different organizations on some of the 172 00:08:52,800 --> 00:08:54,600 patterns that work and we didn't work. 173 00:08:54,900 --> 00:08:57,400 So we sort of brought all that together into the book. 174 00:08:58,100 --> 00:09:01,300 So I think, what I hear you say is that a lot of teams this day, 175 00:09:01,300 --> 00:09:03,900 they will definitely start with tools and Technologies, 176 00:09:03,900 --> 00:09:06,300 probably, right? Thing about how to implement 177 00:09:06,300 --> 00:09:09,400 those, but actually, without looking necessarily to what the 178 00:09:09,400 --> 00:09:12,200 team structure or even the rock structure at that point in time 179 00:09:12,200 --> 00:09:14,800 within the company, you mentioned, interestingly in the 180 00:09:14,800 --> 00:09:15,500 book. Actually. 181 00:09:15,500 --> 00:09:18,300 The first problem is with the org charts itself. 182 00:09:18,500 --> 00:09:21,400 Why do you think typically of chart is maybe the first 183 00:09:21,400 --> 00:09:23,500 problem? We're all this may be a barrier 184 00:09:23,500 --> 00:09:26,200 to fast flow. Maybe barrier into dependencies 185 00:09:26,200 --> 00:09:28,700 blockage and things like that. So maybe you can explain a 186 00:09:28,700 --> 00:09:33,400 little bit around that sure. So let me say the org chart is 187 00:09:33,400 --> 00:09:36,000 not a problem per se. It's not that we shouldn't have 188 00:09:36,000 --> 00:09:38,800 or shorts. They have important benefits in 189 00:09:38,800 --> 00:09:40,800 terms of understanding how we are. 190 00:09:40,800 --> 00:09:43,000 Organized special in large organizations. 191 00:09:43,200 --> 00:09:46,500 It helps with reporting and hopefully also helps with kind 192 00:09:46,500 --> 00:09:49,400 of top-down alignment of strategic goals for the 193 00:09:49,400 --> 00:09:52,400 organization. So everyone understands, how are 194 00:09:52,400 --> 00:09:56,000 we related and how does our work relates to the goals that the 195 00:09:56,000 --> 00:09:57,500 organization is trying to achieve? 196 00:09:57,600 --> 00:10:00,900 So that's all fine. The problem that tends to happen 197 00:10:00,900 --> 00:10:03,800 is when in a way, we give too much importance to the org 198 00:10:03,800 --> 00:10:05,600 chart. In the sense that People started 199 00:10:05,600 --> 00:10:09,400 looking at it as specifying, all the decision, making lines and 200 00:10:09,400 --> 00:10:12,300 specifying with home. Should we interact or not? 201 00:10:12,400 --> 00:10:14,900 If this team is in another department and we shouldn't talk 202 00:10:14,900 --> 00:10:17,600 to them directly. We need to go up to Yaar Ki and 203 00:10:17,600 --> 00:10:19,700 then down the arrow key to get the team. 204 00:10:19,900 --> 00:10:22,600 Those sort of things is where it starts to become a challenge to 205 00:10:22,600 --> 00:10:26,200 fast flow because with the complexity of modern software 206 00:10:26,200 --> 00:10:29,400 delivery and operations, you can do that, but you won't achieve 207 00:10:29,400 --> 00:10:32,900 fast flow because there's too many steps and too much 208 00:10:32,900 --> 00:10:36,500 redirection in a way through the They are key to get to the 209 00:10:36,500 --> 00:10:39,900 actual work getting done. So we want to favor for fast 210 00:10:39,900 --> 00:10:41,100 flow. You want to favor, local 211 00:10:41,100 --> 00:10:44,400 decisions and having teams interact with the right things 212 00:10:44,400 --> 00:10:46,900 at the right time. And so, when you introduce those 213 00:10:46,900 --> 00:10:50,500 sort of blockers with the arrow key and decision-making, having 214 00:10:50,500 --> 00:10:53,300 to be top down, then we're not allowing the people who are 215 00:10:53,300 --> 00:10:56,400 doing the work and closer to the customer to, actually make the 216 00:10:56,400 --> 00:10:59,100 best decisions. That's where really the org 217 00:10:59,100 --> 00:11:02,800 chart can become a problem where people see it as imposing the 218 00:11:02,800 --> 00:11:06,200 communication, lines and imposing Making lines between 219 00:11:06,200 --> 00:11:08,900 teams. That's the key issue there where 220 00:11:08,900 --> 00:11:10,800 it becomes an obstacle to fast flow. 221 00:11:10,800 --> 00:11:14,900 If we misinterpret the org chart as dictating, all these things. 222 00:11:15,100 --> 00:11:18,100 Unfortunately, in many organizations that tends to 223 00:11:18,100 --> 00:11:20,500 happen. It also is coupled with the 224 00:11:20,508 --> 00:11:22,600 problem that in some organizations. 225 00:11:22,600 --> 00:11:26,200 The worth of the managers senior managers is linked to how many 226 00:11:26,200 --> 00:11:29,500 people report to them and that kind of feeds into this 227 00:11:29,500 --> 00:11:33,400 narrative that you need to go up the hierarchy for any kind of 228 00:11:33,400 --> 00:11:36,200 decision making. So that we Can show proof that 229 00:11:36,200 --> 00:11:37,900 the value of the senior managers? 230 00:11:38,200 --> 00:11:42,100 Hopefully, with Team topologies. This sort of approach is being 231 00:11:42,100 --> 00:11:44,400 replaced or move away from that to more. 232 00:11:44,400 --> 00:11:48,000 How do we enable the people and the teams who are under our 233 00:11:48,000 --> 00:11:51,500 year, key to actually be able to make better decisions, more 234 00:11:51,500 --> 00:11:54,300 autonomously and not depend on the are key. 235 00:11:54,900 --> 00:11:58,400 So if I get the sense that fast flow is actually of course, it's 236 00:11:58,400 --> 00:12:00,500 like the main objective that we want to achieve. 237 00:12:00,700 --> 00:12:02,900 But let's say, if we are currently working in a team or 238 00:12:02,900 --> 00:12:06,700 in a company, how do we actually Identify whether we have a good 239 00:12:06,700 --> 00:12:09,800 flow, fast flow, slow flow is any exercises? 240 00:12:09,800 --> 00:12:13,000 Then guidance on how to actually find out where we are at this 241 00:12:13,000 --> 00:12:14,900 point in time. Yeah. 242 00:12:15,100 --> 00:12:18,000 So a couple of things. Well, first, there's a very 243 00:12:18,000 --> 00:12:21,800 straightforward metric called flow efficiency, which is 244 00:12:21,800 --> 00:12:25,200 essentially looking at how long it takes from the moment. 245 00:12:25,200 --> 00:12:29,400 We have an idea for a new feature or new service until 246 00:12:29,400 --> 00:12:31,100 it's actually available to the customer. 247 00:12:31,400 --> 00:12:34,900 So the full kind of lead time from idea to production. 248 00:12:35,100 --> 00:12:38,700 And from that overall, elapsed time how much have we actually 249 00:12:38,700 --> 00:12:42,900 spent working on this feature service versus how much was wait 250 00:12:42,900 --> 00:12:45,100 time? So it turns out that in many 251 00:12:45,100 --> 00:12:48,200 organizations. The actual work time is about 15 252 00:12:48,200 --> 00:12:51,700 percent or less. So that means out of 100 days, 253 00:12:51,700 --> 00:12:54,200 maybe that it takes to get a feature out, 15 days, where 254 00:12:54,200 --> 00:12:58,200 actually work days and 85 days were waiting for someone else or 255 00:12:58,200 --> 00:13:00,600 another team to have availability or someone to 256 00:13:00,600 --> 00:13:04,100 approve or make a decision. When you look at that metric, 257 00:13:04,100 --> 00:13:07,400 which in a way, Very simple, then you can sort of, like, 258 00:13:07,400 --> 00:13:11,000 starting to unfold the flow problems, right? 259 00:13:11,100 --> 00:13:13,800 You can start looking at. Okay, if we spent all this 260 00:13:13,800 --> 00:13:16,000 weight time, where exactly did we spend this? 261 00:13:16,000 --> 00:13:18,200 Wait time? We spend maybe a week or two 262 00:13:18,200 --> 00:13:20,800 weeks, waiting for some infrastructure to be available, 263 00:13:21,000 --> 00:13:24,700 or we waited one week for some approval to start digging into 264 00:13:24,700 --> 00:13:26,400 that. And you start seeing where are 265 00:13:26,400 --> 00:13:29,600 the, wait times, that we want to reduce if we want to achieve 266 00:13:29,600 --> 00:13:32,100 faster delivery. So that's one thing. 267 00:13:32,300 --> 00:13:34,600 Also, the nice thing about that is you can then look at the 268 00:13:34,600 --> 00:13:36,600 flow. Efficiency at different levels, 269 00:13:36,600 --> 00:13:40,000 you can look within the cycle time since we start coding until 270 00:13:40,000 --> 00:13:43,200 if we deploy or you can look at the broader picture of since we 271 00:13:43,200 --> 00:13:46,700 started since we approve this idea until it's actually start 272 00:13:46,700 --> 00:13:49,900 to be used by customers. So you can start wherever it 273 00:13:49,900 --> 00:13:53,200 makes more sense. Sometimes teams don't have a 274 00:13:53,200 --> 00:13:56,500 global view of all the steps in the process and they might want 275 00:13:56,500 --> 00:13:59,700 to look at their own domain of responsibility and understand. 276 00:13:59,700 --> 00:14:02,900 Where are we kind of slowing down, but obviously, at some 277 00:14:02,900 --> 00:14:04,900 point you want to have a more systemvue. 278 00:14:05,300 --> 00:14:07,700 Do you want to see? Because a lot of people say that 279 00:14:07,700 --> 00:14:10,900 about agile some organizations have successfully sort of 280 00:14:10,908 --> 00:14:14,000 adopted agile principles. They have accelerated the speed 281 00:14:14,000 --> 00:14:16,900 of the agile teams, but when you look at the big picture, how 282 00:14:16,900 --> 00:14:20,500 long it takes between an idea actually being approved and 283 00:14:20,500 --> 00:14:22,700 going to production. Maybe there are a lot more teams 284 00:14:22,700 --> 00:14:24,600 involved. Maybe you need financial 285 00:14:24,600 --> 00:14:27,100 approval. You need product, team, product 286 00:14:27,100 --> 00:14:29,300 owner, or product manager approval. 287 00:14:29,600 --> 00:14:32,400 A lot of different steps. Might be required to actually 288 00:14:32,400 --> 00:14:34,900 get until the agile team starts working on this. 289 00:14:35,000 --> 00:14:38,700 So yeah, flow efficiency and then obviously also value stream 290 00:14:38,700 --> 00:14:40,900 mapping. So that's the technique for 291 00:14:40,900 --> 00:14:44,200 actually looking at the overall process and looking at 292 00:14:44,200 --> 00:14:48,100 dependencies between teams, looking at where their cues were 293 00:14:48,100 --> 00:14:50,000 work. Piles up for some teams. 294 00:14:50,300 --> 00:14:54,000 That's more kind of visualizing this whole process, but in terms 295 00:14:54,000 --> 00:14:57,200 of metric, then the flow efficiencies is quite helpful. 296 00:14:58,000 --> 00:15:00,900 So I think also another anti pattern that normally I heard a 297 00:15:00,900 --> 00:15:03,200 lot then it is mentioned a lot of times in the book as well, 298 00:15:03,200 --> 00:15:06,300 which is about Conway's law. Maybe, can you explain a little 299 00:15:06,300 --> 00:15:08,800 bit on that? What do you mean by Conway's law 300 00:15:08,800 --> 00:15:10,400 for people who are not familiar with it? 301 00:15:11,000 --> 00:15:14,900 Yeah, so I'd like to see it as a constraint, not necessarily 302 00:15:14,900 --> 00:15:17,400 anti-pattern, just something that we should be aware. 303 00:15:17,400 --> 00:15:21,100 Especially in software driven. Organizations is Conway's law. 304 00:15:21,300 --> 00:15:24,400 That means is from a paper by Amell Conway, which was 305 00:15:24,400 --> 00:15:26,800 published in 1968. So it's been around for a long 306 00:15:26,800 --> 00:15:30,500 time, but it got more traction with the rise of micro services 307 00:15:30,500 --> 00:15:33,700 and people started seeing in practice how this is actually 308 00:15:33,700 --> 00:15:34,900 happening. Basically. 309 00:15:35,000 --> 00:15:38,900 It says one of the corollaries in that paper that became known 310 00:15:38,900 --> 00:15:41,000 as Conway's law. Says that the structures that 311 00:15:41,008 --> 00:15:43,500 your organization has and the communication paths between 312 00:15:43,500 --> 00:15:47,100 teams strongly influences, the system architecture that we can 313 00:15:47,100 --> 00:15:49,000 achieve. So that means we might have 314 00:15:49,000 --> 00:15:52,600 wonderful architecture that we've designed and that's what 315 00:15:52,600 --> 00:15:54,400 we're trying to build for customers. 316 00:15:54,400 --> 00:15:58,600 But then if the team structures are very different and we don't 317 00:15:58,600 --> 00:16:01,700 have the necessary communication paths in place to achieve that 318 00:16:01,700 --> 00:16:05,000 system architecture, either. We will end up with something. 319 00:16:05,000 --> 00:16:09,000 In quite different on the system architecture or it's going to 320 00:16:09,000 --> 00:16:11,400 cost us a lot more. There's going to be a lot more 321 00:16:11,400 --> 00:16:14,900 challenges because of poor communication responsibilities 322 00:16:14,900 --> 00:16:17,700 that are not aligned to the responsibilities that we expect 323 00:16:17,700 --> 00:16:19,800 in different parts of the system and so on. 324 00:16:20,000 --> 00:16:22,100 So we should see this as a constraint. 325 00:16:22,300 --> 00:16:25,600 It has been validated across different Industries, Conway's 326 00:16:25,600 --> 00:16:27,000 law. And like I said, with 327 00:16:27,000 --> 00:16:30,200 microservices, people started to see these more because 328 00:16:30,200 --> 00:16:33,300 unfortunately, in many places, they thought, well, yeah, this 329 00:16:33,300 --> 00:16:34,800 is the right, architectures, going to lie. 330 00:16:34,900 --> 00:16:38,200 Allow us to go faster, but then they forgot the alignment of the 331 00:16:38,200 --> 00:16:40,100 team structures and communication paths. 332 00:16:40,300 --> 00:16:44,900 And so they ended up with still needing any kind of non trivial 333 00:16:45,000 --> 00:16:48,200 change or feature to require coordination between multiple 334 00:16:48,200 --> 00:16:50,300 teams. The when with microservices the 335 00:16:50,300 --> 00:16:53,000 expectation was that each team will be able to evolve more 336 00:16:53,000 --> 00:16:55,300 independently. And so that's the idea of 337 00:16:55,300 --> 00:16:57,800 Conway's law. So if we are aware of that we 338 00:16:57,800 --> 00:17:01,000 can then make better decisions. We can apply what people call 339 00:17:01,100 --> 00:17:03,600 reverse Conway, maneuver, where it means. 340 00:17:03,600 --> 00:17:07,300 Okay, we can design Our kind of Ideal system architecture that 341 00:17:07,300 --> 00:17:10,500 we think, is going to be a better fit for the requirements 342 00:17:10,500 --> 00:17:14,200 of the customers, and also the non-functional requirements and 343 00:17:14,200 --> 00:17:17,099 then let's look at our team structures and Communications 344 00:17:17,099 --> 00:17:20,099 and maybe adapt them to be more aligned with the system 345 00:17:20,099 --> 00:17:22,900 architecture. There's also a great quote from 346 00:17:22,900 --> 00:17:25,700 Michael Nygaard, who wrote the book, release it, where he says, 347 00:17:25,900 --> 00:17:28,900 when you ship a product, you're also shipping the organization 348 00:17:28,900 --> 00:17:31,600 structures with it. So basically he's talking about 349 00:17:31,600 --> 00:17:34,600 Conway's law and the fact that you get this mirroring effect in 350 00:17:34,600 --> 00:17:37,300 the system of the actual structures you have in the 351 00:17:37,300 --> 00:17:40,800 organization just to add to that, another corollary from 352 00:17:40,800 --> 00:17:43,700 that paper from Canal. Conway was that if you have a 353 00:17:43,708 --> 00:17:47,200 very rigid organization structure, and we go back to 354 00:17:47,200 --> 00:17:50,100 your previous question about organization chart if that's 355 00:17:50,100 --> 00:17:53,700 very static and regions, and it doesn't change easily even at 356 00:17:53,700 --> 00:17:57,300 the team level, that means we're effectively constraining the 357 00:17:57,300 --> 00:17:59,500 kind of solutions. We're able to find for our 358 00:17:59,500 --> 00:18:02,000 systems. There might be a range of 359 00:18:02,000 --> 00:18:04,900 solutions that we don't even think about just because of the 360 00:18:05,000 --> 00:18:08,700 Teams are set up, especially if they're very rigid and it's hard 361 00:18:08,700 --> 00:18:11,800 to change. So, one related, question that I 362 00:18:11,800 --> 00:18:14,600 have does it necessarily have to start from the system 363 00:18:14,600 --> 00:18:16,900 architecture, or the ideal architecture that we have 364 00:18:17,100 --> 00:18:19,400 because in a company or business, there are so many 365 00:18:19,400 --> 00:18:23,000 other departments, for example, from Finance from business, from 366 00:18:23,000 --> 00:18:25,000 a bi-product. Does it always necessarily have 367 00:18:25,000 --> 00:18:26,800 to start from product architecture? 368 00:18:26,800 --> 00:18:30,000 Like maybe from technology point of view, or do you actually also 369 00:18:30,000 --> 00:18:32,000 has a lineman with the product team first? 370 00:18:32,200 --> 00:18:34,700 Like, okay, based on how the business do the business model? 371 00:18:34,900 --> 00:18:37,400 Also aligned with the strategy with the technology team on it. 372 00:18:37,500 --> 00:18:39,600 Then you come up with a team strategy, maybe a little bit 373 00:18:39,600 --> 00:18:41,400 clarification here. Yeah. 374 00:18:41,400 --> 00:18:44,200 That's a really good question. So, two things first. 375 00:18:44,200 --> 00:18:46,800 Let me say there are many decisions being made in 376 00:18:46,800 --> 00:18:50,400 organization outside it that actually, because of Conway's 377 00:18:50,400 --> 00:18:52,700 law can end up having an influence on the system 378 00:18:52,700 --> 00:18:56,100 architecture, if team composition and team structures 379 00:18:56,100 --> 00:18:59,500 are decided, for example, by a jar, and there's no sort of 380 00:18:59,500 --> 00:19:02,500 input from the technical side on, how does this impact to the 381 00:19:02,500 --> 00:19:04,300 work? We're able to do on the system 382 00:19:04,300 --> 00:19:07,200 and the software. Then it jarred some extent is 383 00:19:07,200 --> 00:19:09,700 making decisions on that architecture because we're 384 00:19:09,700 --> 00:19:12,600 limiting the possibilities that we can achieve because of 385 00:19:12,600 --> 00:19:15,500 Conway's law. So that's definitely impact from 386 00:19:15,500 --> 00:19:18,600 other parts of the organization in terms of what we can achieve. 387 00:19:18,900 --> 00:19:23,000 Even if you think about now that we're in this remote or hybrid 388 00:19:23,000 --> 00:19:26,400 world the way you set up your communication tools, your slack, 389 00:19:26,400 --> 00:19:29,300 or Microsoft teams, or what have you, and might actually have 390 00:19:29,300 --> 00:19:31,700 some influence in the way that teams communicate. 391 00:19:32,000 --> 00:19:35,900 Because if any team that depends on another Team that's in 392 00:19:35,900 --> 00:19:38,700 another slack. That I don't have easy way to 393 00:19:38,700 --> 00:19:40,600 communicate with them. That's actually going to 394 00:19:40,600 --> 00:19:43,900 restrict our capacity to decide together based on our 395 00:19:43,900 --> 00:19:45,900 dependencies. The other thing I wanted to 396 00:19:45,908 --> 00:19:48,000 mention. I think you're absolutely right 397 00:19:48,000 --> 00:19:50,800 that this decisions doesn't start only at the system 398 00:19:50,800 --> 00:19:54,100 architecture level. So especially if we want to have 399 00:19:54,100 --> 00:19:57,700 teams that are more autonomous that can deliver and have more 400 00:19:57,700 --> 00:20:01,100 ownership over a slice of a larger product, which tends to 401 00:20:01,100 --> 00:20:03,000 be the case in many organizations that we have 402 00:20:03,000 --> 00:20:06,800 larger products or services. Customs, have a limited number 403 00:20:06,800 --> 00:20:09,900 of team members, then we need to break down this larger product 404 00:20:09,900 --> 00:20:12,900 into smaller chunks. And that's another problem. 405 00:20:12,900 --> 00:20:17,100 We've seen often is that even on the business model side, if you 406 00:20:17,100 --> 00:20:20,900 like there is sometimes monolith organizations that grew over 407 00:20:20,900 --> 00:20:23,800 time and because they were successful and they delivered 408 00:20:23,800 --> 00:20:26,900 useful products and services, but things started to get a 409 00:20:26,900 --> 00:20:29,900 little bit messy and we don't have Clarity anymore on. 410 00:20:29,900 --> 00:20:32,500 What exactly are the different sort of business lines or the 411 00:20:32,500 --> 00:20:34,700 different value that we provide to customers. 412 00:20:34,900 --> 00:20:38,000 Is it becomes blurred and you get this software monolith? 413 00:20:38,000 --> 00:20:41,200 Yes, but also model is on the business model side at the same 414 00:20:41,200 --> 00:20:44,900 time because we just build on top of what we had before and 415 00:20:44,900 --> 00:20:47,900 now it's very hard also to decouple the teams. 416 00:20:48,200 --> 00:20:51,600 And so when we want to do that, we need to start with actually 417 00:20:51,600 --> 00:20:54,900 the business model, understand. Okay, what are the different 418 00:20:54,900 --> 00:20:56,900 value streams going back to that as well? 419 00:20:57,200 --> 00:20:58,600 What are the business value streams? 420 00:20:58,600 --> 00:21:01,500 What are the things that customers pay for or are 421 00:21:01,500 --> 00:21:05,500 interested to that we provide so that we can then Have better 422 00:21:05,500 --> 00:21:08,600 understanding what are the independent lines of business 423 00:21:08,600 --> 00:21:11,900 that we can then align teams and have those teams deliver value 424 00:21:11,900 --> 00:21:14,900 more independently. So yes, it basically starts. 425 00:21:14,900 --> 00:21:18,300 They're speaking about monolith, since you mentioned about it, 426 00:21:18,300 --> 00:21:21,400 many teams, probably currently work with the Monopoly system, 427 00:21:21,400 --> 00:21:24,700 supporting multi lines of businesses and business models. 428 00:21:25,000 --> 00:21:27,900 And of course, the biggest topic everyone wants to talk about is 429 00:21:27,900 --> 00:21:30,300 how to break monolith into microservices. 430 00:21:30,600 --> 00:21:33,200 Is there any good practice from the team topologies point of 431 00:21:33,200 --> 00:21:34,700 view? How to actually conduct? 432 00:21:34,800 --> 00:21:38,600 This exercise. Yeah, so we tend to recommend 433 00:21:38,600 --> 00:21:42,400 that you take a step back before going into microservices. 434 00:21:42,500 --> 00:21:45,700 It can be very helpful. But before we go to that sort of 435 00:21:45,700 --> 00:21:49,300 level of granularity, if you look at the monolith, what we 436 00:21:49,300 --> 00:21:51,700 talk about in the book are fracture planes. 437 00:21:51,900 --> 00:21:55,400 Look at the ways that we can split the monolith that are 438 00:21:55,500 --> 00:21:59,200 effective and that will allow teams to align to this different 439 00:21:59,200 --> 00:22:02,500 smaller pieces. Microservices tend to be from a 440 00:22:02,500 --> 00:22:04,700 more technical perspective. How do we split? 441 00:22:04,900 --> 00:22:08,000 Listen to into different parts, but actually there are different 442 00:22:08,000 --> 00:22:10,300 fracture planes. You can think about obviously 443 00:22:10,300 --> 00:22:13,600 what we just discussed before about the business value 444 00:22:13,600 --> 00:22:16,300 streams. That would be the main kind of 445 00:22:16,300 --> 00:22:19,200 way that we would split the monolith in the language of 446 00:22:19,200 --> 00:22:21,100 domain-driven design. This would be your sort of 447 00:22:21,100 --> 00:22:24,400 bounded context that you understand, this more or less 448 00:22:24,400 --> 00:22:27,700 independent from other contacts of business, but then, there are 449 00:22:27,700 --> 00:22:30,500 other ways. So, we might even be splitting 450 00:22:30,500 --> 00:22:34,200 monolith to some extent based on the location of teams on the 451 00:22:34,200 --> 00:22:36,400 time zone. Owns of teams because if you 452 00:22:36,400 --> 00:22:40,000 have two teams that almost have no overlap in terms of their 453 00:22:40,000 --> 00:22:43,600 time zone or the working hours because of their time zone, then 454 00:22:43,600 --> 00:22:45,800 it's probably a good idea that they're working on very 455 00:22:45,800 --> 00:22:47,300 different parts of the same system. 456 00:22:47,300 --> 00:22:50,400 So they're not working on things that might cause dependencies 457 00:22:50,400 --> 00:22:53,500 between them because it will be very hard to communicate between 458 00:22:53,500 --> 00:22:56,200 those two teams. And we talked about other ideas. 459 00:22:56,200 --> 00:23:00,500 You might have some performance or regulatory requirements on 460 00:23:00,500 --> 00:23:03,500 some parts of the system, which means it makes sense that this 461 00:23:03,500 --> 00:23:06,800 is split from the rest. Stand the sign to one team or a 462 00:23:06,800 --> 00:23:10,800 few teams to take care of. So usually you will need a 463 00:23:10,808 --> 00:23:13,900 combination of fracture planes, especially the larger, the 464 00:23:13,900 --> 00:23:16,100 monolith to actually make sense of that. 465 00:23:16,300 --> 00:23:19,500 And so I think that's the sort of slightly higher level 466 00:23:19,500 --> 00:23:22,900 perspective to start with. Then the microservices, you do, 467 00:23:22,900 --> 00:23:25,700 this more coarse-grained split of the monolith and then you 468 00:23:25,700 --> 00:23:28,400 might look into more fine-grained split with 469 00:23:28,400 --> 00:23:30,800 microservices. I think the other aspect to 470 00:23:30,800 --> 00:23:33,900 consider is the cognitive load on teams that we talk about in 471 00:23:33,900 --> 00:23:36,700 the book. We also want to split and be 472 00:23:36,700 --> 00:23:39,600 mindful of what is the capacity of a single team. 473 00:23:39,800 --> 00:23:43,000 Do we need to split further some larger pieces of the system. 474 00:23:43,000 --> 00:23:46,300 So that actually the smaller pieces fit the capacity of the 475 00:23:46,300 --> 00:23:50,400 different teams, or does this look like it's reasonable size 476 00:23:50,400 --> 00:23:53,900 for a single team to own and to end and we're still talking 477 00:23:53,900 --> 00:23:57,600 about hopefully vertical slices of the original Monmouth. 478 00:23:58,200 --> 00:24:01,500 So these cognitive load seems to be like a key concept within 479 00:24:01,500 --> 00:24:03,700 team topologies. Maybe can you share a little 480 00:24:03,700 --> 00:24:04,700 bit? What do you mean by? 481 00:24:04,900 --> 00:24:07,800 Cognitive load and how do we actually measure whether the 482 00:24:07,800 --> 00:24:09,800 current team really has a good enough? 483 00:24:09,800 --> 00:24:13,800 Cognitive load capacity or is it like too much of it or maybe 484 00:24:13,800 --> 00:24:15,900 even less than it? So maybe can you explain? 485 00:24:15,900 --> 00:24:17,800 What is cognitive load in this sense? 486 00:24:18,500 --> 00:24:20,900 Yeah. So cognitive load is another 487 00:24:20,900 --> 00:24:24,800 sort of constraint on how much we can achieve and how can we 488 00:24:24,800 --> 00:24:29,000 get teams to be high-performing? If we don't like Conway's law, 489 00:24:29,000 --> 00:24:32,000 if we're not aware of the limits of cognitive load or cognitive 490 00:24:32,000 --> 00:24:35,700 capacity on teams, then we're probably gonna not, Be able to 491 00:24:35,700 --> 00:24:38,600 achieve high performance. So cognitive load theory is 492 00:24:38,600 --> 00:24:41,700 actually based on individuals and it's how much of our working 493 00:24:41,700 --> 00:24:44,200 memory is being used at the moment in time. 494 00:24:44,500 --> 00:24:47,100 So that's four individual. So this comes from field of 495 00:24:47,100 --> 00:24:50,000 psychology. This was coined by John sweller. 496 00:24:50,300 --> 00:24:53,400 But what we did with him topology is actually understand 497 00:24:53,400 --> 00:24:55,400 this applies at the team level as well. 498 00:24:55,600 --> 00:24:59,700 It's not a scientifically defined term if you like the 499 00:24:59,700 --> 00:25:03,600 actually research going on by John swallow and others on group 500 00:25:03,600 --> 00:25:06,600 cognitive load, so, It's actually an emerging area. 501 00:25:06,900 --> 00:25:09,900 What we identified is that there is a limit to the capacity of 502 00:25:09,900 --> 00:25:12,200 the team. Again, if the team has too many 503 00:25:12,200 --> 00:25:16,200 responsibilities or responsible for two large size of the system 504 00:25:16,200 --> 00:25:20,000 that are not able to fully understand and grasp how this 505 00:25:20,000 --> 00:25:23,500 code Works how this relates to other parts of the system, 506 00:25:23,700 --> 00:25:26,800 because it's too much for our capacity or we have too many 507 00:25:26,800 --> 00:25:28,800 responsibilities. And basically we're always 508 00:25:28,800 --> 00:25:32,100 running around trying to just respond to requests in the sort 509 00:25:32,100 --> 00:25:34,600 of firefighting mode and context switching. 510 00:25:34,800 --> 00:25:37,000 All the time. That's not going to be conducive 511 00:25:37,000 --> 00:25:40,800 to better performance, more autonomy and more ownership in 512 00:25:40,800 --> 00:25:44,000 those teams. Then cognitive load also can be 513 00:25:44,000 --> 00:25:46,700 split in different types. So we start to understand 514 00:25:46,700 --> 00:25:49,200 better. Yes, the overall idea that teams 515 00:25:49,200 --> 00:25:52,400 have a finite capacity of what they can understand and be 516 00:25:52,400 --> 00:25:54,600 comfortable with. But also, there are different 517 00:25:54,600 --> 00:25:58,000 types of cognitive load. The things we want to maximize 518 00:25:58,000 --> 00:26:00,800 have to do with understanding the business and the standing, 519 00:26:00,800 --> 00:26:03,700 the customers understanding, obviously the system, the code 520 00:26:03,700 --> 00:26:06,400 itself, how it Listen how we improve it? 521 00:26:06,600 --> 00:26:09,100 All those are more related to what is called the germane 522 00:26:09,100 --> 00:26:11,900 cognitive load, everything related, to this solution to the 523 00:26:11,900 --> 00:26:14,700 problem and the solution space. But there are other types of 524 00:26:14,700 --> 00:26:18,200 cognitive load, like extraneous and intrinsic extraneous is 525 00:26:18,200 --> 00:26:21,900 related to all the tasks that we need to do to deliver our work. 526 00:26:22,100 --> 00:26:25,600 How do I deploy my application? How do I run the tests? 527 00:26:25,600 --> 00:26:27,600 How do I access the test database? 528 00:26:27,800 --> 00:26:31,000 All these things that need to happen, but are not directly 529 00:26:31,000 --> 00:26:32,700 related to the problem and the value. 530 00:26:32,700 --> 00:26:36,100 We're providing to the customers and So that's where we should 531 00:26:36,100 --> 00:26:38,900 focus in terms of minimizing that cognitive load. 532 00:26:38,900 --> 00:26:41,900 That's why we introduced the four types of teams and the 533 00:26:41,900 --> 00:26:45,500 Three core interaction modes, which are meant to provide a 534 00:26:45,508 --> 00:26:49,200 sort of ecosystem of teams where you have the teams focused on 535 00:26:49,200 --> 00:26:52,100 the services, but we call streamline teams aligned to the 536 00:26:52,108 --> 00:26:54,900 business value streams. How do we minimize their 537 00:26:54,900 --> 00:26:58,100 cognitive load by providing useful services in a platform 538 00:26:58,100 --> 00:27:02,300 for example abstractions that help these teams go faster and 539 00:27:02,300 --> 00:27:04,600 deploy without worrying about all the details. 540 00:27:04,900 --> 00:27:07,900 Or monitor our service without having to install all the 541 00:27:07,900 --> 00:27:11,400 infrastructure and the tooling. If that can be provided by 542 00:27:11,400 --> 00:27:14,500 platform services that are focused on the experience, on 543 00:27:14,500 --> 00:27:17,900 minimizing the effort for the Streamline teams to understand 544 00:27:17,900 --> 00:27:20,900 how to do these things. With good abstractions and good 545 00:27:20,900 --> 00:27:23,900 developer experience. Then we help them minimize 546 00:27:23,900 --> 00:27:25,800 cognitive load the extraneous kind. 547 00:27:26,000 --> 00:27:29,500 So they have more sort of mental space to understand the business 548 00:27:29,500 --> 00:27:32,600 as well as the code itself. So they can better evolve and 549 00:27:32,600 --> 00:27:34,600 support it. So I think this is enough. 550 00:27:34,700 --> 00:27:36,800 Oh, the good segue to actually describe. 551 00:27:36,800 --> 00:27:39,500 What are the four fundamental team topologies? 552 00:27:39,500 --> 00:27:41,400 You mentioned in the book. So you have mentioned like 553 00:27:41,400 --> 00:27:44,600 streamline team and platform, maybe a brief description of all 554 00:27:44,600 --> 00:27:46,500 the for for the audience here to listen. 555 00:27:47,100 --> 00:27:49,000 So we start with streamline teams. 556 00:27:49,000 --> 00:27:51,600 So this would be teams with end-to-end ownership. 557 00:27:51,700 --> 00:27:53,400 Obviously. There are other terms that are 558 00:27:53,400 --> 00:27:56,100 similar like product teams cross-functional teams. 559 00:27:56,400 --> 00:27:59,700 We call them streamline teams because we thought the provided 560 00:27:59,700 --> 00:28:02,700 a more specific definition, because sometimes you have 561 00:28:02,700 --> 00:28:04,600 streams of work that are not necessarily. 562 00:28:04,800 --> 00:28:07,500 Product or a part of a larger product. 563 00:28:07,500 --> 00:28:10,600 So that's the starting point. So, ideally in organization you 564 00:28:10,600 --> 00:28:13,200 have, mostly streamline teams that are providing value to 565 00:28:13,200 --> 00:28:15,600 customers and have end-to-end ownership. 566 00:28:15,700 --> 00:28:19,100 But because of cognitive load, that means this might introduce 567 00:28:19,100 --> 00:28:22,000 a lot of Demand on this team because we're saying, well, you 568 00:28:22,000 --> 00:28:23,700 need to understand the customer problems. 569 00:28:23,700 --> 00:28:26,500 You need to understand then how to build a solution with 570 00:28:26,500 --> 00:28:28,700 software. You need to understand how to 571 00:28:28,700 --> 00:28:31,900 deploy, how to run the solution to minimize that sort of 572 00:28:31,900 --> 00:28:34,400 cognitive load with an have platform that I mentioned 573 00:28:34,400 --> 00:28:35,800 earlier. Layer where you have platform 574 00:28:35,800 --> 00:28:38,900 teams that are focused on. Providing the Streamline teams 575 00:28:38,900 --> 00:28:41,700 are their customers their focus on providing value to our 576 00:28:41,700 --> 00:28:45,600 internal teams, but also in this product Focus way where we need 577 00:28:45,600 --> 00:28:48,600 to understand our own internal customers and what do they 578 00:28:48,600 --> 00:28:50,800 really need? So we don't go off and build 579 00:28:50,800 --> 00:28:53,800 everything that we think they need but actually we talk to 580 00:28:53,800 --> 00:28:58,000 them, we get quick prototypes, we get fast, validation of, is 581 00:28:58,000 --> 00:28:59,700 this what's going to really help you? 582 00:28:59,900 --> 00:29:03,500 And then we have two more types of teams supporting and helping 583 00:29:03,500 --> 00:29:06,400 reduce cognitive load. One of them is enabling teams. 584 00:29:06,400 --> 00:29:09,600 This teams don't usually build any service. 585 00:29:09,600 --> 00:29:12,100 They are sort of experts in some domain. 586 00:29:12,100 --> 00:29:15,100 What they do is help the Streamline teams in particular, 587 00:29:15,100 --> 00:29:18,500 but maybe also platform teams, increase their awareness, and 588 00:29:18,500 --> 00:29:20,500 their understanding around different domains. 589 00:29:20,500 --> 00:29:23,200 Then this might be more technical understanding about 590 00:29:23,200 --> 00:29:26,000 test automation. For example, monitoring or can 591 00:29:26,000 --> 00:29:29,200 be more kind of product domains understanding more about user 592 00:29:29,200 --> 00:29:30,700 experience. And understanding more about 593 00:29:30,700 --> 00:29:33,200 regulations, perhaps in certain industries. 594 00:29:33,200 --> 00:29:37,300 These teams are usually small team of experts in the enabling 595 00:29:37,300 --> 00:29:41,300 team that are going and helping upskill the Streamline teams so 596 00:29:41,300 --> 00:29:44,300 that they have the necessary knowledge to do their work more 597 00:29:44,300 --> 00:29:47,100 autonomously. Not that we, we need everyone to 598 00:29:47,100 --> 00:29:49,600 become an expert in these domains, but at least have a 599 00:29:49,608 --> 00:29:52,700 sort of working knowledge that we can do the common tasks in 600 00:29:52,700 --> 00:29:55,400 the lifecycle. And finally, we have complicated 601 00:29:55,400 --> 00:29:59,400 subsystem teams, which are optional, we realize in some 602 00:29:59,400 --> 00:30:02,800 cases you do need these teams again because of cognitive load. 603 00:30:03,000 --> 00:30:05,800 So if you have a streamline team where Out of their service 604 00:30:05,800 --> 00:30:08,400 includes. For example, face recognition 605 00:30:08,400 --> 00:30:11,000 functionality nowadays. There are many sort of 606 00:30:11,000 --> 00:30:14,600 solutions, but I actually worked on some systems like that about 607 00:30:14,600 --> 00:30:18,200 10 years ago where they weren't. Well, the third party offerings 608 00:30:18,200 --> 00:30:20,700 that exist today. It was actually you needed 609 00:30:20,700 --> 00:30:23,600 someone with a PhD to understand the algorithm and the stand how 610 00:30:23,600 --> 00:30:26,500 to make changes how to test in those cases. 611 00:30:26,500 --> 00:30:28,700 It makes sense to have a complicated subsystem team where 612 00:30:28,700 --> 00:30:31,400 you say, there's a part of a larger service that really 613 00:30:31,400 --> 00:30:33,800 requires, very specialized knowledge. 614 00:30:33,800 --> 00:30:36,700 PhD. Type of knowledge, usually, not 615 00:30:36,700 --> 00:30:39,500 technology specialization, although in some particular 616 00:30:39,500 --> 00:30:43,400 cases might be the case where this team exists because they 617 00:30:43,400 --> 00:30:46,100 are helping reduce cognitive load on the Streamline team. 618 00:30:46,400 --> 00:30:49,400 So you could have one complicated subsystem team that 619 00:30:49,400 --> 00:30:51,900 only exists to help one streamline team. 620 00:30:52,100 --> 00:30:54,800 Maybe that's the only customer of this complicated subsystem, 621 00:30:54,800 --> 00:30:58,000 but it still makes sense because we reduce their cognitive load. 622 00:30:58,200 --> 00:31:00,900 They wouldn't be able to have end-to-end ownership of a 623 00:31:00,908 --> 00:31:04,600 service where there's one part that is super complicated, but 624 00:31:04,700 --> 00:31:08,500 In general, we find this should only be needed in very 625 00:31:08,500 --> 00:31:10,900 particular case. So most organizations probably 626 00:31:10,900 --> 00:31:13,600 shouldn't have any complicated subsystem teams and in some 627 00:31:13,600 --> 00:31:16,000 cases, they might need one or two maximum. 628 00:31:16,600 --> 00:31:19,400 So you mentioned that the last one the complicated subsystem 629 00:31:19,400 --> 00:31:21,600 team actually is an optional thing. 630 00:31:21,700 --> 00:31:24,500 But how about the other three? The Streamline team, the 631 00:31:24,500 --> 00:31:27,800 enabling team and the platform team, that's a company need to 632 00:31:27,800 --> 00:31:31,000 have all of them because now these days the way I think of it 633 00:31:31,000 --> 00:31:34,100 enabling team, probably a Consulting team can come in and 634 00:31:34,100 --> 00:31:35,500 help too. Enable teams. 635 00:31:35,800 --> 00:31:37,400 And also platform. We are talking about Cloud 636 00:31:37,400 --> 00:31:39,100 platforms. And so many platform as a 637 00:31:39,100 --> 00:31:41,800 service providers. That's the company need to 638 00:31:41,808 --> 00:31:44,400 necessarily have these three teams that you mentioned in the 639 00:31:44,400 --> 00:31:46,800 beginning. So it's not necessarily that you 640 00:31:46,800 --> 00:31:50,000 need two teams. I would say any organization 641 00:31:50,000 --> 00:31:53,100 will be in a better place if they have the thinking around 642 00:31:53,100 --> 00:31:56,200 this types of teams. So platform thinking enabling 643 00:31:56,200 --> 00:31:57,900 thinking. So what do I mean with that? 644 00:31:58,100 --> 00:32:01,000 Well to some extreme because we get this question often. 645 00:32:01,000 --> 00:32:03,700 If we're a small start-up we can't have all these different 646 00:32:03,700 --> 00:32:05,600 teams. So if Start from that, sort of 647 00:32:05,600 --> 00:32:07,800 extreme. And yes, you won't be able to 648 00:32:07,808 --> 00:32:11,000 have stream teams platform team plus enabling, but you can have 649 00:32:11,000 --> 00:32:13,200 the thinking's. So, the platform might be 650 00:32:13,200 --> 00:32:16,800 something as simple as, okay. We use, let's say awas, and we 651 00:32:16,800 --> 00:32:20,800 use some other sauce providers, but the platform, maybe it's 652 00:32:20,800 --> 00:32:23,000 just a Wiki page, that helps teams. 653 00:32:23,000 --> 00:32:25,500 Understand. How do we use that provide some 654 00:32:25,500 --> 00:32:29,400 useful, kind of default some useful recommendations on use 655 00:32:29,400 --> 00:32:31,500 serverless for this types of tasks. 656 00:32:31,500 --> 00:32:34,500 And this is how you can get started or use other services. 657 00:32:34,600 --> 00:32:37,700 Visas for other types of work. In a way, you can define a 658 00:32:37,700 --> 00:32:41,200 platform as just a Wiki page, helping guide teams and 659 00:32:41,200 --> 00:32:45,000 basically building in the shared knowledge of what works and what 660 00:32:45,000 --> 00:32:48,300 doesn't even if we're a start-up and the same for enabling teams 661 00:32:48,300 --> 00:32:50,500 understanding that. First of all, we know that 662 00:32:50,500 --> 00:32:53,800 technology is always evolving and new practices are coming up 663 00:32:53,800 --> 00:32:56,000 10 years ago was developed and five years ago. 664 00:32:56,000 --> 00:32:58,200 I think. Was that sorry started. 665 00:32:58,200 --> 00:33:00,600 That's not going to change that. Sort of evolution is going to 666 00:33:00,600 --> 00:33:04,400 continue to be aware of. How do we help teams? 667 00:33:04,700 --> 00:33:08,300 Evolve in a way that doesn't depend on their free time or 668 00:33:08,300 --> 00:33:11,300 depend on people having the willingness to learn outside of 669 00:33:11,300 --> 00:33:13,300 work. We shouldn't expect that from 670 00:33:13,300 --> 00:33:15,700 people. We should find ways and enabling 671 00:33:15,700 --> 00:33:18,500 teams or dignity. This enabling thinking is a way 672 00:33:18,500 --> 00:33:22,300 of allowing teams to grow, and to gain new capabilities over 673 00:33:22,300 --> 00:33:25,400 time, but you might not have a team, you might have a couple of 674 00:33:25,400 --> 00:33:27,800 people, for example, in a start-up who have been there 675 00:33:27,800 --> 00:33:31,900 longer, maybe are more senior. And so, maybe they dedicate part 676 00:33:31,900 --> 00:33:34,500 of their time to facilitate knowledge to others. 677 00:33:34,600 --> 00:33:37,700 Yes, or maybe even between more Senior Team and more junior 678 00:33:37,700 --> 00:33:40,000 team. If the startup is growing, where 679 00:33:40,000 --> 00:33:43,100 one team is helping facilitate the other, they're not fully 680 00:33:43,100 --> 00:33:45,200 dedicated. But at least you start having 681 00:33:45,200 --> 00:33:48,700 thus enabling thinking. And then at some sort of size. 682 00:33:48,700 --> 00:33:52,000 It starts to make sense that you have platform teams because if 683 00:33:52,000 --> 00:33:55,000 you have many streamline teams, you started want to have ways to 684 00:33:55,000 --> 00:33:59,000 embed good practices in the platform while considering also 685 00:33:59,000 --> 00:34:00,900 the specific needs of different teams. 686 00:34:01,100 --> 00:34:04,500 So starts to make sense to have platform teams and perhaps, 687 00:34:04,700 --> 00:34:07,600 Seems that depends also a lot on the domain. 688 00:34:07,800 --> 00:34:11,000 Like I said, you might have some Consultants helping so we have 689 00:34:11,000 --> 00:34:13,699 one example in the book. Exactly like that where an 690 00:34:13,699 --> 00:34:16,699 enabling team was set up with some external Consultants that 691 00:34:16,699 --> 00:34:19,699 brought sort of the knowledge around continuous delivery and 692 00:34:19,699 --> 00:34:21,800 modern practices for software delivery. 693 00:34:22,100 --> 00:34:24,800 And then you had some internal people who had the application, 694 00:34:24,800 --> 00:34:27,400 the system knowledge. So these people together made 695 00:34:27,400 --> 00:34:30,600 for a good enabling team that helped accelerate their delivery 696 00:34:30,600 --> 00:34:34,000 setup, some good practices and then expired in a way that the 697 00:34:34,000 --> 00:34:36,100 team cuz they had achieved their goals. 698 00:34:36,400 --> 00:34:39,100 There are other domains where you might need a more long-term 699 00:34:39,199 --> 00:34:43,300 enabling team, for example, P user experience or other areas 700 00:34:43,300 --> 00:34:46,600 where there's a constant need to evolve the learning and the 701 00:34:46,600 --> 00:34:49,400 skills of different teams. So it really depends. 702 00:34:49,500 --> 00:34:53,100 But the thinking of why we need this type of approach is what 703 00:34:53,100 --> 00:34:56,699 really matters at any scale. Thanks for that clarification. 704 00:34:57,000 --> 00:34:59,800 So when we have these teams, for example, let's say we have a 705 00:34:59,808 --> 00:35:03,500 streamline team and also platform team or even multiple 706 00:35:03,500 --> 00:35:05,800 streamline teams. In the company, you can have 707 00:35:05,800 --> 00:35:07,500 multiple products and business lines. 708 00:35:07,800 --> 00:35:09,700 I think in the book, you mentioned this concept called 709 00:35:09,700 --> 00:35:12,400 team API how the team should interact with each other. 710 00:35:12,500 --> 00:35:14,800 I mean, a lot of software developers understands about 711 00:35:14,800 --> 00:35:18,200 API, like software apis, but what about team API? 712 00:35:18,200 --> 00:35:22,200 What is actually team API? So it's a bit of a techie term, 713 00:35:22,200 --> 00:35:24,600 right? So apis, application programming 714 00:35:24,600 --> 00:35:27,900 interface is defining the way that you interact with some 715 00:35:27,900 --> 00:35:30,300 system or service through this API. 716 00:35:30,500 --> 00:35:32,800 Basically, it's an interface. So what we're saying is the team 717 00:35:32,800 --> 00:35:36,700 API is the interface to the Team the objective of the team apis 718 00:35:36,700 --> 00:35:39,400 for a team to clarify two other teams. 719 00:35:39,600 --> 00:35:42,500 How do we work? How do we like to communicate 720 00:35:42,500 --> 00:35:45,500 and interact with other teams? What are the practices that we 721 00:35:45,500 --> 00:35:46,900 follow? Also? 722 00:35:46,900 --> 00:35:49,400 What is our sort of roadmap? What are we working on? 723 00:35:49,400 --> 00:35:52,700 What's coming next? It's very much focused on what 724 00:35:52,700 --> 00:35:54,500 other teams need to know about us. 725 00:35:54,800 --> 00:35:57,400 What's going to be helpful for other teams to interact and 726 00:35:57,400 --> 00:36:00,400 understand what we do. So it's bit different from, for 727 00:36:00,400 --> 00:36:02,500 example. Team working agreement, that 728 00:36:02,500 --> 00:36:05,400 tends to be internal to the team where Say okay. 729 00:36:05,500 --> 00:36:08,200 This is how we work together inside the team. 730 00:36:08,400 --> 00:36:12,100 This is how we follow scrum or we follow TD or what practices 731 00:36:12,100 --> 00:36:14,600 do we do internally? And so there might be some 732 00:36:14,600 --> 00:36:17,200 overlap but the intent is quite different. 733 00:36:17,200 --> 00:36:21,200 So the team API is actually making it easier for others to 734 00:36:21,200 --> 00:36:25,100 interface with us as a team. So that we have more clarity and 735 00:36:25,100 --> 00:36:28,100 less ambiguity on how other teams should interact with us. 736 00:36:28,800 --> 00:36:31,400 So maybe, can you share with us? What are some of the good 737 00:36:31,400 --> 00:36:34,400 practices for team apis? Maybe for us to implement? 738 00:36:34,500 --> 00:36:36,400 Until within our daily working life. 739 00:36:37,100 --> 00:36:40,500 Yeah, it's really thinking about the other team's perspective. 740 00:36:40,700 --> 00:36:44,100 So it's a little bit of having that empathy as well to 741 00:36:44,100 --> 00:36:46,500 understand. If other teams might be 742 00:36:46,500 --> 00:36:49,400 frustrated in terms of their interactions with us, or they 743 00:36:49,400 --> 00:36:52,600 don't understand what we do. Okay, how can we make that 744 00:36:52,600 --> 00:36:55,000 better? How can we clarify that through 745 00:36:55,000 --> 00:36:58,800 the team API, perhaps what? I usually recommend two teams is 746 00:36:58,900 --> 00:37:01,400 the team API, should not be a static artifact. 747 00:37:01,500 --> 00:37:05,600 You should evolve it over time as you realize that Problems or 748 00:37:05,600 --> 00:37:08,000 awkward interactions have happened with other teams. 749 00:37:08,300 --> 00:37:12,300 So if for example, we often get slack messages from other teams 750 00:37:12,300 --> 00:37:15,700 asking similar questions with this something that we could 751 00:37:15,700 --> 00:37:17,900 actually make visible in the API. 752 00:37:18,100 --> 00:37:20,900 Maybe there's some documentation that just people don't know how 753 00:37:20,900 --> 00:37:23,600 to access it. So, with the team API, is a sort 754 00:37:23,600 --> 00:37:25,800 of single entry point to our team. 755 00:37:26,100 --> 00:37:27,700 That's where we should. Then make it clear? 756 00:37:27,700 --> 00:37:30,300 This sort of questions. Look at this document and you'll 757 00:37:30,300 --> 00:37:32,500 find the answer, probably in, if not contact us. 758 00:37:32,500 --> 00:37:37,000 So we make that That sort of communication easier and we also 759 00:37:37,000 --> 00:37:40,500 reduce the overload on our team on some things that maybe we 760 00:37:40,500 --> 00:37:43,200 didn't expect to get questions because we have documentation, 761 00:37:43,200 --> 00:37:46,000 but actually it's not visible. It's not easy to access. 762 00:37:46,200 --> 00:37:48,800 You can't expect other teams to know where all of your 763 00:37:48,800 --> 00:37:52,000 documentation is or we'll all of your practices are. 764 00:37:52,200 --> 00:37:55,800 It's really providing this single entry point to help other 765 00:37:55,800 --> 00:37:59,400 teams interact with us. And this is also related to the 766 00:37:59,400 --> 00:38:02,100 tree interaction modes that you mentioned in the book, right? 767 00:38:02,100 --> 00:38:03,800 So maybe you can share a little bit. 768 00:38:03,800 --> 00:38:06,500 What are the Interaction modes that you mentioned. 769 00:38:07,100 --> 00:38:09,600 Yes. So besides the four fundamental 770 00:38:09,600 --> 00:38:12,400 types of teams we talked about, then we have the Three core 771 00:38:12,400 --> 00:38:17,000 interaction modes, which helped these teams understand what are 772 00:38:17,000 --> 00:38:19,300 some useful ways for us to interact. 773 00:38:19,400 --> 00:38:23,100 What are the expected behaviors from us as a team when we're 774 00:38:23,100 --> 00:38:25,600 doing this interaction, with other teams in many 775 00:38:25,600 --> 00:38:29,100 organizations. There is this sort of naive 776 00:38:29,100 --> 00:38:32,100 expectation that well. We just collaborate whenever we 777 00:38:32,100 --> 00:38:34,400 need but that's very Loosely defined. 778 00:38:34,500 --> 00:38:36,700 Find, right. What does that actually mean? 779 00:38:36,900 --> 00:38:39,000 What is the purpose of this collaboration? 780 00:38:39,200 --> 00:38:41,400 And so many teams, actually, when they're talking about 781 00:38:41,400 --> 00:38:44,300 cooperation with other teams. It's actually more. 782 00:38:44,300 --> 00:38:47,300 The relationship they have with other teams, the dependency they 783 00:38:47,300 --> 00:38:48,800 have. They're not actually having 784 00:38:48,800 --> 00:38:53,300 specific concrete ways of interacting specifically what we 785 00:38:53,300 --> 00:38:56,700 described in the book that we found to be the three key 786 00:38:56,700 --> 00:38:59,300 interactions our first collaboration but in a 787 00:38:59,300 --> 00:39:02,600 well-defined way, so we're talking about two teams working 788 00:39:02,600 --> 00:39:04,400 together for a period of time to achieve. 789 00:39:04,600 --> 00:39:07,900 Of a specific outcome. So the more specific this 790 00:39:07,900 --> 00:39:11,200 outcome is the better. We'll be able to identify if 791 00:39:11,200 --> 00:39:14,100 we've achieved it or not. So maybe we're working together 792 00:39:14,100 --> 00:39:18,200 to understand how we automate some deployment of some Services 793 00:39:18,400 --> 00:39:20,100 if the outcome is. Well defined. 794 00:39:20,100 --> 00:39:23,200 And once we have one automated deployment in the pipeline, then 795 00:39:23,200 --> 00:39:24,900 we can say the collaboration is done. 796 00:39:25,100 --> 00:39:27,800 Yes or no. Is the collaboration finished. 797 00:39:28,000 --> 00:39:31,500 And we also set the expectation on how long we expect this to 798 00:39:31,500 --> 00:39:33,700 last. So it's not an open-ended 799 00:39:33,700 --> 00:39:36,500 collaboration. Ian which like I said can lead 800 00:39:36,500 --> 00:39:39,500 to actually more of a relationship and the dependency 801 00:39:39,500 --> 00:39:42,200 between teams where every time we need to deploy, we need to 802 00:39:42,200 --> 00:39:45,200 ask this other team to help us. For example, that's not the 803 00:39:45,200 --> 00:39:46,500 collaboration. We're talking about, that's a 804 00:39:46,500 --> 00:39:48,900 dependency and it's actually a blocking dependency. 805 00:39:48,900 --> 00:39:52,000 We cannot do anything unless this other team has the time to 806 00:39:52,000 --> 00:39:54,300 help us. We want to move away from that 807 00:39:54,300 --> 00:39:57,600 with kind of specific ways that teams should interact to help 808 00:39:57,600 --> 00:40:01,000 them achieve a certain outcomes. So collaboration is one of them 809 00:40:01,200 --> 00:40:04,200 then we have facilitating as another core interaction mode. 810 00:40:04,500 --> 00:40:07,100 Specially for enabling teams. They are facilitating knowledge 811 00:40:07,100 --> 00:40:09,900 to others. So you're typically not actually 812 00:40:09,900 --> 00:40:13,800 building anything or working on some service where you're maybe 813 00:40:13,800 --> 00:40:16,900 pairing or running some workshops or helping teams 814 00:40:16,900 --> 00:40:19,200 understand improve their knowledge around. 815 00:40:19,200 --> 00:40:23,200 Some aspects of either the business or the technical side 816 00:40:23,200 --> 00:40:25,700 or practices that we use in the organization. 817 00:40:25,900 --> 00:40:30,100 So that's the facilitating again should be framed in terms of 818 00:40:30,100 --> 00:40:33,100 what's the expected duration. What do we want to achieve? 819 00:40:33,300 --> 00:40:36,300 What should you know? After we've facilitated for this 820 00:40:36,300 --> 00:40:39,000 period of time and finally, we have acts as a service. 821 00:40:39,000 --> 00:40:41,800 So that's very much based on things like infrastructure as a 822 00:40:41,808 --> 00:40:45,200 service or software as a service where especially for the 823 00:40:45,200 --> 00:40:47,900 platform we're saying. At some point. 824 00:40:47,900 --> 00:40:52,000 We want to have services in a platform that are mature enough 825 00:40:52,000 --> 00:40:55,100 and stable and provide a good developer experience with the 826 00:40:55,107 --> 00:40:58,300 right documentation, right? Level of reliability. 827 00:40:58,600 --> 00:41:02,200 So that teams can consume without actual interaction. 828 00:41:02,400 --> 00:41:06,400 So it's the lack of interaction. As we have this service in a way 829 00:41:06,400 --> 00:41:09,100 that is easy enough to understand to consume 830 00:41:09,100 --> 00:41:11,400 independently. So have one team, providing a 831 00:41:11,408 --> 00:41:14,500 service and then one or more teams consuming the service, 832 00:41:14,900 --> 00:41:17,700 very much. Like you consume AWS Services, 833 00:41:17,700 --> 00:41:19,600 right? You don't expect to have to talk 834 00:41:19,600 --> 00:41:22,200 to AWS Engineers to run their services. 835 00:41:22,400 --> 00:41:25,100 They've done the work. Hopefully, there are degrees 836 00:41:25,100 --> 00:41:28,300 around this where sometimes the service needs some improvements 837 00:41:28,300 --> 00:41:31,000 and the documentation needs Improvement, but, in general, 838 00:41:31,000 --> 00:41:35,700 they're at mature enough state, where other Ins consume them 839 00:41:35,700 --> 00:41:38,700 independently, we did Three core interaction mode. 840 00:41:38,800 --> 00:41:42,800 You can then help teams have more focused, interactions 841 00:41:42,800 --> 00:41:46,100 understand when, and how they should interact with others, 842 00:41:46,300 --> 00:41:48,500 instead of that kind of blurry, everyone. 843 00:41:48,500 --> 00:41:51,000 Collaborates with everyone just to finalize. 844 00:41:51,100 --> 00:41:53,000 We shouldn't expect this interaction, so long. 845 00:41:53,000 --> 00:41:56,300 These three modes to always go perfectly and smoothly, there 846 00:41:56,300 --> 00:41:59,400 will be issues and situations where we thought this was going 847 00:41:59,400 --> 00:42:01,300 to take two weeks. It took two months. 848 00:42:01,500 --> 00:42:04,300 Those are great opportunities to actually reflect on. 849 00:42:04,500 --> 00:42:07,100 Why did it take so long? Was that something that wasn't 850 00:42:07,100 --> 00:42:09,500 clear? Maybe we wanted to collaborate. 851 00:42:09,500 --> 00:42:12,600 The one of the team's actually needs to be facilitated first to 852 00:42:12,600 --> 00:42:15,200 improve their understanding of some domain. 853 00:42:15,200 --> 00:42:17,600 Let's say about infrastructure as code. 854 00:42:17,600 --> 00:42:20,100 They need to better understand it before they can collaborate 855 00:42:20,100 --> 00:42:22,300 with another team that has more experience. 856 00:42:22,600 --> 00:42:24,900 So that the actually makes sense to collaborate. 857 00:42:25,200 --> 00:42:28,500 Otherwise the collaboration becomes a facilitating mode. 858 00:42:28,700 --> 00:42:32,000 We're not saying that it's all going to go nice and smoothly, 859 00:42:32,000 --> 00:42:35,100 but it provides a better framing to Actually learn. 860 00:42:35,100 --> 00:42:38,100 And then understand when some interaction goes wrong or 861 00:42:38,100 --> 00:42:40,500 awkward. How can we learn from that and 862 00:42:40,500 --> 00:42:43,300 course, correct? So having all these knowledge 863 00:42:43,300 --> 00:42:46,100 that we just discussed. I know that various teams are in 864 00:42:46,100 --> 00:42:49,200 different stages. Some are more mature, some more 865 00:42:49,200 --> 00:42:51,000 messy than the other so to speak. 866 00:42:51,200 --> 00:42:55,200 So maybe one key takeaway from you among all these situation. 867 00:42:55,200 --> 00:42:57,300 Of course, it's quite tough to Define. 868 00:42:57,400 --> 00:42:59,700 What will be the key? Takeaway of key message that you 869 00:42:59,700 --> 00:43:01,400 want to give to the listeners, hear? 870 00:43:01,700 --> 00:43:04,200 What can they do in order to improve their team? 871 00:43:04,200 --> 00:43:07,300 The Structural maybe the way of collaboration within their team 872 00:43:07,300 --> 00:43:10,500 in order to become much better aligned to the team topologies. 873 00:43:10,900 --> 00:43:15,600 Just one, I could be many up to you, looking back at our 874 00:43:15,600 --> 00:43:18,300 conversation. I would say for engineering 875 00:43:18,300 --> 00:43:21,000 managers, in general. Obviously, you have different 876 00:43:21,000 --> 00:43:23,800 responsibilities and different organizations, but in general, 877 00:43:23,800 --> 00:43:27,000 start by acknowledging this constraints that we talked about 878 00:43:27,000 --> 00:43:28,900 like Conway's law, cognitive load. 879 00:43:29,100 --> 00:43:32,500 Also trust boundaries that we didn't talk about, but the fact 880 00:43:32,500 --> 00:43:36,900 that we are conditioned as Owens in certain ways and specifically 881 00:43:36,900 --> 00:43:39,700 in software delivery. Also things like Conway's law. 882 00:43:39,700 --> 00:43:42,600 So acknowledge that this constraints exist. 883 00:43:42,700 --> 00:43:45,600 Often, we're focused on what are the good practices or best 884 00:43:45,600 --> 00:43:47,900 practices? And what's the best way to do 885 00:43:47,900 --> 00:43:50,400 things? Practices and principles are 886 00:43:50,400 --> 00:43:53,300 obviously necessary and useful, but they should be informed by. 887 00:43:53,300 --> 00:43:55,300 What are the constraints in the first place? 888 00:43:55,600 --> 00:43:58,400 Constraints are usually things. We cannot really change. 889 00:43:58,600 --> 00:44:02,500 So limits on cognitive load limits on trust between groups 890 00:44:02,500 --> 00:44:04,800 of teams. Conway's law are things Cannot 891 00:44:04,800 --> 00:44:07,000 really change. So we need to acknowledge them 892 00:44:07,000 --> 00:44:10,200 and then build and decide on practices and principles based 893 00:44:10,200 --> 00:44:12,200 on that. Because if we don't, then we 894 00:44:12,200 --> 00:44:14,400 might be fighting these constraints rather than 895 00:44:14,400 --> 00:44:16,900 understanding and leveraging them in our advantage. 896 00:44:17,100 --> 00:44:20,100 So I would say that's the first thing, the other thing with Team 897 00:44:20,100 --> 00:44:22,400 topologies. Hopefully, we're not just 898 00:44:22,400 --> 00:44:25,500 clarifying the ways that teams can interact and their mission 899 00:44:25,500 --> 00:44:28,700 of different types of teams. But also we're hopefully helping 900 00:44:28,700 --> 00:44:32,500 teams become more motivated with feeling more autonomous that I 901 00:44:32,500 --> 00:44:35,500 have more ownership of their service or the things they 902 00:44:35,500 --> 00:44:37,800 provide and that they're becoming more competent. 903 00:44:37,900 --> 00:44:41,200 So these are the key drivers of intrinsic motivation. 904 00:44:41,400 --> 00:44:43,700 Daniel pink wrote about in his book drive. 905 00:44:44,000 --> 00:44:47,400 So we think Tim topology is also helps teams, become more 906 00:44:47,400 --> 00:44:50,700 autonomous have more ownership. And so the role of the 907 00:44:50,700 --> 00:44:53,800 engineering manager, ideally starts to move away from 908 00:44:53,800 --> 00:44:57,500 managing the team per se and and making decisions for the team to 909 00:44:57,500 --> 00:45:01,200 actually making less decisions. Let the teams have more kind of 910 00:45:01,200 --> 00:45:04,700 local decision-making and so if you're sort of getting Out of 911 00:45:04,700 --> 00:45:07,900 the way of the teams, providing them what they need to become 912 00:45:07,900 --> 00:45:11,900 more autonomous in terms of skills competences and support. 913 00:45:11,900 --> 00:45:15,900 Then you can look more into how do we help even if we're a 914 00:45:15,908 --> 00:45:18,500 manager of one team? How do we help this team? 915 00:45:18,500 --> 00:45:22,200 Understand how to deal with other teams in a more productive 916 00:45:22,200 --> 00:45:24,100 way? How we help this team. 917 00:45:24,100 --> 00:45:27,100 Our team remove blocking dependencies on other teams. 918 00:45:27,400 --> 00:45:30,600 That's not easy for a team that there's already quite busy with 919 00:45:30,600 --> 00:45:33,500 their day-to-day work and their goals as a team. 920 00:45:33,700 --> 00:45:38,000 It's I think we're managers can actually help a lot is start 921 00:45:38,000 --> 00:45:40,900 helping address the blocking dependencies problem. 922 00:45:41,100 --> 00:45:44,100 This is unfamiliar for many teams to deal with is, how do we 923 00:45:44,100 --> 00:45:46,100 deal with this? We can apply the interaction 924 00:45:46,100 --> 00:45:48,400 patterns. Let's have some collaboration so 925 00:45:48,400 --> 00:45:51,300 that we don't depend on you anymore to do the deployments. 926 00:45:51,300 --> 00:45:52,700 For example, how do we collaborate? 927 00:45:52,700 --> 00:45:55,300 So we understand how to automate our own deployments. 928 00:45:55,300 --> 00:45:59,000 For example, the managers can have a very strong I think input 929 00:45:59,000 --> 00:46:02,600 on that helping team navigate their dependencies on others. 930 00:46:02,900 --> 00:46:06,900 Can we actually Move or minimize blocking dependencies in 931 00:46:06,900 --> 00:46:09,300 particular. And finally, one last thing. 932 00:46:09,700 --> 00:46:12,700 Sorry, if it's too much, just one last thing is start. 933 00:46:12,700 --> 00:46:16,100 Also thinking about alignment of purpose, between the team and 934 00:46:16,100 --> 00:46:18,800 individuals with a fundamental types of teams. 935 00:46:19,000 --> 00:46:22,200 We now have ability to be more clear on what is the mission of 936 00:46:22,200 --> 00:46:26,200 this team of a streamline team is different from enabling team 937 00:46:26,200 --> 00:46:28,500 or platform team. We have more clarity of. 938 00:46:28,500 --> 00:46:31,300 Why does our team exists. What are we trying to achieve? 939 00:46:31,300 --> 00:46:34,200 Who are customers, but then there's also the individual 940 00:46:34,300 --> 00:46:35,300 All-purpose. Right. 941 00:46:35,300 --> 00:46:38,700 Every person has their own individual goals and individual 942 00:46:38,700 --> 00:46:42,500 motivation and often we don't consider the two together. 943 00:46:42,500 --> 00:46:44,300 We think. Well, the team purpose and 944 00:46:44,300 --> 00:46:46,500 everyone aligns to the team purpose again. 945 00:46:46,500 --> 00:46:50,300 It's not really how things work people have their own goals and 946 00:46:50,300 --> 00:46:54,000 what they want to achieve, we can Surface those conversations, 947 00:46:54,000 --> 00:46:58,000 understand someone who is really focused on technical side and 948 00:46:58,000 --> 00:47:00,800 the standing the technology and keeping up to date on that. 949 00:47:00,900 --> 00:47:03,800 Maybe it's not a great fit for a streamline team where you want 950 00:47:03,800 --> 00:47:05,300 more. He's shaped or more. 951 00:47:05,300 --> 00:47:08,100 General is people that are actually more focused on 952 00:47:08,100 --> 00:47:11,100 end-to-end delivery. So maybe that person is a better 953 00:47:11,100 --> 00:47:13,900 fit for a platform or even perhaps enabling team. 954 00:47:14,200 --> 00:47:17,800 And so helping understand what are the individual purpose and 955 00:47:17,800 --> 00:47:21,200 how they align. Which types of teams often is a 956 00:47:21,200 --> 00:47:24,300 mixed, where you need people to align their individual Purpose 957 00:47:24,300 --> 00:47:27,400 with the team, but also be willing to learn and improve on 958 00:47:27,400 --> 00:47:30,200 some areas that they don't have as much experience yet. 959 00:47:30,300 --> 00:47:33,000 So even for platform, team, for example, you might have people 960 00:47:33,000 --> 00:47:35,800 who are more focused on understanding the technology and 961 00:47:35,800 --> 00:47:38,400 the technical side, but they still need to understand. 962 00:47:38,400 --> 00:47:40,600 How do we deal with internal customers? 963 00:47:40,700 --> 00:47:44,100 How do we get much better insights on what they need? 964 00:47:44,300 --> 00:47:48,100 How our platform is helping or not getting metrics and getting 965 00:47:48,100 --> 00:47:51,200 the right interactions with those teams in short, understand 966 00:47:51,200 --> 00:47:54,900 your constraints, first. Get out of the way of teams as 967 00:47:54,900 --> 00:47:57,500 much as possible. Let them make more decisions on 968 00:47:57,500 --> 00:48:00,500 their own increase their autonomy and ownership help 969 00:48:00,500 --> 00:48:03,500 teams deal with dependencies between them, especially 970 00:48:03,500 --> 00:48:06,000 blocking the pain. Is help them navigate those and 971 00:48:06,000 --> 00:48:09,700 hopefully minimize those so we can have faster flow and finally 972 00:48:09,700 --> 00:48:12,500 help align individual purpose and in purpose. 973 00:48:13,200 --> 00:48:16,100 Thanks for all the tips. So I know that we arrived to the 974 00:48:16,100 --> 00:48:19,100 end of our conversation, but I have one last question that 975 00:48:19,100 --> 00:48:21,900 normally I ask for all my guests which is called the tree 976 00:48:21,900 --> 00:48:24,600 technical leadership wisdom. So maybe manual. 977 00:48:24,600 --> 00:48:26,200 Can you share with the audience here? 978 00:48:26,200 --> 00:48:28,200 What are your three technical leadership wisdom? 979 00:48:28,800 --> 00:48:31,900 So it's basically what I just said, I think from a team 980 00:48:31,900 --> 00:48:34,800 topologies perspective understanding In this 981 00:48:34,800 --> 00:48:38,600 constraints that we have, then understanding that we'll be able 982 00:48:38,600 --> 00:48:42,100 to achieve more productivity and more faster flow. 983 00:48:42,100 --> 00:48:44,100 If we have teams with more autonomy. 984 00:48:44,400 --> 00:48:47,900 And finally, if we help reduce dependencies between teams, 985 00:48:47,900 --> 00:48:50,400 especially blocking dependencies, which again 986 00:48:50,400 --> 00:48:53,400 involves a lot of the things we talked about understanding your 987 00:48:53,400 --> 00:48:56,100 value streams. Understanding where is the wait 988 00:48:56,100 --> 00:48:59,100 time, where are the dependencies the handovers of work between 989 00:48:59,100 --> 00:49:01,300 teams that we might need to deal with. 990 00:49:01,500 --> 00:49:05,600 And then how do we increase the skills of Our streamline teams 991 00:49:05,600 --> 00:49:09,800 with enabling aspects and also reduce their cognitive load with 992 00:49:09,900 --> 00:49:12,500 platform. So I would say those three 993 00:49:12,500 --> 00:49:16,100 things, understand constraints, like Conway's law cognitive load 994 00:49:16,100 --> 00:49:18,400 responder. He's looking for ways to improve 995 00:49:18,400 --> 00:49:21,800 the autonomy and the ownership of the Streamline teams and 996 00:49:21,800 --> 00:49:25,100 other types of teams. Help teams navigate sort of the 997 00:49:25,100 --> 00:49:28,500 ecosystem and navigate and reduce blocking dependencies 998 00:49:28,500 --> 00:49:30,400 between them. Thanks so much man. 999 00:49:30,400 --> 00:49:32,500 Well, so for people who wants to follow you online. 1000 00:49:32,500 --> 00:49:34,100 Is there a place for them to follow you? 1001 00:49:34,700 --> 00:49:36,800 Yes, so there are two main places. 1002 00:49:37,100 --> 00:49:38,400 First. We have our website team 1003 00:49:38,400 --> 00:49:41,900 topologies.com. So in there, you can find new 1004 00:49:42,000 --> 00:49:44,900 industry examples and case studies that came out after the 1005 00:49:44,900 --> 00:49:47,300 book was published. The book was published late 1006 00:49:47,400 --> 00:49:49,900 2019. So since then, we've learned 1007 00:49:49,900 --> 00:49:53,000 also new patterns, and we have new examples. 1008 00:49:53,300 --> 00:49:56,400 So all of that is available at team topologies.com. 1009 00:49:56,700 --> 00:49:59,600 And then we have started an academy called team topologies 1010 00:49:59,600 --> 00:50:01,900 academy. So that's at academy.com 1011 00:50:01,900 --> 00:50:05,500 topologies.com., What we're trying to do is Have video based 1012 00:50:05,500 --> 00:50:09,400 on demand courses that help people learn about the key ideas 1013 00:50:09,400 --> 00:50:12,000 of topologies, sort of more condensed way. 1014 00:50:12,000 --> 00:50:15,200 So we have a first course called team topologies distilled and 1015 00:50:15,200 --> 00:50:18,100 then we'll be adding more courses where we bring our 1016 00:50:18,100 --> 00:50:21,500 latest insights around team topologies things that work. 1017 00:50:21,500 --> 00:50:24,400 Well, things that maybe in certain situations don't work as 1018 00:50:24,400 --> 00:50:28,100 well, and also new patterns that we find and new knowledge. 1019 00:50:28,300 --> 00:50:31,800 So that's all kind of come in the next months and years for 1020 00:50:31,800 --> 00:50:34,100 the Academy. So, thanks my love for you. 1021 00:50:34,300 --> 00:50:36,600 Time is really great to have a talk with you today, and thanks 1022 00:50:36,600 --> 00:50:39,000 for sharing your knowledge. Thank you very much. 1023 00:50:41,500 --> 00:50:44,900 Thank you for listening to this episode and for staying right 1024 00:50:44,900 --> 00:50:47,700 till the end. If you highly enjoyed, please 1025 00:50:47,700 --> 00:50:50,600 share it with your friends and colleagues who you think would 1026 00:50:50,600 --> 00:50:53,400 also benefit from listening to this episode. 1027 00:50:53,600 --> 00:50:56,500 And if you're new to the podcast, make sure to subscribe 1028 00:50:56,500 --> 00:50:59,400 and leave me your valuable review and feedback. 1029 00:50:59,500 --> 00:51:03,200 It really, really helps me a lot in order to grow this podcast 1030 00:51:03,200 --> 00:51:05,800 better. You can also find the full show 1031 00:51:05,800 --> 00:51:09,300 notes of this conversation on the episode page at technology. 1032 00:51:09,300 --> 00:51:12,600 No, the death. Including the full transcript 1033 00:51:12,600 --> 00:51:16,300 interesting quotes, and links to the resources and mentions from 1034 00:51:16,300 --> 00:51:19,100 the conversation. And lastly make sure to 1035 00:51:19,100 --> 00:51:21,700 subscribe to the show's mailing list on pecola journal. 1036 00:51:21,700 --> 00:51:25,000 The deaf to get notified for any future episodes. 1037 00:51:25,400 --> 00:51:28,100 Stay tuned for the next technique Journal episode. 1038 00:51:28,200 --> 00:51:29,800 And until then. Goodbye.