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
- Luna: So we've talked a lot about developer productivity and process — but one thing that always trips up teams is deciding what to build next. Lucas: Yeah, the backlog debate. Everyone has an opinion, and without a framework, the loudest voice wins. This episode we're looking at Cost of Delay — an economic framework that one CTO I spoke with uses to rank every feature request. Luna: Remind me — Cost of Delay is basically the cost of not building something now, right? Lucas: Exactly. It's the revenue or benefit you lose per unit of time if you delay a feature. Combine that with job size, and you get Weighted Shortest Job First — or WSJF. The CTO I spoke with, at a mid-size SaaS company — about 50 engineers — adopted this two years ago. Luna: What drove him to it? Was it just arguing in backlog meetings? Lucas: Pretty much. He said the product team would present a prioritized list, and engineering would push back because the estimates seemed off. But there was no common language for why feature A was more important than feature B. So he introduced Cost of Delay as that language. Luna: How does it work in practice? Do they actually calculate a dollar figure? Lucas: That's the key — they do, but loosely. The formula is simple: Cost of Delay equals the value per time unit, divided by the job size in story points or ideal days. Value breaks down into three components: revenue impact, customer satisfaction, and strategic value. For each feature, the product manager estimates a rough delay cost per week. Luna: Rough — so not a precise number. Lucas: Right. They use t-shirt sizes for cost of delay: small, medium, large, extra large — mapped to dollar ranges. Small might be $1,000 per week, medium $5,000, large $20,000. That's enough to rank. Then engineering estimates job size in story points. Divide cost of delay by story points, and the highest number goes first. Luna: So it's not just about value — it's about value per unit of effort. That makes sense. A huge feature with high value might still be lower priority than a small feature with medium value if the small one ships faster. Lucas: Exactly. He gave me a concrete example. They had two features in the backlog: a data export tool for enterprise customers and a redesigned login page. The data export tool had a cost of delay of $10,000 per week — large, because several enterprise deals were pending that required it. The login page had a cost of delay of $2,000 per week — medium, mostly UX improvement. Luna: But the login page was estimated at 20 story points, and the data export tool at 80 — so the ratios would be $10,000 over 80 — $125 per point for data export — and $2,000 over 20 — $100 per point for login. So data export wins by a narrow margin. Lucas: You got it. And that's exactly what they did. But here's the interesting part: the login page was labeled 'urgent' by the product team because the CEO wanted a fresher look. The Cost of Delay framework gave them a way to say, 'This is important, but the data export tool is more valuable per unit of time.' So they did the data export first. Luna: And how did the CEO react to that? Lucas: The CTO told me he brought the CEO into the process. He showed him the numbers, and the CEO agreed. In fact, the CEO started using Cost of Delay language himself in meetings. That's when the CTO knew it had stuck. Luna: So it's not just a prioritization tool — it's a communication tool. Lucas: Exactly. It gives everyone a shared vocabulary. But it's not perfect. One pitfall the CTO mentioned: teams can over-optimize. They start spending too much time estimating cost of delay precisely, trying to get exact dollar amounts. He had to remind them that rough is fine — the point is to rank, not to predict revenue. Luna: I can see that. If you spend three hours debating whether a feature costs $4,000 or $5,000 per week, you've already lost. Lucas: Right. He caps estimation time at 15 minutes per feature. Another pitfall: they initially used cost of delay as a static number, but it changes over time. A feature that's worth $5,000 per week in Q1 might be worth $1,000 in Q3 if the market shifts. So they revisit the backlog monthly and update cost of delay estimates. Luna: That makes sense. What about dependencies? Sometimes a small feature unblocks a big one — does the framework account for that? Lucas: That's a good point. The CTO said they handle dependencies by grouping features into 'value streams' — a set of features that together deliver a business outcome. They estimate cost of delay for the whole value stream, not individual features. Then within that stream, they use WSJF to sequence the components. Luna: So they're essentially doing hierarchical prioritization. Lucas: Exactly. And they found that this reduces the 'dependency debate' — because if a feature is part of a high-cost-of-delay stream, it gets done faster even if it's not the highest individually. Luna: One thing I wonder — does this work for teams that aren't building revenue-generating features? Like internal tools or platform teams? Lucas: Great question. The CTO said they adapted it. For internal tools, cost of delay is measured in terms of developer time saved or risk reduction. For example, a CI pipeline improvement that saves 10 developer hours per week — they estimate that at, say, $1,500 per week based on fully loaded cost. Then same formula. Luna: So it's still value — just a different kind of value. Lucas: Right. And it forces platform teams to think about their customers — other engineers — and quantify the impact. He said that alone shifted the culture from 'we build cool stuff' to 'we build stuff that makes the company faster.' Luna: What about when a feature has zero direct cost of delay? Like something nice to have but not urgent. Lucas: That's the bottom of the backlog. They create a separate 'innovation bucket' — maybe 10% of capacity — where they pick low-cost-of-delay features that are small and fun. It keeps the team motivated without disrupting the priority order. Luna: That's smart. So the framework doesn't kill creativity — it just contains it. Lucas: Exactly. And that's the philosophy: Cost of Delay isn't a straitjacket, it's a starting point. The CTO said the biggest win was that after implementing it, the number of 'emergency' features dropped by 60 percent. Because when you surface the real cost of delay, a lot of so-called emergencies turn out to be low value. Luna: That's a tangible result. And it aligns with what we hear about good prioritization — it's about making trade-offs visible. Lucas: And that visibility is exactly what enables better decisions. If you're a CTO or engineering lead, even just introducing a rough cost of delay for the top ten features can transform your backlog meetings from opinion battles into a collaborative ranking exercise. Luna: You know, speaking of things that make a real difference with small effort — that's actually how I feel about listener support for this show. Lucas: Same here. A couple of dollars a month from people who find these conversations useful genuinely keeps us going. If you've gotten something out of this episode, you can throw a coffee our way at buy me a coffee dot com slash fexingo. Luna: It really does make a difference. No pressure — just if you want to help keep the episodes free and ad-free. Lucas: Alright, back to Cost of Delay. One more thing the CTO shared: they actually started using the framework for bug fixes too. A bug that costs $10,000 per week in lost customer trust has a high cost of delay. So it gets fixed before a feature with lower delay cost. Luna: That makes a lot of sense. So it's a universal lens for prioritization. Lucas: Exactly. And the key takeaway from this CTO: start simple. Pick one value stream, estimate cost of delay for the top five features, and see if it changes your next sprint. If it does, expand from there. Luna: Seems like a low-risk experiment with potentially high reward. Lucas: That's the idea. And if you try it, let us know how it goes. We'd love to feature your story on a future episode. Luna: Thanks for listening.