I'm sorry, but by the end of that podcast I was fully willing to go get myself a life sentence for doing something horrible to the presenters. They made two main points:
1. You, as a member of internal IT, are subservient to marketing. Suck their dicks! "You're collaborating, but make no mistake, you're not a partner." (Also, the CEO will "piss on" the CIO whenever he gets a chance.)
2. Internal software development must obviously be "fungible", because it's a thing businesses do, and all the other things that businesses do are. Since every other department spends marginal amounts of ingenuity (and lots of bureaucracy) to do reliable, repeatable things, and managers can "crack the whip" to remove some of the slack+busywork+bureaucracy from their processes, then software engineering (a process of spending one's entire budget of ingenuity each day to create things that have never existed, and for which there is no precedent) must obviously be amenable to the same demands to "work smarter, not harder." And he says this while namedropping the Mythical Man Month.
I don't know about you, but the only thing I want to do in relation to these sorts of companies, is to out-compete them and obviate their markets in the long run, by keeping all my employees healthy and sane instead of "pushing" them to death for no marginal gains. This sort of attitude is precisely why "developing for the Enterprise" doesn't catch on as a trend among startups, no matter how profitable it is.
---
P.S.: They also begin to make the [sensible!] point that you should probably ask people "what do you need" instead of saying "send me your requirements" and then stonewalling, but it doesn't quite get there. That's obviously the reason you linked it, but it falls flat.
Here, I'll make the point they should have made, and I'll do it in one paragraph:
> Since your whole training in programming is basically a course in "teasing out the specifics of what people want in concrete machine-encodable business-domain terms", the fastest way to get those requirements out of people (who have not been trained in that) is to present yourself as a REPL, not a compiler. Imagine if you had to throw code over a wall and wait a few days to see it get rejected with an obscure compiler error (basically, imagine the 1970s.) Now imagine sitting down with the computer and just trying things and seeing what works. For the sake of everyone's sanity, you want to present yourself as the second kind of system. Otherwise, "buy" becomes a much more pleasant notion than "build", and as a CIO that should make you feel like you're not doing your job.