Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Cost of Delay to Prioritize Features
Transcript
- Lucas: If today's tech conversation gave you something usable, a couple of dollars a month is genuinely what keeps these going — buy me a coffee dot com slash fexingo, if you've gotten something out of them. Luna: Yeah, it's a small thing that adds up. And we're ad-free because of it, which I love. Lucas: Exactly. So back to prioritization — let's get into the numbers. Have you ever seen a team that just cannot decide what to build next? Luna: All the time. It's usually a battle between the loudest sales rep and the CEO's pet project. Lucas: Right. That's the HiPPO problem — Highest Paid Person's Opinion. And it's terrible for outcomes. But there's a framework that actually fixes this: Cost of Delay. Luna: Cost of Delay — I've heard of it, mostly in lean and kanban circles. But how does it work in practice? Lucas: So Cost of Delay is essentially the economic value of delivering something sooner versus later. You quantify what it costs your business if a feature is delayed by a month, a quarter, whatever. And then you combine that with job size to get a priority score. Luna: And that's WSJF, right? Weighted Shortest Job First. Lucas: Exactly. Cost of Delay divided by job size gives you a WSJF score. The higher the score, the sooner you build it. It's like return on investment per unit of time. Luna: But how do you actually quantify Cost of Delay? Isn't it just made-up numbers? Lucas: It can be, if you're sloppy. But there's a structured way. You break Cost of Delay into three components: business value, time criticality, and risk reduction or opportunity enablement. Business value is things like revenue increase or cost savings. Time criticality is how urgent it is — like a regulatory deadline. And risk reduction is how much this feature reduces future risk or enables other opportunities. Luna: So it's like a three-dimensional scoring. But how do you get agreement on the numbers? That's always the hard part. Lucas: You use relative estimation, not absolute. You pick a baseline feature — say, 'add a simple export to CSV' — and give it a one in each dimension. Then you compare everything else to that. It's like planning poker for value. The team and stakeholders together debate and assign numbers like 1, 2, 3, 5, 8, 13. It forces trade-offs. Luna: So it's not about precision. It's about alignment. Lucas: Exactly. The CTO I talked to — let's call her Maria — runs a B2B SaaS company with about 50 engineers. They were drowning. Sales demanded custom integrations, product wanted new features, and infrastructure needed upgrades. Everything was 'top priority.' She introduced Cost of Delay in a quarterly planning session. Luna: How did the team react? I imagine some pushback. Lucas: A lot. Sales didn't trust it because their favorite features scored low on time criticality. But Maria ran a pilot on one team for one quarter. She had them prioritize using WSJF for every new feature request. At the end of the quarter, that team delivered 40 percent more value — measured by customer adoption and revenue impact — than the teams using the old method. Luna: Forty percent? That's huge. What was the old method? Lucas: Basically first-come-first-served with executive overrides. The loudest voice won. Cost of Delay gave them a data-backed argument. One example: a big customer wanted a specific API integration. Sales said it was urgent. But when they scored it, business value was high — 8 — but time criticality was low — 2 — because the customer wasn't leaving. And risk reduction was 1. So WSJF was 11 divided by a job size of 13 — less than 1. Meanwhile, a small internal tool to automate deployment scoring had a WSJF of 3. They built that first, and it saved the team 10 hours a week. Luna: That's the kind of story that converts people. But what about the argument that Cost of Delay doesn't work for non-product work? Like infrastructure or security? Lucas: Great question. Maria actually applied it to infrastructure, too. For a security upgrade, business value was moderate, time criticality was high — because of a compliance deadline — and risk reduction was very high. That pushed it up the list. The key is to include risk reduction as a dimension. Without it, infrastructure always loses to shiny features. Luna: So it's not just for product. It's for any work that has a business impact. What about the downside? When does Cost of Delay fail? Lucas: It fails when you over-quantify. If you try to be too precise, you waste time arguing over whether something is a 5 or an 8. It also fails if you don't revisit scores regularly — a feature that was low priority three months ago might now be critical. And it fails if leadership overrides the system too often. Then people stop trusting it. Luna: So it requires discipline. What did Maria do to maintain that? Lucas: She made Cost of Delay part of the monthly review. The product team rescored every item in the backlog. And she set a rule: if an executive wanted to override, they had to write down their own Cost of Delay estimate and explain why it was different. That alone cut executive overrides by 80 percent. Luna: That's smart. It forces them to think economically instead of emotionally. Lucas: Exactly. And the result was that engineering started feeling like they were working on the right things. Morale went up, and so did velocity. Because when you're not context-switching between five 'urgent' projects, you actually get things done. Luna: I can see that. So for someone listening who wants to try this, what's the first step? Lucas: Pick one team. Pick a baseline feature. Spend an afternoon scoring your top ten features with the team and stakeholders. Use relative sizing: 1, 2, 3, 5, 8. Don't get hung up on the exact numbers. Then calculate WSJF and see if the order surprises you. It almost always does. Luna: And if the order is controversial, that's the conversation you need to have. Lucas: That's exactly right. The framework doesn't make the decision — it surfaces the trade-offs. And that's where good leadership comes in.