#156 - Making Work Visible: Exposing Time Theft to Optimize Work & Flow - Dominica DeGrandis

[00:01:10] Episode Introduction

Henry Suryawirawan: Hello to all of you, my friends and my listeners. You’re listening to the Tech Lead 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 Tech Lead Journal’s various other contents on LinkedIn, X, Instagram, YouTube, and TikTok. And consider supporting this podcast by either buying me a coffee at techleadjournal.dev/tip or becoming a patron at techleadjournal.dev/patron.

My guest for today’s episode is Dominica DeGrandis. Dominica is the author of one of my favorite books, “Making Work Visible”. In this episode, 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 visible 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.

[00:03:28] Introduction

Henry Suryawirawan: Hey, everyone. Welcome back to another new episode of the Tech Lead 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 DeGrandis. So Dominica, thank you so much for your time. Looking forward to our discussion today.

Dominica DeGrandis: Delighted to be here. Henry. Thank you.

[00:03:47] Career Journey

Henry Suryawirawan: 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?

Dominica DeGrandis: All right. Well, my first job out of university was at Boeing Airlines. It’s a very large company, and I felt very ill prepared. I didn’t know what to expect based on the courses that I had 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 an 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 in 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 head count 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 gonna 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 DevOps. And I got very involved in the DevOps community. I was just happened to be in the right place at the right time. I was just kind of lucky to meet all these great luminaries of the DevOps community and teach them Kanban and be able to help out the practitioners working in the trenches who were really suffering from being overloaded. You know, 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, 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 of looking at entire value streams now instead of just individual team metrics.

Henry Suryawirawan: 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?

[00:08:45] Making Work Visible & Five Thieves of Time

Henry Suryawirawan: 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?

Dominica DeGrandis: Yeah. Well, 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. So the part one and part two sort of introduce these concepts, identify how you can see that this is happening in your organization. And then part two 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 WIP do you have? Our team has, you know, 110 items just in the validate state. 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 needed it already. We needed it six months ago. And if we look at the team pain 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 three of 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 increase 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 thief 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 through 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.

Henry Suryawirawan: 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 Kanban 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?

[00:15:31] Thief: Too Much WIP

Henry Suryawirawan: 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 you, if your analogy is a thief, right? This is like the thief of all thiefs. So tell us more what is too much WIP, why is it a problem and what can we do about it?

Dominica DeGrandis: 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 gonna 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 it 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. We’re human. And so we wanna 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.

[00:18:33] WIP is a Leading Indicator

Henry Suryawirawan: 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?

Dominica DeGrandis: Yeah. So people always say, well, what should our WIP be ? Usually the answer to that is lower. You know, a hundred 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 WIP 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 canceled work, that kind of thing. All things that everybody has. But that conversation alone, and looking at that math, 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 teams, they’ll have their planned work. Can we talk about unplanned work now?

Henry Suryawirawan: Sure. Yeah.

[00:20:45] Thief: Unplanned Work

Dominica DeGrandis: 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 an urgent need to get through fast. What happens with that unplanned work now? Is that the work that you were going to get through checkout faster, but now your checkout time is gonna 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 wanna 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.

Henry Suryawirawan: Right.

Dominica DeGrandis: Yeah.

Henry Suryawirawan: Yeah. So speaking about unplanned work, I’m sure these days in software engineering team, right, they can relate too. Things like, for example, if there’s a customer complaints, incidents, right? Downtime or whatever that is. Or sometimes it’s just bug, 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.

[00:23:04] Making Sense of WIP

Henry Suryawirawan: 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, burdened by a lot of these tasks. And some of the solutions actually are things like, for example, you set up a Kanban. 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 WIP and, kind of like solve this problem?

Dominica DeGrandis: Yeah, a number of ways. One of my favorite 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, we’ll have capacity to pull more work into our workflow, because we finished work. And this stems from Arne Roock’s work and his famous quote about “stop starting and start finishing”.

[00:24:38] Thief: Conflicting Priorities

Henry Suryawirawan: 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?

Dominica DeGrandis: Yeah, yeah. This is where having a crystal clear prioritization, policy, and process in place is going to help. It’s where having psychological safety and a generative culture comes into play so that people can be okay with knowing when they have to say, actually, we don’t have capacity for that right now. Or say, oh, okay. This is now the number one priority. This is when yesterday’s number one 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 could do x number of features over a period of six weeks. And we had a capacity for five of those, like five features. And we put the decision on the leaders to prioritize that list.

So there might’ve been a hundred 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 so you got five spaces. We can have five 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 yours 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. Like, 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, then 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.

Henry Suryawirawan: Thanks for covering this conflicting priorities, right? Because prioritization probably is one of the root cause of too much work in progress, right? 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 leadership 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?

[00:29:17] Thief: Unknown Dependencies

Henry Suryawirawan: 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 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?

Dominica DeGrandis: 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 priority is 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 timeframe. 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 skillset 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 wanna 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 unessential work off of the bottlenecks plate, right?

Here’s where we talk about bottlenecks with blockers. How can we find help for that bottleneck area? How can we invest in new tools and processes to help that bottleneck 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.

Henry Suryawirawan: 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 solutions. Seems 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.

[00:32:53] Managing Dependencies

Henry Suryawirawan: I mean, I just wanna highlight one quote that you put in the book, so every dependency doubles 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 wanna cover on that?

Dominica DeGrandis: Yeah. That quote actually came from Troy McGinnis 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 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 are… You know, there’s like eight different, scenarios that could occur. And so every time you add an additional dependency to that list, it, just doubles the probability that you’re gonna be that much later. So the number of blockers and dependencies impacts it. And it’s why, you know, like Team Topologies, such a popular book, where they talk about organizational structure and sort of what to do about that. And you mentioned Conway’s Law, you know, for those on listening, Conway’s Law is 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 gonna follow practices that are well optimized for optimization of an end-to-end workflow and end-to-end value stream. The goal of which is to deliver high level business value to the customer. Yeah. So, I think that we need to be clear about what practices we’re gonna use for decisions in organization and how those groups are gonna 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 and on about how teams are measured and how it can negatively impact… You know, “tell me how you’re gonna measure me and I’ll tell you how I’m gonna 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.

Henry Suryawirawan: 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.

[00:36:40] Thief: Neglected Work

Henry Suryawirawan: The last one that we haven’t covered is the neglected work. Some people call it, you know, uh, 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?

Dominica DeGrandis: 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 deprioritized or have a lower priority. And it also is waiting. It 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”?

Henry Suryawirawan: No, I haven’t.

Dominica DeGrandis: Okay. 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 that’s 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 in how long it takes to deliver things, the more neglected work we have in the system, the lower the probability is that we’re gonna 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. 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 gonna deliver requests. And neglected work just will blindside us to that, cause we, we don’t see it coming until it turns into an emergency, sometimes.

Henry Suryawirawan: Yeah. So I think it’s very important to understand this quadrant, important, urgent, right? Neglected, which probably is like an important thing, but sometimes not urgent. And it’s always important for us to analyze and make sure that we raise, you know, the urgency or the priorities for the team to work on.

Dominica DeGrandis: Yeah. Just one more point. One more point on how neglected work is often technical debt that is not on the radar of 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.

Henry Suryawirawan: Right. Thanks for adding that. Yeah, technical debt is always tricky whenever engineering team wants to raise it, right, so how can their business also prioritize that?

[00:41:21] Make Organization Work Visible

Henry Suryawirawan: 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?

Dominica DeGrandis: Yes, absolutely. Working with a team right now where one of their OKRs, 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. Okay. Well, in their tool set, they have a work item type 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 of, you know, did they meet their 30%?

So that’s pretty… that’s so far so good. But defects aren’t their only OKRs. So another OKR 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 in 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 four 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? 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, you know, outside of their features and their security items, outside of their stories, they only were able to deliver less than 2.5% 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 gonna work… We only got 100%. What are we gonna work less on? And then some organizations can actually set their WIP limits per that artifact type.

Henry Suryawirawan: 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 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.

Dominica DeGrandis: 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 know, 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 in 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, may be 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 discovered that they had 11 months of large capabilities queued up, that they were only delivering one in six of those capabilities in a quarter 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 a quarter, 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, prioritization decisions that are happening that may be outside of the team’s control.

Henry Suryawirawan: 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 features that the team is working. But look at it from the higher level. And second thing you mentioned about capabilities, 90 days long. Sometimes we don’t have equal batch size, right? So that’s why it’s very, very important to reduce your batch 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 and manage them properly.

[00:50:19] Measuring Flow

Henry Suryawirawan: So the other thing is about how to measure, right? So after you make the work visible, you mentioned a couple of times about flow metrics. Maybe what can the leaders or managers do in order to measure, start measuring how they get things done?

Dominica DeGrandis: Well, I would start with what prevents the team from getting their work done. And if the response to that is too much WIP on our plate, then we need to measure how much WIP 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. 60, 90, 120 days. And what are we gonna 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. Okay, 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. Cause if you ask, if teams are measured at the individual team level, they’re gonna wanna 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 wanna 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 have 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.

Flow efficiency, I think is a really hard metric to measure, and because usually there’s never enough wait states. And even if an organization has a lot of wait, 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, oftentimes people won’t put the work in that state.

I don’t know, they say there’s too much overhead. Or they don’t wanna 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. And 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 80-90%, which just is inaccurate because there’s insufficient wait states in the tool sets. If you are able to measure, if you do have good wait 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.

Henry Suryawirawan: 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.

[00:55:11] 3 Tech Lead Wisdom

Henry Suryawirawan: So Dominica, unfortunately, due to time, we have to cut it here. But I have one last question for you, which I ask 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 three technical leadership wisdom?

Dominica DeGrandis: Yeah. Well, I think that we’re asking people to adapt to change rapidly now, and that people are overloaded and stressed out, and it’s 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 o’clock 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 workday.

And so create some psychological safety. Number two, create some psychological safety in your organization. What we would call a generative culture where people are okay 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. It’s 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 be very careful about how people are measured and incentivized in your organization.

Henry Suryawirawan: 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 your book, right? So for people who want to check out Dominica’s book, Making Work Visible, I think highly, highly recommend it. But for people who want to follow up other resources or your work, is there a place where they can find you online?

Dominica DeGrandis: Uh, yeah. LinkedIn is probably the best place. LinkedIn, there’s not too many Dominica DeGrandis-es on LinkedIn, so you should have no problem finding me. Just reach out.

Henry Suryawirawan: I’ll put it in the show notes. So thank you so much for your time today, Dominica. Really learned a lot from you.

Dominica DeGrandis: Thank you, Henry. Appreciate it.

– End –