Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Uses Cost of Delay to Prioritize the Feature Queue
Transcript
- Lucas: One of the hardest decisions a CTO makes isn't about architecture. It's about what to build next. Luna: Yeah, the feature queue. Everyone has an opinion — sales wants this, support wants that, your CEO has a pet idea. Lucas: Exactly. And without a framework, it's whoever shouts loudest or has the biggest title. That's why I want to talk about cost of delay today — specifically how one CTO we spoke with uses it to make prioritization systematic. Luna: Cost of delay — that's the Don Reinertsen concept, right? Quantifying the economic impact of not building something. Lucas: Right. And the key insight is that delay isn't linear. For some features, waiting a month costs you a little. For others, it costs you a lot — maybe you miss a market window, or a competitor eats your lunch. Luna: If today's tech conversation gave you something usable, consider supporting the show at buy me a coffee dot com slash fexingo. Listener support is what keeps this ad-free. Lucas: Yeah, it really helps. And it lets us dig into frameworks like this without worrying about sponsors. So — back to cost of delay. The CTO we talked to works at a B2B SaaS company with about 80 engineers. Luna: And they had a classic problem: too many good ideas, not enough teams. Lucas: Exactly. They were using a simple priority matrix — value versus effort — but it felt arbitrary. So they adopted cost of delay, specifically the CD3 metric: cost of delay divided by duration. Luna: CD3 — essentially weighted shortest job first. Lucas: Right. You estimate the cost of delay in dollars per week, divide by the duration in weeks, and get a score. Higher score means higher priority. Simple math. Luna: But estimating cost of delay in dollars — that's the hard part. Lucas: It is. But they didn't need precision. They used ranges: low, medium, high, with anchors. A low delay cost might be 'no revenue impact, just nice to have.' High would be 'losing $50,000 a week in new deals.' Luna: So they put dollar figures on intangibles like competitive pressure, customer retention, even developer productivity. Lucas: Exactly. And once they had that, they ran a real test. They had two features competing: a new integration with a key partner, and a performance upgrade to reduce latency. Luna: Classic choice. New revenue versus tech debt. Lucas: Right. The integration had a high cost of delay — about $40,000 a week — because the partner was launching a campaign and they'd lose mindshare. Duration was estimated at 12 weeks. So CD3 was about 3,300. Luna: And the performance upgrade? Lucas: Lower cost of delay — maybe $15,000 a week — because churn from slow load times was gradual. But the duration was only 4 weeks. So CD3 was 3,750 — higher than the integration. Luna: So the performance upgrade actually won, even though it wasn't the shiny new thing. Lucas: Exactly. And that surprised leadership. But the math showed that fixing performance now had a bigger marginal impact per week of delay. The $15,000 a week was happening right now — the integration's $40,000 was a future risk, but it took longer to capture. Luna: It's a concrete way to compare apples and oranges on the same scale. Lucas: And it changed how the company talked about priorities. No more 'this is strategic' or 'this is urgent.' They had numbers. Not perfect numbers, but a shared language. Luna: What about features where the cost of delay is hard to estimate? Like a new analytics dashboard that might open upsell opportunities but you can't quantify. Lucas: The CTO said they'd still put a number on it — even if it's a guess — because the act of guessing forces you to surface assumptions. And they revisit. If the score was wrong, they adjust. Luna: So it's as much about discipline as about accuracy. Lucas: Right. Another risk they ran into: ignoring dependencies. A feature with a high CD3 might depend on another team's API that isn't ready. So they added a 'blocked' flag and only considered items that were ready to start. Luna: So they didn't just sort by score blindly. Lucas: No. They used CD3 as the primary sort, but then applied constraints — team capacity, dependencies, strategic alignment. The framework gave them a starting point, not the final answer. Luna: I've also heard about cost of delay profiles — like expedite, standard, fixed date, intangible. Did they use those? Lucas: They did. They categorized each feature. Fixed-date items, like regulatory compliance, get a different treatment because delay isn't linear — there's a cliff. For those, they used a different calculation: cost of delay equals cost of missing the deadline. Luna: So the framework is flexible. That makes sense. One size doesn't fit all. Lucas: Exactly. The CTO said the biggest win wasn't picking the right feature every time — it was getting the team to think economically. Engineers started asking 'what's the cost of delay for this tech debt?' instead of just 'this code is ugly.' Luna: That's a cultural shift. Moving from 'clean code' to 'economic value.' Lucas: And it helped with stakeholders. When the CEO wanted a feature, the team could say 'we hear you, but based on our CD3 scores, here's what's higher priority and why.' The CEO could challenge the numbers — which led to better estimates. Luna: So it depoliticizes prioritization. Lucas: To a large extent. Not completely — there's always some politics — but it gives you a data-backed argument. The CTO told me that after six months, they reduced the average time from idea to deployment by 25 percent. Luna: Because they were working on the most valuable things first, not just the loudest. Lucas: Exactly. And they also stopped starting too many things. By ranking everything, they could see which items had very low CD3 — those became 'never' or 'someday,' and they stopped wasting time on them. Luna: So cost of delay isn't just about saying yes — it's about saying no. Lucas: That's the hidden value. Saying no to low-value work is harder than saying yes to everything. But CD3 gives you permission to kill things. Luna: What about the risk of gaming the numbers? If a product manager wants their feature prioritized, they might inflate the cost of delay. Lucas: The CTO said they had that concern. So they made the estimates public — shared in a spreadsheet everyone could see. And they reviewed them weekly. If someone's estimate was way off, it became obvious. Peer pressure kept it honest. Luna: Transparency as a check on bias. I like that. Lucas: It also forced people to own their assumptions. If you say a feature is losing $50,000 a week, you'd better have a story behind that number. The conversation shifted from opinions to evidence. Luna: One more thing — how often did they revisit the cost of delay? Markets change, competitors move. Lucas: They did a full re-estimate every month. But for any feature that was active or in the top 10, they'd check the cost of delay weekly. If a competitor launched something, the cost of delay for a related feature might spike, and they'd reprioritize. Luna: So it's a living document, not a one-time exercise. Lucas: Right. And the key is that they didn't try to be perfect. They accepted uncertainty and iterated. The CTO said, 'I'd rather be roughly right than precisely wrong.' Luna: That's a good mantra for any prioritization framework. Lucas: I think cost of delay, and specifically CD3, is one of those ideas that sounds academic but is surprisingly practical once you try it. Start small — pick one team, one quarter, and just do it for new features. See if the conversation changes. Luna: Any final practical tip for someone starting? Lucas: Don't overthink the dollar amounts. Use relative comparisons first — 'this feature's cost of delay is three times that one.' Then gradually get more precise. And remember, the goal isn't perfect math — it's better decisions. Luna: Better decisions, less politics, faster delivery. That's a win. Lucas: I think it's one of the most underused tools in engineering leadership. Worth a try.