I want you to think about the way that your team prioritizes, maybe the way you personally prioritize. We've recently talked about the concept of cost of delay on this show. We're going to go a little bit more into this concept in today's episode and talk about different classes of service. This is a concept that is discussed in Kanban most frequently, but it can be applied regardless of your kind of working philosophy. And the idea of classes of service is to change the way you think about or prioritize different types of work based on their cost of delay curves. What do I mean by a cost of delay curve? Well, first, let's talk about the different classes of service. This is probably the best way to understand the cost of delay curve. There are different classes of service that are typically discussed. The ones that are most commonly discussed are standard, fixed date, expedited, and standardized. Standard, fixed date, expedited, and intangible. And each of these tends to have a curve that the cost of delay would look like. In a standard cost of delay, generally speaking, the curve will most match something close to linear. It is often, you know, you will discount that over time. So it might look a little bit more logarithmic, like it has a little bit of a curve off. So the sooner something is done, generally speaking, the more valuable it is. But generally, these tasks are going to be your standard work items. These are things that your product team is likely doing, you know, product briefs on. These are things that you expect to do, the things that tend to be on your roadmap. So, you know, you're going to have to do a lot of work on your roadmap. Another thing that will likely show up in your roadmap is that you're going to have to do a lot of work on your product team. Another thing that will likely show up in your roadmap are fixed date items. Fixed date items look like a cliff. There's some kind of hard date where the value delivery, all right, the value delivery changes drastically in a moment. In other words, there is a point in time where the value goes drastically down or the cost goes drastically up. Now, remember, cost of delay isn't just talking about, you know, money that you would have to pay out. This is talking about opportunity cost, operational costs. It may be talking about, you know, issues with downstream consumers and costs associated there, resources, etc. So the fixed date costs tend to look like a cliff. And usually this is representative of some kind of commitment. It might be representative of, for example, a SOC audit. Fixed dates don't always have just one cliff as well. You may have kind of like a monthly cliff where the cost increases in kind of a stair step motion. This is, for example, how taxes might look. Delaying doing your taxes past a specific date would incur a fee. And that fee happens immediately. Also, if you're in the United States, that is the soft reminder that your taxes are due in about a month. The category of expedite tends to look like an exponential curve. Expedite may also look like a very steep linear curve. Interestingly, an exponential curve and a linear curve on their far right portions kind of look similar. The final curve I want to talk about is the intangible curve. And the intangible curve. Doesn't have one specific shape. It has more of a range. If you think about it like a like a hurricane prediction chart. And you can imagine that the hurricane prediction chart looks kind of linear, like a fairly low value. But it could have a sudden upturn that looks exponential. The idea being that the cost of delay is difficult to predict, perhaps more difficult to predict for these particular types of items. So what does all this mean? And how does it affect the cost of delay? How should you rationalize it? How should you think about prioritization between these items? And why do these curves look different? We're going to talk about that right after we talk about today's sponsor. In a perfect world, you have your code base perfectly documented. But the truth is, you probably remember the last time you had a question about your code base. And you spent hours digging. You spent hours looking through Slack channels, PRs, Jira tickets, and wikis looking for the answer. Or what about the last time you bounced out of the IDE to answer a colleague's question? Maintaining a shared understanding of a code base, much less multiple code bases, gets harder as an engineering team grows. And getting answers to questions also becomes more time consuming when you're onboarding new team members or working on refactoring existing projects. This all becomes even harder when you actually do have documentation. But it turns out that half of it is out of date. Unblocked solves these time sinks. It provides helpful and accurate answers to your questions about your code base in seconds. And these answers are specific to your team and specific to your code base because it complements your source code with relevant discussions from GitHub, Slack, Jira, Notion, Confluence, and more. Like an extended team member who never sleeps, Unblocked is aware of every decision, every discussion, and every part of your code base. And it's a great way to get your code base in place. And it's a great way to get your code base in place. And it's a great way to get your code base in place. With Unblocked, teams ship faster by spending less time digging for information and dealing with interruptions. Check out Unblocked at getunblocked.com. That's getunblocked.com. We're talking about cost of delay in today's episode. If you've never done a cost of delay exercise, I encourage you to do it. Do a quick poll. Imagine you and your product manager or product owner, maybe your boss, whoever that is, maybe it's an engineering manager or director. You all get in a room, a quick Zoom channel, and try to evaluate, independently evaluate, what is the cost of delay for a given epic, a set of stories that you might have in your backlog, or for a given feature. And try to name this cost of delay in some common unit. Don't allow people to create a story around their cost of delay. You want to have some common unit so that you're comparing apples to apples. Usually the best unit to do this with is dollars or whatever form of money currency your team uses. This may be a common language that you have within your team that you measure cost with differently. For example, losing. A certain number of acquisitions might represent cost for a sales team. What you'll find is that very likely, if you're not measuring cost of delay as a team and you're using just your best guess, that you're going to have a wide variance between the different people who are involved in the discussion. And if you were instead to provide a simple calculation, some kind of simple framework for calculating cost of delay, then your variance will drastically be reduced. And this is important for a lot of reasons. One of the simplest reasons is so that you can communicate about different variations in priority based on the actual value that's going to be delivered for that particular piece of work. But the next step is in understanding the curve in the cost of delay. For example, if you have that fixed time or fixed deadline curve, it's not really that much of a curve. It depends on the time. Frame that you're evaluating it for. If the deadline is in three months from now and you're evaluating the weekly cost of delay for the next two months, then the cost of delay is going to be fairly minimal. It's only once you hit that cliff that the cost of delay actually actually comes into play. So how do we rationalize between these different curves in cost of delay? As with many things that are worth talking about. The answer is. It's truly that it depends. But we don't want to leave it there. What does it depend on? How can we make a decision in a given context based on, let's say, two items with different curves? So I'm going to discuss a common scenario, perhaps two common scenarios. And then we'll discuss why certain decisions might be made in those in those scenarios. So scenario one is that you have a fixed deadline that's upcoming. And you also have some normal work, some kind of feature work that you want to prioritize against the fixed deadline work. The fixed deadline work has some value once it's delivered. Let's say you're going to win a particular contract, whereas otherwise you would not have. And in particular, that contract has to be done by a certain date. It's a drop dead deadline. And the feature work has some cost of delay. Which is kind of the flip side of the coin of value as well. Once you deliver these features, you can predict that you're going to have some kind of value delivered to your consumers. Now, let's imagine that the feature delivery cost of delay. Let's say it's, you know, let's say both of these take three weeks for simplicity's sake. You're going to deliver a feature in three weeks or you're going to meet the deadline by focusing on that particular set of work in the next three weeks. Let's imagine. That your potential value. Right. The cost of delay is greater for the feature work than it is for the fixed deadline work. In other words, the feature is going to potentially net you, let's say, $20,000 a week. And the fixed deadline work is only going to net you on average $15,000 a week. The rational decision in this situation is to focus on the feature work and to allow that particular deal. Whatever it was that was causing that cliff or the fixed deadline to fail. Now, this seems counterintuitive. It seems like deadlines always win. But I want to dig into the primary protests against this method and against this kind of rationality. The first thing that I'm hearing in the back of my mind from my many years of working with product counterparts and customer service counterparts is that the relationship is worth more. You know, that integrity of the relationship is worth more than delivering the feature. In this case, and in many cases like this, we need to account for that in the cost of delay model. In other words, the cost of delay may look like we're only accounting for winning that particular contract. But we may also need to account for the loss of trust with whoever that particular consumer client is. So if we say that we're 20% less likely to work with them in the future, what does that translate to in terms of cost of delay? And most kind of objections to this way of thinking that you would prioritize feature work over some kind of fixed deadline work. Most objections to that are because the cost of delay or the evaluation of that value delivery is not going to be the same. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. It's going to be different. We're not actually counting the cost that we would incur of missing that deadline completely. So let's imagine that we lose this client forever. And we want to calculate what that cost of delay impact would be. Maybe the lifetime value of that particular client for your business is $2 million. And we risk losing them by 50%. We have a 50% shot now rather than if we were at 100% before if we made this deadline. Now that we've missed this deadline, maybe we put that relationship in jeopardy. And now we're at 50%. So $2 million of potential lifetime value from this particular partner, from this client. And we multiply that using a utility function of 50%. Because now we are only 50%. And we're not certain that we're going to renew this relationship. That would create a cost of delay of $1 million. Now the alternative protest here is that that's not real money. That we're talking about theoretical money. We're multiplying out the lifetime value of this particular partner. And the truth is that we're doing that with the feature work as well. If we say, oh, the cost of delay for this feature work is X number of dollars. Well, that's not real money either. We don't know who's going to adopt. We don't know what its impact will be. We are predicting that we will make a certain amount of money in this certain amount of time. So one antidote, if you feel like your cost of delay models are not representing reality or these kind of A-B comparisons between value generation, cost of delay in one situation, cost of delay in another situation, is to ensure that your cost of delay models are inclusive of those kinds of considerations. The potential loss of a client. For example, making sure you're counting the costs associated with all of those parts of the puzzle. Now it's reasonable to also expect that your feature delivery may incur similar theoretical costs of delay. Like for example, if people were expecting new features to come out and they didn't, then you might be eroding trust with those consumers as well. So if your feature delivery was for the, like a GA release, right? General audience release. Then perhaps you erode your trust. With them by some small percentage, maybe one or 2% rather than the larger 50%. But if you're eroding your trust with all of your consumer base by one or 2%, and depending on how large your consumer base is, that may actually have a larger impact than eroding the trust with that one particular consumer by 50%. So now you can see why we say it depends, but it can be rationalized, right? We can actually go down the path of the trust. And that's the key to making better decisions this way. In most cases, you will have a pretty clear winner. You'll recognize the cost of delay in a given search, a circumstance for a given period of time. And you'll be able to prioritize with, with pretty clear gaps. The one specific kind of work I'd like to discuss and then provide you with a way of thinking about, you know, de-risking based on this kind of work is the intangible work. Again, this is based on the intangible work. This is based on the idea that the work is representative of some unknown amount of risk that could have a sudden spike, right? An example of this might be technical debt. If that technical debt is masking a problem that then results in some major outage of your product on some given day, then the risk profile for that goes sharply up. Your cost of delay went from, you know, a very low amount to a very high amount based on some event that you did not predict. Another slightly more predictable example of this intangible work might be scaling a database. Let's imagine that your business is growing at a fairly steady rate. And you recognize that the database instance that you're currently using, you're going to max out that resource in some period of time. Now, the period of time is, where the variability comes into play. If you grow at a steady rate for the next, let's say, six months, then it's possible that your database is going to be just fine for that amount of time. But it's also possible that any one big client could double your resource needs. And so once again, you have a highly variable cost of delay curve in this situation. Think again about that. At the very lastension, the path of a given hurricane, the further out it goes, the more uncertainty there is. And it's very possible that the hurricane takes a sharp turn that you did not expect it to take. So a practical strategy that I can recommend here dealing with intangibles is to try to find the intangibles that have the highest cost of delay risk. Now we're going to define this so you can kind of write this out. The cost of delay risk that we're going to sort these items by. So this is your tech debt backlog. You're going to look for items that have a high variance of cost of delay potential. So in other words, maybe this will cost us $10. Maybe it'll cost us $1,000. Maybe it'll cost us $100,000 or $1,000,000. This is a high variance of cost of delay. And more specifically, you're looking at variance both in the vertical and the horizontal axes. So in other words, it might cost us $1,000 every day for the next year or two years, or it might cost us $1,000 today and $1,000,000 tomorrow. Of course, we're basing this off of risk profiles of likelihood, right? So I want you to do some analysis to determine what is the likelihood of delay risk? And if you do that, you're going to get a lot of data. So I want you to do some analysis to determine what is the likelihood that this variance is high. In our previous example, it is possible that you get a mega corporation that requires you to double your resources, but the likelihood of that may be fairly low. An important mental model you might make use of here is what we talked about in previous episodes recently about the average. This is not a time that you want to use an average. Instead, you want to use a distribution. You want to look at something like the normal distribution of variance for a given tech debt item. Now, this is not something that's easy to produce. This is not something that most teams are likely to have. So what you're really trying to do here is come up with a reasonable guess, right? So for a given item in your backlog related to tech debt, you might say, okay, for the cost of delay, you're going to need to double your resources, right? So what you're going to need to double your particular tech debt item, I think there is a median of, let's say, $10,000 a week with a standard deviation of $20,000 a week. Or perhaps you recognize that the distribution is not actually normal, that it's skewed. And it's not necessarily likely that anyone listening to this podcast is trying to fit a curve with relation to the risk of any given tech debt item in your backlog. But instead, you're trying to identify, okay, which of these has the highest likelihood of high variance? That's the nutshell version of this. And even if you just bucket these into, okay, this has a high likelihood, this has a medium likelihood. If you were to take the bucket that has high likelihood of high variance, and then all you're going to do is sort by the amount of time required to remedy the issue, to deal with the issue. And then you're going to sort by the amount of time required to deal with the tech debt. And we're going to take the shortest item on the list. And what we're going to do here is we're going to view this like a risk management exercise, like a portfolio. You're making investments in a potential return. Again, this is the flip side of cost, right? Cost of delay is the flip side of value delivery. So you're making an investment with an uncertain return. And these investments are going to be weighted towards the ones that have the highest likelihood of growth, the highest likelihood of a high cost of delay in a short amount of time. This kind of framework works best if you can dedicate a certain amount of time, very similar to setting aside a percentage of your income into an investment. Again, remembering that the value delivery of this, it may not be immediate. And in fact, you may actually never be able to get a certain amount of return. So you may never know whether that investment was good. Unlike a stock portfolio, you're not going to get clear returns on investments here. You may just never experience that potential cost that you had outlined. Similarly, if you invest in that fixed deadline work, you don't know necessarily what the risk was of missing the deadline because you never actually incur that cost. But it's important here to recognize that cost of delay, and this framework more generally, is not looking at profit versus loss as two separate categories. Cost of delay, in this case, is talking about potential loss of opportunity, as well as actual spend. These are kind of combined into a single kind of fluid metric. In other words, you could have a hundred dollars in your bank account and have a real and tangible return on investment. And you could have a hundred dollars in your bank account and have a real and tangible return on investment. And you could have a hundred dollars in your bank account and have a real and tangible cost of delay of three million dollars, even though you could never actually pay out three million dollars. In this case, the cost of delay is going to be an opportunity cost rather than an actual resource cost. There's so much more that we could talk about here in comparing when to invest in a particular direction, how to use these curves for cost of delay. And if you're interested in talking more about this specific subject, let me know. Well, send me an email at developer T at gmail.com. You can also contact me in our discord community, head over to developer t.com slash discord. I'm there. And a ton of a ton of other listeners are there as well. Thank you again to today's sponsor unblocked. If you would rather spend your time coding, instead of digging for answers or dealing with questions from colleagues, give unblocked to try unblocked provides helpful and accurate answers to questions about your code base. Get started with unblocked. Get unblocked.com. That's get unblocked.com. Thanks so much for listening. And until next time, enjoy your tea.