Hacker News Reader

Comment by maheshba | Hacker News Reader

That's a great point; I should definitely have included it in the list! I think new projects (especially ones that seek to innovate) have two phases: in the first phase, everyone's trying to kill it; in the second phase, everyone's trying to grow it. The kill-it phase is actually valuable for exactly the reason you outlined: it gives a small team the chance to create something highly coherent. (The grow-it phase is sometimes worse than the kill-it phase, but that's an entirely different story).

View on HN

Reminds me of Kent Beck's 3x [0] (there are also video presentations online).

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...

Can you explain more what you mean by the kill-it phase? Why is everyone trying to kill it?

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.

Well said! This has happened to me, I was introducing a new system and in conversation with a a primary customer team during the planning and initial dev constantly. They provided good feedback, and were supportive. When they realised we would stop supporting the old system, the attitude changed immediately and they did everything they could to derail the project.

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.

Reply on news.ycombinator.com