Technically Leadership

The episode delivers substantive ideas about overconfidence in prediction, the value of data-driven validation through mathematics, and the importance of organizational slack and cross-functional collaboration. However, the insights are somewhat familiar to experienced operators (the mythical man-month, user validation, avoiding over-engineering), and significant portions of the conversation involve repetition, tangential stories, and conversational filler that dilute the density.

“there's one about doing data driven product...these kind of like, fit into an arc...people tend to think that they're better at predicting what's going to happen than they are”

“what if they all did something amazing? Well then we'd have 700amazing events resulting in $30...you can multiply you numbers together and pretty quickly make amazing ideas look bad”

McKinley repackages well-established principles - Conway's Law, the mythical man-month, empirical validation over intuition - through the lens of organizational overconfidence. The 'choose boring technology' framing is somewhat novel but has become its own cliché in engineering circles. The connection between these ideas feels incremental rather than genuinely fresh or counterintuitive.

“I think that that's just people tend to think that they're better at predicting what's going to happen than they are”

“the thing that you're going to have as a fixed point which is like we're going to do this on MySQL even if we don't like it...apply your creativity elsewhere”

Dan McKinley is a legitimate practitioner with meaningful seniority: early Etsy engineer (2007-2014 during critical growth), work at Stripe and other substantial companies, principal engineer and VP roles. His perspective is grounded in real operational experience at scale, not theoretical. However, the interview doesn't fully leverage his depth - questions remain somewhat surface-level and don't push into the hardest parts of organizational change.

“I worked at Etsy from 2007 to 2014...I just like watch it, watch the movie happen like six or seven times at least with like different, different principal actors”

“Etsy like at that period, I, I thought was like a really, really effective engineering organization”

McKinley provides some concrete examples (Etsy product failures, MySQL/memcache/PHP stack, the 700 users × $30 math example, hack weeks in 2007) but remains largely abstract about implementation details. He describes principles but rarely names specific metrics, timelines, or measurable outcomes from organizational changes. The Rackspace anecdote from the host provides more specificity than McKinley's own examples.

“700 people like get to this place on the site a day which is, you know, nothing because millions and millions of people come to the site every day”

“we were doing hack weeks in 2007 when it was completely impossible to raise money like in New York”

The host asks reasonable setup questions but rarely follows up with challenging pushback or probing for deeper specifics. Questions tend toward affirmation ('right?') rather than genuine inquiry. The host doesn't press McKinley on contradictions (e.g., how to actually measure 'organizational velocity' or the real failure rate of boring tech bets), missed opportunities to test claims, and allows abstract discussions to drift. The conversation is cordial but lacks journalistic rigor.

“Right? So I mean you had talked about like getting in contact with users earlier when it came to product for, for the data driven one”

“Right, right”