1 00:00:00,040 --> 00:00:05,120 In the book, I use this concept of the five thieves of time that 2 00:00:05,120 --> 00:00:07,600 I think resonates with everybody, whether they're in 3 00:00:07,600 --> 00:00:11,840 technology or not. And these five thieves of time 4 00:00:11,840 --> 00:00:15,760 are related to too much work in progress, conflicting 5 00:00:15,760 --> 00:00:20,440 priorities, unplanned work, unknown dependencies, and 6 00:00:20,440 --> 00:00:26,320 neglected work or neglected WIP. And so most everybody has 7 00:00:26,320 --> 00:00:31,840 experienced all of those and are looking for ways to deal with 8 00:00:31,880 --> 00:00:40,520 that kind of time theft. Hey everyone, my name is Henry 9 00:00:40,520 --> 00:00:44,600 Surya Virawan and you're listening to the Technically 10 00:00:44,600 --> 00:00:47,840 Journal podcast, the show where I'll be bringing you the 11 00:00:47,840 --> 00:00:50,960 greatest technical leaders, practitioners and thought 12 00:00:50,960 --> 00:00:54,360 leaders in the industry to discuss about their journey, 13 00:00:54,640 --> 00:00:58,240 ideas and practices that we all can learn and apply. 14 00:00:58,840 --> 00:01:01,880 To build a highly performing technical team and to make an 15 00:01:01,880 --> 00:01:05,920 impact in your personal work. So let's dive into our journal. 16 00:01:11,040 --> 00:01:13,200 Hello to all of you, my friends, and my listeners. 17 00:01:13,320 --> 00:01:15,880 You are listening to the Technically Journal Podcast, the 18 00:01:15,880 --> 00:01:18,240 podcast where you can learn about technical leadership and 19 00:01:18,240 --> 00:01:21,480 excellence from my conversations with great thought leaders in 20 00:01:21,480 --> 00:01:24,640 the tech industry. If you haven't, please subscribe 21 00:01:24,640 --> 00:01:27,920 on your favorite podcast app to get notified for new episodes. 22 00:01:28,360 --> 00:01:30,440 Also, subscribe to Techlegional's various other 23 00:01:30,440 --> 00:01:34,960 contents on LinkedIn X, Instagram, YouTube, and Tiktok. 24 00:01:35,640 --> 00:01:38,920 And consider supporting this podcast by either buying me a 25 00:01:38,920 --> 00:01:43,200 coffee at techlegional dot dev tip or becoming a patron at 26 00:01:43,200 --> 00:01:47,880 techlegional dot dev patron. My guest for today's episode is 27 00:01:47,880 --> 00:01:51,520 Dominica de Grandis. Dominica is the author of one of 28 00:01:51,520 --> 00:01:54,240 my favorite books making work visible. 29 00:01:54,760 --> 00:01:57,880 In this episode we. We discussed how we can optimize 30 00:01:57,880 --> 00:02:01,440 our workflow and reclaim control of our work and time. 31 00:02:02,080 --> 00:02:06,120 Dominica unveiled the concept of the Five Thieves of time that 32 00:02:06,120 --> 00:02:10,160 rob us of our productivity, which includes too much work in 33 00:02:10,160 --> 00:02:13,800 progress, conflicting priorities, unplanned work, 34 00:02:14,320 --> 00:02:16,760 unknown dependencies, and neglected work. 35 00:02:17,200 --> 00:02:20,480 She also shared actionable practices and tips on dealing 36 00:02:20,480 --> 00:02:24,320 with each of those five thieves. Towards the end, Dominica 37 00:02:24,320 --> 00:02:27,480 emphasized the importance of making work feasible within an 38 00:02:27,480 --> 00:02:30,560 organization and how to measure our flow of work. 39 00:02:31,320 --> 00:02:34,320 I hope you enjoy listening to this episode and getting to 40 00:02:34,320 --> 00:02:37,440 understand the different time thefts that I'm sure frustrate 41 00:02:37,440 --> 00:02:40,960 many of us in our daily work. If you enjoy listening to this 42 00:02:40,960 --> 00:02:44,520 episode, please do share it with your colleagues, your friends 43 00:02:44,560 --> 00:02:48,240 and communities and leave a five star rating and review on Apple 44 00:02:48,240 --> 00:02:51,720 Podcasts and Spotify. Your small help will help me a 45 00:02:51,720 --> 00:02:54,920 lot in getting more people to discover and listen to this 46 00:02:54,920 --> 00:02:56,960 podcast, and I really appreciate it. 47 00:02:57,480 --> 00:03:00,440 So let's now go to my conversation with Dominica after 48 00:03:00,440 --> 00:03:02,080 quick words. From our sponsor. 49 00:03:02,320 --> 00:03:05,200 Hey, a quick message for those of you who are listening to this 50 00:03:05,200 --> 00:03:08,560 episode on Spotify. I have a small favor to ask. 51 00:03:08,920 --> 00:03:12,320 Spotify now allows mobile users to rate podcasts. 52 00:03:12,760 --> 00:03:15,960 I would really appreciate it if you can take a quick pause to go 53 00:03:15,960 --> 00:03:18,760 to the Techni Journal podcast page and leave your favorite 54 00:03:18,760 --> 00:03:20,920 show your best rating on Spotify. 55 00:03:21,440 --> 00:03:24,040 It will help me a lot to get this podcast to reach more 56 00:03:24,040 --> 00:03:26,440 people on the platform. Thanks a lot. 57 00:03:29,040 --> 00:03:31,760 Hey everyone, welcome back to the new episode of the Techni 58 00:03:31,760 --> 00:03:33,400 Journal Podcast. I'm very excited. 59 00:03:33,400 --> 00:03:36,720 Today I have a guest that I have been admiring for a long time 60 00:03:36,760 --> 00:03:38,960 After reading her book, Make Work Visible. 61 00:03:39,480 --> 00:03:42,240 Her name is Dominica de Grandes. So, Dominica, thank you so much 62 00:03:42,280 --> 00:03:43,880 for your time. Looking forward to our 63 00:03:43,880 --> 00:03:46,480 discussion today. Delighted to be here Henry. 64 00:03:46,480 --> 00:03:49,640 Thank you. Yeah, Dominica, if I may ask you 65 00:03:49,640 --> 00:03:52,480 in the beginning to share maybe your career journey, any 66 00:03:52,480 --> 00:03:55,240 highlights or turning points that we all can learn from? 67 00:03:55,800 --> 00:03:58,480 All right. Well, my first job out of 68 00:03:58,480 --> 00:04:01,360 university was at Boeing Airlines. 69 00:04:01,480 --> 00:04:07,400 It's a very large company and I felt I was very ill prepared. 70 00:04:07,400 --> 00:04:11,040 I didn't know what to expect based on the courses that I'd 71 00:04:11,040 --> 00:04:15,280 taken at school, so I had a lot of learning to do really 72 00:04:15,280 --> 00:04:18,360 quickly, mostly about configuration management. 73 00:04:18,519 --> 00:04:21,120 That was what I did for many years, software configuration 74 00:04:21,120 --> 00:04:25,280 management, just building decoder rings so people could 75 00:04:25,280 --> 00:04:29,480 understand what version of what file was in what environment and 76 00:04:29,760 --> 00:04:32,520 on and on. And that was quite a big problem 77 00:04:32,720 --> 00:04:36,120 for many years. So there was a opportunity to 78 00:04:36,120 --> 00:04:41,320 provide value in that space. And then I went on to work for a 79 00:04:41,320 --> 00:04:47,880 variety of different companies from big telecom to startups and 80 00:04:48,320 --> 00:04:51,480 doing software configuration management, build management, 81 00:04:51,480 --> 00:04:54,640 release management, deployment automation. 82 00:04:54,800 --> 00:05:00,120 And then probably a real turning point in my career was in around 83 00:05:00,320 --> 00:05:06,440 2005, 2006, 2007, I was working at Corbis, which was Bill Gates 84 00:05:06,440 --> 00:05:11,760 other company in Seattle outside of Microsoft and we started 85 00:05:11,760 --> 00:05:15,600 implementing Kanban and it was supposedly the first 86 00:05:15,600 --> 00:05:20,520 implementation of Kanban in the US for engineering and software 87 00:05:20,520 --> 00:05:25,280 development. I was so excited about this way 88 00:05:25,280 --> 00:05:29,560 of working. I never really did Scrum. 89 00:05:29,840 --> 00:05:33,160 We went sort of straight from waterfall to this pull system 90 00:05:33,160 --> 00:05:37,920 that was Kanban and where I had to learn how to start capturing 91 00:05:37,920 --> 00:05:42,480 meaningful metrics and present those metrics to my peers and 92 00:05:42,480 --> 00:05:46,280 and leadership. And it was a really pivotal time 93 00:05:46,480 --> 00:05:50,200 in my career where I had to learn how to speak in front of 94 00:05:50,200 --> 00:05:54,400 people and present data. And it really did blow me away 95 00:05:54,520 --> 00:05:59,480 because I got budget and headcount and empathy from other 96 00:05:59,480 --> 00:06:01,840 teams. It was a great learning lesson, 97 00:06:01,840 --> 00:06:06,080 even though I was terrified to get up and speak in front of 98 00:06:06,080 --> 00:06:10,000 many other people. But very good learning lesson 99 00:06:10,040 --> 00:06:13,440 that really laid the foundation for the work that I was going to 100 00:06:13,440 --> 00:06:18,160 do later on, which was going more into helping other 101 00:06:18,160 --> 00:06:24,600 organizations understand Kanban and flow and pull systems. 102 00:06:24,840 --> 00:06:27,560 And why too much work in progress is a problem. 103 00:06:27,760 --> 00:06:33,520 And how to collect and measure flow metrics, interpret them and 104 00:06:33,520 --> 00:06:36,080 help other companies do that too. 105 00:06:36,520 --> 00:06:40,080 And that's really carried me on to where I am today, you know, 106 00:06:40,200 --> 00:06:43,280 from there, I was independent for a number of years. 107 00:06:43,280 --> 00:06:47,880 I used to travel a lot and do workshops primarily for IT OPS 108 00:06:47,880 --> 00:06:50,960 and then later dev OPS and I got very involved in the dev OPS 109 00:06:51,120 --> 00:06:53,040 community. I was just happened to be in the 110 00:06:53,040 --> 00:06:56,360 right place at the right time. So I was just kind of lucky to 111 00:06:56,400 --> 00:07:00,880 meet all these great luminaries of the dev OPS community and 112 00:07:00,880 --> 00:07:06,120 teach them Kanban and be able to help out the practitioners 113 00:07:06,520 --> 00:07:10,840 working in the trenches who were really suffering from being 114 00:07:10,840 --> 00:07:14,520 overloaded and too much cognitive load, too many 115 00:07:14,520 --> 00:07:19,720 conflicting priorities, too many dependencies that were invisible 116 00:07:19,720 --> 00:07:22,880 and became blockers. And then through the whole 117 00:07:23,080 --> 00:07:26,920 continuous improvement and delivery and deployment 118 00:07:26,920 --> 00:07:30,680 automation. So my role, which I had done 119 00:07:30,680 --> 00:07:34,600 most of my career, was shifted rather rapidly after that 120 00:07:34,760 --> 00:07:39,680 because the pipeline was mostly automated, so we didn't spend as 121 00:07:39,680 --> 00:07:42,880 much time having to worry about doing database restores from 122 00:07:43,120 --> 00:07:47,120 production and making sure that every environment was set up 123 00:07:47,120 --> 00:07:51,240 with identical software. That became less of an issue, 124 00:07:51,600 --> 00:07:56,600 and I kind of worked my way out of that job and moved more into 125 00:07:57,280 --> 00:08:01,040 help setting people up for success in that journey and that 126 00:08:01,040 --> 00:08:05,040 sort of transformational journey looking at entire value streams 127 00:08:05,040 --> 00:08:08,720 now instead of just individual team metrics. 128 00:08:09,480 --> 00:08:10,800 Thank you for sharing your story. 129 00:08:10,800 --> 00:08:13,800 I think it's really interesting how you got into Kanban, right. 130 00:08:13,920 --> 00:08:16,560 I think today we are going to cover some of the important 131 00:08:16,560 --> 00:08:19,280 topics you just mentioned. You know, things about flow, 132 00:08:19,280 --> 00:08:22,920 Kanban, flow metrics, how to help people so that they don't 133 00:08:22,920 --> 00:08:25,840 get overloaded with high cognitive load and things like 134 00:08:25,840 --> 00:08:28,520 that. So I think for your book, I mean 135 00:08:28,520 --> 00:08:30,800 if people haven't read it before, right. 136 00:08:30,800 --> 00:08:34,039 So I think the book is really, really how to make your kind of 137 00:08:34,039 --> 00:08:37,640 like all these tasks work is visible, right, So that we can 138 00:08:37,640 --> 00:08:41,480 actually see what kind of problems that we have and try to 139 00:08:41,480 --> 00:08:44,760 optimize how we can finish all the tasks, right. 140 00:08:45,160 --> 00:08:47,920 The first thing is, I think you cover in the book the background 141 00:08:47,920 --> 00:08:50,480 of the story you wrote. This book is because people now 142 00:08:50,480 --> 00:08:54,520 seems to have too many things to do, like we have everything to 143 00:08:54,520 --> 00:08:57,200 do, but we have. Very little time to finish it. 144 00:08:57,560 --> 00:09:00,920 So maybe in the beginning, can you tell us the background of 145 00:09:01,000 --> 00:09:04,880 how do you envision this book helping people to make their 146 00:09:04,880 --> 00:09:06,720 work more visible? Yeah. 147 00:09:07,360 --> 00:09:11,840 Well, in the book I use this concept of the five these of 148 00:09:11,840 --> 00:09:15,760 time that I think resonates with everybody, whether they're in 149 00:09:15,760 --> 00:09:20,000 technology or not. And these five thieves of time 150 00:09:20,000 --> 00:09:23,920 are related to too much work in progress, conflicting 151 00:09:23,920 --> 00:09:28,560 priorities, unplanned work, unknown dependencies and 152 00:09:28,560 --> 00:09:34,440 neglected work or neglected WIP. And so most everybody has 153 00:09:34,440 --> 00:09:39,880 experienced all of those and are looking for ways to deal with 154 00:09:39,880 --> 00:09:45,400 that kind of time theft. So the part one and Part 2 sort 155 00:09:45,400 --> 00:09:51,120 of introduce these concepts. Identify how you can see that 156 00:09:51,120 --> 00:09:53,880 this is happening in your organization. 157 00:09:54,200 --> 00:09:57,160 And then Part 2 talks about what to do about it. 158 00:09:57,720 --> 00:10:01,480 And there are exercises. Especially in the second edition 159 00:10:01,480 --> 00:10:04,240 of the book we added more exercises. 160 00:10:04,520 --> 00:10:09,760 I like to make things provide a lot of utility for the readers 161 00:10:10,000 --> 00:10:15,880 so that they can do exercises to practice exposing and bringing 162 00:10:16,400 --> 00:10:21,320 these time thieves out into the open and collecting data around 163 00:10:21,400 --> 00:10:25,240 these issues. Because I think that's when you 164 00:10:25,240 --> 00:10:29,320 can start to have the really good conversations, when you can 165 00:10:29,480 --> 00:10:34,080 start seeing, yeah, how much WHIP do you have on our team has 166 00:10:34,080 --> 00:10:40,480 you know, 110 items just in the validate state, you know, and we 167 00:10:40,480 --> 00:10:42,280 only have five people on our team. 168 00:10:42,640 --> 00:10:47,160 So right there you can start to see and expose just how 169 00:10:47,160 --> 00:10:51,360 overloaded the teams are. And then when we look at the 170 00:10:51,360 --> 00:10:55,640 pain points, one of the most prominent exercises in the book 171 00:10:55,640 --> 00:11:01,000 is what I call a demand analysis where we have the teams identify 172 00:11:01,000 --> 00:11:03,400 what is the nature of their demand. 173 00:11:03,520 --> 00:11:05,680 Do they have a lot of unplanned work? 174 00:11:05,920 --> 00:11:10,760 Do they work primarily on technical debt or security? 175 00:11:11,000 --> 00:11:15,040 And then the second part of the exercise is identifying what 176 00:11:15,040 --> 00:11:18,880 prevents them from getting their work done, what randomizes their 177 00:11:18,880 --> 00:11:22,160 day. And then the third part is what 178 00:11:22,160 --> 00:11:25,280 do their customers grumble about? 179 00:11:25,600 --> 00:11:29,480 And we call that business pain? And when I'm using the term 180 00:11:29,480 --> 00:11:32,600 customer there, I'm talking about the internal customer, 181 00:11:32,600 --> 00:11:37,280 like their boss or the product manager, but somebody internal 182 00:11:37,280 --> 00:11:41,200 to the company who's making requests from them, what are 183 00:11:41,200 --> 00:11:45,600 they not so happy about? And we find that there's this 184 00:11:45,720 --> 00:11:51,480 correlation or almost this mirror of what causes pain for 185 00:11:51,480 --> 00:11:55,840 the team is correlated to what the customer is grumbling about. 186 00:11:56,160 --> 00:12:01,720 For example, if the customer is unhappy because things take too 187 00:12:01,720 --> 00:12:06,040 long, You know, we asked for this feature six months ago and 188 00:12:06,040 --> 00:12:09,240 we still don't have it. You know, it's taking too long. 189 00:12:09,240 --> 00:12:11,840 We need it already. We needed it six months ago. 190 00:12:12,280 --> 00:12:16,400 And if we look at the team pane side, it's because they have too 191 00:12:16,400 --> 00:12:19,360 much WIP. They're overloaded with so much 192 00:12:19,360 --> 00:12:24,600 WIP that it's taking them longer to deliver those feature 193 00:12:24,600 --> 00:12:27,480 requests. So they often mirror one 194 00:12:27,480 --> 00:12:30,920 another. And if people are complaining 195 00:12:30,920 --> 00:12:35,760 that things are taking too long, then it makes sense to clearly 196 00:12:35,760 --> 00:12:40,120 understand, to clearly measure how long things actually take. 197 00:12:40,360 --> 00:12:43,520 And so with there, then we get into the metrics which I cover 198 00:12:43,520 --> 00:12:48,520 in Part 3, how to measure your flow time, why it's important to 199 00:12:48,520 --> 00:12:51,200 measure that. So usually that will be an 200 00:12:51,200 --> 00:12:55,760 outcome of the demand analysis exercise is now that you've 201 00:12:55,760 --> 00:13:00,240 identified team pain and business pain, if everybody on 202 00:13:00,240 --> 00:13:03,520 your team had two votes, what would you vote on? 203 00:13:03,520 --> 00:13:07,800 What would provide the biggest return or improvement or 204 00:13:07,800 --> 00:13:11,560 increased morale and happiness if you could make a dent in this 205 00:13:11,560 --> 00:13:15,640 bit of a pain area, Yeah. So just sort of going through 206 00:13:15,640 --> 00:13:18,800 each time with EVE, with that, you know, identifying the 207 00:13:18,800 --> 00:13:24,560 problem, why it matters, exercises to dig into it deeper, 208 00:13:24,800 --> 00:13:29,480 ultimately leading to experiments that people can do 209 00:13:29,680 --> 00:13:32,600 to find their way through the challenges. 210 00:13:32,840 --> 00:13:37,040 I think that this work that we're doing really does require 211 00:13:37,040 --> 00:13:41,200 experimentation in many cases because we don't always know 212 00:13:41,200 --> 00:13:44,760 causality of a problem. You know, we don't always know 213 00:13:44,760 --> 00:13:49,960 cause and effect, and so when that occurs, we don't really 214 00:13:49,960 --> 00:13:52,800 have a best practice. We have a best practice. 215 00:13:52,800 --> 00:13:56,360 If we've done it before and we know why it happens, then we can 216 00:13:56,360 --> 00:13:59,400 have a playbook for that. But if the team is doing 217 00:13:59,400 --> 00:14:05,160 something new and novel and they haven't done it before, then I 218 00:14:05,160 --> 00:14:08,320 think experimentation is very powerful. 219 00:14:08,640 --> 00:14:14,280 And looking at the change curve and looking at the Kubler Ross 220 00:14:14,280 --> 00:14:17,080 change curve, the one that everybody's familiar with that 221 00:14:17,080 --> 00:14:19,960 was adapted from this grief model, but it's been made 222 00:14:19,960 --> 00:14:23,720 applicable for business. And so it goes to like shock, 223 00:14:23,720 --> 00:14:28,320 denial, frustration, depression, experiment, decision and then 224 00:14:28,320 --> 00:14:31,720 integration. And I think what's represented 225 00:14:31,720 --> 00:14:35,720 so well on that change curve is the turning point. 226 00:14:35,720 --> 00:14:40,160 And it's when experimentation starts happening because that's 227 00:14:40,160 --> 00:14:44,960 when people can start to take some ownership in what's going 228 00:14:44,960 --> 00:14:48,960 on in their world and all the change that's occurring and 229 00:14:48,960 --> 00:14:54,400 participate and come up with ideas for improvements and work 230 00:14:54,400 --> 00:14:58,040 to get buy in for experiments from stakeholders. 231 00:14:58,040 --> 00:15:01,760 I think that is very useful. Right. 232 00:15:02,360 --> 00:15:04,960 So I think if people haven't heard about WIP before, right, 233 00:15:04,960 --> 00:15:08,680 it stands for Work in Progress. This is one of the core thing in 234 00:15:08,680 --> 00:15:13,320 Lean and also in Kamban and also Dominica's book So the Five 235 00:15:13,320 --> 00:15:16,240 Thieves of Time. When I read them, I laughed 236 00:15:16,240 --> 00:15:18,520 because I can relate to all of them actually. 237 00:15:18,520 --> 00:15:21,600 So those are like too much work in progress, unknown 238 00:15:21,600 --> 00:15:25,200 dependencies, unplanned work, conflicting priorities and 239 00:15:25,200 --> 00:15:27,680 neglected work. I'm sure all the listeners here 240 00:15:27,680 --> 00:15:30,720 can also relate to them. Maybe let's just cover them one 241 00:15:30,720 --> 00:15:32,880 by one, right? So starting with too much WIP. 242 00:15:32,880 --> 00:15:36,000 You have mentioned this a few Times Now and in your book you 243 00:15:36,000 --> 00:15:38,480 mentioned this is like the ultimate ringleader. 244 00:15:38,480 --> 00:15:41,320 You know if your if your analogy is a thief, right? 245 00:15:41,320 --> 00:15:43,160 This is like the thief of all thieves. 246 00:15:43,400 --> 00:15:45,840 So tell us more. What is too much WIP? 247 00:15:46,680 --> 00:15:49,760 Why is it a problem and what can we do about it? 248 00:15:50,520 --> 00:15:55,560 In textbook terms, too much WIP is when demand outweighs 249 00:15:55,560 --> 00:16:00,080 capacity, so you have too many requests than your team can 250 00:16:00,080 --> 00:16:04,040 handle, and it's a problem. And it's why it's the 251 00:16:04,040 --> 00:16:06,560 ringleader. For example, if you have 252 00:16:06,560 --> 00:16:11,640 unplanned work that disrupts your day, now you have to work 253 00:16:11,640 --> 00:16:14,600 on that in addition to all the planned work, right? 254 00:16:14,960 --> 00:16:19,280 So it creates more work in progress for the teams, and the 255 00:16:19,280 --> 00:16:23,000 more things that we try to juggle at the same time, the 256 00:16:23,000 --> 00:16:28,640 more scattered we are, the less time we can focus deeply on this 257 00:16:28,640 --> 00:16:32,920 one important item that we need to complete as soon as possible. 258 00:16:33,400 --> 00:16:36,280 WIP is a leading indicator, right? 259 00:16:36,280 --> 00:16:42,880 We know that, say, as soon as you commute home, if there's a 260 00:16:42,880 --> 00:16:46,960 lot of traffic on the roads, your commute is going to take 261 00:16:46,960 --> 00:16:49,560 longer. So it's the same thing with too 262 00:16:49,560 --> 00:16:54,800 much knowledge, work in play. The more WIP we have, the longer 263 00:16:54,800 --> 00:16:59,880 things take and the increase in cognitive load in our 264 00:16:59,880 --> 00:17:04,040 functioning, which can cause stress, cause all kinds of 265 00:17:04,040 --> 00:17:08,720 health issues and can lead to burnout and depression. 266 00:17:09,079 --> 00:17:13,440 So it's very important to try and limit the amount of work so 267 00:17:13,440 --> 00:17:16,720 that we can have higher quality on what we're delivering. 268 00:17:16,880 --> 00:17:21,800 That is going to provide more confidence in our ability to 269 00:17:21,800 --> 00:17:26,400 deliver high quality things when our customers are expecting 270 00:17:26,400 --> 00:17:28,680 them. But we find more and more that 271 00:17:28,680 --> 00:17:32,520 that's a rare scenario because we have a hard time saying no, 272 00:17:32,720 --> 00:17:35,800 that we're human. And so we want to say yes, yes, 273 00:17:35,800 --> 00:17:37,840 I can do that. Yes, I can do that. 274 00:17:38,120 --> 00:17:42,320 And there's many reasons why we say yes when we probably really 275 00:17:42,320 --> 00:17:45,960 ought to say no. If we say yes to everything, 276 00:17:46,080 --> 00:17:50,760 then we can't deliver our most important yes, if that makes 277 00:17:50,880 --> 00:17:55,000 sense to you. So I think it's really essential 278 00:17:55,200 --> 00:17:59,800 that we get really brutally honest about what is the one 279 00:17:59,800 --> 00:18:04,600 most important thing to get done today, or at least to get to a 280 00:18:04,600 --> 00:18:08,880 nice stopping point so that we can make progress on that. 281 00:18:09,320 --> 00:18:15,240 We have to ruthlessly protect our time so that we can complete 282 00:18:15,240 --> 00:18:18,880 our most important work, which is really hard to do if we just 283 00:18:18,880 --> 00:18:21,680 have too much demand, too much stuff on our plates. 284 00:18:22,120 --> 00:18:25,480 But I think the nature of wanting to be helpful and 285 00:18:25,480 --> 00:18:28,200 wanting to be valuable to our teammates and to our 286 00:18:28,200 --> 00:18:33,080 organization, we end up saying yes more than we should. 287 00:18:34,080 --> 00:18:37,200 So I think this, when you say it's a leading indicator, right. 288 00:18:37,200 --> 00:18:41,240 So I think people just need to, you know, understand the concept 289 00:18:41,240 --> 00:18:43,960 of cycle time and WIP and throughput, right. 290 00:18:44,280 --> 00:18:47,560 Maybe if you can go through, you know why Too much WIP actually 291 00:18:47,560 --> 00:18:50,120 is a leading indicator. Yeah. 292 00:18:50,320 --> 00:18:53,640 So people always say, well, what should our WIP be? 293 00:18:54,120 --> 00:18:56,280 Usually the answer to that is lower. 294 00:18:56,400 --> 00:19:01,760 You know 100 is better than 110, but there is an equation that we 295 00:19:01,760 --> 00:19:06,080 can use to have this conversation and it's called 296 00:19:06,080 --> 00:19:09,240 Little's law and it's based on averages. 297 00:19:09,480 --> 00:19:13,760 And it's where your average flow time or cycle time equals your 298 00:19:13,760 --> 00:19:17,120 average web over your average throughput, your throughput 299 00:19:17,120 --> 00:19:20,600 being the number of items completed over a period of time. 300 00:19:21,040 --> 00:19:24,600 And when we look at the math, because WIP, your work in 301 00:19:24,600 --> 00:19:27,520 progress is the numerator in the equation. 302 00:19:27,920 --> 00:19:31,440 As soon as that WIP increases, we know that it's going to 303 00:19:31,440 --> 00:19:35,080 extend your lead time cycle time, flow time, whatever you're 304 00:19:35,080 --> 00:19:38,240 using as long as the assumptions are in place. 305 00:19:38,240 --> 00:19:40,240 There are some assumptions in that law. 306 00:19:40,600 --> 00:19:42,920 You know you have to have a stable system. 307 00:19:42,920 --> 00:19:47,720 Your WIP needs to remain fairly relative and the, you know, you 308 00:19:47,720 --> 00:19:50,800 shouldn't have cancelled work, that kind of thing, all all 309 00:19:50,800 --> 00:19:54,520 things that everybody has. But that conversation alone and 310 00:19:54,520 --> 00:19:58,520 looking at that math, I can show you why this is so important and 311 00:19:58,520 --> 00:20:02,920 why it's a leading indicator. Leading because WIP is partially 312 00:20:02,920 --> 00:20:06,360 completed work. We've started it, but it's not 313 00:20:06,360 --> 00:20:09,520 done yet. Most of all the other metrics 314 00:20:09,840 --> 00:20:11,840 are based on work that's completed. 315 00:20:12,000 --> 00:20:16,600 You know, throughput, flow time, flow efficiency, those metrics 316 00:20:16,600 --> 00:20:19,120 are all based on work that's already completed. 317 00:20:19,560 --> 00:20:24,040 But your WIP metric, which we call flow load is work that's in 318 00:20:24,040 --> 00:20:26,160 progress. So that's why it's considered a 319 00:20:26,160 --> 00:20:30,880 leading indicator and so powerful to use because you can 320 00:20:30,880 --> 00:20:36,280 look at it right now and have it spark a conversation about what 321 00:20:36,280 --> 00:20:41,400 do we need to delay for now because most they'll have their 322 00:20:41,400 --> 00:20:43,640 planned work. Can we talk about unplanned work 323 00:20:43,640 --> 00:20:46,800 now? It's yeah, because they'll be 324 00:20:46,800 --> 00:20:50,080 working on their planned work and usually they're allocated 325 00:20:50,080 --> 00:20:52,840 100% right to work on this planned work. 326 00:20:53,160 --> 00:20:58,600 But then priorities change and or unplanned work hits them and 327 00:20:58,600 --> 00:21:00,280 now they have to stop what they're doing. 328 00:21:00,680 --> 00:21:04,720 They have to stop their planned work, context switch, pick up 329 00:21:04,720 --> 00:21:10,040 the unplanned work, work on that context switch, get back to the 330 00:21:10,080 --> 00:21:13,600 planned work. It's like being at their grocery 331 00:21:13,600 --> 00:21:17,480 store and somebody jumps the queue in front of you, right? 332 00:21:17,480 --> 00:21:20,040 You're at the checkout line, ready to go next, and somebody 333 00:21:20,040 --> 00:21:23,120 cuts in front and then they check out because they have the 334 00:21:23,120 --> 00:21:29,360 urgent need to get through fast. What happens with that unplanned 335 00:21:29,360 --> 00:21:32,520 work now is that the work that you are going to get through 336 00:21:32,520 --> 00:21:36,920 checkout faster, but now your checkout time is going to be 337 00:21:36,920 --> 00:21:39,640 longer because of this unplanned work. 338 00:21:40,120 --> 00:21:43,760 So I think that one of the exercises is identifying what is 339 00:21:43,760 --> 00:21:48,200 the criteria for unplanned work and be really clear on that. 340 00:21:48,480 --> 00:21:52,520 Sometimes teams will want to Group A lot of different things 341 00:21:52,520 --> 00:21:54,520 into the unplanned work category. 342 00:21:55,000 --> 00:22:00,440 But I think it's important to be really clear, could you have 343 00:22:00,440 --> 00:22:03,760 anticipated that? Could you have anticipated this 344 00:22:03,760 --> 00:22:07,680 audit was going to happen, you know, at least once this year, 345 00:22:08,000 --> 00:22:11,440 things like that. So that's sort of the just as a 346 00:22:11,440 --> 00:22:16,080 circle back on the relationship between WIP throughput and flow 347 00:22:16,080 --> 00:22:19,960 time or your cycle time. I'm using flow time and cycle 348 00:22:19,960 --> 00:22:23,600 time interchangeably. We're talking about just 349 00:22:23,600 --> 00:22:26,840 tracking how long things take from beginning to end. 350 00:22:27,240 --> 00:22:31,360 And for flow time, that's the conversation that needs to occur 351 00:22:31,360 --> 00:22:35,880 is when does the clock start and when does the clock stop, right? 352 00:22:36,720 --> 00:22:39,640 Yeah, so speaking about unplanned work, I'm sure these 353 00:22:39,640 --> 00:22:42,680 days in software engineering team, right, they can relate to 354 00:22:42,680 --> 00:22:45,880 things like for example if there's a customer complaints, 355 00:22:45,880 --> 00:22:49,880 incidents, right, downtime or whatever that is, or sometimes 356 00:22:49,880 --> 00:22:52,640 it's just bugs, right? Like you work on something or 357 00:22:52,640 --> 00:22:56,120 actually it caused a bug, right. This is what you categorize as 358 00:22:56,120 --> 00:22:58,720 rework. So something urgent you need to 359 00:22:58,720 --> 00:23:01,760 fix it and things like that. And it actually creates a lot of 360 00:23:01,760 --> 00:23:03,920 unpredictable workload for the team. 361 00:23:04,400 --> 00:23:07,360 So if we go back to the too much work in progress kind of a 362 00:23:07,360 --> 00:23:09,760 problem, right? I think it's granted like almost 363 00:23:09,760 --> 00:23:13,000 every team now is you know a burden by a lot of these tasks. 364 00:23:13,200 --> 00:23:15,680 And some of the solutions actually are things like for 365 00:23:15,680 --> 00:23:19,000 example, you set up a come button, make it like a pull 366 00:23:19,000 --> 00:23:21,640 system and also limit your work in progress. 367 00:23:21,920 --> 00:23:24,720 So tell us a little bit more how we can, you know, make sense 368 00:23:24,720 --> 00:23:27,800 about our web and and kind of like solve this problem. 369 00:23:28,200 --> 00:23:32,360 Yeah, a number of ways. One of my favourite and useful 370 00:23:32,360 --> 00:23:37,400 ways is to look at the rate of arrival of work and the rate of 371 00:23:37,400 --> 00:23:40,880 departure. So the rate of departure has to 372 00:23:40,880 --> 00:23:44,680 do with looking at your throughput, how many items were 373 00:23:44,680 --> 00:23:49,640 delivered over a period of time, Understanding that that is the 374 00:23:49,720 --> 00:23:53,240 capacity of the team that they were able to deliver X number of 375 00:23:53,240 --> 00:23:57,080 things over this period of time. And you can combine that with 376 00:23:57,080 --> 00:24:01,080 the various different types of work features, bugs, technical 377 00:24:01,080 --> 00:24:03,320 debt, security. Or you could just look at those 378 00:24:03,400 --> 00:24:06,560 individually. But the idea is to understand 379 00:24:06,560 --> 00:24:11,240 this departure rate determines arrival rate. 380 00:24:11,600 --> 00:24:18,120 Departure rate of completing work is going to determine what 381 00:24:18,120 --> 00:24:23,080 the arrival rate, what your WIP limit should be and when we do, 382 00:24:23,080 --> 00:24:28,920 will have capacity to pull more work into our workflow because 383 00:24:28,920 --> 00:24:32,440 we finished work. And this stems from ARN Rook's 384 00:24:32,480 --> 00:24:37,000 work and his famous quote about the stop starting and start 385 00:24:37,000 --> 00:24:38,600 finishing. Yeah. 386 00:24:39,160 --> 00:24:42,640 So the concept of limiting work in progress, right, how can we 387 00:24:42,640 --> 00:24:44,680 use that? Because I think that's one of 388 00:24:44,680 --> 00:24:47,560 the key probably for leaders, especially for managers or 389 00:24:47,560 --> 00:24:50,880 leaders, right, in order to actually manage their work. 390 00:24:50,880 --> 00:24:54,360 So you mentioned about rate of delivery and rate of arrival, 391 00:24:54,360 --> 00:24:56,720 right. So when the arrival is getting 392 00:24:56,720 --> 00:25:00,280 too many, right, how can we manage them by limiting our work 393 00:25:00,280 --> 00:25:02,080 in progress. Yeah, yeah. 394 00:25:02,280 --> 00:25:07,280 This is we're having a crystal clear prioritization policy and 395 00:25:07,280 --> 00:25:10,120 process in place is going to help. 396 00:25:10,400 --> 00:25:15,440 It's we're having psychological safety and a generative culture 397 00:25:15,680 --> 00:25:21,760 comes into play so that people can be OK with knowing when they 398 00:25:21,760 --> 00:25:25,800 have to say, actually we don't have capacity for that right now 399 00:25:25,920 --> 00:25:30,120 or say, oh, OK, this is now the number one priority. 400 00:25:30,200 --> 00:25:33,400 This is when yesterday's is #1. Priority is not today's number 401 00:25:33,400 --> 00:25:36,680 one priority because priorities change and we need to be able to 402 00:25:36,680 --> 00:25:40,400 adapt to that. But when that happens, we need 403 00:25:40,400 --> 00:25:44,760 to give people permission to say, you know, hold on, we have 404 00:25:44,760 --> 00:25:48,840 a new priority, one. That means something has to 405 00:25:48,840 --> 00:25:53,640 give, like we only have 100% for good or for bad. 406 00:25:53,680 --> 00:25:58,400 This is our current amount of capacity that our group has. 407 00:25:58,800 --> 00:26:02,880 So knowing that what should be the number one priority and what 408 00:26:02,880 --> 00:26:07,840 should we say no to. So when I worked at Corbis, the 409 00:26:07,840 --> 00:26:11,680 way that we solved this with executives in leadership was we 410 00:26:11,680 --> 00:26:15,160 told them that well first we measured how long it took us. 411 00:26:15,160 --> 00:26:18,800 You know, basically we get to X number of features over a period 412 00:26:18,880 --> 00:26:24,880 of six weeks and we had a capacity for five of those like 413 00:26:24,880 --> 00:26:30,880 5 features and we put the decision on the leaders to 414 00:26:30,880 --> 00:26:34,280 prioritize that list. So there might have been 100 415 00:26:34,360 --> 00:26:38,160 requests in the backlog. And instead of all of those 416 00:26:38,160 --> 00:26:41,120 being thrown on the team and the team scrambling and trying to do 417 00:26:41,120 --> 00:26:45,800 all those and trying to prioritize them, we explained to 418 00:26:46,040 --> 00:26:51,360 leadership the idea about WIP limits and the team's capacity 419 00:26:51,640 --> 00:26:57,200 and said you got five spaces, we can have 5 feature requests on 420 00:26:57,200 --> 00:27:01,520 this team at a time. We would like you to decide on 421 00:27:01,520 --> 00:27:05,360 what those five things are and when we deliver one, there will 422 00:27:05,360 --> 00:27:08,720 be another opening. And when we first started this 423 00:27:08,720 --> 00:27:13,520 process, it was quite chaotic. And the leaders used to, you 424 00:27:13,520 --> 00:27:18,080 know, whoever yelled the loudest would usually get their way. 425 00:27:18,560 --> 00:27:22,760 But over time, it turned into more of a democratic approach. 426 00:27:22,760 --> 00:27:25,560 I voted for years last week. You need to vote for mine this 427 00:27:25,560 --> 00:27:27,280 week. They would meet once a week. 428 00:27:27,560 --> 00:27:30,400 You know, the head of marketing, the head of engineering, the 429 00:27:30,400 --> 00:27:32,840 head of sales would be in this room. 430 00:27:33,160 --> 00:27:36,920 And because the question was very simple, which item should 431 00:27:36,920 --> 00:27:40,280 we pull in next? They didn't have to delegate 432 00:27:40,280 --> 00:27:41,600 that. They didn't have to bring in 433 00:27:41,600 --> 00:27:45,720 their engineers to talk about details and provide estimates. 434 00:27:46,320 --> 00:27:50,720 We did away with estimates because the question to leaders 435 00:27:50,720 --> 00:27:56,320 became knowing that it takes us six weeks to deliver something. 436 00:27:56,320 --> 00:28:02,040 Once we start on it, which thing do you want us to deliver next? 437 00:28:02,240 --> 00:28:06,840 So it was a very simple question that leaders could then ponder 438 00:28:06,840 --> 00:28:09,480 and think about. And first it was arguing that it 439 00:28:09,480 --> 00:28:13,720 was democratic decision. And then over time it turned 440 00:28:13,720 --> 00:28:19,600 into a analysis of the business case, what makes the most sense, 441 00:28:19,600 --> 00:28:24,200 what is the highest value for our company to deliver in six 442 00:28:24,200 --> 00:28:27,800 weeks for our customers. So we simplified a lot. 443 00:28:27,800 --> 00:28:32,360 So we reduced the time that had been spent on estimation by 444 00:28:32,360 --> 00:28:37,480 having our customers prioritize that work based on data that we 445 00:28:37,480 --> 00:28:41,080 provided them on our cycle time, on our flow time. 446 00:28:42,000 --> 00:28:44,280 Thanks for covering this conflicting priorities, right? 447 00:28:44,280 --> 00:28:47,280 Because prioritization probably is one of the root cause of too 448 00:28:47,280 --> 00:28:50,600 much work in progress, right? Because like like you mentioned, 449 00:28:50,600 --> 00:28:53,160 like I think it's typical in most of the companies, right, 450 00:28:53,160 --> 00:28:56,080 leaders have their own objectives and they just throw 451 00:28:56,080 --> 00:28:58,960 it to the team, but they actually don't get visibility of 452 00:28:58,960 --> 00:29:02,040 the team, probably struggling on how to prioritize, you know, the 453 00:29:02,040 --> 00:29:05,680 upcoming tasks to them, right? And I think what you mentioned 454 00:29:05,680 --> 00:29:09,760 is very important that leaders should clearly identify which 455 00:29:09,760 --> 00:29:12,360 one is the most priority, right? Because all cannot be the 456 00:29:12,360 --> 00:29:14,760 priority. And if we have to choose one by 457 00:29:14,760 --> 00:29:16,920 one sequentially, what would that be, right. 458 00:29:17,560 --> 00:29:20,920 So maybe we have covered the three of the thieves of time, 459 00:29:20,920 --> 00:29:22,640 right. So the too much WIP, the 460 00:29:22,720 --> 00:29:26,320 unplanned work and conflicting priorities just now let's move 461 00:29:26,320 --> 00:29:29,720 to the next one, which I find it is also tricky managing 462 00:29:29,720 --> 00:29:31,720 dependencies, right. So what do you call unknown 463 00:29:31,720 --> 00:29:33,640 dependencies? Sometimes work. 464 00:29:33,720 --> 00:29:35,800 You know you can't finish just by yourself, right? 465 00:29:35,800 --> 00:29:38,440 You need to collaborate. Maybe you need to rely on third 466 00:29:38,440 --> 00:29:40,480 parties and things like that, right? 467 00:29:40,880 --> 00:29:43,320 So how can we tackle this problem? 468 00:29:43,320 --> 00:29:45,720 First of all, like, maybe sometimes we don't know we have 469 00:29:45,720 --> 00:29:47,800 dependencies. Or sometimes, if we do know 470 00:29:47,800 --> 00:29:49,560 dependencies, how do we manage them? 471 00:29:50,080 --> 00:29:53,760 Yeah, my thoughts on dependencies have altered a bit 472 00:29:54,200 --> 00:29:56,200 because there's different kinds of dependencies. 473 00:29:56,440 --> 00:29:59,360 Dependencies in many ways are just prerequisites. 474 00:29:59,920 --> 00:30:03,080 You know, A has to happen before B happens, and A is done by a 475 00:30:03,080 --> 00:30:05,280 different team and their priorities different than our 476 00:30:05,280 --> 00:30:08,200 priority. So scheduling and all of that is 477 00:30:08,200 --> 00:30:10,920 a problem. But the real issue is when 478 00:30:10,920 --> 00:30:17,120 there's a blocker, what is blocking our capability to 479 00:30:17,120 --> 00:30:23,000 deliver these items within the expected time frame? 480 00:30:23,240 --> 00:30:29,280 And it's those blockers that we need to bring visibility to and 481 00:30:29,760 --> 00:30:35,640 find a way to reduce the cost. Maybe it doesn't make sense to 482 00:30:35,640 --> 00:30:39,720 have every skill set on every team just because there are 483 00:30:39,720 --> 00:30:42,640 prerequisites for them in the book. 484 00:30:42,640 --> 00:30:47,440 I do have some exercises and a dependency matrix, but my 485 00:30:47,440 --> 00:30:52,080 thinking now more is to try and really get a handle on the 486 00:30:52,120 --> 00:30:56,160 expensive blockers and understanding the cost of delay 487 00:30:56,600 --> 00:31:02,840 of having this critical element blocked and then using, say the 488 00:31:02,840 --> 00:31:08,240 theory of constraints to reduce the risk of costly blockers. 489 00:31:08,520 --> 00:31:12,600 Most people right away they want to say we need to hire more 490 00:31:12,600 --> 00:31:16,640 people, we need more people on the team, which is a valid 491 00:31:16,680 --> 00:31:20,280 approach, but it's usually the last thing that we would look 492 00:31:20,280 --> 00:31:23,840 for, right? Because how long does it take to 493 00:31:23,840 --> 00:31:27,080 onboard an engineer in your department? 494 00:31:27,520 --> 00:31:30,520 People will say six months to a year when I ask them that 495 00:31:30,720 --> 00:31:34,520 because it's not just getting them up to speed, but it's the 496 00:31:34,520 --> 00:31:37,720 onboarding, it's the interviewing, all the resume 497 00:31:37,760 --> 00:31:41,240 hunting. It can be very costly to onboard 498 00:31:41,240 --> 00:31:44,680 new talent. And so before we go down that 499 00:31:44,680 --> 00:31:51,320 path, let's look at how to take an essential work off of the 500 00:31:51,320 --> 00:31:53,960 bottlenecks plate. Right. 501 00:31:53,960 --> 00:31:56,720 Here's where we talk about bottlenecks with blockers. 502 00:31:57,040 --> 00:32:01,720 How can we find help for that bottlenecked area? 503 00:32:02,040 --> 00:32:06,920 How can we invest in new tools and processes to help that 504 00:32:06,920 --> 00:32:09,920 bottlenecked area? That's really what the Theory of 505 00:32:09,920 --> 00:32:14,440 Constraints is about, is finding these other ways that will 506 00:32:14,600 --> 00:32:20,920 unblock dependencies and blockers faster than trying to 507 00:32:20,920 --> 00:32:24,800 hire new talent. That could take 6 to 12 months. 508 00:32:25,280 --> 00:32:28,440 Yeah, I think, yeah, what you mentioned about hiring people or 509 00:32:28,440 --> 00:32:30,000 even find outsourcing team, right. 510 00:32:30,000 --> 00:32:32,760 It's kind of like common when we see that the team maybe cannot 511 00:32:32,760 --> 00:32:34,960 deliver fast, yeah, we just tend to. 512 00:32:35,440 --> 00:32:37,920 Go to the easy solution, seems to easy, right? 513 00:32:37,920 --> 00:32:40,360 But what you mentioned is actually really expensive, you 514 00:32:40,480 --> 00:32:43,560 know, onboarding interviews, getting them up to speed and 515 00:32:43,560 --> 00:32:46,160 things like that. So also dependencies, right? 516 00:32:46,160 --> 00:32:49,480 Sometimes you know it's caused by the organization structure, 517 00:32:49,480 --> 00:32:52,440 you know, this Conway's law communication pattern and things 518 00:32:52,440 --> 00:32:54,240 like that. I mean, I just want to highlight 519 00:32:54,240 --> 00:32:55,720 one quote that you put in the book. 520 00:32:56,200 --> 00:32:59,720 So every dependency double S your chance of being delayed or 521 00:32:59,720 --> 00:33:01,240 late. So I think this is really 522 00:33:01,240 --> 00:33:05,000 important because sometimes leaders don't see the impact of 523 00:33:05,000 --> 00:33:07,360 dependencies in the team or maybe the organization 524 00:33:07,360 --> 00:33:09,480 structure. Maybe from your experience, 525 00:33:09,480 --> 00:33:10,920 anything you want to cover on that? 526 00:33:11,640 --> 00:33:16,360 Yeah, that quote actually came from Troy Mcgannis, whose work I 527 00:33:16,360 --> 00:33:20,200 borrowed heavily on when I talk about dependencies and blockers 528 00:33:20,200 --> 00:33:23,960 and bottlenecks. And the story behind that one 529 00:33:23,960 --> 00:33:28,560 is, imagine that you're going out to dinner at a fine dining 530 00:33:28,560 --> 00:33:31,960 restaurant and you're meeting three other people there. 531 00:33:32,160 --> 00:33:35,000 Well, what is the probability the fine dining where they won't 532 00:33:35,000 --> 00:33:38,200 see you until everybody arrives and only then you get to your 533 00:33:38,200 --> 00:33:40,800 table? What is the probability of being 534 00:33:40,840 --> 00:33:45,560 seated on time when there's four people involved that are on 535 00:33:45,560 --> 00:33:48,400 different teams or coming from different locations? 536 00:33:48,800 --> 00:33:52,960 And it's really quite low because of the probabilities. 537 00:33:52,960 --> 00:33:56,960 You know, you could be on time, but I'm late and the two other 538 00:33:56,960 --> 00:34:00,280 people are late, or I'm on time but you're late and the other 539 00:34:00,280 --> 00:34:04,520 two people, you know, there's like 8 different scenarios that 540 00:34:04,520 --> 00:34:07,640 could occur. And so every time you add an 541 00:34:07,640 --> 00:34:12,639 additional dependency to that list, it just double S the 542 00:34:12,639 --> 00:34:15,719 probability that you're going to be that much later. 543 00:34:15,719 --> 00:34:19,800 So the number of blockers and dependencies impacts it and 544 00:34:19,800 --> 00:34:24,080 that's why, you know, like Team Topology is such a popular book 545 00:34:24,239 --> 00:34:27,960 where they talk about organization structure and sort 546 00:34:27,960 --> 00:34:31,560 of what to do about that. And you mentioned Conway's Law. 547 00:34:31,719 --> 00:34:35,840 You know for those on listening Conway's Law as how a system 548 00:34:35,840 --> 00:34:38,440 design will mirror the communication structures of the 549 00:34:38,440 --> 00:34:41,199 organization which designs it, right. 550 00:34:41,239 --> 00:34:47,400 And so if we're looking at individual teams, optimizing at 551 00:34:47,400 --> 00:34:51,679 the team level, a group that's organized that way and that is 552 00:34:51,679 --> 00:34:55,679 focused just on their silo. It's unlikely that they're going 553 00:34:55,679 --> 00:34:58,760 to follow practices that are well optimized for optimization 554 00:34:58,760 --> 00:35:02,440 of an end to end workflow, an end to end value stream, the 555 00:35:02,440 --> 00:35:06,240 goal of which is to deliver high level this value to the 556 00:35:06,240 --> 00:35:07,600 customer. Yeah. 557 00:35:07,960 --> 00:35:13,760 So I think that we need to be clear about what practices we're 558 00:35:13,760 --> 00:35:19,240 going to use for decisions and organization and how those 559 00:35:19,240 --> 00:35:22,400 groups are going to be measured because how people are measured 560 00:35:22,400 --> 00:35:26,120 within an organization effectively constrains the 561 00:35:26,120 --> 00:35:29,640 production of the metrics that they're going to implement. 562 00:35:30,120 --> 00:35:36,080 We want to make sure that how teams are measured are in line 563 00:35:36,320 --> 00:35:40,120 with the desired results of that organization. 564 00:35:40,600 --> 00:35:43,560 I don't know I could, I could go on on about how teams are 565 00:35:43,560 --> 00:35:47,960 measured and how it can negatively impact, You know, 566 00:35:47,960 --> 00:35:49,640 tell me how you're going to measure me and I'll tell you how 567 00:35:49,640 --> 00:35:53,200 I'm going to behave. And we need to be really careful 568 00:35:53,200 --> 00:35:55,520 about how we're measuring groups. 569 00:35:55,680 --> 00:35:59,040 But depending on how they're organized, we see this a lot. 570 00:35:59,200 --> 00:36:01,360 We have all these individual teams that have dependencies 571 00:36:01,360 --> 00:36:05,760 across each other, and each of those teams is measured for 572 00:36:05,760 --> 00:36:09,880 optimizing their slice of the value stream. 573 00:36:10,160 --> 00:36:14,960 Then we have conflicting goals and we wonder why it's so 574 00:36:14,960 --> 00:36:17,880 difficult to get something delivered on time. 575 00:36:18,520 --> 00:36:20,040 Right. I think that's a very important 576 00:36:20,040 --> 00:36:21,440 point you just brought up, right. 577 00:36:21,440 --> 00:36:25,720 So knowing like how the teams or the group of teams are measured, 578 00:36:25,720 --> 00:36:26,800 right? Because sometimes. 579 00:36:27,200 --> 00:36:30,760 They can optimize locally based on how they are measured, but 580 00:36:30,760 --> 00:36:33,800 systematically, right, or maybe holistically they're actually 581 00:36:33,800 --> 00:36:36,400 conflicting to each other. So I think that's also another 582 00:36:36,400 --> 00:36:37,880 important point you just brought up. 583 00:36:38,160 --> 00:36:41,120 So thanks for covering that for this unknown dependencies, the 584 00:36:41,120 --> 00:36:43,840 last one that we haven't covered is the neglected work. 585 00:36:43,960 --> 00:36:47,760 Some people call it, you know, work in progress that is delayed 586 00:36:47,760 --> 00:36:50,720 or maybe things that are just not or partially done right. 587 00:36:50,720 --> 00:36:52,120 Some people call it partially done. 588 00:36:52,520 --> 00:36:55,120 So tell us more. What is this neglected work? 589 00:36:55,120 --> 00:36:58,400 How can we tackle it? And how come it can cause a 590 00:36:58,560 --> 00:37:01,400 problem? Yeah, neglected work. 591 00:37:01,440 --> 00:37:04,920 It just doesn't get the love or the attention that it needs. 592 00:37:04,920 --> 00:37:08,360 It keeps getting deprioritized. And others, you know, jump the 593 00:37:08,360 --> 00:37:12,160 queue and cut in front of it. It's often really important 594 00:37:12,160 --> 00:37:14,400 work. If it doesn't get done, it will 595 00:37:14,400 --> 00:37:17,680 become urgent and then it will become unplanned. 596 00:37:17,680 --> 00:37:22,320 Work like technical debt is a good example of very important 597 00:37:22,320 --> 00:37:27,240 work that does need to be done. But because it's not an 598 00:37:27,240 --> 00:37:32,920 immediate emergency, it will often get, deprioritize or have 599 00:37:32,920 --> 00:37:37,960 a lower priority. And it also is waiting. 600 00:37:37,960 --> 00:37:41,440 It's gets stuck in the queue waiting to be done. 601 00:37:41,880 --> 00:37:46,720 It's like when work displaces other work, the neglected work, 602 00:37:46,720 --> 00:37:49,040 other new work comes in and gets a higher priority. 603 00:37:49,320 --> 00:37:52,400 It's like, have you heard, like robbing Peter to pay Paul? 604 00:37:52,960 --> 00:37:54,480 No, I haven't. OK. 605 00:37:54,680 --> 00:38:00,200 It's a term that we use to describe we're going to take 606 00:38:00,200 --> 00:38:04,880 away something from one person in order to get this other thing 607 00:38:04,880 --> 00:38:07,880 delivered. But we keep taking away from a 608 00:38:07,880 --> 00:38:12,680 very important resource and now because that work is important, 609 00:38:12,680 --> 00:38:16,400 it will eventually become very urgent to do. 610 00:38:16,520 --> 00:38:21,520 And now we add risk into our decision making process in 611 00:38:21,520 --> 00:38:25,800 delaying that work. So we call that neglected work 612 00:38:25,800 --> 00:38:30,480 and the longer it's neglected then when it does get delivered, 613 00:38:30,800 --> 00:38:35,240 it will increase our flow time. It'll take that much longer 614 00:38:35,240 --> 00:38:38,120 because it's been neglected and sitting in the queue and waiting 615 00:38:38,440 --> 00:38:41,400 for so long. So this neglected work 616 00:38:41,400 --> 00:38:47,040 contributes to us thinking that say we're measuring our cycle 617 00:38:47,040 --> 00:38:49,960 time and we're saying, hey, look, we're doing great. 618 00:38:49,960 --> 00:38:52,200 We're getting these things delivered in two and three 619 00:38:52,200 --> 00:38:54,400 weeks. But then the neglected work that 620 00:38:54,400 --> 00:38:57,960 was so important that kept getting neglected gets delivered 621 00:38:58,320 --> 00:39:02,040 and it took six months, say, to finally get that out. 622 00:39:02,040 --> 00:39:04,120 What does that do to your flow time now? 623 00:39:04,560 --> 00:39:10,360 It kicks your flow time way up. And so now it impacts your 624 00:39:10,360 --> 00:39:15,400 ability to be predictable. If we're looking to be more 625 00:39:15,400 --> 00:39:19,800 predictable and how long it takes to deliver things, the 626 00:39:19,800 --> 00:39:22,720 more neglected work we have in the system, the lower the 627 00:39:22,720 --> 00:39:25,400 probability is that we're going to be able to deliver. 628 00:39:25,400 --> 00:39:29,760 When we say we are neglected, WIP is like this hidden 629 00:39:29,920 --> 00:39:33,320 important time thief that we don't pay enough attention to 630 00:39:33,640 --> 00:39:36,480 because we think everything is going really well. 631 00:39:36,720 --> 00:39:39,960 And then we have some important neglected work that finally gets 632 00:39:39,960 --> 00:39:44,320 done and we realize, oh wow, that took much longer to do. 633 00:39:44,320 --> 00:39:46,680 And we have unhappy customers and leaders. 634 00:39:47,000 --> 00:39:51,320 It's sort of like we think we're here when we really should be 635 00:39:51,320 --> 00:39:53,600 here. I wish I could show you this 636 00:39:53,600 --> 00:39:56,640 cartoon. It's about like, you're here, 637 00:39:56,920 --> 00:40:00,640 but you thought you were here and we really should be here. 638 00:40:02,280 --> 00:40:05,680 Neglected work plays into that problem. 639 00:40:06,000 --> 00:40:09,680 Like where are we and where should we really be when it 640 00:40:09,680 --> 00:40:13,880 comes to how realistic we are with being predictable and when 641 00:40:13,880 --> 00:40:18,520 we're going to deliver requests? And neglected work just will 642 00:40:18,520 --> 00:40:23,080 blind side us to that because we we don't see it coming until it 643 00:40:23,080 --> 00:40:25,480 turns into an emergency sometimes. 644 00:40:26,280 --> 00:40:27,840 Yeah, yeah. So I think it's very important 645 00:40:27,840 --> 00:40:30,000 to understand this quadrant, important, urgent, right. 646 00:40:30,000 --> 00:40:32,440 Neglected was probably so like an important thing, but 647 00:40:32,440 --> 00:40:35,080 sometimes not urgent. And it's always important for us 648 00:40:35,080 --> 00:40:38,760 to analyse and make sure that we erase, you know, the urgency or 649 00:40:38,760 --> 00:40:40,760 the priorities for the team to work on. 650 00:40:41,320 --> 00:40:45,000 Yeah, just one more .1 more point on that is neglected work 651 00:40:45,160 --> 00:40:49,000 is often technical debt that is not on the radar. 652 00:40:49,200 --> 00:40:54,360 Business teams or project teams, you know, not in my project, 653 00:40:54,440 --> 00:40:56,680 Don't do that kind of stuff in my project. 654 00:40:56,880 --> 00:40:59,400 So that's another reason why it keeps getting delayed and 655 00:40:59,400 --> 00:41:01,880 neglected until it becomes an emergency. 656 00:41:02,160 --> 00:41:06,200 And because business people don't always see or understand 657 00:41:06,560 --> 00:41:09,920 the need to fix this technical debt. 658 00:41:10,280 --> 00:41:12,120 That's why it can be so insidious. 659 00:41:13,480 --> 00:41:14,880 Right. Thanks for adding that. 660 00:41:14,880 --> 00:41:17,720 Yeah, technical that is always tricky whenever engineering team 661 00:41:17,720 --> 00:41:20,720 wants to erase it, right. So how can their business also 662 00:41:20,720 --> 00:41:22,720 prioritize that? So the whole important thing 663 00:41:22,720 --> 00:41:25,360 about your book is actually to make work visible, right? 664 00:41:25,360 --> 00:41:28,960 So I'm sure most of the teams these days have some sort of 665 00:41:28,960 --> 00:41:31,920 Kanban, you know, the boards to do in progress and done. 666 00:41:32,320 --> 00:41:35,480 But I think apart from that, from organization point of view, 667 00:41:35,480 --> 00:41:39,360 how can we also make work more visible so that the leaders from 668 00:41:39,360 --> 00:41:43,560 top to down can actually see how things you know flow, how things 669 00:41:43,560 --> 00:41:45,040 are blocked and things like that. 670 00:41:45,040 --> 00:41:48,040 Maybe from your experience, can you give us some tips how to 671 00:41:48,040 --> 00:41:50,520 actually make work visible in a larger scope? 672 00:41:51,320 --> 00:41:54,760 Yes, absolutely. Working with the team right now 673 00:41:54,760 --> 00:41:59,960 where one of their OK Rs, their objectives and key results was 674 00:42:00,000 --> 00:42:06,600 to show that 30% of their defects would be fixed before 675 00:42:06,600 --> 00:42:10,200 the next planning cycle. So within 10 weeks that they 676 00:42:10,200 --> 00:42:15,120 would fix 30% of their defects. OK, well, in their tool set, 677 00:42:15,240 --> 00:42:18,000 they have a work item type, it's called defect. 678 00:42:18,160 --> 00:42:22,040 So they can measure how many defects they have and they can 679 00:42:22,240 --> 00:42:25,400 look at their start and end dates and they can measure over 680 00:42:25,400 --> 00:42:29,600 time how many they did. And then from there, the math is 681 00:42:29,600 --> 00:42:33,400 pretty simple, right? They just have to divide their 682 00:42:33,400 --> 00:42:36,560 throughput by the total defects to come up with a percentage. 683 00:42:37,200 --> 00:42:38,920 You know, did they meet their 30%? 684 00:42:39,440 --> 00:42:42,400 So that's pretty that's so far so good. 685 00:42:42,560 --> 00:42:47,720 But defects aren't their only. OK Rs show another OK R is that 686 00:42:47,720 --> 00:42:52,560 10% of their work would be fixing technical debt and 10% of 687 00:42:52,560 --> 00:42:54,840 their work would be fixing security risks. 688 00:42:55,280 --> 00:42:59,200 Well, they don't have artifacts for technical debt or security 689 00:42:59,200 --> 00:43:02,320 risks. They're all just kind of hidden 690 00:43:02,320 --> 00:43:06,080 in with the stories and the other work that they do. 691 00:43:06,520 --> 00:43:08,200 And so we see this again and again. 692 00:43:08,200 --> 00:43:13,280 And it's fairly, I mean we have to ask the question, what flows 693 00:43:13,280 --> 00:43:16,640 in software delivery? And there are 4 main work item 694 00:43:16,640 --> 00:43:20,800 types that we look at. We have features, user facing 695 00:43:20,800 --> 00:43:25,720 functionality requested usually by external customers or 696 00:43:25,720 --> 00:43:29,080 internal customers. We have defects, you know, bugs 697 00:43:29,080 --> 00:43:32,480 in production. Then there's technical debt, and 698 00:43:32,480 --> 00:43:37,760 then there's like security vulnerabilities, patching risks, 699 00:43:37,800 --> 00:43:41,760 those kinds of things, and the debts and the risks. 700 00:43:41,760 --> 00:43:46,320 The security item rarely have their own artifact type in the 701 00:43:46,320 --> 00:43:50,360 tool set so that you can get visibility on just those types 702 00:43:50,360 --> 00:43:52,560 of work. Usually people just have 703 00:43:52,560 --> 00:43:56,360 visibility on their feature requests, their stories and 704 00:43:56,360 --> 00:44:02,040 their defects. So being able to clearly see, 705 00:44:02,440 --> 00:44:06,760 you know that these four major types of work that organizations 706 00:44:06,760 --> 00:44:11,760 need to work on is important. So you can look at what your 707 00:44:11,920 --> 00:44:15,920 ratio is and have conversations about what should it be. 708 00:44:16,080 --> 00:44:21,120 Should we in this case, you know, should debt be 10% of our 709 00:44:21,120 --> 00:44:25,520 demand, should security work be 10% of our demand, Why 10%? 710 00:44:25,720 --> 00:44:29,320 How much was it when these organizations measured that? 711 00:44:29,440 --> 00:44:31,840 Well, first of all, they didn't have the capability to see that 712 00:44:31,840 --> 00:44:35,680 for five months into their implementation of their flow 713 00:44:35,680 --> 00:44:37,880 metrics. And when they did, when they 714 00:44:37,880 --> 00:44:41,720 were in a position to start measuring their technical debts 715 00:44:41,720 --> 00:44:45,080 that you know, outside of their features and their security 716 00:44:45,080 --> 00:44:48,920 items outside of their stories, they only were able to deliver 717 00:44:48,920 --> 00:44:52,680 less than 2, 1/2% of security items. 718 00:44:53,040 --> 00:44:58,360 So then you can see how that would spark a conversation of we 719 00:44:58,360 --> 00:45:01,200 need to allocate more capacity to do security. 720 00:45:01,320 --> 00:45:03,120 Well, where do we take that from? 721 00:45:03,320 --> 00:45:06,760 Should we do less features? Should we do less technical 722 00:45:06,760 --> 00:45:10,000 debt? Maybe security needs to be 20% 723 00:45:10,000 --> 00:45:13,760 of our demand, maybe technical debt needs to be higher. 724 00:45:14,200 --> 00:45:19,560 Once you can make all of those types of work visible, you can 725 00:45:19,560 --> 00:45:24,280 have these conversations on how much should we allocate for each 726 00:45:24,280 --> 00:45:29,480 different type of work and how do we set up our tool set so 727 00:45:29,480 --> 00:45:33,480 that we can measure each of those types of work. 728 00:45:33,920 --> 00:45:37,520 So I think that's one off the top that people can do to get 729 00:45:37,520 --> 00:45:41,800 more visibility of their work is what kind of work do they have 730 00:45:42,040 --> 00:45:45,000 and how much is getting done. And it's a trade off. 731 00:45:45,320 --> 00:45:49,080 If we decide to work on more security items, that means we're 732 00:45:49,080 --> 00:45:51,520 going to work. We only got 100%. 733 00:45:51,520 --> 00:45:54,040 What are we going to work less on? 734 00:45:54,400 --> 00:45:57,760 And then some organizations can actually set their WIP limits 735 00:45:57,920 --> 00:46:03,560 per that artifact type. Right so I think this techniques 736 00:46:03,600 --> 00:46:06,360 making work visible. You cover so many examples in 737 00:46:06,360 --> 00:46:09,360 the book, so for people who would love to get ideas how you 738 00:46:09,360 --> 00:46:13,800 can visualize your work better. You can refer to Dominica's book 739 00:46:14,120 --> 00:46:15,880 and I think it's the phrase right. 740 00:46:15,880 --> 00:46:18,440 So if you cannot see, you cannot manage, right? 741 00:46:18,640 --> 00:46:21,400 So I think that's why maybe people these days have a mental 742 00:46:21,400 --> 00:46:24,280 juggle, like which things that they they have to prioritize 743 00:46:24,280 --> 00:46:27,600 first or they feel that they are blocked somehow but they just 744 00:46:27,600 --> 00:46:30,880 couldn't understand where. So I think making things visible 745 00:46:30,880 --> 00:46:35,240 definitely will help a lot. Yeah, well, there's one other 746 00:46:35,440 --> 00:46:37,600 important thing to make your work visible. 747 00:46:37,840 --> 00:46:40,840 A bit of a suggestion here. And so if you have your 748 00:46:40,840 --> 00:46:44,400 different types, you'll make all your types of work visible and 749 00:46:44,400 --> 00:46:50,440 then broaden the focus, broaden the span of the visibility. 750 00:46:50,760 --> 00:46:54,760 It's fairly easy to get visibility on the smaller 751 00:46:54,960 --> 00:46:58,160 individual team artifacts like stories. 752 00:46:58,560 --> 00:47:03,280 But when we do that, it's like we're sort of chasing down the 753 00:47:03,280 --> 00:47:06,640 wrong problem. We should have visibility on our 754 00:47:06,640 --> 00:47:08,240 stories. I'm not saying not to measure 755 00:47:08,360 --> 00:47:13,520 your stories, but it's important to get the big picture and to 756 00:47:13,640 --> 00:47:16,320 look at the end to end value stream. 757 00:47:16,560 --> 00:47:21,000 Our team coined this phrase. It's called Stuck in Storyland 758 00:47:21,360 --> 00:47:25,600 and Stuck in Storyland. It's a phrase that refers to a 759 00:47:25,600 --> 00:47:31,120 micro workflow, just a small slice of an end to end overall 760 00:47:31,160 --> 00:47:36,120 value stream versus a macro workflow, which is sort of the 761 00:47:36,400 --> 00:47:39,880 Gold Star of visualizing business value because it starts 762 00:47:39,880 --> 00:47:43,240 with a customer and it ends with a customer. 763 00:47:43,680 --> 00:47:49,480 And and some organizations, if they're just chasing team 764 00:47:49,480 --> 00:47:52,680 efficiency by only looking at stories, because stories are 765 00:47:52,680 --> 00:47:55,240 easy to measure because you have an artifact in your tool set 766 00:47:55,240 --> 00:48:00,000 that's called a story, you're missing out on looking at the 767 00:48:00,000 --> 00:48:03,800 customer value, the business value that's at the higher 768 00:48:03,920 --> 00:48:06,440 level. And this is much harder to get 769 00:48:06,440 --> 00:48:10,520 visibility on because work that's way upstream, maybe in a 770 00:48:10,520 --> 00:48:15,040 discovery process or waiting on funding or approval or 771 00:48:15,040 --> 00:48:18,360 prioritization, maybe in a different tool set. 772 00:48:18,720 --> 00:48:23,560 It may be in a spreadsheet. But when we can start looking at 773 00:48:23,560 --> 00:48:28,680 just how much WIP is upfront ahead of development and 774 00:48:28,680 --> 00:48:32,520 engineering and we can do the math and see how much is 775 00:48:32,520 --> 00:48:37,320 invested in starting these big initiatives that get delayed for 776 00:48:37,320 --> 00:48:40,880 sometimes up to a year. What is the cost of that? 777 00:48:41,200 --> 00:48:45,040 We looked at this recently at a company and it discovered that 778 00:48:45,280 --> 00:48:51,520 they had eleven months of large capabilities queued up that they 779 00:48:51,520 --> 00:48:56,560 were only delivering one in six of those capabilities in 1/4 780 00:48:56,760 --> 00:49:01,920 compared to what was planned. And so they had $4 million 781 00:49:01,920 --> 00:49:06,280 invested in starting capabilities that were taking 782 00:49:06,440 --> 00:49:10,360 almost a year. And so now they're considering 783 00:49:10,360 --> 00:49:13,880 introducing capability limits for them. 784 00:49:13,880 --> 00:49:18,720 A capability is a chunk of value that's bounded by 1/4 by 90 785 00:49:18,720 --> 00:49:20,520 days. So it's supposed to be done in 786 00:49:20,520 --> 00:49:25,280 90 days, but it's taking almost a year to do for 84% of them. 787 00:49:25,640 --> 00:49:30,880 This is a huge eye opener for leaders and then when you add 788 00:49:30,880 --> 00:49:36,000 the cost of that, it will get the attention and hopefully help 789 00:49:36,160 --> 00:49:40,160 to change some partisation decisions that are happening 790 00:49:40,320 --> 00:49:42,360 that may be outside of the team's control. 791 00:49:42,960 --> 00:49:45,680 Yeah, thanks for the plug. So the two things that I got 792 00:49:45,680 --> 00:49:49,160 from your insights just now, right, so first of all is always 793 00:49:49,160 --> 00:49:52,040 try to broaden the visibility, not just at the team level, the 794 00:49:52,040 --> 00:49:54,200 stories, you know, the, the features that the team is 795 00:49:54,200 --> 00:49:56,240 working. But look at it at it from the 796 00:49:56,240 --> 00:49:58,200 higher level. And second thing you mentioned 797 00:49:58,200 --> 00:50:01,600 about capabilities, 90 days long, sometimes we don't have 798 00:50:01,600 --> 00:50:04,320 equal bat size, right. So that's why it's very, very 799 00:50:04,320 --> 00:50:07,320 important to reduce your bat size so that we can get more 800 00:50:07,320 --> 00:50:10,240 predictability. So Dominica, thanks so much for, 801 00:50:10,240 --> 00:50:12,600 you know, covering this, making the work more visible. 802 00:50:12,600 --> 00:50:16,000 So hopefully leaders take that as the cue to, you know, get 803 00:50:16,000 --> 00:50:18,520 things much, much better to organize then manage them 804 00:50:18,520 --> 00:50:21,040 properly. So the other thing is about how 805 00:50:21,040 --> 00:50:23,360 to measure right? So after you make the work 806 00:50:23,360 --> 00:50:25,440 visible. You mentioned a couple times 807 00:50:25,440 --> 00:50:29,160 about flow metrics maybe. What can the leaders or managers 808 00:50:29,160 --> 00:50:32,800 do in order to measure? Start measuring how they get 809 00:50:32,880 --> 00:50:36,960 things done? Well, I would start with what 810 00:50:36,960 --> 00:50:39,120 prevents the team from getting their work done. 811 00:50:39,320 --> 00:50:44,640 And if the response to that is too much WEP on our plate, then 812 00:50:44,640 --> 00:50:49,040 we need to measure how much WEP the team has, which most tool 813 00:50:49,040 --> 00:50:51,400 sets. You can just query your system 814 00:50:51,720 --> 00:50:56,440 and say show me everything that's been started but it's not 815 00:50:56,440 --> 00:50:59,560 completed yet. How many things do we have in 816 00:50:59,560 --> 00:51:02,000 place? And then create an aging report. 817 00:51:02,080 --> 00:51:06,800 Aging report is so powerful, you just can say show me everything 818 00:51:07,000 --> 00:51:10,560 that has been started, but it hasn't been updated in X number 819 00:51:10,560 --> 00:51:13,280 of days. So that could be 30 days, 60 820 00:51:13,280 --> 00:51:18,880 days, 90 days, 200 days, however long and you can see the age. 821 00:51:18,880 --> 00:51:22,880 Then we have all this work in the funnel that hasn't been 822 00:51:22,880 --> 00:51:27,160 touched in a long, long time, 6090 hundred 20 days. 823 00:51:27,560 --> 00:51:29,160 And what are we going to do about that? 824 00:51:29,640 --> 00:51:34,000 So aging report, excellent report to start reviewing on at 825 00:51:34,000 --> 00:51:37,840 least a monthly basis. And then the other pain point 826 00:51:37,840 --> 00:51:41,760 about things taking too long. OK, well, let's measure how long 827 00:51:41,760 --> 00:51:45,280 things actually take. So this is your cycle time or 828 00:51:45,280 --> 00:51:47,440 what I sometimes refer to as flow time. 829 00:51:47,680 --> 00:51:53,080 And with this, now it's important to set the criteria 830 00:51:53,240 --> 00:51:57,600 for when to stop the clock. Because if you ask if teams are 831 00:51:57,600 --> 00:52:00,560 measured at the individual team level, they're going to want to 832 00:52:00,560 --> 00:52:04,520 stop the clock when they hand off their work to another team. 833 00:52:04,800 --> 00:52:10,320 However, if we're working to measure when the customer can 834 00:52:10,320 --> 00:52:15,600 use that feature or that service, then we want to measure 835 00:52:15,600 --> 00:52:19,600 when the customer can access that change that request. 836 00:52:20,160 --> 00:52:25,080 So conversations on when to stop the clock and also when to start 837 00:52:25,080 --> 00:52:28,600 the clock, you know, how soon upstream can we start it during 838 00:52:28,600 --> 00:52:32,520 the discovery phase, do we have the capability to do that? 839 00:52:32,760 --> 00:52:36,840 So that's where I work with a lot of organizations is helping 840 00:52:36,840 --> 00:52:38,840 them. We've had those conversations 841 00:52:38,840 --> 00:52:44,000 about where can we get the most visibility from the broadest 842 00:52:44,000 --> 00:52:48,600 sense like can we see when a capability is in discovery, can 843 00:52:48,600 --> 00:52:52,880 we start the clock then to when that capability is delivered to 844 00:52:52,880 --> 00:52:55,800 the customer. That's a great way to expand 845 00:52:55,800 --> 00:53:00,160 visibility on your flow time. I like the metric of flow 846 00:53:00,160 --> 00:53:03,680 distribution. I briefly touched on it earlier. 847 00:53:03,880 --> 00:53:08,080 This is the ratio of the different types of work. 848 00:53:08,280 --> 00:53:12,600 So if you have features and defects and security work and 849 00:53:12,600 --> 00:53:18,080 technical debt, what is that distribution look like? 850 00:53:18,120 --> 00:53:21,120 And yeah, things will be different sized. 851 00:53:21,400 --> 00:53:25,960 But you know, if you work for small batch size then you can 852 00:53:25,960 --> 00:53:32,640 get a general idea of the ratio of say defects to technical debt 853 00:53:32,920 --> 00:53:36,800 and have that conversation a flow efficiency. 854 00:53:36,800 --> 00:53:39,200 I think it's a really hard metric to measure. 855 00:53:39,680 --> 00:53:44,040 And because usually there's never enough weight States. 856 00:53:44,240 --> 00:53:47,400 And even if an organization has a lot of weight, you know, 857 00:53:47,400 --> 00:53:52,240 waiting on design or ready for design or ready for development 858 00:53:52,240 --> 00:53:56,240 or ready for test or ready for release, even if they do have 859 00:53:56,320 --> 00:54:03,600 those ready for or wait states, often times people won't put the 860 00:54:03,600 --> 00:54:05,840 work in that state. I don't know. 861 00:54:05,840 --> 00:54:08,880 They say there's too much overhead, or they don't want to 862 00:54:08,880 --> 00:54:13,160 make their teammate look bad, or there's a lot of reasons why 863 00:54:13,400 --> 00:54:18,560 those wait states don't get completed or filled out, or it's 864 00:54:18,560 --> 00:54:20,880 just really hard to calculate the wait time. 865 00:54:21,400 --> 00:54:26,600 So flow efficiency is the ratio of active time versus wait time, 866 00:54:26,800 --> 00:54:31,360 and flow efficiency is almost always optimistically high. 867 00:54:31,720 --> 00:54:35,720 I see it all the time. It'll be 8090%, which just is 868 00:54:35,720 --> 00:54:40,720 inaccurate because there's insufficient weight states in 869 00:54:40,720 --> 00:54:44,320 the tool sets. If you are able to measure if 870 00:54:44,320 --> 00:54:47,160 you do have good weight states. I think that it's just a more 871 00:54:47,160 --> 00:54:53,240 advanced practice, but I rarely see that being practiced well, 872 00:54:53,760 --> 00:54:57,880 so that's why I tend to focus more on measuring WIP, measuring 873 00:54:57,880 --> 00:55:00,560 your flow time, and measuring your throughput. 874 00:55:01,320 --> 00:55:03,080 Yeah. Thanks for mentioning all these 875 00:55:03,080 --> 00:55:05,240 metrics. I think we get some ideas how we 876 00:55:05,240 --> 00:55:08,760 can, you know, try to optimize our flow, optimize our work, 877 00:55:08,880 --> 00:55:10,760 right. So again, thank you so much for 878 00:55:10,760 --> 00:55:14,480 this insightful conversation. So, Dominica, unfortunately, due 879 00:55:14,480 --> 00:55:17,600 to time, we have to cut it here. But I have one last question for 880 00:55:17,600 --> 00:55:20,560 you, which I asked to all of my guests, which I call the three 881 00:55:20,560 --> 00:55:23,480 technical leadership wisdom. Think of it just like an advice 882 00:55:23,480 --> 00:55:26,120 you want to give to us listeners here to learn from you. 883 00:55:26,400 --> 00:55:28,760 So what will be your 3 technical leadership wisdom? 884 00:55:29,680 --> 00:55:35,840 Yeah, well, I think that we're asking people to adapt to change 885 00:55:36,200 --> 00:55:42,200 rapidly now, and that people are overloaded and stressed out and 886 00:55:42,200 --> 00:55:48,680 just more and more work to do. And so I encourage leaders to 887 00:55:48,680 --> 00:55:53,400 understand the need for focus time for teams. 888 00:55:53,760 --> 00:55:56,280 You know, this is complicated work, this knowledge work that 889 00:55:56,280 --> 00:55:57,440 we do. It's complex. 890 00:55:57,440 --> 00:56:01,280 It's complicated. And we need allocated time, 891 00:56:01,400 --> 00:56:06,000 uninterrupted time, to do that. And so we need to give our 892 00:56:06,000 --> 00:56:10,480 people, you know, 90 minutes to 120 minutes of uninterrupted 893 00:56:10,480 --> 00:56:14,840 time during business hours that they can be heads down in their 894 00:56:14,840 --> 00:56:16,960 work without getting interrupted. 895 00:56:17,320 --> 00:56:20,600 And so I think we need to be careful about what time we 896 00:56:20,600 --> 00:56:24,880 schedule our weekly meetings and other meetings and provide 897 00:56:24,880 --> 00:56:28,640 people with uninterrupted time to do their most important work. 898 00:56:28,640 --> 00:56:31,320 Because if they can't get it done during business hours, you 899 00:56:31,320 --> 00:56:34,600 end up doing it at 10:00 at night after you put the kids to 900 00:56:34,600 --> 00:56:36,960 bed. Or are you doing it on Sundays, 901 00:56:36,960 --> 00:56:40,840 when really we want people to do their most important work during 902 00:56:40,840 --> 00:56:44,160 the work day? And so create some psychological 903 00:56:44,160 --> 00:56:48,160 safety #2 Create some psychological safety in your 904 00:56:48,160 --> 00:56:53,120 organization, what we would call a generative culture where 905 00:56:53,120 --> 00:56:56,800 people are OK acknowledging that they have too much on their 906 00:56:56,800 --> 00:57:00,640 plate, they're overloaded cognitively, that they need more 907 00:57:00,640 --> 00:57:04,480 space and need to reduce the load so they can finish their 908 00:57:04,480 --> 00:57:07,720 most important work. And then the measures, how 909 00:57:07,720 --> 00:57:12,720 people are incentivized and measured, because how people are 910 00:57:12,720 --> 00:57:16,400 measured is very important to them and they will behave 911 00:57:16,560 --> 00:57:19,720 accordingly to make the metrics look good. 912 00:57:20,000 --> 00:57:24,000 And so there can be unintended consequences for that. 913 00:57:24,480 --> 00:57:28,680 For example, in one organization I worked with, they thought it 914 00:57:28,680 --> 00:57:33,960 was a good idea in their cafeteria to put the names of 915 00:57:33,960 --> 00:57:37,360 developers who had more than 10 bugs assigned to them. 916 00:57:37,880 --> 00:57:41,120 Because like we called it the naughty list, your name went on 917 00:57:41,120 --> 00:57:44,160 the board if you had more than 10 bugs. 918 00:57:44,440 --> 00:57:47,720 And what started happening was people were saying, well, no, 919 00:57:47,720 --> 00:57:50,960 that's that shouldn't really be assigned to me, That should be 920 00:57:50,960 --> 00:57:55,720 assigned to somebody else. And it just caused so much angst 921 00:57:55,800 --> 00:57:59,320 that it made things take even longer because people were so 922 00:57:59,320 --> 00:58:02,680 fearful and worried about getting on the naughty list. 923 00:58:02,680 --> 00:58:05,240 And those bugs, some of them weren't high priority, they were 924 00:58:05,240 --> 00:58:08,760 low priority. So I think it's be very careful 925 00:58:08,760 --> 00:58:12,960 about how people are measured and incentivized in your 926 00:58:12,960 --> 00:58:15,880 organization. I really love all of them, 927 00:58:15,880 --> 00:58:18,080 right? So space, psychological safety 928 00:58:18,080 --> 00:58:19,800 and also, you know, measurement, right? 929 00:58:19,800 --> 00:58:22,440 So I think really, really important how you measure 930 00:58:22,440 --> 00:58:24,960 people. So, Dominica, I can't highly 931 00:58:24,960 --> 00:58:26,240 recommend enough for your book, right? 932 00:58:26,240 --> 00:58:29,720 So for people who want to check out Dominica's book Making work 933 00:58:29,720 --> 00:58:31,800 visible, I think highly, highly recommended. 934 00:58:32,120 --> 00:58:34,880 But for people who want to follow up other resources or 935 00:58:34,880 --> 00:58:37,600 your work, is there a place where they can find you online? 936 00:58:38,120 --> 00:58:40,520 Yeah, LinkedIn is probably the best place. 937 00:58:40,520 --> 00:58:42,600 LinkedIn. There's not too many Dominica 938 00:58:42,600 --> 00:58:46,840 degrandises on LinkedIn, so you should have no problem finding 939 00:58:46,840 --> 00:58:48,080 me. Just reach out. 940 00:58:48,600 --> 00:58:50,480 I'll put it in the show notes. So thank you so much for your 941 00:58:50,480 --> 00:58:52,560 time today. Dominica really learned a lot 942 00:58:52,560 --> 00:58:54,760 from you. Thank you, Henry. 943 00:58:54,760 --> 00:58:59,720 Appreciate it. Thank you for listening to this 944 00:58:59,720 --> 00:59:02,120 episode and for staying right until the end. 945 00:59:02,480 --> 00:59:05,640 If you highly enjoyed it, I would appreciate if you share it 946 00:59:05,640 --> 00:59:08,640 with your friends and colleagues who you think would also benefit 947 00:59:08,640 --> 00:59:11,400 from listening to this episode and if you're new to the 948 00:59:11,400 --> 00:59:13,640 podcast. Make sure to subscribe and leave 949 00:59:13,640 --> 00:59:15,640 me your valuable review and feedback. 950 00:59:16,000 --> 00:59:18,880 It helps me a lot in order to grow this podcast better. 951 00:59:19,400 --> 00:59:22,280 You can also find the full show notes of this conversation on 952 00:59:22,280 --> 00:59:25,280 the episode page at Techlyjournal dot dev website, 953 00:59:25,560 --> 00:59:29,160 including the full transcript, interesting quotes, and links to 954 00:59:29,160 --> 00:59:31,560 the resources mentioned from the conversation. 955 00:59:32,000 --> 00:59:35,040 And lastly, make sure to subscribe to the show's mailing 956 00:59:35,040 --> 00:59:38,840 list on techlyjournal dot dev to get notified for any future 957 00:59:38,840 --> 00:59:41,440 episodes. Stay tuned for the next Techly 958 00:59:41,440 --> 00:59:44,360 Journal episode, and until then, goodbye.