Dev Interrupted

The episode contains a handful of genuinely useful operational observations - notably the two-layer MCP data approach and the P90-over-average methodology - but these are surrounded by large stretches of generic AI commentary, chit-chat about token models, and restatements of obvious points. The insight rate is uneven.

“the most useful measure is, you know, cost per contribution, AI spend divided by contribution. You know, it's a very simple one. You could compute it as spend per merged merge request or per engineer per Sprint”

“we prefer P90 to average for example. Right. Um, because we want to find out the slowest 10%. You know, we don't want an average because it flatters us”

The timezone-as-dominant-bottleneck finding is a genuinely counterintuitive and evidence-backed claim that cuts against the common 'large PRs are slow' narrative. Most of the rest - data-context-insight-action, AI as a partner not replacement, Goodhart's Law - is recycled from standard engineering management discourse.

“first of all, we assume that big complex merge requests were what was slowing the review time down...But we joined up the data and we looked at it and size and complexity accounted for maybe 5 to 10% the slowdown”

“70 to 80%. Something like that came from time zone differences, a hunch that we didn't even think about too much”

Nik Sudan is a genuine practitioner running engineering operations at Kraken, a large-scale crypto exchange with thousands of engineers, and he speaks from real operational experience rather than theory. However, he is a LinearB customer selected for a vendor interview series, which caps independent credibility, and his title (Engineering Operations Lead) is mid-senior rather than C-suite.

“review time in my view is arguably the most important part of cycle time and it is the current bottleneck for us and probably the bottleneck for many companies right now”

“our designers are a lot more hands on now with coding...working in a separate repository...when it's time to productionize they just hand over the repository, the files, the Linux engineers”

The timezone bottleneck finding is well-quantified with approximate splits (5-10% size vs 70-80% timezone) and the cost-per-contribution metric is concretely defined. However, no absolute dollar figures for AI spend are given, timelines are absent, and most other claims remain at a conceptual level.

“size and complexity accounted for maybe 5 to 10% the slowdown. Right. 80, 70 to 80%. Something like that came from time zone differences”

“cost per contribution, AI spend divided by contribution. You know, it's a very simple one. You could compute it as spend per merged merge request or per engineer per Sprint”

This is a vendor-produced interview with a customer guest; the host never challenges a single claim, frequently restates the guest's answers at length before asking the next question, and steers conversation toward LinearB product mentions. A mid-episode promotional break by a third voice further underscores the format's PR nature rather than journalistic depth.

“So what I hear about some of, like, the shape of how y' all think about A.I. here's what I, here's what I hear. It's like, it's almost like this um, permeable barrier”

“your CFO, they aren't looking at adoption rates or token counts anymore. They want to see what all of that generated code is actually delivering for the business”