Another oldish man ranting...
What I get from this article is that he's saying that some proportion of one's R&D output should be on internal tools or process improvements. He claims 30%, I'd say 10% is probably plenty, but he's far more senior and richer than me, so maybe he's right.
From my sysadmin (now known as devops engineer) position, I can see some really shoddy tools, systems and processes that applications have to use. A few years back I built a system to alleviate a whole load of productivity problems and solve a raft of technical problems as well. It's only just getting traction from the dev side of the house because it's literally taken this long for any of the devs to have enough latitude to engineer it into their builds. The thing is, as with so many things like this, it's hard to put a solid "price" on any of this, so it's hard to factor it into the normal dev cycle (which is a management failing, IMHO).
Herein lies the failings of many a technical organisation - developing features is not enough. Spending some proportion of your time fixing up legacy, decom'ing old crap, or building new tools isn't actually going to slow you down - in truth it probably won't speed you up either, but it means you can raise the base level of technology in your organisation and so can build better systems, applications and features in the future. For people like a number of my employers, and indeed Twitter, this means you get to create barriers to entry and can outperform your existing competition.
I see this 'continuous improvement' thing as *engineering* - it's part of what I learned about the craft of engineering at college and uni, yet it's something that's completely lacking in many so-called "engineering" organisations. Nice to see someone with some credentials talking about it - maybe one or two outfits will be listening.