1 00:00:00,080 --> 00:00:02,720 Scrum in my opinion is a pure business practice. 2 00:00:02,760 --> 00:00:05,160 Head Child kind of became a micromanagement tool product. 3 00:00:05,320 --> 00:00:07,560 Thinks its own way. Technology thinks the other way. 4 00:00:07,640 --> 00:00:09,680 Sometimes they balance each other, sometimes they fight each 5 00:00:09,720 --> 00:00:11,480 other. When the project was a failure, 6 00:00:11,520 --> 00:00:15,000 it was most of the time not the tech that was failing, but that 7 00:00:15,000 --> 00:00:17,520 we built the wrong thing. You really need to differentiate 8 00:00:17,520 --> 00:00:20,200 between problems and solutions because a lot of teams are 9 00:00:20,200 --> 00:00:23,120 skipping this step and coming up as a solution too early. 10 00:00:23,200 --> 00:00:25,920 If you want to have an empowered team and you only have 11 00:00:25,920 --> 00:00:29,240 introverted engineers who only want to work on their tickets, 12 00:00:29,240 --> 00:00:32,800 then that's the the strong team. We as an industry, we are 13 00:00:32,800 --> 00:00:35,320 working still like on the conveyor belt. 14 00:00:35,400 --> 00:00:39,000 And the conveyor belt is a useful metaphor for industry and 15 00:00:39,000 --> 00:00:42,280 for manufacturing, but it's not a very good metaphor for 16 00:00:42,280 --> 00:00:44,960 producing software. In a lot of traditional 17 00:00:44,960 --> 00:00:49,400 settings, they see writing code as the manufacturing line, but 18 00:00:49,400 --> 00:00:52,840 the fundamental misunderstanding is that building software is the 19 00:00:52,840 --> 00:00:55,400 design process. We are not implementing A solved 20 00:00:55,400 --> 00:00:58,680 problem, we are solving the problems, so we are making 21 00:00:58,800 --> 00:01:01,040 creative decisions every hour of the day. 22 00:01:01,360 --> 00:01:04,599 The rise of AI is a very good argument for engineers. 23 00:01:04,599 --> 00:01:07,280 I asked them what are they worth in 10 years that you can write 24 00:01:07,280 --> 00:01:09,600 JavaScript? I don't think they're not worth 25 00:01:09,600 --> 00:01:11,520 much in 10 years. So the main topic of our 26 00:01:11,520 --> 00:01:13,520 discussion is move fast and break silos. 27 00:01:13,640 --> 00:01:15,040 What are some of the key practices? 28 00:01:15,360 --> 00:01:19,560 Everything is centered around how we slice the work and how we 29 00:01:19,560 --> 00:01:22,080 are aligning the teams around this work. 30 00:01:22,400 --> 00:01:24,480 What I mean was how the work is sliced. 31 00:01:24,640 --> 00:01:43,600 It's for me about how. Hello everyone, welcome back to 32 00:01:43,600 --> 00:01:45,960 another new episode of the Techni General Podcast. 33 00:01:45,960 --> 00:01:48,160 Today I have with me Klaus Breyer. 34 00:01:48,480 --> 00:01:51,480 So he's kind of like experienced CPTO, right? 35 00:01:51,760 --> 00:01:54,080 I haven't heard about the term CPTO before. 36 00:01:54,320 --> 00:01:56,680 I guess it's something that maybe we can also talk about. 37 00:01:56,960 --> 00:01:59,760 So Klaus, welcome to the show. I'm really looking forward to 38 00:01:59,760 --> 00:02:02,680 discuss the topics that we plan to talk about because it's 39 00:02:02,680 --> 00:02:05,320 something about, you know, highly functional and performing 40 00:02:05,320 --> 00:02:07,480 teams, engineering teams, right? So welcome to the show. 41 00:02:08,240 --> 00:02:10,360 Yes, it's a pleasure. It's an honor to be here. 42 00:02:11,000 --> 00:02:14,160 Klaus, maybe in the beginning, I want you to share a little bit 43 00:02:14,160 --> 00:02:17,360 more about yourself, right? If you can share career turning 44 00:02:17,360 --> 00:02:19,760 points that you think we can learn from you, I think that 45 00:02:19,760 --> 00:02:21,680 will be great. Yes, sure. 46 00:02:21,680 --> 00:02:25,720 So I studied software engineering and directly 47 00:02:25,720 --> 00:02:28,840 afterwards I Co founded my first company. 48 00:02:29,200 --> 00:02:33,120 It was a digital agency and I was the CTO. 49 00:02:33,720 --> 00:02:37,920 This was already 15 years ago, so when the year 2010 now. 50 00:02:37,920 --> 00:02:42,520 And from the beginning I was puzzled or fascinated with the 51 00:02:42,520 --> 00:02:46,320 challenge of how engineers and designers could work together. 52 00:02:46,760 --> 00:02:49,880 At the beginning I thought it was a tool problem then not 53 00:02:50,000 --> 00:02:52,760 using the right tools for better handovers and so on. 54 00:02:53,120 --> 00:02:56,040 But yeah, because this was not something that was teach at 55 00:02:56,040 --> 00:02:58,800 university because we were all just engineers. 56 00:02:59,280 --> 00:03:02,560 So I need to figure it out during my first company and 57 00:03:02,880 --> 00:03:05,960 luckily, and this is a good thing, starting out with an 58 00:03:05,960 --> 00:03:09,640 agency in the career you have a lot of projects or you every 59 00:03:09,640 --> 00:03:12,000 time you have the possibility to start over. 60 00:03:12,480 --> 00:03:14,240 So it's a good start into the career. 61 00:03:14,240 --> 00:03:16,360 In general. I think I would recommend it 62 00:03:16,360 --> 00:03:19,320 because with every new project you can improve what you have 63 00:03:19,320 --> 00:03:23,000 already learned. After I exited this agency, I 64 00:03:23,000 --> 00:03:27,640 founded my next startup. It was AB2B Marketplace SARS, 65 00:03:28,040 --> 00:03:31,440 where brands can do campaigns with influencers. 66 00:03:31,440 --> 00:03:36,480 And this time I was not only CTO but only CPO Chief Product 67 00:03:36,480 --> 00:03:39,520 Officer as well. Because in my first company I 68 00:03:39,520 --> 00:03:44,080 learned when the project was a failure, it was most of the time 69 00:03:44,080 --> 00:03:47,280 not the tech that was failing, but that we built the wrong 70 00:03:47,280 --> 00:03:49,760 thing. So in my second company, I was 71 00:03:50,320 --> 00:03:55,200 very motivated to also step into this product role and learn more 72 00:03:55,200 --> 00:03:57,560 skills and learn how to lead product manager. 73 00:03:57,560 --> 00:04:02,240 So I moved up the value chain, so to say a little bit and 74 00:04:02,400 --> 00:04:03,920 learning more of the product skills. 75 00:04:04,240 --> 00:04:09,240 And as you said, CPTO, it's not common nowadays, but I feel it 76 00:04:09,240 --> 00:04:13,360 gets more and more popular, especially in the software as a 77 00:04:13,360 --> 00:04:18,240 service world where product intake is very closely related. 78 00:04:18,320 --> 00:04:23,200 And I think having a separate CTO and CPO could make sense in 79 00:04:23,200 --> 00:04:27,120 some other cases where you need a lot of industry knowledge, for 80 00:04:27,120 --> 00:04:31,360 example. But most of the B2B says, in my 81 00:04:31,440 --> 00:04:34,560 opinion, it really makes sense to combine those skills. 82 00:04:35,200 --> 00:04:38,520 And yeah, I, I did the startup also for a couple of years and 83 00:04:38,520 --> 00:04:42,560 we exited the startup. And at the moment for the last 84 00:04:42,560 --> 00:04:46,040 couple of years, I'm doing a mix of interim management, some 85 00:04:46,040 --> 00:04:48,480 consulting and interim management. 86 00:04:48,480 --> 00:04:54,800 Since I'm basically infusing my startup spirit into corporate at 87 00:04:54,800 --> 00:04:58,360 the moment, like building startups inside of corporate and 88 00:04:58,360 --> 00:05:00,920 see a whole set of different challenges again. 89 00:05:00,920 --> 00:05:05,760 Because now it's also talking about other stakeholders from a 90 00:05:05,760 --> 00:05:11,440 bigger business about the tech. And ultimately it's also owning 91 00:05:11,440 --> 00:05:15,920 the strategy for the whole business unit and not just being 92 00:05:16,000 --> 00:05:19,680 one of the Co founders. So I moved up the value chain 93 00:05:20,160 --> 00:05:24,240 once more, starting from tech, ending ours responsible for 94 00:05:24,240 --> 00:05:27,120 whole business units. Thank you for sharing such a 95 00:05:27,160 --> 00:05:29,680 unique story, right? So I'm a little bit intrigued by 96 00:05:29,680 --> 00:05:32,960 this CPTO role because it's not common yet, right? 97 00:05:33,360 --> 00:05:36,880 So I think in your experience, having to play multiple roles, 98 00:05:36,880 --> 00:05:41,360 CTOCPO and CPTO, right? And even move even higher up, 99 00:05:41,360 --> 00:05:45,200 right, What do you think are the key critical skills required if 100 00:05:45,200 --> 00:05:48,520 you really want to become one person handling both product and 101 00:05:48,520 --> 00:05:51,200 technology? Because in many places it is 102 00:05:51,200 --> 00:05:53,800 like a duality, right? Product thinks it's own way, 103 00:05:54,040 --> 00:05:56,520 technology thinks the other way. Sometimes they balance each 104 00:05:56,520 --> 00:05:57,960 other, sometimes they fight each other. 105 00:05:58,240 --> 00:06:01,200 But if you're one person, what are the some of the critical key 106 00:06:01,200 --> 00:06:04,680 skills do you think? When interestingly, if you look 107 00:06:04,680 --> 00:06:11,280 back 1020 years ago, a lot of what is now product was part of 108 00:06:11,320 --> 00:06:15,240 technology and part of the responsibility of the CTO. 109 00:06:15,240 --> 00:06:19,480 But then I think of the last 10-15 years we had this, I call 110 00:06:19,480 --> 00:06:23,360 it product movement, where the product became the special 111 00:06:23,360 --> 00:06:27,480 discipline. So maybe even somebody at the 112 00:06:27,480 --> 00:06:30,920 moment having the title CTO could also have the 113 00:06:30,920 --> 00:06:34,920 responsibility for products. So it's at the end just it's 114 00:06:34,920 --> 00:06:37,440 just a title game. But skills wise, what's 115 00:06:37,440 --> 00:06:42,560 important is I think you need to really understand how you need 116 00:06:42,560 --> 00:06:45,840 to understand the principles of product management so that you 117 00:06:45,880 --> 00:06:49,040 are trying to find out the problem before you build a 118 00:06:49,040 --> 00:06:52,280 solution. You also need to know how to 119 00:06:52,280 --> 00:06:57,320 handle those people who are better in those skills than you 120 00:06:57,320 --> 00:06:58,680 are. Because if you have a good 121 00:06:58,680 --> 00:07:01,920 product manager in your team, even the head of product and a 122 00:07:01,920 --> 00:07:05,760 couple of product managers, then they are, they know the 123 00:07:05,760 --> 00:07:08,080 interview techniques better than you are. 124 00:07:08,320 --> 00:07:10,920 But at the end, you are responsible of bringing 125 00:07:10,920 --> 00:07:14,080 everybody together so that everybody can work with the 126 00:07:14,080 --> 00:07:16,320 other departments in the correct way. 127 00:07:16,320 --> 00:07:21,320 And at the end, sometimes it's just a sanity check on being a 128 00:07:21,320 --> 00:07:24,160 sparrings partner for those kind of people in the team. 129 00:07:24,400 --> 00:07:27,960 If it really makes sense to go in this direction because the 130 00:07:27,960 --> 00:07:31,000 interview techniques and the product management techniques, 131 00:07:31,240 --> 00:07:35,120 they should know them. But if it really makes sense in 132 00:07:35,120 --> 00:07:39,400 the context you as a CPTO, you are the the ultimate sparrings 133 00:07:39,400 --> 00:07:41,040 partner. Yeah. 134 00:07:41,280 --> 00:07:44,760 So sometimes also in my view, right, So looking at all the 135 00:07:44,760 --> 00:07:48,600 CPOCTO that I have seen in my career, right, I can see that 136 00:07:48,600 --> 00:07:50,880 product tends to be very optimistic, you know? 137 00:07:50,880 --> 00:07:52,640 Yeah, we can do this. You know, there's so many 138 00:07:52,640 --> 00:07:56,400 things, good vision, you know, very far ahead and sometimes the 139 00:07:56,400 --> 00:07:59,680 technology is the pessimistic 1. So being a little bit more 140 00:07:59,680 --> 00:08:02,640 cautious thinking about how to scale this, secure this and 141 00:08:02,640 --> 00:08:05,640 things like that. Now if you are into one person, 142 00:08:05,640 --> 00:08:09,000 so to speak, right, how do you see this so-called extremes? 143 00:08:09,000 --> 00:08:12,280 Are you sometimes juggling between being optimistic versus 144 00:08:12,280 --> 00:08:15,680 pessimistic, or some tips and tricks that you have done so far 145 00:08:15,680 --> 00:08:19,520 in your role? I feel it's like a pendulum that 146 00:08:19,520 --> 00:08:24,640 swings back and forth because sometimes you are stagnating on 147 00:08:24,640 --> 00:08:27,960 the product side and you are working with the product people 148 00:08:27,960 --> 00:08:32,640 more to really find out the what is the right, what is the ADL 149 00:08:32,640 --> 00:08:37,000 customer profile or problems? Do they have like to really find 150 00:08:37,000 --> 00:08:39,840 out those kind of things? And then on the other, then 151 00:08:39,840 --> 00:08:42,919 there are other phases where you're tackling tech depth 152 00:08:42,919 --> 00:08:45,560 because this is the biggest issue because we cannot scale 153 00:08:45,840 --> 00:08:49,520 with the tech that we're having. So for me, it's it's like a 154 00:08:49,520 --> 00:08:51,760 pendulum. I need to decide where I 155 00:08:52,160 --> 00:08:58,400 focusing at every moment or how I bring it down to a joint 156 00:08:58,400 --> 00:09:01,560 strategy at the end that it makes sense for both worlds, the 157 00:09:01,560 --> 00:09:03,960 challenges that the company's facing. 158 00:09:04,920 --> 00:09:06,360 Right. So I think the art is the 159 00:09:06,440 --> 00:09:08,200 playing the pendulum part, right? 160 00:09:08,200 --> 00:09:11,760 So where you can actually juggle between two different heads and 161 00:09:11,760 --> 00:09:14,800 make sure you keep sanity of yourself, I guess. 162 00:09:15,520 --> 00:09:18,720 So the main topic of our discussion is this thing or term 163 00:09:18,720 --> 00:09:21,760 you coin, you know, move fast and break silos. 164 00:09:21,840 --> 00:09:24,640 It's very similar to, you know, the Facebook motto, move fast 165 00:09:24,640 --> 00:09:29,520 and break things, except that, yeah, except that you put break 166 00:09:29,520 --> 00:09:31,520 silos. So maybe tell us a little bit of 167 00:09:31,520 --> 00:09:33,800 the background. How do you come up with this 168 00:09:33,800 --> 00:09:36,680 motto? So as I said, I'm always since 169 00:09:36,680 --> 00:09:39,520 always fascinated with the challenge of how people are work 170 00:09:39,520 --> 00:09:43,840 together because I'm basically responsible to how people are 171 00:09:43,840 --> 00:09:46,480 working together since the early days of my career. 172 00:09:46,880 --> 00:09:51,000 And so I saw a lot of tools, learned a lot of techniques and 173 00:09:51,000 --> 00:09:55,840 tried out a lot of techniques. And I just realized that we as 174 00:09:55,880 --> 00:10:00,320 an industry are at an interesting point at the moment 175 00:10:00,720 --> 00:10:06,040 because if you look back like to let's look back over 100 years 176 00:10:06,120 --> 00:10:08,120 and let's look back to Henry Ford. 177 00:10:08,800 --> 00:10:13,120 He was a successful car manufacturer, but he was not 178 00:10:13,120 --> 00:10:16,360 like a multinational corporation. 179 00:10:16,680 --> 00:10:19,840 And if you look at the manufacturing process from Ford 180 00:10:19,840 --> 00:10:23,440 back then, the cars were standing at once at one place 181 00:10:23,440 --> 00:10:25,720 and the workers were moving around the cars. 182 00:10:25,720 --> 00:10:29,440 They were building 1 car on one place and it took 12 hours to 183 00:10:29,440 --> 00:10:32,920 build a single car. And as we all knew then Henry 184 00:10:32,920 --> 00:10:37,560 Ford leveraged the conveyor belts for the manufacturing 185 00:10:37,560 --> 00:10:42,240 process and then the cars came to the workers and this caused 186 00:10:42,240 --> 00:10:45,920 that the workers can specialized better on a single task. 187 00:10:46,240 --> 00:10:50,360 And then Henry Ford could produce 8 cars in 12 hours 188 00:10:50,360 --> 00:10:54,160 instead of 1 car. And Ford, he was a very smart 189 00:10:54,160 --> 00:10:56,240 guy because he had not more capital. 190 00:10:56,320 --> 00:10:59,400 The conveyor belt was already invented by other industries, 191 00:10:59,640 --> 00:11:03,240 but it just brought it together and leveraged it for mass 192 00:11:03,240 --> 00:11:06,160 production. And I think this is the 193 00:11:06,160 --> 00:11:08,960 situation where we are right now with product development. 194 00:11:09,200 --> 00:11:14,520 There are a lot of tools out there already, but you need to 195 00:11:14,520 --> 00:11:18,360 know the tools, you need to know that they are existing. 196 00:11:18,560 --> 00:11:21,600 You need to maybe have a little bit of experience with them to 197 00:11:21,600 --> 00:11:25,600 apply them to your situation. And this was kind of my 198 00:11:25,600 --> 00:11:29,640 motivation to work on this topic because I really see a lot of 199 00:11:29,640 --> 00:11:33,120 tools out there. I really see a lot of misaligned 200 00:11:33,120 --> 00:11:38,080 teams in my direct work as an interim manager or if I'm 201 00:11:38,320 --> 00:11:42,920 advising a start up. I think we as an industry, we 202 00:11:42,920 --> 00:11:47,280 are working still like on the conveyor belt. 203 00:11:47,360 --> 00:11:51,680 And the conveyor belt is a useful metaphor for industry and 204 00:11:51,680 --> 00:11:56,040 for manufacturing, but it's not a very good metaphor for 205 00:11:56,040 --> 00:11:59,880 producing software because with a conveyor belt software 206 00:12:00,240 --> 00:12:03,720 development process, you end up in waterfall because you have 207 00:12:03,720 --> 00:12:07,320 one step after the other and you have silos on all parts. 208 00:12:07,720 --> 00:12:13,920 And I think part of the problem is that in a lot of traditional 209 00:12:13,920 --> 00:12:19,120 settings, they see writing code as the manufacturing line. 210 00:12:19,440 --> 00:12:23,360 It's just making it happen. Somebody other already had the 211 00:12:23,360 --> 00:12:28,640 idea upfront, some stakeholder, some product owner, somebody had 212 00:12:28,640 --> 00:12:31,320 already idea. But I think the fundamental 213 00:12:31,320 --> 00:12:35,320 misunderstanding is here that building software is the design 214 00:12:35,320 --> 00:12:38,880 process. Because as a software engineers 215 00:12:38,920 --> 00:12:41,320 we are not implementing A solved problem. 216 00:12:41,320 --> 00:12:45,400 We are solving the problems. So we are making creative 217 00:12:45,400 --> 00:12:51,200 decisions every hour of the day. So I think we need revolution 218 00:12:51,200 --> 00:12:53,960 like the industrial revolution that was kick started by Henry 219 00:12:53,960 --> 00:12:57,360 Ford, but I think it's going into the different direction 220 00:12:57,360 --> 00:13:01,240 because it's going into the directions to how we are making 221 00:13:01,240 --> 00:13:05,200 decisions and who is making the decisions in what context and 222 00:13:05,200 --> 00:13:07,520 and how we are aligning those things. 223 00:13:08,680 --> 00:13:10,280 Yeah. So I think you brought up a very 224 00:13:10,280 --> 00:13:13,040 interesting point, right, Because I can see even in the 225 00:13:13,280 --> 00:13:16,160 industry, right, in the software development industry, so to 226 00:13:16,160 --> 00:13:19,400 speak, so many people still treat software development as 227 00:13:19,400 --> 00:13:23,600 like manufacturing process or assembly line process, right, 228 00:13:23,760 --> 00:13:26,720 where they think producing program is like producing 229 00:13:26,720 --> 00:13:29,160 widgets, so to speak, right. Or maybe car parts in your. 230 00:13:29,200 --> 00:13:30,120 Analogy. Right. 231 00:13:30,560 --> 00:13:33,520 But I think in many, many literature and maybe HR 232 00:13:33,520 --> 00:13:37,320 practices and all that, it seems that this kind of process 233 00:13:37,320 --> 00:13:39,720 actually is not optimal simply because, you know, there are a 234 00:13:39,720 --> 00:13:42,720 lot of ways, a lot of inefficiencies in the process. 235 00:13:43,080 --> 00:13:47,200 So maybe if you can tell us why the difference of software if 236 00:13:47,200 --> 00:13:50,040 you compare to the manufacturing process, because many people 237 00:13:50,040 --> 00:13:51,520 think it's an engineering thing, right? 238 00:13:51,520 --> 00:13:55,320 So it should work similar to manufacturing process. 239 00:13:55,440 --> 00:13:57,280 So maybe what do you think is the biggest difference? 240 00:13:58,280 --> 00:14:01,080 Yeah, the biggest difference is that the software engineers, 241 00:14:01,080 --> 00:14:05,240 they need to find out how they are solving the problem. 242 00:14:05,600 --> 00:14:10,120 Because if you are producing a WeChat or car part, somebody 243 00:14:10,120 --> 00:14:13,760 else has already made the design and already the machines are in 244 00:14:13,760 --> 00:14:17,200 place and the machines are configured and you just press a 245 00:14:17,200 --> 00:14:19,160 button and then you you do something. 246 00:14:19,160 --> 00:14:21,160 With software engineering, it's different. 247 00:14:21,200 --> 00:14:25,600 You need to make decisions the whole day and you are part of 248 00:14:25,600 --> 00:14:28,440 the design process and I think we should embrace this. 249 00:14:28,440 --> 00:14:32,480 We should understand that the developers are part of the 250 00:14:32,480 --> 00:14:36,320 design process and this means, like I will explain later, that 251 00:14:36,320 --> 00:14:40,680 they are starting much earlier in the process, having a say in 252 00:14:40,680 --> 00:14:43,320 what problems we are tackling, having a say in how the 253 00:14:43,320 --> 00:14:46,000 solutions are are designed as well. 254 00:14:46,920 --> 00:14:49,440 Yeah. So I think what you said is very 255 00:14:49,440 --> 00:14:51,800 important, right, for all software engineers and also the 256 00:14:51,800 --> 00:14:53,680 managers, right. So software engineering is 257 00:14:53,680 --> 00:14:57,280 mostly making decisions and design almost all the time, 258 00:14:57,280 --> 00:14:59,280 right? Because when we start the 259 00:14:59,280 --> 00:15:02,000 software is simple, right? But as we grow in terms of maybe 260 00:15:02,000 --> 00:15:04,720 business requirements and all that, you make a lot of changes 261 00:15:04,720 --> 00:15:07,280 that you didn't foresee before in the very beginning, right? 262 00:15:07,520 --> 00:15:10,080 And that's why you keep tweaking, refactoring, maybe 263 00:15:10,080 --> 00:15:13,000 even migrating some parts of your software into something 264 00:15:13,000 --> 00:15:15,040 new. So I think this is probably the 265 00:15:15,040 --> 00:15:17,240 biggest difference against the manufacturing, right? 266 00:15:17,800 --> 00:15:20,640 And if you, if you want to compare it with manufacturing, 267 00:15:20,640 --> 00:15:25,160 then maybe the manufacturing part is the pure act of pressing 268 00:15:25,160 --> 00:15:28,560 a key on the keyboard, like just writing the code. 269 00:15:28,560 --> 00:15:32,160 And as we all know, just writing the code is the smallest part of 270 00:15:32,160 --> 00:15:33,960 we as engineer what we are doing. 271 00:15:34,280 --> 00:15:37,560 Most of the work is happening inside of the head while you try 272 00:15:37,560 --> 00:15:39,720 to how to dissect the problem and so on. 273 00:15:40,160 --> 00:15:43,080 And writing code, we probably will do less and less in the 274 00:15:43,080 --> 00:15:45,640 future with say hi. So it's more and more important 275 00:15:45,920 --> 00:15:49,800 that engineers are really used, leveraged in a way to solve 276 00:15:49,800 --> 00:15:52,560 problems. How do you think you can 277 00:15:52,560 --> 00:15:56,440 convince or maybe influence stakeholders management about 278 00:15:56,440 --> 00:15:59,800 this thing where software engineering is mostly a decision 279 00:15:59,800 --> 00:16:02,600 process rather than a production process, right? 280 00:16:03,000 --> 00:16:05,680 So because this is something like AI would say a 281 00:16:05,680 --> 00:16:08,360 misperception in many of the stakeholders mind. 282 00:16:08,960 --> 00:16:11,840 And most of the time the stakeholders or senior 283 00:16:11,840 --> 00:16:15,080 management of companies, they will have a feeling that 284 00:16:15,080 --> 00:16:19,440 something is not working well with the development process 285 00:16:19,440 --> 00:16:23,920 because they don't get what they were promised or they get it 286 00:16:24,000 --> 00:16:25,960 later than it was promised to them. 287 00:16:25,960 --> 00:16:31,000 So if you talk to externals or about internals as well, I think 288 00:16:31,000 --> 00:16:35,440 nobody is really happy with their process and how they are 289 00:16:35,440 --> 00:16:37,440 doing. And if you look at the 290 00:16:37,440 --> 00:16:41,960 externals, they will see a lot of symptoms of what is going 291 00:16:41,960 --> 00:16:44,040 wrong. And if you look at a lot of, if 292 00:16:44,040 --> 00:16:47,000 you talk to the internals, they will come with a lot of reasons 293 00:16:47,000 --> 00:16:50,440 to you why why staff is not working in the right way. 294 00:16:51,240 --> 00:16:52,720 Yeah. So I think in many software 295 00:16:52,720 --> 00:16:55,360 teams, definitely this is the thing that is happening, right? 296 00:16:55,400 --> 00:16:58,880 And you also have a few things that you think are the problems 297 00:16:58,880 --> 00:17:01,560 in the current status quo of software development practices, 298 00:17:01,560 --> 00:17:03,360 right? Maybe if you can outline some of 299 00:17:03,360 --> 00:17:06,079 the biggest ones that you think would be good to discuss today. 300 00:17:06,760 --> 00:17:09,160 Yeah. I mean, if you started the agile 301 00:17:09,160 --> 00:17:13,000 movement at the beginning, the coders, they had a vision when 302 00:17:13,000 --> 00:17:16,400 they created this manifesto for Agile software development. 303 00:17:16,760 --> 00:17:20,119 Individuals and interactions, working software, customer 304 00:17:20,119 --> 00:17:23,400 collaboration, responding to change, those are all the right 305 00:17:23,400 --> 00:17:26,680 values. But business historically 306 00:17:26,680 --> 00:17:29,320 struggled with understanding engineers. 307 00:17:29,800 --> 00:17:33,960 And so Scrum came up and Scrum, in my opinion, is a pure 308 00:17:33,960 --> 00:17:37,920 business practice, like doing acceptance test, making small 309 00:17:37,920 --> 00:17:40,880 releases, planning games and and so on. 310 00:17:41,200 --> 00:17:43,520 Those are business practices. Those are not software 311 00:17:43,520 --> 00:17:48,560 engineering practices per SE, but it was a tool for business 312 00:17:48,560 --> 00:17:53,240 to make the engineers manageable in a way for them. 313 00:17:53,640 --> 00:17:58,240 Then the result was that a child kind of became a micromanagement 314 00:17:58,240 --> 00:18:00,360 tool because it was used for everything. 315 00:18:00,920 --> 00:18:04,520 Product owners, they are receiving a lot of requests 316 00:18:04,520 --> 00:18:07,400 every day. Some of the requests are urgent, 317 00:18:07,400 --> 00:18:11,960 some of them are not urgent. But the urgent requests, at one 318 00:18:11,960 --> 00:18:15,320 point they get into the backlog and then in the backlog, 319 00:18:15,320 --> 00:18:18,720 suddenly they know they have an urgent request that is also 320 00:18:18,720 --> 00:18:20,920 planned. And if you have other planned 321 00:18:20,920 --> 00:18:24,920 work in the backlog, then your original work gets prioritised 322 00:18:24,920 --> 00:18:26,720 down. And so you are never in a 323 00:18:26,720 --> 00:18:30,920 position as a team where you can really commit to something 324 00:18:30,920 --> 00:18:35,240 because all the urgent requests they are intermingled with what 325 00:18:35,240 --> 00:18:38,320 you have already planned. So it's so it's really hard. 326 00:18:38,320 --> 00:18:43,000 And the result is that the team is doing the trade-offs at the 327 00:18:43,000 --> 00:18:46,880 very end because the time is running out and then you need to 328 00:18:46,880 --> 00:18:49,320 do the trade-offs. But those trade-offs are maybe 329 00:18:49,320 --> 00:18:52,080 not the best trade-offs. Such trade-offs, there could 330 00:18:52,080 --> 00:18:55,520 have been better trade-offs if they would have done earlier on 331 00:18:55,520 --> 00:18:58,520 a higher abstraction level and not just when time is running 332 00:18:58,520 --> 00:19:01,880 out. This is part of my point here 333 00:19:01,880 --> 00:19:04,400 that it's important to make the trade-offs early on with the 334 00:19:04,480 --> 00:19:09,320 engineers and in the organization that is always 335 00:19:09,320 --> 00:19:14,680 striving for efficiency. This causes a lot of people 336 00:19:14,680 --> 00:19:18,040 working on their own and then you end up with a different 337 00:19:18,280 --> 00:19:22,960 development and product organization because product and 338 00:19:23,160 --> 00:19:27,280 engineering, they are optimizing for themselves to cope with the 339 00:19:27,280 --> 00:19:29,120 pressure to cope with the efficiency. 340 00:19:29,520 --> 00:19:33,200 But the problem often is the efficiency is only there because 341 00:19:33,200 --> 00:19:36,080 it was not completely aligned at the beginning. 342 00:19:36,080 --> 00:19:38,320 And then the time is running out and you need to be efficient and 343 00:19:38,320 --> 00:19:42,680 then silos are created. China or ticket systems in 344 00:19:42,720 --> 00:19:47,920 general are not the ultimate tool to help in such a high 345 00:19:47,920 --> 00:19:51,560 pressure solution because developers are out of time. 346 00:19:51,560 --> 00:19:55,400 They say, hey, stop, just create a ticket for me and then we 347 00:19:55,400 --> 00:19:59,160 manage it via the backlog. So and then discuss a situation 348 00:19:59,160 --> 00:20:02,120 where somebody is creating the ticket and somebody else is just 349 00:20:02,120 --> 00:20:04,840 implementing the ticket. And this is for me the the 350 00:20:04,840 --> 00:20:08,240 definition of a silo because you have a wall in between there. 351 00:20:08,240 --> 00:20:12,560 You have not a process where there is a time and place for 352 00:20:12,560 --> 00:20:15,440 new requirements and how you'll find those requirements. 353 00:20:15,920 --> 00:20:21,640 In theory, a silo is a nice place to be because you could 354 00:20:21,640 --> 00:20:24,720 work blissful a long 8 hours a day. 355 00:20:24,720 --> 00:20:27,120 You're just working on tickets and you went into the next 356 00:20:27,120 --> 00:20:29,400 ticket. But in reality, it's not like 357 00:20:29,400 --> 00:20:32,160 that. You have a Kanban board with 10 358 00:20:32,160 --> 00:20:37,920 columns, you have a QA, you have a UXQA, you have somebody else 359 00:20:37,920 --> 00:20:39,960 need to green light something and so on. 360 00:20:39,960 --> 00:20:43,280 And if something is falling through the cracks, the ticket 361 00:20:43,280 --> 00:20:46,640 is going back to the developers. You need to context switch as a 362 00:20:46,640 --> 00:20:50,840 developer and then you need to increase the font size or or 363 00:20:50,840 --> 00:20:53,000 whatever you need to do. And then you put it back. 364 00:20:53,000 --> 00:20:57,040 And it's not just the ticket workflow, it's also you are 365 00:20:57,040 --> 00:21:01,180 interrupted all the time because we live in a world where your Co 366 00:21:01,180 --> 00:21:04,480 workers cannot work on something without asking you constantly 367 00:21:04,720 --> 00:21:08,080 for something. And I mean, even in theory, if 368 00:21:08,120 --> 00:21:11,440 we assume that silos would be nice, it's not like that. 369 00:21:11,600 --> 00:21:16,840 And AI will also not help us with this solution, not from the 370 00:21:16,840 --> 00:21:19,880 communication side, not from the implementation side. 371 00:21:20,320 --> 00:21:23,360 It makes product development even more complicated in my 372 00:21:23,360 --> 00:21:26,120 opinion. Because now you need also to 373 00:21:26,120 --> 00:21:29,760 bring AI to the table like machine learning engineers, 374 00:21:30,040 --> 00:21:34,920 maybe in a separate department, data scientists and and also UX 375 00:21:34,920 --> 00:21:38,600 user experience. You need to bring AI expertise 376 00:21:38,600 --> 00:21:41,720 and user experience expertise together to make really great 377 00:21:41,720 --> 00:21:46,040 product where the AI is really leveraged by the user 378 00:21:46,040 --> 00:21:48,080 experience. Because if you do it 379 00:21:48,160 --> 00:21:53,440 traditionally user experience, they don't know how to work with 380 00:21:53,840 --> 00:21:58,160 AI tools where you have not a guaranteed response, where you 381 00:21:58,280 --> 00:22:01,520 only have response and 5% of the case is the correct one or in 382 00:22:01,760 --> 00:22:05,280 40% of the cases. So you need to bring even more 383 00:22:05,280 --> 00:22:09,280 parties together. And This is why I think 1 needs 384 00:22:09,280 --> 00:22:13,920 to fundamentally look at how teams are making decisions and 385 00:22:13,920 --> 00:22:16,440 such continuously evolving systems. 386 00:22:16,440 --> 00:22:21,440 And I'm here to share my mental model about how to achieve this. 387 00:22:21,960 --> 00:22:25,200 Yeah, I think what you just mentioned, right, it happens in 388 00:22:25,200 --> 00:22:28,880 many teams, right, When we say people practice Agile, which I 389 00:22:28,880 --> 00:22:32,400 think I would say most teams would believe that they practice 390 00:22:32,400 --> 00:22:36,280 Agile in some what in some shape or the others, right, Typically 391 00:22:36,280 --> 00:22:38,480 Scrum, right, and Scrum Bun as well. 392 00:22:39,000 --> 00:22:42,280 So I think the interesting part that you mentioned, it becomes 393 00:22:42,280 --> 00:22:44,800 like a micromanagement tool because when it started, the 394 00:22:44,880 --> 00:22:48,440 agile movement seems to be moving away from that 395 00:22:48,440 --> 00:22:51,360 micromanagement, right? But these days, I think it 396 00:22:51,360 --> 00:22:53,160 happens in many different teams, right? 397 00:22:53,160 --> 00:22:56,360 Even the stand ups is more like a status updates where the 398 00:22:56,360 --> 00:22:58,680 manager or the leaders keep asking about status and all 399 00:22:58,680 --> 00:22:59,640 that. And I can. 400 00:23:00,000 --> 00:23:02,640 See the micromanagement danger part there. 401 00:23:02,880 --> 00:23:06,240 And ticketing is kind of like the practice in most software 402 00:23:06,240 --> 00:23:08,400 engineering team. You create a ticket for your 403 00:23:08,400 --> 00:23:11,880 product requirements, you hand it over to software development, 404 00:23:11,880 --> 00:23:14,720 maybe tester, maybe a few other process right in the stages 405 00:23:14,960 --> 00:23:17,760 before it gets deployed. So ticketing is like the main 406 00:23:17,760 --> 00:23:20,920 collaboration or main communication channel, which I 407 00:23:20,920 --> 00:23:23,760 think sometimes there could be a problem, so to speak, right? 408 00:23:23,960 --> 00:23:26,080 And people don't talk to each other and they talk just through 409 00:23:26,080 --> 00:23:28,080 tickets, right? So I think that also defeats. 410 00:23:28,080 --> 00:23:31,520 Exactly. And I mean, there's a place for 411 00:23:31,520 --> 00:23:36,800 ticket systems and in my opinion it's for support work or for 412 00:23:37,280 --> 00:23:39,760 reactive work like we are calling it. 413 00:23:40,320 --> 00:23:46,240 But feature development with ticket system at its core is not 414 00:23:46,240 --> 00:23:49,480 a good idea, because you really removed the collaboration. 415 00:23:49,480 --> 00:23:52,360 And there is. Yeah, and especially if the 416 00:23:52,520 --> 00:23:55,320 problem itself is not well defined, right, The design is 417 00:23:55,320 --> 00:23:58,240 not well defined. I think it's the communication 418 00:23:58,240 --> 00:24:01,120 and you know, the back and forth, probably opinion sharing, 419 00:24:01,120 --> 00:24:03,480 right, to come up with the perfect kind of like not 420 00:24:03,480 --> 00:24:06,960 perfect, maybe a better design or better solution, right from 421 00:24:07,000 --> 00:24:10,800 cross functional roles. So I think knowing about this 422 00:24:10,800 --> 00:24:14,040 problem, right, the status quo, so many different things that 423 00:24:14,040 --> 00:24:16,840 are not optimal. So tell us a little bit more 424 00:24:16,840 --> 00:24:18,720 about your approach right in this move. 425 00:24:18,720 --> 00:24:20,640 Things break silos. What are some of the key 426 00:24:20,640 --> 00:24:22,520 practices that you want to advocate today? 427 00:24:22,520 --> 00:24:28,440 Yeah, everything is centered around how we slice the work and 428 00:24:28,440 --> 00:24:31,880 how we are aligning the teams around this work. 429 00:24:32,240 --> 00:24:36,640 What I mean with how the work is sliced, it's for me about how 430 00:24:36,640 --> 00:24:42,680 our objectives are defined, how we are slicing problems, how we 431 00:24:42,680 --> 00:24:46,520 are slicing solutions and how are we slicing delivery. 432 00:24:46,800 --> 00:24:51,080 So the first important thing is to understand that all four 433 00:24:51,080 --> 00:24:54,400 things are different. Things like you have objectives 434 00:24:54,400 --> 00:24:57,600 on the highest level, and then you really need to differentiate 435 00:24:57,600 --> 00:25:00,840 between problems and solutions because a lot of teams are 436 00:25:00,840 --> 00:25:04,680 skipping this step and coming up with a solution too early. 437 00:25:05,160 --> 00:25:09,000 And then you also need to really think about how you are slicing 438 00:25:09,000 --> 00:25:12,520 delivery. So slicing objectives, that's 439 00:25:13,000 --> 00:25:17,760 the easiest rule in my opinion, because you can just have one 440 00:25:18,000 --> 00:25:22,840 objective for a team. Like it's either an engagement, 441 00:25:22,840 --> 00:25:24,640 it's growth, or it's monetization. 442 00:25:24,640 --> 00:25:28,000 Like on the highest level, A-Team should only have one 443 00:25:28,360 --> 00:25:30,480 engagement. Or like a unit where you have a 444 00:25:30,480 --> 00:25:34,440 couple of teams, they should all work on the same objective. 445 00:25:34,680 --> 00:25:39,240 And we really need to be clear, I'll be focusing this year or 446 00:25:39,240 --> 00:25:43,120 this half year on engagement or on growth because this then 447 00:25:43,120 --> 00:25:46,680 defines on what problems A-Team should be working on. 448 00:25:47,600 --> 00:25:49,600 Yeah. So maybe let's go 1 by 1, maybe 449 00:25:49,640 --> 00:25:51,360 objective and then development on that. 450 00:25:51,960 --> 00:25:55,040 So maybe, you know, hearing what you say about slicing objective, 451 00:25:55,280 --> 00:25:57,960 I think fundamentally this is one of the biggest problems in 452 00:25:57,960 --> 00:25:59,920 many, you know, software engineering team or product 453 00:25:59,920 --> 00:26:02,960 team, right is because there are so many objectives given maybe 454 00:26:02,960 --> 00:26:05,800 sometimes from the top, sometimes it's from regulations 455 00:26:05,800 --> 00:26:08,720 that come, you know, in the middle of the whatever quarterly 456 00:26:08,720 --> 00:26:10,280 planning or annual planning, right. 457 00:26:10,880 --> 00:26:15,920 So I think slicing it to work on just one objective probably is 458 00:26:15,920 --> 00:26:18,000 kind of like impossible for many of the teams. 459 00:26:18,080 --> 00:26:21,640 Or is there anything that you think maybe a change of mindset, 460 00:26:21,640 --> 00:26:25,000 a change of perspective and change of priorities that could 461 00:26:25,000 --> 00:26:28,840 actually allow team to actually focus on just one objective at a 462 00:26:28,840 --> 00:26:31,080 particular time? So maybe from your experience, 463 00:26:31,080 --> 00:26:35,840 share some practices. So when I talk about slicing 464 00:26:35,840 --> 00:26:40,120 objectives, I mean I'm focusing on the strategic feature 465 00:26:40,120 --> 00:26:44,280 development like what we have as we as a company have on the road 466 00:26:44,280 --> 00:26:48,200 map to develop what to achieve our company goals. 467 00:26:48,480 --> 00:26:51,600 If you have regulatory requirements and those kind of 468 00:26:51,600 --> 00:26:57,320 things, I would try to manage this as what I call reactive 469 00:26:57,320 --> 00:27:00,240 work. Like in a bigger setup, you can 470 00:27:00,240 --> 00:27:04,520 always have a part of the bigger part of the team on strategic 471 00:27:04,520 --> 00:27:07,680 feature development and then you have a smaller part of the team 472 00:27:07,960 --> 00:27:13,560 working on reactive work. And it's just important that the 473 00:27:14,000 --> 00:27:18,120 part of the team that is allocated to the strategic 474 00:27:19,000 --> 00:27:23,400 feature development that they are really working on on 475 00:27:23,400 --> 00:27:26,760 strategic features. And this ratio is something you 476 00:27:26,760 --> 00:27:29,080 need to define in an engineering strategy. 477 00:27:29,200 --> 00:27:33,640 At what point you are, do you have a lot of technical debt and 478 00:27:34,280 --> 00:27:35,040 and so on. Yeah. 479 00:27:35,840 --> 00:27:37,960 Yeah, thanks for clarifying that because I think it's very 480 00:27:37,960 --> 00:27:40,280 important, right, If you want to be practical in you know, 481 00:27:40,280 --> 00:27:42,880 slicing these objectives. So the ratio is something that 482 00:27:42,880 --> 00:27:45,280 every team, every company has to define, right. 483 00:27:45,640 --> 00:27:48,240 I think it's something that depends on the stage of the 484 00:27:48,240 --> 00:27:50,600 company as well. Sometimes if you are still 485 00:27:50,600 --> 00:27:52,880 product doing product development, right, you could 486 00:27:52,880 --> 00:27:57,160 have more ratio of that versus the other reactive thing, right? 487 00:27:57,360 --> 00:27:59,560 And sometimes it could change depending on the situation. 488 00:28:00,160 --> 00:28:03,200 So let's move to the next slicing that you outline, right, 489 00:28:03,200 --> 00:28:06,200 Which is slicing the problem which you know some people use. 490 00:28:06,560 --> 00:28:08,960 You meant. I would maybe quickly, I goodly 491 00:28:08,960 --> 00:28:11,640 would like to add that most of what I'm addressing here is 492 00:28:11,640 --> 00:28:13,880 really towards feature development. 493 00:28:14,280 --> 00:28:17,880 As I said, you need to have keeping the light on the part of 494 00:28:17,880 --> 00:28:19,480 the team. You need to have some part of 495 00:28:19,480 --> 00:28:21,920 the team responsible for directive work. 496 00:28:21,920 --> 00:28:26,120 But all the other things that I have now that will now come, 497 00:28:26,400 --> 00:28:29,720 they are mostly related to strategic feature development. 498 00:28:30,560 --> 00:28:32,360 Yeah. Thanks for the addition of that. 499 00:28:32,680 --> 00:28:34,840 So let's move on to the next slicing which you mentioned 500 00:28:34,880 --> 00:28:37,120 slicing problem, right? And you mentioned. 501 00:28:37,120 --> 00:28:39,520 Some problems. Yeah, in some teams they could 502 00:28:39,520 --> 00:28:42,720 even skip this or they merge it into solutions straight away, 503 00:28:42,720 --> 00:28:45,000 right? So why is it important to slice 504 00:28:45,000 --> 00:28:47,000 the problems? Because I, I don't know 505 00:28:47,040 --> 00:28:48,320 practically how would you do that? 506 00:28:49,080 --> 00:28:54,280 The why for slicing the problems is you need a time and place 507 00:28:54,280 --> 00:28:56,680 where you align with the senior leadership. 508 00:28:56,680 --> 00:29:01,800 What problems are you tackling? And then interdisciplinary team 509 00:29:01,920 --> 00:29:06,080 where an interdisciplinary for me means product design, 510 00:29:06,080 --> 00:29:09,320 engineering, maybe machine learning, maybe some other 511 00:29:09,320 --> 00:29:12,360 expertise. It's all in one team and they 512 00:29:12,360 --> 00:29:16,360 should work as an empowered team on fulfilling this problem. 513 00:29:16,640 --> 00:29:19,920 This is why it's very important to make this distinguished to 514 00:29:19,920 --> 00:29:24,240 make this distinction because if you are starting with a solution 515 00:29:24,240 --> 00:29:28,520 too early and you give the team 1/2 thoughts through a solution 516 00:29:28,520 --> 00:29:33,000 and say no, now you do. Then the team has no way of 517 00:29:33,280 --> 00:29:37,440 really they don't have a saying in what they are building and so 518 00:29:37,440 --> 00:29:42,200 they are not responsible for it and they cannot really commit to 519 00:29:42,200 --> 00:29:44,360 it. So they will then extend the 520 00:29:44,480 --> 00:29:48,280 deadline because they have not really a saying in it and they 521 00:29:48,280 --> 00:29:51,320 assume that it's given that it needs to be like this. 522 00:29:51,680 --> 00:29:55,560 But in the most of the cases, on the one hand, it's not 523 00:29:55,560 --> 00:29:59,440 completely thought through what really the problem is that we 524 00:29:59,440 --> 00:30:02,240 are solving before you're giving something to the team that this 525 00:30:02,240 --> 00:30:04,840 is 1 aspect. And as I said, the other aspect 526 00:30:04,840 --> 00:30:08,520 is that the team needs to be part of the solution. 527 00:30:08,840 --> 00:30:13,680 And really engineering as a first class citizen if you want, 528 00:30:13,960 --> 00:30:16,080 is also part of defining the solution. 529 00:30:16,080 --> 00:30:19,520 That's very important. And when we are slicing 530 00:30:19,520 --> 00:30:24,160 problems, we are just focusing on what is the current context 531 00:30:24,160 --> 00:30:28,320 of the user of the customer and what is our desired outcome. 532 00:30:28,440 --> 00:30:32,080 Like this is really the core of the problem definition. 533 00:30:32,520 --> 00:30:36,200 This is something I am I've taken from the Shape Up 534 00:30:36,200 --> 00:30:39,560 methodology. Shape Up is the product 535 00:30:39,560 --> 00:30:41,480 development process from Basecamp. 536 00:30:41,760 --> 00:30:45,760 They open sourced it a couple of years ago and they are using 537 00:30:45,840 --> 00:30:47,720 such a framing technique as well. 538 00:30:48,440 --> 00:30:51,640 And this really helps for alignment with senior 539 00:30:51,640 --> 00:30:54,080 leadership. And there's also a good 540 00:30:54,080 --> 00:30:57,920 abstraction level of, of defining what are we doing in 541 00:30:57,920 --> 00:31:02,240 the next couple of weeks? Because such a sliced problem 542 00:31:02,240 --> 00:31:06,840 should also come with a certain appetite of how much you want to 543 00:31:06,840 --> 00:31:09,120 invest. The appetite is also a concept 544 00:31:09,120 --> 00:31:13,280 from Shape Up and this appetite is also a concept from shape up 545 00:31:13,280 --> 00:31:17,720 and appetite basically is you have a fixed time box, but you 546 00:31:17,720 --> 00:31:19,840 have a variable scope in the time box. 547 00:31:20,360 --> 00:31:23,080 And if you bring those two things together, you have a 548 00:31:23,160 --> 00:31:25,920 problem. You know what problem you want 549 00:31:25,920 --> 00:31:30,400 to solve and you have a idea of how much time you want to spend 550 00:31:30,400 --> 00:31:34,200 with this problem. It helps and it guides how the 551 00:31:34,760 --> 00:31:38,040 implementing interdisciplinary team is then thinking about 552 00:31:38,040 --> 00:31:40,520 solution. Because if you have a certain 553 00:31:40,520 --> 00:31:43,800 problem and you say I want to invest six weeks for a solution, 554 00:31:44,120 --> 00:31:47,440 then the team will end up with different solutions, then you 555 00:31:47,440 --> 00:31:50,120 should say I want to invest one week with a solution. 556 00:31:50,120 --> 00:31:53,760 And so you can use this problem definition together with the 557 00:31:53,760 --> 00:31:57,960 appetite as a very good communication technique because 558 00:31:58,120 --> 00:32:01,240 business stakeholders can say how much it's worth to them and 559 00:32:01,240 --> 00:32:05,200 the team can say what they could then actually deliver for this. 560 00:32:06,440 --> 00:32:09,720 Yeah, I like this, you know, breaking down into fixed 561 00:32:09,720 --> 00:32:13,480 timeline and variable scope because in many different teams 562 00:32:13,480 --> 00:32:16,160 it's always like top down, you know, we have, I don't know like 563 00:32:16,160 --> 00:32:20,080 annual road map broken down into quarterly road map and the team 564 00:32:20,080 --> 00:32:22,800 just delivered that, right. But actually if we come up with 565 00:32:22,800 --> 00:32:25,520 a well defined problem that is sliced properly according to the 566 00:32:25,520 --> 00:32:28,160 time that we are willing to spend maybe as a company or a 567 00:32:28,160 --> 00:32:31,040 team, right, then we can come up with different solutions. 568 00:32:31,240 --> 00:32:34,240 So I think that's a really novel thing, maybe for some people, 569 00:32:34,240 --> 00:32:36,600 but I do really like how it is being done, yeah. 570 00:32:37,640 --> 00:32:40,560 I mean, even if you're doing estimates, you end up with 571 00:32:40,560 --> 00:32:44,160 variable time anyway because estimates are never correct. 572 00:32:44,280 --> 00:32:48,240 So it's better to embrace this fact and work with a variable 573 00:32:48,240 --> 00:32:52,160 scope instead because if your scope is flexible, you can 574 00:32:52,160 --> 00:32:56,120 always guarantee quality. You can guarantee the cost and 575 00:32:56,120 --> 00:33:00,280 the time that it takes. And so as software engineering 576 00:33:00,280 --> 00:33:03,880 is in its nature, because it's a design process, as I said, 577 00:33:04,160 --> 00:33:09,280 unpredictable, it's basically just the agreement between 578 00:33:09,280 --> 00:33:12,000 senior leadership and the engineering organization. 579 00:33:12,480 --> 00:33:17,400 You are now investing 6 weeks, 4 weeks, one week and giving your 580 00:33:17,400 --> 00:33:22,000 best and solving this problem. And within this time box you are 581 00:33:22,000 --> 00:33:24,200 flexible how you are solving the problem. 582 00:33:25,600 --> 00:33:27,760 Right. So let's move on to the 583 00:33:27,840 --> 00:33:30,800 solutions and delivery, right? So let's say given the team has 584 00:33:30,800 --> 00:33:33,880 been given a fixed timeline and a well defined problem, so to 585 00:33:33,880 --> 00:33:35,920 speak, right? So how would you slice, you 586 00:33:36,000 --> 00:33:38,000 know, the solutioning and the delivery aspects? 587 00:33:38,920 --> 00:33:42,760 It's important that you start with the most important thing 588 00:33:43,080 --> 00:33:47,400 first, because if you want to end after your time box is over, 589 00:33:47,600 --> 00:33:51,560 you need to be able to drop the pen and it needs to be 590 00:33:51,560 --> 00:33:55,400 shippable. So you want to work on one scope 591 00:33:55,400 --> 00:33:58,960 of the solution after the another and you want to start 592 00:33:58,960 --> 00:34:03,400 with the most important scopes first so that you can always 593 00:34:03,520 --> 00:34:06,400 like when we are doing a planning of how we are 594 00:34:06,400 --> 00:34:09,360 approaching a feature development initiative, then 595 00:34:09,360 --> 00:34:11,239 we're building a graph of scopes. 596 00:34:11,239 --> 00:34:16,320 Like we have a handful or 10 scopes and we draw dependencies 597 00:34:16,320 --> 00:34:21,159 and how we want to tackle them. And then a line, a cut off line, 598 00:34:21,239 --> 00:34:23,600 we move it in from the back to the beginning. 599 00:34:23,760 --> 00:34:28,199 And we always ask ourselves, can we cut the project at this point 600 00:34:28,520 --> 00:34:32,159 and does it still make sense or is there something we have moved 601 00:34:32,159 --> 00:34:35,239 further down that is really, really important? 602 00:34:35,360 --> 00:34:39,880 And if you slice a solution in this way, you always make sure 603 00:34:39,880 --> 00:34:43,159 that you need to slide the solution in a way that you can 604 00:34:43,159 --> 00:34:44,880 always stop. Yeah. 605 00:34:44,880 --> 00:34:47,480 So I think that is also kind of like novel, right for some 606 00:34:47,480 --> 00:34:50,560 people because typically when you are given a requirement, you 607 00:34:50,560 --> 00:34:53,480 will come up with the design such that you will just meet 608 00:34:53,480 --> 00:34:55,760 whatever that is expected of you, right. 609 00:34:56,120 --> 00:34:59,840 But I think this mental model that keep on moving the cutting 610 00:34:59,840 --> 00:35:02,880 line, so to speak, right, So that you can deliver value in, 611 00:35:02,880 --> 00:35:05,960 you know, the smallest shape as possible, I think that's also 612 00:35:05,960 --> 00:35:08,720 important. While it's important that after 613 00:35:08,720 --> 00:35:12,080 every scope that you delivered that it's tested and that it's 614 00:35:12,080 --> 00:35:14,680 deployed, it could still be after a feature flag and 615 00:35:14,680 --> 00:35:18,360 everything, but it's really important your your definition 616 00:35:18,360 --> 00:35:22,840 of done for a scope. Because if you just implement 617 00:35:22,840 --> 00:35:24,880 the scope and implement the scope and you move all the 618 00:35:24,880 --> 00:35:28,400 testing to the end, then you can also not end after your time box 619 00:35:28,400 --> 00:35:31,240 is over. So it's always thinking those 620 00:35:31,240 --> 00:35:33,480 increments. And I really like the 621 00:35:33,480 --> 00:35:38,560 granularity of problems, thinking in terms of weeks and 622 00:35:38,760 --> 00:35:43,760 resources like 6 weeks, three people working on it because 623 00:35:43,760 --> 00:35:47,600 it's a good level of granularity to align with the senior 624 00:35:47,600 --> 00:35:49,680 leadership and the rest of the company. 625 00:35:50,160 --> 00:35:54,160 And the level of scopes where you, let's say in six weeks you 626 00:35:54,160 --> 00:35:56,440 have 8 scopes or something like this. 627 00:35:56,880 --> 00:36:00,760 This is also a good granularity to work on one thing for a 628 00:36:00,760 --> 00:36:02,480 couple of days and then finish it. 629 00:36:02,840 --> 00:36:07,560 And after every scope, the team really needs to be in this 630 00:36:07,560 --> 00:36:10,120 mindset of we need to finish the scope. 631 00:36:10,720 --> 00:36:13,800 We need to implement everything that we have in mind, like 632 00:36:13,800 --> 00:36:17,120 finish, we need to get it done to work on the next scope. 633 00:36:17,520 --> 00:36:21,320 This is also an important part. A lot of the times the teams are 634 00:36:21,320 --> 00:36:24,560 comparing what they could have done within the scope and then 635 00:36:24,560 --> 00:36:27,680 they use too much time on the scope and it your plan that you 636 00:36:27,680 --> 00:36:30,520 have at the beginning, it cuts delayed and delayed and delayed. 637 00:36:30,840 --> 00:36:35,880 So you need to have a really sharp prioritization to finish 638 00:36:35,880 --> 00:36:40,440 the scope and also what scopes we need to ship for the whole 639 00:36:40,440 --> 00:36:43,760 initiative. So sometimes it also means you 640 00:36:43,760 --> 00:36:49,120 need to trust the scopes. For example, I remember an 641 00:36:49,120 --> 00:36:53,760 initiative we have planned to roughly build 3 features within 642 00:36:53,760 --> 00:36:56,680 this initiative. And we thought, yeah, we make 3 643 00:36:56,680 --> 00:37:00,880 very shallow features because we want to see how customer are 644 00:37:00,880 --> 00:37:04,400 responding to it and then in later initiative make one or two 645 00:37:04,400 --> 00:37:07,800 of them better. But then during this six weeks 646 00:37:07,800 --> 00:37:11,520 initiative, in this time we had the product manager did a call 647 00:37:11,520 --> 00:37:13,800 with the customer showing what we already had. 648 00:37:14,200 --> 00:37:17,160 And then we realised, oh, it really does not make sense what 649 00:37:17,160 --> 00:37:20,440 we have. And so we changed the scopes of 650 00:37:20,440 --> 00:37:24,240 the whole initiative and decided we do two things well and not 651 00:37:24,360 --> 00:37:26,560 three things pretty pretty shallow. 652 00:37:26,560 --> 00:37:29,960 So if you work like this, you are really agile in a way that 653 00:37:29,960 --> 00:37:33,320 you can adjust what you are doing and you can have real 654 00:37:33,680 --> 00:37:36,200 customer feedback guiding you there. 655 00:37:36,760 --> 00:37:38,320 Yeah. So I also like what you 656 00:37:38,320 --> 00:37:41,240 mentioned earlier about, you know, slicing the work in terms 657 00:37:41,240 --> 00:37:44,600 of weeks and resources, right. So weeks is kind of like small 658 00:37:44,600 --> 00:37:47,720 enough that you can kind of like BHR rather than some teams 659 00:37:47,720 --> 00:37:49,960 actually do it in quarterly planning, right. 660 00:37:50,200 --> 00:37:54,920 So which is kind of like long. So slicing the work is one part 661 00:37:54,920 --> 00:37:57,440 that you think is going to help a lot of teams. 662 00:37:57,440 --> 00:38:01,160 The other aspect is actually aligning teams against this kind 663 00:38:01,160 --> 00:38:02,960 of like work, right? So. 664 00:38:03,320 --> 00:38:06,800 We have missed 1 aspect and this is the slicing of delivery. 665 00:38:07,600 --> 00:38:11,160 But it's a short one I think because if you are, you have 666 00:38:11,160 --> 00:38:13,920 sliced a solution that you start with the most important scopes 667 00:38:13,920 --> 00:38:17,600 and so on and then you actually start working on it and working 668 00:38:17,600 --> 00:38:21,680 on it means everybody is working on the same thing at the same 669 00:38:21,680 --> 00:38:24,200 time. So it does not mean front end is 670 00:38:24,200 --> 00:38:28,760 preparing something, back end is preparing something and then at 671 00:38:28,760 --> 00:38:30,360 one point they are bringing it together. 672 00:38:30,360 --> 00:38:33,880 No, it means everybody is working on the same thing. 673 00:38:33,880 --> 00:38:37,040 Like the designer, the front end engineer, the back end engineer. 674 00:38:37,520 --> 00:38:41,680 Let's say they first start with the overview table of a feature 675 00:38:41,960 --> 00:38:44,600 and they all do the same thing at the same time. 676 00:38:44,600 --> 00:38:48,960 And then they finish this table and then they start with the 677 00:38:49,080 --> 00:38:51,520 edit functionality, and then they do the delete 678 00:38:51,520 --> 00:38:53,920 functionality. And everybody's really working 679 00:38:53,920 --> 00:38:55,520 on the same thing at the same time. 680 00:38:55,520 --> 00:38:59,800 And this needs some adjustments to work like this to not only 681 00:38:59,800 --> 00:39:04,080 chase efficiency, like I said at the beginning, but there's much 682 00:39:04,080 --> 00:39:08,920 more chances for pairing up in this kind of setting, working on 683 00:39:08,920 --> 00:39:12,320 the same thing. It's a lot of chances that front 684 00:39:12,320 --> 00:39:14,880 ends learn something from back end and vice versa. 685 00:39:15,280 --> 00:39:19,720 It's pretty hard for designers sometimes to work like this 686 00:39:20,080 --> 00:39:24,240 because designers, they need to have a bigger picture, they need 687 00:39:24,240 --> 00:39:27,160 to define the styles that they are using and so on. 688 00:39:27,160 --> 00:39:30,440 So this is something that's sometimes a challenge if you 689 00:39:30,440 --> 00:39:33,240 switch to this way of working and if you it's really strict, 690 00:39:33,800 --> 00:39:37,160 this could be mitigated if you have a good component library 691 00:39:37,160 --> 00:39:41,400 already and if you have a ripe major product. 692 00:39:41,800 --> 00:39:45,600 If you don't have this, this situation, then you, I tend to 693 00:39:45,600 --> 00:39:49,720 be a little bit loose here. So I allow the designers to 694 00:39:50,240 --> 00:39:53,400 design a little bit more. And yeah, basically it's not me 695 00:39:53,400 --> 00:39:55,480 allowing them. It's designers come up with the 696 00:39:55,480 --> 00:40:00,000 idea that they need to design other parts of the product as 697 00:40:00,000 --> 00:40:04,280 well of the initiative as well. To make the decisions now, but 698 00:40:04,280 --> 00:40:08,200 we really try to say this is the personal workflow of the 699 00:40:08,200 --> 00:40:11,040 designer. We don't need the whole team to 700 00:40:11,040 --> 00:40:14,240 give feedback on everything. So because you don't want to end 701 00:40:14,240 --> 00:40:18,600 up with 30 or 40 Figma screens and then all the developers are 702 00:40:18,600 --> 00:40:22,280 implementing them at one point. I think for engineering is the 703 00:40:22,280 --> 00:40:23,920 same. Sometimes you need to think 704 00:40:23,920 --> 00:40:28,320 about the architecture a few steps further than what you're 705 00:40:28,320 --> 00:40:32,400 at the moment are doing. But we really try and as a rule 706 00:40:32,400 --> 00:40:36,160 of thumb and the teams that I have led that it's like 70 to 707 00:40:36,160 --> 00:40:39,400 80% of the time is really spent together. 708 00:40:39,400 --> 00:40:43,200 So the delivery is really sliced in a way that everybody is 709 00:40:43,200 --> 00:40:45,200 working on the same thing at the same time. 710 00:40:45,920 --> 00:40:47,560 Yeah. I think the key also when we 711 00:40:47,560 --> 00:40:50,560 want to work that way, right, it's not to build the silos 712 00:40:50,560 --> 00:40:52,840 within the team where you have specialization either like. 713 00:40:53,320 --> 00:40:55,000 Exactly. You don't want to end up with a 714 00:40:55,080 --> 00:40:57,080 lot of mini waterfalls, Yeah. Yeah. 715 00:40:57,200 --> 00:41:00,120 So I think, yeah, try to avoid from that kind of practice where 716 00:41:00,120 --> 00:41:02,800 you have specializations and silo within the team itself. 717 00:41:03,080 --> 00:41:06,080 And it may be worse if you assign tickets to different 718 00:41:06,080 --> 00:41:07,880 stages while you building the team. 719 00:41:07,920 --> 00:41:11,600 Exactly. So slicing is 1 aspect that you 720 00:41:11,600 --> 00:41:14,280 think can help, right? The other aspect is actually 721 00:41:14,280 --> 00:41:17,400 aligning the team with this work, right? 722 00:41:17,680 --> 00:41:20,240 So tell us a little bit more the importance of this alignment. 723 00:41:21,040 --> 00:41:23,520 Yep. So I, I really like the 724 00:41:24,200 --> 00:41:27,120 blueprint of empowered product teams here. 725 00:41:27,160 --> 00:41:30,440 It's from Marty Kagan from the Silicon Valley Product Group. 726 00:41:30,840 --> 00:41:35,440 And the idea is that you have one product team and the product 727 00:41:35,440 --> 00:41:37,160 team has everything the team needs. 728 00:41:37,160 --> 00:41:40,680 You have a product manager. Product manager is responsible 729 00:41:40,680 --> 00:41:44,400 that the team is delivering value to the customer, but also 730 00:41:44,400 --> 00:41:47,440 for the business viability, addressing the business 731 00:41:47,440 --> 00:41:50,480 viability risk. This means the connection to go 732 00:41:50,480 --> 00:41:53,400 to market like does it make sense what we're building to 733 00:41:53,400 --> 00:41:56,880 what we are to the customers that we are acquiring. 734 00:41:57,480 --> 00:42:01,000 And this is different from a product owner in a scrum 735 00:42:01,000 --> 00:42:03,320 setting. A product owner is only somebody 736 00:42:03,320 --> 00:42:06,080 who is writing tickets into a backlog. 737 00:42:06,080 --> 00:42:09,040 Like a product manager comes with a certain skill set. 738 00:42:09,440 --> 00:42:12,280 He or she needs to know interview techniques and you 739 00:42:12,280 --> 00:42:16,080 really need to own this. This person is owning if the 740 00:42:16,560 --> 00:42:20,480 team is really creating value. And then you have designers, 741 00:42:20,840 --> 00:42:23,520 they are responsible for the usability risk and for the 742 00:42:23,520 --> 00:42:26,720 experience. And then you have engineers, and 743 00:42:26,840 --> 00:42:30,880 it should be insourced engineers, because you need to 744 00:42:30,880 --> 00:42:34,680 have insourced engineers to really create this innovation 745 00:42:34,680 --> 00:42:39,960 and really use them also for shaping the solution that is 746 00:42:39,960 --> 00:42:41,960 built after the problem is defined. 747 00:42:41,960 --> 00:42:45,240 So engineers are responsible for feasibility risk and for 748 00:42:45,240 --> 00:42:47,800 delivery. And so you're basically building 749 00:42:47,800 --> 00:42:49,760 the team with all the capabilities. 750 00:42:49,760 --> 00:42:52,680 So you need to hire engineers that can address this 751 00:42:52,680 --> 00:42:55,920 feasibility risk and you need to find the product manager that 752 00:42:55,920 --> 00:42:59,320 can own the customer value and the business viability risk. 753 00:42:59,720 --> 00:43:03,600 And then you give problems to the team or objectives to the 754 00:43:03,600 --> 00:43:06,760 team basically. And then such a team is doing 755 00:43:06,760 --> 00:43:10,320 the discovery of the problems and of the solutions that can 756 00:43:10,480 --> 00:43:13,800 help achieving this objective and also the delivery. 757 00:43:13,800 --> 00:43:17,200 So they should organise themselves and the level of 758 00:43:17,200 --> 00:43:21,120 objectives is the right way of steering such a team. 759 00:43:21,920 --> 00:43:27,120 Yeah, I find that this is the ideal thing that many teams want 760 00:43:27,120 --> 00:43:29,640 to practice. But for whatever reasons, right, 761 00:43:29,640 --> 00:43:33,040 in practice, many things are not running this way, right? 762 00:43:33,040 --> 00:43:35,200 So for example, when we mentioned about empowered 763 00:43:35,480 --> 00:43:38,560 product teams, right, I think still many teams are given 764 00:43:38,560 --> 00:43:42,160 mandates from the stakeholders and management and maybe they're 765 00:43:42,160 --> 00:43:44,600 just given, OK, this is the problem, here's what the 766 00:43:44,600 --> 00:43:47,760 solutions that we think would work, just go ahead and deliver 767 00:43:47,760 --> 00:43:49,800 it, right? And product managers become more 768 00:43:49,800 --> 00:43:53,240 like a proxy rather than, you know, an empowered one, right, 769 00:43:53,240 --> 00:43:56,040 that can come up with the solutions, maybe even thinking 770 00:43:56,040 --> 00:43:59,000 about doing interviews, coming up with the well defined 771 00:43:59,000 --> 00:44:02,080 problems and all that. So tell us, what do you think we 772 00:44:02,080 --> 00:44:05,520 should do in order to kind of like align these teams practices 773 00:44:05,520 --> 00:44:08,640 such that it becomes more empowered because it's, I think 774 00:44:08,640 --> 00:44:11,080 it's still pretty rare in many software engineering teams. 775 00:44:12,000 --> 00:44:13,920 Yeah. If you look at the problem, 776 00:44:14,240 --> 00:44:17,440 you're on the one side, you have the skills of the individuals, 777 00:44:17,640 --> 00:44:19,880 that the individuals need to have the skills. 778 00:44:20,200 --> 00:44:24,240 And the other part is that you as a technical leader create the 779 00:44:24,240 --> 00:44:28,120 organization for it. And so it's really two parts. 780 00:44:28,480 --> 00:44:32,760 And the part with the, the part that you as a, as a tech leader 781 00:44:32,760 --> 00:44:35,720 can do yourself is like aligning the organization around it. 782 00:44:36,240 --> 00:44:41,480 Here I always like to start with defining the problems, because 783 00:44:41,480 --> 00:44:47,120 if you start with the problem definition, you can do it on 784 00:44:47,120 --> 00:44:50,280 your own or you can, let's say the product, you have a product 785 00:44:50,280 --> 00:44:52,920 manager and he's, he knows what it means to be an empowered 786 00:44:52,920 --> 00:44:54,960 product team, but you're struggling with the rest of the 787 00:44:54,960 --> 00:44:58,520 organization. They give requirements and so 788 00:44:58,520 --> 00:44:59,760 on. Then I feel it's the 789 00:44:59,760 --> 00:45:03,960 responsibility for the technical leader to create the process 790 00:45:03,960 --> 00:45:06,160 that the team can work as an empowered team. 791 00:45:06,560 --> 00:45:09,160 And this means if stakeholders are coming with concrete 792 00:45:09,160 --> 00:45:12,960 requirements like with solutions, you take them and you 793 00:45:13,640 --> 00:45:18,000 rephrase them has problems. And then you go back to your 794 00:45:18,000 --> 00:45:21,520 stakeholders and you say, are those the problems that you want 795 00:45:21,520 --> 00:45:24,280 to address? Just making sure like it's just 796 00:45:24,320 --> 00:45:29,160 ensuring and it's not even you can really do this without being 797 00:45:29,160 --> 00:45:31,080 offensive. Like you just say we have a new 798 00:45:31,080 --> 00:45:33,440 product, we have a new product process. 799 00:45:33,440 --> 00:45:35,280 We want to focus on the problems 1st. 800 00:45:35,760 --> 00:45:38,640 And then if you are doing the work for them, but then 801 00:45:38,640 --> 00:45:43,360 afterwards you discuss it with them, then sometimes they really 802 00:45:43,560 --> 00:45:45,680 they want to make sure that the problems are correct. 803 00:45:45,680 --> 00:45:48,000 So they will give you feedback and help you with the product 804 00:45:48,000 --> 00:45:50,920 definitions. And then you slowly can educate 805 00:45:50,920 --> 00:45:54,840 them that this is your process, but you need to define the 806 00:45:54,840 --> 00:45:57,160 process. And but this is a good starting 807 00:45:57,160 --> 00:46:00,400 point. And Yep, the the other solution 808 00:46:00,400 --> 00:46:05,320 is where the other situation is, where the stakeholders are, 809 00:46:05,880 --> 00:46:08,600 whether it's not an issue with the stakeholders, but the team 810 00:46:08,600 --> 00:46:13,320 is not willing to work in this way or not capable. 811 00:46:13,320 --> 00:46:16,480 And I mean, here you need to invest in the skills of the 812 00:46:16,480 --> 00:46:18,600 people or maybe you need to switch people. 813 00:46:18,960 --> 00:46:22,120 Because if you have, if you want to have an empowered team and 814 00:46:22,120 --> 00:46:26,960 you only have introverted engineers who only want to work 815 00:46:26,960 --> 00:46:29,920 on their tickets, then that's the wrong team. 816 00:46:30,120 --> 00:46:31,960 Maybe you can educate some of them. 817 00:46:32,400 --> 00:46:38,040 And for me, the rise of AI is a very good argument for engineers 818 00:46:38,040 --> 00:46:42,560 because their skills of writing JavaScript or Go or whatever. 819 00:46:42,920 --> 00:46:46,120 I asked them what are they worth in 10 years that you can write 820 00:46:46,120 --> 00:46:48,680 JavaScript. I I don't think they're, they're 821 00:46:48,680 --> 00:46:51,600 not worth much in 10 years, maybe not even in five years, 822 00:46:51,600 --> 00:46:53,360 maybe even not next year, I don't know. 823 00:46:53,720 --> 00:46:58,240 But at one point your skills of writing code are not relevant 824 00:46:58,240 --> 00:47:00,560 anymore. I think that is safe to say at 825 00:47:00,560 --> 00:47:05,080 the moment and this is my main motivation for the engineers to 826 00:47:05,160 --> 00:47:08,280 bring them further at the beginning of the process and 827 00:47:08,280 --> 00:47:12,960 really shaping the solutions, be also part of shaping the 828 00:47:12,960 --> 00:47:14,720 solutions. Yeah. 829 00:47:14,720 --> 00:47:17,080 And this comes back to the earlier, right, when we 830 00:47:17,080 --> 00:47:19,640 mentioned about slicing the objectives and slicing the 831 00:47:19,640 --> 00:47:22,520 problems, right? Because engineers definitely we 832 00:47:22,520 --> 00:47:24,000 can come up with the solutions, right. 833 00:47:24,280 --> 00:47:26,200 But understanding the objectives, that's the first 834 00:47:26,200 --> 00:47:28,600 thing, right. And then the problems defining 835 00:47:28,600 --> 00:47:31,400 the problems, getting involved in defining the problems, I 836 00:47:31,400 --> 00:47:34,600 think that kind of like. Exactly. 837 00:47:34,880 --> 00:47:39,320 So we have a review process also for problems, so that engineers 838 00:47:39,400 --> 00:47:42,840 read all the problem definitions and can give their feedback also 839 00:47:42,840 --> 00:47:45,840 on this stage. So this is the most important 840 00:47:46,040 --> 00:47:47,600 step. Be really clear about the 841 00:47:47,600 --> 00:47:50,520 problem you want to solve. Yeah, I really like that because 842 00:47:50,520 --> 00:47:53,640 many, many times I've heard the emphasis on the objectives, 843 00:47:53,640 --> 00:47:57,000 right, Well defined objectives with clear metrics and all that. 844 00:47:57,360 --> 00:48:00,040 And then the problems is something that probably we can 845 00:48:00,120 --> 00:48:03,440 practice right in order to involve the engineers to come up 846 00:48:03,440 --> 00:48:06,160 with more innovative solutions and they really understand what 847 00:48:06,160 --> 00:48:09,040 exactly the problems that we need to tackle to achieve that 848 00:48:09,040 --> 00:48:11,760 objectives. Also as part of the alignment of 849 00:48:11,760 --> 00:48:15,440 the teams, you mentioned that you prefer a small team and 850 00:48:15,440 --> 00:48:18,120 small here is the 2-3 people team. 851 00:48:18,440 --> 00:48:21,480 I think this is really small, but tell us the argument behind 852 00:48:21,480 --> 00:48:25,600 this. What I mean is I prefer two to 853 00:48:25,600 --> 00:48:29,520 three people collaborating at every point in time. 854 00:48:30,000 --> 00:48:35,280 This means two to three people implementing 1 initiative, like 855 00:48:35,280 --> 00:48:38,680 implementing one solution to a problem, but it also means two 856 00:48:38,680 --> 00:48:43,200 to three people collaborating on shaping the solution. 857 00:48:43,440 --> 00:48:47,080 It means two to three people discussing what problems should 858 00:48:47,080 --> 00:48:49,840 be solved. Like I would always aim for 859 00:48:49,840 --> 00:48:53,760 small groups that have all the capabilities that they are 860 00:48:53,760 --> 00:48:56,800 needing. So this means, for example, 861 00:48:56,800 --> 00:49:00,720 let's say we are shaping a problem that we want to solve. 862 00:49:00,720 --> 00:49:04,720 So we are shaping the solution. And then you need to have a 863 00:49:04,920 --> 00:49:08,200 technical, a senior technical person there. 864 00:49:08,200 --> 00:49:10,640 You need to have a product manager, you need to have a 865 00:49:10,640 --> 00:49:13,040 designer who knows about interactions. 866 00:49:13,040 --> 00:49:16,200 And so they are collaborate and shaping a solution. 867 00:49:16,800 --> 00:49:21,200 But it does not mean that those are the same people need to 868 00:49:21,200 --> 00:49:23,800 implement this because sometimes you maybe want to have a 869 00:49:23,800 --> 00:49:26,680 different pairing and implementation phase where you 870 00:49:26,680 --> 00:49:30,920 are pairing a junior with a senior and maybe it's the same 871 00:49:30,920 --> 00:49:35,440 designer and maybe the product managers not that involved 872 00:49:35,440 --> 00:49:38,480 during the delivery, just from time to time. 873 00:49:38,880 --> 00:49:42,520 So you have then another team of two to three people and would 874 00:49:42,520 --> 00:49:45,920 also aim for two to three people making those decisions. 875 00:49:45,920 --> 00:49:49,720 With the senior leadership, it's basically a, let's say ACEO, 876 00:49:50,040 --> 00:49:54,840 it's a technical leader, CTO, and it's a product manager or 877 00:49:54,840 --> 00:49:57,640 whoever is in responsibility of the process. 878 00:49:58,160 --> 00:50:01,880 Because if you have more people, you have more communication 879 00:50:02,400 --> 00:50:04,880 because communication scales exponentially. 880 00:50:04,880 --> 00:50:08,400 If you have three people, everyone needs to talk to two 881 00:50:08,400 --> 00:50:12,200 others, so you end up with three lines of communication. 882 00:50:12,480 --> 00:50:16,280 But if you have, let's say 5 people in a team, everybody is 883 00:50:16,440 --> 00:50:21,120 talking to four other peoples. If you imagine it as a graph of 884 00:50:21,120 --> 00:50:24,200 people who need to talk to each other, that the picture is much 885 00:50:24,200 --> 00:50:27,760 more more complex. Bring together who can make the 886 00:50:27,760 --> 00:50:31,720 decision like from a authority point of view but also from a 887 00:50:31,720 --> 00:50:35,960 skill point of view and then you can make decisions pretty fast. 888 00:50:35,960 --> 00:50:40,080 And they need to be a enabled, they need to have the allowance 889 00:50:40,520 --> 00:50:43,120 to make this decision. This is important from a process 890 00:50:43,120 --> 00:50:44,600 wise. Right. 891 00:50:44,720 --> 00:50:47,560 Thanks for the clarification. So it's more like a dynamic, 892 00:50:48,080 --> 00:50:50,040 kind of like teaming. Of. 893 00:50:50,600 --> 00:50:52,880 Group of people working on certain particular thing, right 894 00:50:52,880 --> 00:50:55,560 at the time and you mentioned about the communication 895 00:50:55,560 --> 00:50:58,800 challenges if let's say you grow into more people, right? 896 00:50:58,800 --> 00:51:01,400 Definitely, you know, there are more lines, right, To 897 00:51:01,400 --> 00:51:03,520 communicate with each other and not to mention the 898 00:51:03,520 --> 00:51:05,920 misunderstanding that could happen as well when you have so 899 00:51:05,920 --> 00:51:08,760 many people. One of the aspects is about the 900 00:51:08,760 --> 00:51:11,240 alignment with the value streams, right? 901 00:51:11,240 --> 00:51:13,520 This is also partly what you emphasize, right? 902 00:51:13,800 --> 00:51:17,800 Alignment with value streams. So tell us what is the thing 903 00:51:17,800 --> 00:51:18,320 here? Yeah. 904 00:51:18,800 --> 00:51:22,840 So this is an idea from the Team Topologies book from Matthew 905 00:51:22,840 --> 00:51:27,240 Skelton and the ideas that you have all the capabilities in the 906 00:51:27,240 --> 00:51:31,280 team that you need to deliver value to the customer from the 907 00:51:31,760 --> 00:51:35,760 idea of what value we want to deliver to the customer to the 908 00:51:35,800 --> 00:51:37,720 delivery. So it does. 909 00:51:37,880 --> 00:51:43,200 For example, bad practice would be to have a dedicated design 910 00:51:43,200 --> 00:51:46,640 team, a dedicated front end engineering team, dedicated back 911 00:51:46,640 --> 00:51:49,560 end engineering team, because then you have a lot of handovers 912 00:51:49,560 --> 00:51:52,120 between the teams. What you really want is to have 913 00:51:52,120 --> 00:51:54,760 one team with a designer, a front end engineer and a back 914 00:51:54,760 --> 00:51:57,760 end engineer. But the same goes also for other 915 00:51:57,760 --> 00:52:00,840 handovers. Let's say you divide your teams 916 00:52:00,840 --> 00:52:03,720 along the customer journey. So for example, if you're an 917 00:52:03,720 --> 00:52:07,360 e-commerce and then you have one team for search, one team for 918 00:52:07,360 --> 00:52:10,280 the catalog, one team for checkout, one team for payment, 919 00:52:10,560 --> 00:52:13,160 one team for fulfilment. So you also have a lot of 920 00:52:13,160 --> 00:52:16,280 handovers if you want to change, if you want to implement the 921 00:52:16,280 --> 00:52:20,280 change of how you delivering value to the customer, let's say 922 00:52:20,280 --> 00:52:22,800 you're implementing A discounting mechanism or 923 00:52:22,800 --> 00:52:26,120 something like this. So also here you want to have 924 00:52:26,120 --> 00:52:29,880 teams that are capable to work on all parts of the platform. 925 00:52:30,520 --> 00:52:34,640 I think it's too much to dive deeper into the ideas of team 926 00:52:34,640 --> 00:52:38,560 topologies because there are really ideas and how you can 927 00:52:38,680 --> 00:52:43,040 maintain a coherent architecture and coherent user experience 928 00:52:43,320 --> 00:52:47,040 around those kind of teams. But I just want to touch it here 929 00:52:47,040 --> 00:52:50,280 because it's also very important if you build such an empowered 930 00:52:50,280 --> 00:52:53,680 product team that it really has all the capabilities that's 931 00:52:53,680 --> 00:52:55,760 needed. And this goes a little bit back 932 00:52:56,080 --> 00:52:59,360 to the of of the slicing of problems because we need to 933 00:52:59,360 --> 00:53:02,440 slice the problems also in a way that they are fitting your 934 00:53:02,440 --> 00:53:04,640 teams. But this is something that we 935 00:53:04,640 --> 00:53:08,240 will touch in one of the next parts when we talk about how we 936 00:53:08,240 --> 00:53:13,120 are mapping the sliced work to the different levels of the 937 00:53:13,120 --> 00:53:16,320 organization. Yeah, I think Team Topologies 938 00:53:16,320 --> 00:53:19,040 definitely highly recommend everyone to follow if you 939 00:53:19,040 --> 00:53:21,120 haven't heard about it. So I think what you mentioned 940 00:53:21,120 --> 00:53:23,720 just now is the concept of stream aligned team, right? 941 00:53:23,720 --> 00:53:26,920 So it's one of the team structure that is advocated 942 00:53:26,920 --> 00:53:29,840 within the Team Topologies. So let's go to the mapping of 943 00:53:29,840 --> 00:53:31,400 the work itself to the organization. 944 00:53:31,400 --> 00:53:35,040 So how can people do that? Now I'm basically bringing 945 00:53:35,040 --> 00:53:38,360 together the idea of the two to three people always working 946 00:53:38,360 --> 00:53:41,280 together with how we are slicing the work. 947 00:53:41,560 --> 00:53:44,920 If you start at the bottom and the delivery team, you have two 948 00:53:44,920 --> 00:53:48,120 to three people walking, delivering. 949 00:53:48,400 --> 00:53:51,080 Yeah. And then you have a level above, 950 00:53:51,160 --> 00:53:53,560 you have the slicing of the solutions there. 951 00:53:53,880 --> 00:53:58,200 Normally you would have a three factor of an engineering lead of 952 00:53:58,320 --> 00:54:02,440 a product person and the designer design lead. 953 00:54:02,440 --> 00:54:07,400 And they, as I said, the more senior people, they should slice 954 00:54:07,400 --> 00:54:10,240 how the solutions are looking for this team. 955 00:54:10,240 --> 00:54:15,200 And then they have a couple of three or four teams below them. 956 00:54:15,200 --> 00:54:18,000 For them, they are slicing the solution because they have the 957 00:54:18,000 --> 00:54:22,400 most insight into the system and then they need to check with 958 00:54:22,400 --> 00:54:25,920 them during delivery. And one level above, maybe you 959 00:54:25,920 --> 00:54:30,040 have a middle management layer, director of engineering, 960 00:54:30,040 --> 00:54:32,040 director, product director design. 961 00:54:32,400 --> 00:54:36,160 This is the place where you slice the problems because you 962 00:54:36,160 --> 00:54:39,720 need to align to the objective that you're slicing. 963 00:54:40,240 --> 00:54:42,560 You need to align on the objectives on the topmost layer 964 00:54:42,560 --> 00:54:49,200 on the CEOCTOCPTOCPO like technical product leadership and 965 00:54:49,680 --> 00:54:53,440 also design leadership. So the idea is that you have 966 00:54:53,440 --> 00:54:57,800 always two to three people, that you always have the required 967 00:54:57,800 --> 00:55:01,240 skills and that they are able to make the decisions like 968 00:55:01,520 --> 00:55:04,880 objectives on the top, what problems to address on the 969 00:55:05,160 --> 00:55:08,560 director level, if it's a bigger organization, if it's a small 970 00:55:08,560 --> 00:55:12,480 organization, it's probably the same people that are slicing the 971 00:55:12,480 --> 00:55:14,280 solutions. Yeah. 972 00:55:14,280 --> 00:55:17,680 So I find this kind of alignment is very, very crucial, right, 973 00:55:17,680 --> 00:55:20,320 Especially when your organization grows really large, 974 00:55:20,320 --> 00:55:23,000 because sometimes people couldn't really identify the 975 00:55:23,000 --> 00:55:25,600 work that they're doing, how it actually aligns with the 976 00:55:25,600 --> 00:55:28,560 business, right? Be it, you know, efficiency, 977 00:55:28,560 --> 00:55:30,640 engagement, revenue, whatever that is, right? 978 00:55:30,640 --> 00:55:33,480 So sometimes people just don't understand what problems they're 979 00:55:33,480 --> 00:55:35,280 solving, what objectives they're aligning to. 980 00:55:35,760 --> 00:55:38,720 And I think it's a small simple exercise of aligning all these 981 00:55:38,720 --> 00:55:41,800 like objectives, problems, solution delivery can really 982 00:55:41,800 --> 00:55:45,200 help people to give the clearance like the clearer 983 00:55:45,360 --> 00:55:48,200 picture of, you know, what things they achieve together as 984 00:55:48,200 --> 00:55:51,280 a company, right? And it's also important to note 985 00:55:51,280 --> 00:55:55,160 that this is not top down. It's really a two way exchange 986 00:55:55,280 --> 00:55:58,400 like one of the principle of Tokyo asked that stuff is 987 00:55:58,400 --> 00:56:00,760 bubbling up from the bottom again. 988 00:56:00,760 --> 00:56:03,920 Like if you have a problem with delivery, you cannot deliver 989 00:56:03,920 --> 00:56:08,000 something, then you go one step up to the people who sliced the 990 00:56:08,000 --> 00:56:11,600 solution with you. And if you then find out, oh, we 991 00:56:11,600 --> 00:56:14,680 need to solve a different problem, then you go one step up 992 00:56:14,680 --> 00:56:16,920 again. And so it goes up and down and 993 00:56:17,520 --> 00:56:19,480 it really needs to be a dynamic process. 994 00:56:19,480 --> 00:56:22,400 This is not because if it would only top down, then we have 995 00:56:22,520 --> 00:56:25,840 waterfall again, but for interdisciplinary waterfalls. 996 00:56:27,000 --> 00:56:28,520 Right. So we have discussed so many 997 00:56:28,520 --> 00:56:32,040 things right just now about your thing, right move things and 998 00:56:32,040 --> 00:56:33,960 breaks our laws. Are there any things that you 999 00:56:33,960 --> 00:56:36,960 think we should also cover because the time is approaching 1000 00:56:36,960 --> 00:56:39,480 almost to the end now. So are there any things that you 1001 00:56:39,480 --> 00:56:43,840 want to chip in more here? Just maybe one thing for a large 1002 00:56:43,840 --> 00:56:48,080 organization, this is that like big organisations and just one 1003 00:56:48,080 --> 00:56:51,200 empowered product team, I think it's important to think of the 1004 00:56:51,200 --> 00:56:54,720 reporting structures of the company as a technical leader. 1005 00:56:54,720 --> 00:56:58,840 With the reporting structure you can steer to a certain degree 1006 00:56:58,840 --> 00:57:02,680 how the teams are working. If I want the teams to work on a 1007 00:57:02,680 --> 00:57:06,440 scope by scope, then I let report them scopes. 1008 00:57:06,920 --> 00:57:10,720 So then they are forced to think in scopes and yeah, they can 1009 00:57:10,720 --> 00:57:12,960 make it more complicated and work different anyway. 1010 00:57:13,240 --> 00:57:16,760 But I probably will find it out because then the results are not 1011 00:57:16,760 --> 00:57:18,960 in check with what they are reported. 1012 00:57:19,440 --> 00:57:21,960 This is just important. And there are a couple of tools 1013 00:57:21,960 --> 00:57:25,600 also from Basecamp, a tool like the hill chart. 1014 00:57:25,600 --> 00:57:28,560 The idea of the hill chart is that work is more like a hill 1015 00:57:28,560 --> 00:57:31,320 than a straight line. So you have always an uphill 1016 00:57:31,320 --> 00:57:34,400 phase when you are figuring things out and then you have a 1017 00:57:34,400 --> 00:57:37,320 downhill phase of making things happen and then you could align 1018 00:57:37,320 --> 00:57:41,160 the scopes on the uphill phase. Then I as a leader understand 1019 00:57:41,160 --> 00:57:43,960 all the team is with this scope in this phase. 1020 00:57:43,960 --> 00:57:48,800 They are trying to find out what it's about or I know how they 1021 00:57:48,800 --> 00:57:52,520 just need to implement it. So this is a different view from 1022 00:57:52,520 --> 00:57:54,280 you as a leader. And this is what I meant with 1023 00:57:54,320 --> 00:57:56,960 granularity. When then I see and I can 1024 00:57:57,160 --> 00:58:00,720 compare the scopes from a couple of teams and I can see are they 1025 00:58:00,720 --> 00:58:04,280 making good progress or are they having unknowns because they are 1026 00:58:04,360 --> 00:58:08,160 flagging the unknowns. I want them to flag unknowns on 1027 00:58:08,160 --> 00:58:12,040 the hill chart as well. Then I quickly can see if they 1028 00:58:12,040 --> 00:58:15,920 understand what I want from them, how to work as well. 1029 00:58:15,920 --> 00:58:20,440 And there are other tools from Basecamp like moving the needle 1030 00:58:20,840 --> 00:58:26,080 where you have a scale, time is progressing linearly and you 1031 00:58:26,680 --> 00:58:30,120 manually need to set a needle of how far you are into the 1032 00:58:30,120 --> 00:58:33,160 process. But maybe we'll leave a link and 1033 00:58:33,160 --> 00:58:36,000 people can look it up. It's a tool from Basecamp and 1034 00:58:36,840 --> 00:58:39,760 it's always inspiring to see what they are doing because they 1035 00:58:40,080 --> 00:58:43,840 think about product development in such a different way. 1036 00:58:44,240 --> 00:58:47,760 And then you are still free to implement it in your own tools, 1037 00:58:47,840 --> 00:58:49,840 in your mirror board and your confluence. 1038 00:58:50,120 --> 00:58:53,040 However I like to know it. Right. 1039 00:58:53,280 --> 00:58:56,000 So definitely, we'll put all of them in the show notes for 1040 00:58:56,000 --> 00:58:59,160 people who want to study further right about those techniques 1041 00:58:59,240 --> 00:59:01,600 from Basecamp. So Claus has been a great 1042 00:59:01,600 --> 00:59:03,760 conversation. I think we all learn a lot about 1043 00:59:03,960 --> 00:59:06,760 a thing or two, how to optimize our product development or 1044 00:59:06,760 --> 00:59:09,400 software development, right? So as we reach the end of our 1045 00:59:09,400 --> 00:59:12,440 conversation, I have only one last question, which I always 1046 00:59:12,440 --> 00:59:15,120 ask to all my guests. I call this the tree technical 1047 00:59:15,120 --> 00:59:17,640 leadership wisdom. If you can think of them just 1048 00:59:17,640 --> 00:59:20,520 like advice, maybe if you can share your version today that 1049 00:59:20,520 --> 00:59:22,480 will be great. Yeah, sure. 1050 00:59:22,840 --> 00:59:27,800 So first would be don't give your team a backlog of stuff. 1051 00:59:28,440 --> 00:59:33,840 Give give your team a clear goal and a deadline and then let them 1052 00:59:33,920 --> 00:59:37,880 figure it out. That is would be my first thing 1053 00:59:38,600 --> 00:59:42,760 because it also helps you as a leader to really think about 1054 00:59:42,760 --> 00:59:46,120 what we want to achieve and not get distracted and a lot of 1055 00:59:46,120 --> 00:59:49,720 small things first, this and this and then and the second one 1056 00:59:49,720 --> 00:59:55,120 would be stay calm because nobody is doing agile in the 1057 00:59:55,120 --> 00:59:59,040 right way or not. I have not seen two companies 1058 00:59:59,440 --> 01:00:02,760 doing the same process. So I think it's important to 1059 01:00:02,760 --> 01:00:06,760 stop asking yourself if you implement a certain methodology 1060 01:00:06,760 --> 01:00:10,200 like Scrum or Safe or whatever correctly. 1061 01:00:10,240 --> 01:00:13,680 I think it's more important to really observe what is going on 1062 01:00:14,080 --> 01:00:16,920 in your organization and then adjust accordingly. 1063 01:00:17,520 --> 01:00:20,600 But. That said, it's a segue to my 1064 01:00:20,600 --> 01:00:23,560 third advice. You really need to understand 1065 01:00:23,680 --> 01:00:27,200 what others are doing and what trends are there in the 1066 01:00:27,200 --> 01:00:29,480 industry. Like we have a lot of 1067 01:00:29,480 --> 01:00:33,840 interesting trends like multiple development, also a good podcast 1068 01:00:33,840 --> 01:00:36,840 episode with you. And there are trends like shape 1069 01:00:36,840 --> 01:00:41,320 up and you need to talk to other leaders how they are doing it 1070 01:00:41,320 --> 01:00:45,400 and being exchanged with them to really understand what they are 1071 01:00:45,400 --> 01:00:47,320 doing. And I think it's more important 1072 01:00:47,320 --> 01:00:50,920 to understand, as I said, what are the problems of your own 1073 01:00:50,920 --> 01:00:54,440 team and what others are doing, and then come up with good 1074 01:00:54,760 --> 01:00:58,800 solutions for them. Yeah, I really love them, Right? 1075 01:00:58,800 --> 01:01:01,480 Staying calm, right? So nobody actually practiced 1076 01:01:01,560 --> 01:01:03,080 anything perfectly, I would say, right? 1077 01:01:03,200 --> 01:01:06,400 And it's also highly contextual. I will slightly tweak the third 1078 01:01:06,400 --> 01:01:09,640 one to listen to the podcast. So if you want to learn, you 1079 01:01:09,640 --> 01:01:12,240 know, about new techniques of other things that people are 1080 01:01:12,240 --> 01:01:14,080 doing, thought leaders in the industry. 1081 01:01:14,480 --> 01:01:15,920 So thanks for pointing that out as well. 1082 01:01:16,280 --> 01:01:19,040 So Claus, if people love this conversation, they want to 1083 01:01:19,280 --> 01:01:21,480 follow up with you, ask you more questions. 1084 01:01:21,480 --> 01:01:23,200 Is there a place where they can find you online? 1085 01:01:23,800 --> 01:01:25,920 Yeah, sure. So I have a blog. 1086 01:01:26,200 --> 01:01:33,280 The domain is VO1 dot IO and I'm also active on LinkedIn. 1087 01:01:33,480 --> 01:01:38,040 So on on LinkedIn I post more shorter things and on the blog I 1088 01:01:38,200 --> 01:01:41,880 sometimes post longer things. And yeah, I share my thoughts 1089 01:01:41,880 --> 01:01:45,160 and I test some resonance because I'm also thinking of 1090 01:01:45,160 --> 01:01:48,320 maybe writing a book about this topic on one day. 1091 01:01:48,320 --> 01:01:52,920 So if you're interested in interdisciplinary topics and how 1092 01:01:52,920 --> 01:01:57,080 teams should or can work together, and feel free to 1093 01:01:57,080 --> 01:02:01,200 follow me there. And yeah, beyond that, I'd like 1094 01:02:01,200 --> 01:02:03,800 to invite everybody with listening to this podcast to 1095 01:02:04,040 --> 01:02:06,680 just connect with me. Also, on a personal level, I'm 1096 01:02:06,680 --> 01:02:10,640 very curious to hear how others are approaching their team set 1097 01:02:10,640 --> 01:02:14,200 up, how they are slicing their work, how they are creating 1098 01:02:14,200 --> 01:02:17,560 strategic alignment. Yeah, either if they have a 1099 01:02:17,640 --> 01:02:21,400 concrete challenge or just want to exchange ideas or just share 1100 01:02:21,760 --> 01:02:25,240 if they're maybe proud of their own approach, because such 1101 01:02:25,240 --> 01:02:28,560 conversations also help me to develop this topic further. 1102 01:02:29,160 --> 01:02:34,160 And yeah, in some rare cases, if I have time, I maybe can also 1103 01:02:34,160 --> 01:02:40,040 help hands on as an advisor or as an interim lead, but I don't 1104 01:02:40,040 --> 01:02:42,880 want to promise too much. But sometimes it's one thing 1105 01:02:42,880 --> 01:02:45,560 leads to another and I can help actually. 1106 01:02:46,400 --> 01:02:49,000 Yeah, out of curiosity, what is behind this name? 1107 01:02:49,000 --> 01:02:52,320 VO1 dot IO? It is quite unique I find. 1108 01:02:52,920 --> 01:02:58,400 Yeah, it's just this mindset of starting with the version 01, 1109 01:02:58,600 --> 01:03:02,200 like with the the first iteration of my blog basically. 1110 01:03:02,200 --> 01:03:06,400 And I have kept this mindset since my early days and at the 1111 01:03:06,400 --> 01:03:10,600 moment I think it's probably my 3rd or 4th iteration of the 1112 01:03:10,600 --> 01:03:12,440 block. But her name still sticks 1113 01:03:12,440 --> 01:03:16,920 because it's this mindset. Always create a version 0.1 and 1114 01:03:16,920 --> 01:03:20,720 then see how the resonance is and then continue from there. 1115 01:03:21,440 --> 01:03:23,440 Love that. So yeah, thanks for sharing. 1116 01:03:23,720 --> 01:03:25,800 Thank you so much for today's discussion, Klaus. 1117 01:03:25,800 --> 01:03:29,160 I hope people would learn a thing or two again about move 1118 01:03:29,160 --> 01:03:31,800 things break silos, right? Not break things, right? 1119 01:03:31,880 --> 01:03:33,400 Yes, move things, break silos.