I have been part of platform and product teams. So I think I sort of know what the author means by "kill-it" phase.

When new platform is being worked upon it's extremely difficult to get product teams to adopt. The PMs on the product teams view a new platform as a distraction because it seemingly doesn't help them launch new features. Worse it's taking the engineers who could be working on features to integrate with this new platform.

Typically during planning phase not too many oppose a new platform. However, when it comes to integrating (or adopting it) then everyone suddenly becomes conservative; no one wants to be the first mover, take the risk to be early adopter. It could also stem from product teams' prior experience of having burnt their fingers trying to integrate with a new platform.

I have seen quite a few platform teams get abandoned after everyone signed up. The platform team need to put in an extra effort to get product teams adopt.

Have you tried to build something (lets say, a new kind of storage engine that is not SQL-based) and bring it up to other developers or people at your workplace (never mind business guys)? What is/was their response? Perhaps kill it with fire. If not due to valid technical reasons, financial reasons might seal the deal for it.

And I totally understand the impulse to kill it. Do not unleash it onto the world unless you have thought about your projects long term future (something php & js ignored to do at the time it seems). Thus you end up with tons of pet projects that are either sensibly kept private/ununleashed or because people fear the judgement of others (aka the kill it impulse).

I'd say the nature of the beast is that entrenchment/reinforcement of existing tools/patterns and mental models tend to stick around as they are safe, so a ton of innovation never occurs as someone might not bother to follow a certain path. It's the same with water flowing into existing grooves/cracks in rocks, instead of making new grooves, unless forced to.

The natural reaction to "let's build something in-house" is almost invariably "let's try an OTS solution, surely one must already exist". Most successful internal projects require either an organizational culture of "we're at the forefront of technology" (but then you get "surely one must already exist in some other division" instead), a nuclear icebreaker of a champion that is willing to put their neck on the line, or a series of (un)fortunate events that leave your project as the only way out.