In the book, I use this concept of the five thieves of time that I think resonates with everybody, whether they're in technology or not. And these five thieves of time are related to too much work in progress, conflicting priorities, unplanned work, unknown dependencies, and neglected work or neglected WIP. And so most everybody has experienced all of those and are looking for ways to deal with
that kind of time theft. Hey everyone, my name is Henry Surya Virawan and you're listening to the Technically Journal podcast, the show where I'll be bringing you the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply. To build a highly performing technical team and to make an impact in your personal work. So let's dive into our journal.
Hello to all of you, my friends, and my listeners. You are listening to the Technically Journal Podcast, the podcast where you can learn about technical leadership and excellence from my conversations with great thought leaders in the tech industry. If you haven't, please subscribe on your favorite podcast app to get notified for new episodes. Also, subscribe to Techlegional's various other contents on LinkedIn X, Instagram, YouTube, and Tiktok.
And consider supporting this podcast by either buying me a coffee at techlegional dot dev tip or becoming a patron at techlegional dot dev patron. My guest for today's episode is Dominica de Grandis. Dominica is the author of one of my favorite books making work visible. In this episode we. We discussed how we can optimize our workflow and reclaim control of our work and time.
Dominica unveiled the concept of the Five Thieves of time that rob us of our productivity, which includes too much work in progress, conflicting priorities, unplanned work, unknown dependencies, and neglected work. She also shared actionable practices and tips on dealing with each of those five thieves. Towards the end, Dominica emphasized the importance of making work feasible within an organization and how to measure our flow of work.
I hope you enjoy listening to this episode and getting to understand the different time thefts that I'm sure frustrate many of us in our daily work. If you enjoy listening to this episode, please do share it with your colleagues, your friends and communities and leave a five star rating and review on Apple Podcasts and Spotify. Your small help will help me a lot in getting more people to discover and listen to this podcast, and I really appreciate it.
So let's now go to my conversation with Dominica after quick words. From our sponsor. Hey, a quick message for those of you who are listening to this episode on Spotify. I have a small favor to ask. Spotify now allows mobile users to rate podcasts. I would really appreciate it if you can take a quick pause to go to the Techni Journal podcast page and leave your favorite show your best rating on Spotify. It will help me a lot to get this podcast to reach more
people on the platform. Thanks a lot. Hey everyone, welcome back to the new episode of the Techni Journal Podcast. I'm very excited. Today I have a guest that I have been admiring for a long time After reading her book, Make Work Visible. Her name is Dominica de Grandes. So, Dominica, thank you so much for your time. Looking forward to our discussion today. Delighted to be here Henry.
Thank you. Yeah, Dominica, if I may ask you in the beginning to share maybe your career journey, any highlights or turning points that we all can learn from? All right. Well, my first job out of university was at Boeing Airlines. It's a very large company and I felt I was very ill prepared. I didn't know what to expect based on the courses that I'd taken at school, so I had a lot of learning to do really quickly, mostly about configuration management.
That was what I did for many years, software configuration management, just building decoder rings so people could understand what version of what file was in what environment and on and on. And that was quite a big problem for many years. So there was a opportunity to
provide value in that space. And then I went on to work for a variety of different companies from big telecom to startups and doing software configuration management, build management, release management, deployment automation.
And then probably a real turning point in my career was in around 2005, 2006, 2007, I was working at Corbis, which was Bill Gates other company in Seattle outside of Microsoft and we started implementing Kanban and it was supposedly the first implementation of Kanban in the US for engineering and software development. I was so excited about this way of working. I never really did Scrum.
We went sort of straight from waterfall to this pull system that was Kanban and where I had to learn how to start capturing meaningful metrics and present those metrics to my peers and and leadership. And it was a really pivotal time in my career where I had to learn how to speak in front of people and present data. And it really did blow me away because I got budget and headcount and empathy from other
teams. It was a great learning lesson, even though I was terrified to get up and speak in front of many other people. But very good learning lesson that really laid the foundation for the work that I was going to do later on, which was going more into helping other organizations understand Kanban and flow and pull systems. And why too much work in progress is a problem. And how to collect and measure flow metrics, interpret them and help other companies do that too.
And that's really carried me on to where I am today, you know, from there, I was independent for a number of years. I used to travel a lot and do workshops primarily for IT OPS and then later dev OPS and I got very involved in the dev OPS community. I was just happened to be in the
right place at the right time. So I was just kind of lucky to meet all these great luminaries of the dev OPS community and teach them Kanban and be able to help out the practitioners working in the trenches who were really suffering from being overloaded and too much cognitive load, too many conflicting priorities, too many dependencies that were invisible and became blockers. And then through the whole continuous improvement and delivery and deployment
automation. So my role, which I had done most of my career, was shifted rather rapidly after that because the pipeline was mostly automated, so we didn't spend as much time having to worry about doing database restores from production and making sure that every environment was set up
with identical software. That became less of an issue, and I kind of worked my way out of that job and moved more into help setting people up for success in that journey and that sort of transformational journey looking at entire value streams now instead of just individual team metrics. Thank you for sharing your story. I think it's really interesting how you got into Kanban, right. I think today we are going to cover some of the important
topics you just mentioned. You know, things about flow, Kanban, flow metrics, how to help people so that they don't get overloaded with high cognitive load and things like that. So I think for your book, I mean if people haven't read it before, right. So I think the book is really, really how to make your kind of like all these tasks work is visible, right, So that we can actually see what kind of problems that we have and try to optimize how we can finish all the tasks, right.
The first thing is, I think you cover in the book the background of the story you wrote. This book is because people now seems to have too many things to do, like we have everything to do, but we have. Very little time to finish it. So maybe in the beginning, can you tell us the background of how do you envision this book helping people to make their
work more visible? Yeah. Well, in the book I use this concept of the five these of time that I think resonates with everybody, whether they're in technology or not. And these five thieves of time are related to too much work in progress, conflicting priorities, unplanned work, unknown dependencies and neglected work or neglected WIP. And so most everybody has experienced all of those and are looking for ways to deal with that kind of time theft. So the part one and Part 2 sort
of introduce these concepts. Identify how you can see that this is happening in your organization. And then Part 2 talks about what to do about it. And there are exercises. Especially in the second edition of the book we added more exercises. I like to make things provide a lot of utility for the readers so that they can do exercises to practice exposing and bringing these time thieves out into the open and collecting data around
these issues. Because I think that's when you can start to have the really good conversations, when you can start seeing, yeah, how much WHIP do you have on our team has you know, 110 items just in the validate state, you know, and we only have five people on our team. So right there you can start to see and expose just how
overloaded the teams are. And then when we look at the pain points, one of the most prominent exercises in the book is what I call a demand analysis where we have the teams identify what is the nature of their demand. Do they have a lot of unplanned work? Do they work primarily on technical debt or security? And then the second part of the exercise is identifying what prevents them from getting their work done, what randomizes their
day. And then the third part is what do their customers grumble about? And we call that business pain? And when I'm using the term customer there, I'm talking about the internal customer, like their boss or the product manager, but somebody internal to the company who's making requests from them, what are they not so happy about? And we find that there's this correlation or almost this mirror of what causes pain for the team is correlated to what the customer is grumbling about.
For example, if the customer is unhappy because things take too long, You know, we asked for this feature six months ago and we still don't have it. You know, it's taking too long. We need it already. We needed it six months ago. And if we look at the team pane side, it's because they have too much WIP. They're overloaded with so much WIP that it's taking them longer to deliver those feature requests. So they often mirror one
another. And if people are complaining that things are taking too long, then it makes sense to clearly understand, to clearly measure how long things actually take. And so with there, then we get into the metrics which I cover in Part 3, how to measure your flow time, why it's important to
measure that. So usually that will be an outcome of the demand analysis exercise is now that you've identified team pain and business pain, if everybody on your team had two votes, what would you vote on?
What would provide the biggest return or improvement or increased morale and happiness if you could make a dent in this bit of a pain area, Yeah. So just sort of going through each time with EVE, with that, you know, identifying the problem, why it matters, exercises to dig into it deeper, ultimately leading to experiments that people can do to find their way through the challenges.
I think that this work that we're doing really does require experimentation in many cases because we don't always know causality of a problem. You know, we don't always know cause and effect, and so when that occurs, we don't really have a best practice. We have a best practice. If we've done it before and we know why it happens, then we can
have a playbook for that. But if the team is doing something new and novel and they haven't done it before, then I think experimentation is very powerful. And looking at the change curve and looking at the Kubler Ross change curve, the one that everybody's familiar with that was adapted from this grief model, but it's been made applicable for business. And so it goes to like shock, denial, frustration, depression, experiment, decision and then
integration. And I think what's represented so well on that change curve is the turning point. And it's when experimentation starts happening because that's when people can start to take some ownership in what's going on in their world and all the change that's occurring and participate and come up with ideas for improvements and work to get buy in for experiments from stakeholders. I think that is very useful. Right.
So I think if people haven't heard about WIP before, right, it stands for Work in Progress. This is one of the core thing in Lean and also in Kamban and also Dominica's book So the Five Thieves of Time. When I read them, I laughed because I can relate to all of them actually. So those are like too much work in progress, unknown dependencies, unplanned work, conflicting priorities and neglected work. I'm sure all the listeners here can also relate to them. Maybe let's just cover them one
by one, right? So starting with too much WIP. You have mentioned this a few Times Now and in your book you mentioned this is like the ultimate ringleader. You know if your if your analogy is a thief, right? This is like the thief of all thieves. So tell us more. What is too much WIP? Why is it a problem and what can we do about it? In textbook terms, too much WIP is when demand outweighs capacity, so you have too many requests than your team can
handle, and it's a problem. And it's why it's the ringleader. For example, if you have unplanned work that disrupts your day, now you have to work on that in addition to all the planned work, right? So it creates more work in progress for the teams, and the more things that we try to juggle at the same time, the more scattered we are, the less time we can focus deeply on this one important item that we need to complete as soon as possible. WIP is a leading indicator, right?
We know that, say, as soon as you commute home, if there's a lot of traffic on the roads, your commute is going to take longer. So it's the same thing with too much knowledge, work in play. The more WIP we have, the longer things take and the increase in cognitive load in our functioning, which can cause stress, cause all kinds of health issues and can lead to burnout and depression.
So it's very important to try and limit the amount of work so that we can have higher quality on what we're delivering. That is going to provide more confidence in our ability to deliver high quality things when our customers are expecting them. But we find more and more that that's a rare scenario because we have a hard time saying no, that we're human. And so we want to say yes, yes, I can do that. Yes, I can do that.
And there's many reasons why we say yes when we probably really ought to say no. If we say yes to everything, then we can't deliver our most important yes, if that makes sense to you. So I think it's really essential that we get really brutally honest about what is the one most important thing to get done today, or at least to get to a nice stopping point so that we can make progress on that.
We have to ruthlessly protect our time so that we can complete our most important work, which is really hard to do if we just have too much demand, too much stuff on our plates. But I think the nature of wanting to be helpful and wanting to be valuable to our teammates and to our organization, we end up saying yes more than we should. So I think this, when you say it's a leading indicator, right.
So I think people just need to, you know, understand the concept of cycle time and WIP and throughput, right. Maybe if you can go through, you know why Too much WIP actually is a leading indicator. Yeah. So people always say, well, what should our WIP be? Usually the answer to that is lower. You know 100 is better than 110, but there is an equation that we can use to have this conversation and it's called Little's law and it's based on averages.
And it's where your average flow time or cycle time equals your average web over your average throughput, your throughput being the number of items completed over a period of time. And when we look at the math, because WIP, your work in progress is the numerator in the equation. As soon as that WIP increases, we know that it's going to extend your lead time cycle time, flow time, whatever you're using as long as the assumptions are in place. There are some assumptions in that law.
You know you have to have a stable system. Your WIP needs to remain fairly relative and the, you know, you shouldn't have cancelled work, that kind of thing, all all things that everybody has. But that conversation alone and looking at that math, I can show you why this is so important and why it's a leading indicator. Leading because WIP is partially completed work. We've started it, but it's not done yet. Most of all the other metrics are based on work that's completed.
You know, throughput, flow time, flow efficiency, those metrics are all based on work that's already completed. But your WIP metric, which we call flow load is work that's in progress. So that's why it's considered a leading indicator and so powerful to use because you can look at it right now and have it spark a conversation about what do we need to delay for now because most they'll have their planned work. Can we talk about unplanned work
now? It's yeah, because they'll be working on their planned work and usually they're allocated 100% right to work on this planned work. But then priorities change and or unplanned work hits them and now they have to stop what they're doing. They have to stop their planned work, context switch, pick up the unplanned work, work on that context switch, get back to the planned work. It's like being at their grocery store and somebody jumps the queue in front of you, right?
You're at the checkout line, ready to go next, and somebody cuts in front and then they check out because they have the urgent need to get through fast. What happens with that unplanned work now is that the work that you are going to get through checkout faster, but now your checkout time is going to be longer because of this unplanned work. So I think that one of the exercises is identifying what is the criteria for unplanned work and be really clear on that.
Sometimes teams will want to Group A lot of different things into the unplanned work category. But I think it's important to be really clear, could you have anticipated that? Could you have anticipated this audit was going to happen, you know, at least once this year, things like that. So that's sort of the just as a circle back on the relationship between WIP throughput and flow time or your cycle time. I'm using flow time and cycle
time interchangeably. We're talking about just tracking how long things take from beginning to end. And for flow time, that's the conversation that needs to occur is when does the clock start and when does the clock stop, right? Yeah, so speaking about unplanned work, I'm sure these days in software engineering team, right, they can relate to things like for example if there's a customer complaints, incidents, right, downtime or whatever that is, or sometimes
it's just bugs, right? Like you work on something or actually it caused a bug, right. This is what you categorize as rework. So something urgent you need to fix it and things like that. And it actually creates a lot of unpredictable workload for the team. So if we go back to the too much work in progress kind of a problem, right? I think it's granted like almost every team now is you know a burden by a lot of these tasks.
And some of the solutions actually are things like for example, you set up a come button, make it like a pull system and also limit your work in progress. So tell us a little bit more how we can, you know, make sense about our web and and kind of like solve this problem. Yeah, a number of ways. One of my favourite and useful ways is to look at the rate of arrival of work and the rate of
departure. So the rate of departure has to do with looking at your throughput, how many items were delivered over a period of time, Understanding that that is the capacity of the team that they were able to deliver X number of things over this period of time. And you can combine that with the various different types of work features, bugs, technical debt, security. Or you could just look at those individually. But the idea is to understand this departure rate determines arrival rate.
Departure rate of completing work is going to determine what the arrival rate, what your WIP limit should be and when we do, will have capacity to pull more work into our workflow because we finished work. And this stems from ARN Rook's work and his famous quote about the stop starting and start finishing. Yeah. So the concept of limiting work in progress, right, how can we
use that? Because I think that's one of the key probably for leaders, especially for managers or leaders, right, in order to actually manage their work. So you mentioned about rate of delivery and rate of arrival, right. So when the arrival is getting too many, right, how can we manage them by limiting our work in progress. Yeah, yeah. This is we're having a crystal clear prioritization policy and process in place is going to help.
It's we're having psychological safety and a generative culture comes into play so that people can be OK with knowing when they have to say, actually we don't have capacity for that right now or say, oh, OK, this is now the number one priority. This is when yesterday's is #1. Priority is not today's number one priority because priorities change and we need to be able to adapt to that. But when that happens, we need to give people permission to say, you know, hold on, we have
a new priority, one. That means something has to give, like we only have 100% for good or for bad. This is our current amount of capacity that our group has. So knowing that what should be the number one priority and what should we say no to. So when I worked at Corbis, the way that we solved this with executives in leadership was we told them that well first we measured how long it took us.
You know, basically we get to X number of features over a period of six weeks and we had a capacity for five of those like 5 features and we put the decision on the leaders to prioritize that list. So there might have been 100
requests in the backlog. And instead of all of those being thrown on the team and the team scrambling and trying to do all those and trying to prioritize them, we explained to leadership the idea about WIP limits and the team's capacity and said you got five spaces, we can have 5 feature requests on this team at a time. We would like you to decide on what those five things are and when we deliver one, there will be another opening. And when we first started this
process, it was quite chaotic. And the leaders used to, you know, whoever yelled the loudest would usually get their way. But over time, it turned into more of a democratic approach. I voted for years last week. You need to vote for mine this week. They would meet once a week. You know, the head of marketing, the head of engineering, the head of sales would be in this room. And because the question was very simple, which item should we pull in next? They didn't have to delegate
that. They didn't have to bring in their engineers to talk about details and provide estimates. We did away with estimates because the question to leaders became knowing that it takes us six weeks to deliver something. Once we start on it, which thing do you want us to deliver next? So it was a very simple question that leaders could then ponder and think about. And first it was arguing that it
was democratic decision. And then over time it turned into a analysis of the business case, what makes the most sense, what is the highest value for our company to deliver in six weeks for our customers. So we simplified a lot. So we reduced the time that had been spent on estimation by having our customers prioritize that work based on data that we provided them on our cycle time, on our flow time. Thanks for covering this conflicting priorities, right?
Because prioritization probably is one of the root cause of too much work in progress, right? Because like like you mentioned, like I think it's typical in most of the companies, right, leaders have their own objectives and they just throw it to the team, but they actually don't get visibility of the team, probably struggling on how to prioritize, you know, the upcoming tasks to them, right? And I think what you mentioned is very important that leaders should clearly identify which
one is the most priority, right? Because all cannot be the priority. And if we have to choose one by one sequentially, what would that be, right. So maybe we have covered the three of the thieves of time, right. So the too much WIP, the unplanned work and conflicting priorities just now let's move to the next one, which I find it is also tricky managing dependencies, right. So what do you call unknown dependencies? Sometimes work. You know you can't finish just by yourself, right?
You need to collaborate. Maybe you need to rely on third parties and things like that, right? So how can we tackle this problem? First of all, like, maybe sometimes we don't know we have dependencies. Or sometimes, if we do know dependencies, how do we manage them? Yeah, my thoughts on dependencies have altered a bit because there's different kinds of dependencies. Dependencies in many ways are just prerequisites.
You know, A has to happen before B happens, and A is done by a different team and their priorities different than our priority. So scheduling and all of that is a problem. But the real issue is when there's a blocker, what is blocking our capability to deliver these items within the expected time frame? And it's those blockers that we need to bring visibility to and
find a way to reduce the cost. Maybe it doesn't make sense to have every skill set on every team just because there are prerequisites for them in the book. I do have some exercises and a dependency matrix, but my thinking now more is to try and really get a handle on the expensive blockers and understanding the cost of delay of having this critical element blocked and then using, say the theory of constraints to reduce the risk of costly blockers.
Most people right away they want to say we need to hire more people, we need more people on the team, which is a valid approach, but it's usually the last thing that we would look for, right? Because how long does it take to onboard an engineer in your department? People will say six months to a year when I ask them that because it's not just getting them up to speed, but it's the onboarding, it's the interviewing, all the resume hunting. It can be very costly to onboard
new talent. And so before we go down that path, let's look at how to take an essential work off of the bottlenecks plate. Right. Here's where we talk about bottlenecks with blockers. How can we find help for that bottlenecked area? How can we invest in new tools and processes to help that bottlenecked area? That's really what the Theory of Constraints is about, is finding these other ways that will unblock dependencies and blockers faster than trying to
hire new talent. That could take 6 to 12 months. Yeah, I think, yeah, what you mentioned about hiring people or even find outsourcing team, right. It's kind of like common when we see that the team maybe cannot deliver fast, yeah, we just tend to. Go to the easy solution, seems to easy, right? But what you mentioned is actually really expensive, you know, onboarding interviews, getting them up to speed and things like that. So also dependencies, right?
Sometimes you know it's caused by the organization structure, you know, this Conway's law communication pattern and things like that. I mean, I just want to highlight one quote that you put in the book. So every dependency double S your chance of being delayed or late. So I think this is really important because sometimes leaders don't see the impact of dependencies in the team or maybe the organization structure. Maybe from your experience, anything you want to cover on that?
Yeah, that quote actually came from Troy Mcgannis, whose work I borrowed heavily on when I talk about dependencies and blockers and bottlenecks. And the story behind that one is, imagine that you're going out to dinner at a fine dining restaurant and you're meeting three other people there. Well, what is the probability the fine dining where they won't see you until everybody arrives and only then you get to your
table? What is the probability of being seated on time when there's four people involved that are on different teams or coming from different locations? And it's really quite low because of the probabilities. You know, you could be on time, but I'm late and the two other people are late, or I'm on time but you're late and the other two people, you know, there's like 8 different scenarios that
could occur. And so every time you add an additional dependency to that list, it just double S the probability that you're going to be that much later. So the number of blockers and dependencies impacts it and that's why, you know, like Team Topology is such a popular book where they talk about organization structure and sort of what to do about that. And you mentioned Conway's Law.
You know for those on listening Conway's Law as how a system design will mirror the communication structures of the organization which designs it, right. And so if we're looking at individual teams, optimizing at the team level, a group that's organized that way and that is
focused just on their silo. It's unlikely that they're going to follow practices that are well optimized for optimization of an end to end workflow, an end to end value stream, the goal of which is to deliver high level this value to the
customer. Yeah. So I think that we need to be clear about what practices we're going to use for decisions and organization and how those groups are going to be measured because how people are measured within an organization effectively constrains the production of the metrics that they're going to implement. We want to make sure that how teams are measured are in line with the desired results of that organization.
I don't know I could, I could go on on about how teams are measured and how it can negatively impact, You know, tell me how you're going to measure me and I'll tell you how I'm going to behave. And we need to be really careful about how we're measuring groups. But depending on how they're organized, we see this a lot. We have all these individual teams that have dependencies across each other, and each of those teams is measured for optimizing their slice of the value stream.
Then we have conflicting goals and we wonder why it's so difficult to get something delivered on time. Right. I think that's a very important point you just brought up, right. So knowing like how the teams or the group of teams are measured, right? Because sometimes. They can optimize locally based on how they are measured, but systematically, right, or maybe holistically they're actually conflicting to each other. So I think that's also another important point you just brought up.
So thanks for covering that for this unknown dependencies, the last one that we haven't covered is the neglected work. Some people call it, you know, work in progress that is delayed or maybe things that are just not or partially done right. Some people call it partially done. So tell us more. What is this neglected work? How can we tackle it? And how come it can cause a problem? Yeah, neglected work. It just doesn't get the love or the attention that it needs.
It keeps getting deprioritized. And others, you know, jump the queue and cut in front of it. It's often really important work. If it doesn't get done, it will become urgent and then it will become unplanned. Work like technical debt is a good example of very important work that does need to be done. But because it's not an immediate emergency, it will often get, deprioritize or have a lower priority. And it also is waiting. It's gets stuck in the queue waiting to be done.
It's like when work displaces other work, the neglected work, other new work comes in and gets a higher priority. It's like, have you heard, like robbing Peter to pay Paul? No, I haven't. OK. It's a term that we use to describe we're going to take away something from one person in order to get this other thing delivered. But we keep taking away from a very important resource and now because that work is important, it will eventually become very urgent to do.
And now we add risk into our decision making process in delaying that work. So we call that neglected work and the longer it's neglected then when it does get delivered, it will increase our flow time. It'll take that much longer because it's been neglected and sitting in the queue and waiting for so long. So this neglected work contributes to us thinking that say we're measuring our cycle time and we're saying, hey, look, we're doing great.
We're getting these things delivered in two and three weeks. But then the neglected work that was so important that kept getting neglected gets delivered and it took six months, say, to finally get that out. What does that do to your flow time now? It kicks your flow time way up. And so now it impacts your
ability to be predictable. If we're looking to be more predictable and how long it takes to deliver things, the more neglected work we have in the system, the lower the probability is that we're going to be able to deliver. When we say we are neglected, WIP is like this hidden important time thief that we don't pay enough attention to because we think everything is going really well.
And then we have some important neglected work that finally gets done and we realize, oh wow, that took much longer to do. And we have unhappy customers and leaders. It's sort of like we think we're here when we really should be here. I wish I could show you this cartoon. It's about like, you're here, but you thought you were here and we really should be here. Neglected work plays into that problem.
Like where are we and where should we really be when it comes to how realistic we are with being predictable and when we're going to deliver requests? And neglected work just will blind side us to that because we we don't see it coming until it turns into an emergency sometimes. Yeah, yeah. So I think it's very important to understand this quadrant, important, urgent, right. Neglected was probably so like an important thing, but
sometimes not urgent. And it's always important for us to analyse and make sure that we erase, you know, the urgency or the priorities for the team to work on. Yeah, just one more .1 more point on that is neglected work is often technical debt that is not on the radar. Business teams or project teams, you know, not in my project, Don't do that kind of stuff in my project. So that's another reason why it keeps getting delayed and neglected until it becomes an emergency.
And because business people don't always see or understand the need to fix this technical debt. That's why it can be so insidious. Right. Thanks for adding that. Yeah, technical that is always tricky whenever engineering team wants to erase it, right. So how can their business also prioritize that? So the whole important thing about your book is actually to make work visible, right?
So I'm sure most of the teams these days have some sort of Kanban, you know, the boards to do in progress and done. But I think apart from that, from organization point of view, how can we also make work more visible so that the leaders from top to down can actually see how things you know flow, how things are blocked and things like that. Maybe from your experience, can you give us some tips how to actually make work visible in a larger scope?
Yes, absolutely. Working with the team right now where one of their OK Rs, their objectives and key results was to show that 30% of their defects would be fixed before the next planning cycle. So within 10 weeks that they would fix 30% of their defects. OK, well, in their tool set, they have a work item type, it's called defect. So they can measure how many defects they have and they can look at their start and end dates and they can measure over
time how many they did. And then from there, the math is pretty simple, right? They just have to divide their throughput by the total defects to come up with a percentage. You know, did they meet their 30%? So that's pretty that's so far so good. But defects aren't their only. OK Rs show another OK R is that 10% of their work would be fixing technical debt and 10% of their work would be fixing security risks. Well, they don't have artifacts for technical debt or security
risks. They're all just kind of hidden in with the stories and the other work that they do. And so we see this again and again. And it's fairly, I mean we have to ask the question, what flows in software delivery? And there are 4 main work item types that we look at. We have features, user facing functionality requested usually by external customers or internal customers. We have defects, you know, bugs
in production. Then there's technical debt, and then there's like security vulnerabilities, patching risks, those kinds of things, and the debts and the risks. The security item rarely have their own artifact type in the tool set so that you can get visibility on just those types of work. Usually people just have visibility on their feature requests, their stories and their defects. So being able to clearly see, you know that these four major types of work that organizations
need to work on is important. So you can look at what your ratio is and have conversations about what should it be. Should we in this case, you know, should debt be 10% of our demand, should security work be 10% of our demand, Why 10%? How much was it when these organizations measured that? Well, first of all, they didn't have the capability to see that for five months into their implementation of their flow
metrics. And when they did, when they were in a position to start measuring their technical debts that you know, outside of their features and their security items outside of their stories, they only were able to deliver less than 2, 1/2% of security items. So then you can see how that would spark a conversation of we need to allocate more capacity to do security. Well, where do we take that from? Should we do less features? Should we do less technical
debt? Maybe security needs to be 20% of our demand, maybe technical debt needs to be higher. Once you can make all of those types of work visible, you can have these conversations on how much should we allocate for each different type of work and how do we set up our tool set so that we can measure each of those types of work. So I think that's one off the top that people can do to get more visibility of their work is what kind of work do they have
and how much is getting done. And it's a trade off. If we decide to work on more security items, that means we're going to work. We only got 100%. What are we going to work less on? And then some organizations can actually set their WIP limits per that artifact type. Right so I think this techniques making work visible. You cover so many examples in the book, so for people who would love to get ideas how you
can visualize your work better. You can refer to Dominica's book and I think it's the phrase right. So if you cannot see, you cannot manage, right? So I think that's why maybe people these days have a mental juggle, like which things that they they have to prioritize first or they feel that they are blocked somehow but they just couldn't understand where. So I think making things visible definitely will help a lot. Yeah, well, there's one other important thing to make your work visible.
A bit of a suggestion here. And so if you have your different types, you'll make all your types of work visible and then broaden the focus, broaden the span of the visibility. It's fairly easy to get visibility on the smaller individual team artifacts like stories. But when we do that, it's like we're sort of chasing down the wrong problem. We should have visibility on our
stories. I'm not saying not to measure your stories, but it's important to get the big picture and to look at the end to end value stream. Our team coined this phrase. It's called Stuck in Storyland and Stuck in Storyland. It's a phrase that refers to a micro workflow, just a small slice of an end to end overall value stream versus a macro workflow, which is sort of the Gold Star of visualizing business value because it starts with a customer and it ends with a customer.
And and some organizations, if they're just chasing team efficiency by only looking at stories, because stories are easy to measure because you have an artifact in your tool set that's called a story, you're missing out on looking at the customer value, the business value that's at the higher level. And this is much harder to get visibility on because work that's way upstream, maybe in a discovery process or waiting on funding or approval or prioritization, maybe in a different tool set.
It may be in a spreadsheet. But when we can start looking at just how much WIP is upfront ahead of development and engineering and we can do the math and see how much is invested in starting these big initiatives that get delayed for sometimes up to a year. What is the cost of that? We looked at this recently at a company and it discovered that they had eleven months of large capabilities queued up that they were only delivering one in six of those capabilities in 1/4
compared to what was planned. And so they had $4 million invested in starting capabilities that were taking almost a year. And so now they're considering introducing capability limits for them. A capability is a chunk of value that's bounded by 1/4 by 90 days. So it's supposed to be done in 90 days, but it's taking almost a year to do for 84% of them.
This is a huge eye opener for leaders and then when you add the cost of that, it will get the attention and hopefully help to change some partisation decisions that are happening that may be outside of the team's control. Yeah, thanks for the plug. So the two things that I got from your insights just now, right, so first of all is always try to broaden the visibility, not just at the team level, the stories, you know, the, the features that the team is
working. But look at it at it from the higher level. And second thing you mentioned about capabilities, 90 days long, sometimes we don't have equal bat size, right. So that's why it's very, very important to reduce your bat size so that we can get more predictability. So Dominica, thanks so much for, you know, covering this, making the work more visible. So hopefully leaders take that as the cue to, you know, get things much, much better to organize then manage them
properly. So the other thing is about how to measure right? So after you make the work visible. You mentioned a couple times about flow metrics maybe. What can the leaders or managers do in order to measure? Start measuring how they get things done? Well, I would start with what prevents the team from getting their work done. And if the response to that is too much WEP on our plate, then we need to measure how much WEP the team has, which most tool
sets. You can just query your system and say show me everything that's been started but it's not completed yet. How many things do we have in place? And then create an aging report. Aging report is so powerful, you just can say show me everything that has been started, but it hasn't been updated in X number of days. So that could be 30 days, 60 days, 90 days, 200 days, however long and you can see the age.
Then we have all this work in the funnel that hasn't been touched in a long, long time, 6090 hundred 20 days. And what are we going to do about that? So aging report, excellent report to start reviewing on at least a monthly basis. And then the other pain point about things taking too long. OK, well, let's measure how long things actually take. So this is your cycle time or what I sometimes refer to as flow time. And with this, now it's important to set the criteria
for when to stop the clock. Because if you ask if teams are measured at the individual team level, they're going to want to stop the clock when they hand off their work to another team. However, if we're working to measure when the customer can use that feature or that service, then we want to measure when the customer can access that change that request.
So conversations on when to stop the clock and also when to start the clock, you know, how soon upstream can we start it during the discovery phase, do we have the capability to do that? So that's where I work with a lot of organizations is helping them. We've had those conversations about where can we get the most visibility from the broadest sense like can we see when a capability is in discovery, can we start the clock then to when that capability is delivered to
the customer. That's a great way to expand visibility on your flow time. I like the metric of flow distribution. I briefly touched on it earlier. This is the ratio of the different types of work. So if you have features and defects and security work and technical debt, what is that distribution look like? And yeah, things will be different sized.
But you know, if you work for small batch size then you can get a general idea of the ratio of say defects to technical debt and have that conversation a flow efficiency. I think it's a really hard metric to measure. And because usually there's never enough weight States.
And even if an organization has a lot of weight, you know, waiting on design or ready for design or ready for development or ready for test or ready for release, even if they do have those ready for or wait states, often times people won't put the work in that state. I don't know.
They say there's too much overhead, or they don't want to make their teammate look bad, or there's a lot of reasons why those wait states don't get completed or filled out, or it's just really hard to calculate the wait time. So flow efficiency is the ratio of active time versus wait time, and flow efficiency is almost always optimistically high. I see it all the time. It'll be 8090%, which just is inaccurate because there's insufficient weight states in
the tool sets. If you are able to measure if you do have good weight states. I think that it's just a more advanced practice, but I rarely see that being practiced well, so that's why I tend to focus more on measuring WIP, measuring your flow time, and measuring your throughput. Yeah. Thanks for mentioning all these metrics. I think we get some ideas how we can, you know, try to optimize our flow, optimize our work, right. So again, thank you so much for
this insightful conversation. So, Dominica, unfortunately, due to time, we have to cut it here. But I have one last question for you, which I asked to all of my guests, which I call the three technical leadership wisdom. Think of it just like an advice you want to give to us listeners here to learn from you. So what will be your 3 technical leadership wisdom?
Yeah, well, I think that we're asking people to adapt to change rapidly now, and that people are overloaded and stressed out and just more and more work to do. And so I encourage leaders to understand the need for focus time for teams. You know, this is complicated work, this knowledge work that we do. It's complex. It's complicated. And we need allocated time,
uninterrupted time, to do that. And so we need to give our people, you know, 90 minutes to 120 minutes of uninterrupted time during business hours that they can be heads down in their work without getting interrupted. And so I think we need to be careful about what time we schedule our weekly meetings and other meetings and provide people with uninterrupted time to do their most important work.
Because if they can't get it done during business hours, you end up doing it at 10:00 at night after you put the kids to bed. Or are you doing it on Sundays, when really we want people to do their most important work during
the work day? And so create some psychological safety #2 Create some psychological safety in your organization, what we would call a generative culture where people are OK acknowledging that they have too much on their plate, they're overloaded cognitively, that they need more space and need to reduce the load so they can finish their
most important work. And then the measures, how people are incentivized and measured, because how people are measured is very important to them and they will behave accordingly to make the metrics look good. And so there can be unintended consequences for that. For example, in one organization I worked with, they thought it was a good idea in their cafeteria to put the names of developers who had more than 10 bugs assigned to them.
Because like we called it the naughty list, your name went on the board if you had more than 10 bugs. And what started happening was people were saying, well, no, that's that shouldn't really be assigned to me, That should be assigned to somebody else. And it just caused so much angst that it made things take even longer because people were so fearful and worried about getting on the naughty list. And those bugs, some of them weren't high priority, they were
low priority. So I think it's be very careful about how people are measured and incentivized in your organization. I really love all of them, right? So space, psychological safety and also, you know, measurement, right? So I think really, really important how you measure people. So, Dominica, I can't highly recommend enough for your book, right? So for people who want to check out Dominica's book Making work visible, I think highly, highly recommended.
But for people who want to follow up other resources or your work, is there a place where they can find you online? Yeah, LinkedIn is probably the best place. LinkedIn. There's not too many Dominica degrandises on LinkedIn, so you should have no problem finding me. Just reach out. I'll put it in the show notes. So thank you so much for your time today. Dominica really learned a lot from you. Thank you, Henry.
Appreciate it. Thank you for listening to this episode and for staying right until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode and if you're new to the podcast. Make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better.
You can also find the full show notes of this conversation on the episode page at Techlyjournal dot dev website, including the full transcript, interesting quotes, and links to the resources mentioned from the conversation. And lastly, make sure to subscribe to the show's mailing list on techlyjournal dot dev to get notified for any future episodes. Stay tuned for the next Techly Journal episode, and until then, goodbye.