4 ms·

I really think this is a great list however I think one of the major factors why this project succeeded isn't listed but is mentioned in the intro. > We hit pr

I really think this is a great list however I think one of the major factors why this project succeeded isn't listed but is mentioned in the intro. > 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.

maheshba 5y ago
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).
- aurelius83 5y ago
  Can you explain more what you mean by the kill-it phase? Why is everyone trying to kill it?
  - BatteryMountain 5y ago
    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.
  - vishnugupta 5y ago
    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.
    - faichai 5y ago
      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.
  - orthoxerox 5y ago
    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.
- dgb23 5y ago
  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-expand-extract-6d4c94a7539 https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-ex...
krubar 5y ago
I think this can be related to what Mel Conway stated in his famous "How Committees Invent?" > 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.

maheshba 5y ago

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

aurelius83 5y ago
Can you explain more what you mean by the kill-it phase? Why is everyone trying to kill it?
- BatteryMountain 5y ago
  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.
- vishnugupta 5y ago
  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.
  - faichai 5y ago
    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.
- orthoxerox 5y ago
  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.
dgb23 5y ago
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-expand-extract-6d4c94a7539 https://medium.com/@kentbeck_7670/fast-slow-in-3x-explore-ex...

krubar 5y ago

I think this can be related to what Mel Conway stated in his famous "How Committees Invent?" > 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.