So from that perspective you're describing the first two "explore" and "expand". The third is also interesting "extract" where a project reduces risk over everything else.
Both are missing the fourth part of a lifecycle. If we take the 4x analogy further (which is a popular video game genre) then there would be a "extinguish" phase. In a 4x video game that is where you take over the whole play area (map etc.), essentially by bullying out or assimilating the other factions.
In the real world this is also kind of true (see Amazon as a popular example in tech, or price dumping strategies practiced by Pharma and other large industries). But it is generally frowned upon as it hurts the economy and erodes social contracts. Also for most projects and organizations it isn't feasible to do so. So the "extinguish" part could be understood as "gracefully fading out" from which new cycles can be grown.
[0] https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-ex...
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.
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.
> Let us first examine the tendency to overpopulate a design effort. It is a natural temptation of the initial designer-the one whose preliminary design concepts influence the organization of the design effort-to delegate tasks when the apparent complexity of the system approaches his limits of comprehension. This is the turning point in the course of the design. Either he struggles to reduce the system to comprehensibility and wins, or else he loses control of it. The outcome is almost predictable if there is schedule pressure and a budget to be managed.
> We hit production with a 3-person team in less than a year; and subsequently scaled the team to 30+ engineers spanning multiple sub-teams
Starting with a small skilled team to build the core and actively plan for a larger team at some point is absolutely critical for project success in my experience, especially with complex projects like this. That small team can have a much tighter communication loop and all keep a single unified picture of what the end goal is. When the team grows this single unified picture is no longer feasible so it has to be broken down into sections, which is a good thing, but if the core isn't setup so that the sections are sufficiently decoupled things fall apart quickly.