A lot of this is, IMO, very basic - a project is not done until it’s tested and running in prod - I am surprised anywhere with engineers with any experience at

A lot of this is, IMO, very basic - a project is not done until it’s tested and running in prod - I am surprised anywhere with engineers with any experience at all would act otherwise. I don’t think having 40 people work on one thing at once is good at all. It’s like solving scaling by just getting a faster machine. Eventually you may not be able to purchase a machine fast enough to do everything you need to do… And you’re going to have a ton of deadweight. I hate “agile” as practiced but, in theory, it solves this. If you scope out a project well, you should have a general sense for what cross-team dependencies exist and be able to put it on the other team’s plate. You need a decent amount of “trust” but ideally the other team will actually appropriately prioritize it, ie if it takes only two days of work to unblock a project with big business impact, they won’t push back that their Epic Rewrite v3 is too important and maybe they’ll get to it in 6 months. The biggest problem I’ve seen is with bucketing all projects in long planning cycles (3 months, 6 months, 12 months, etc.). Every cross team dependency then takes about one planning cycle to be accomplished, and unexpected additional work/dependencies become nightmares. Also, while “ownership” and specialization are good to an extent, fixing a particular engineer to a specific domain over long intervals almost always causes problems because X% of engineers either aren’t skilled enough to be able to handle owning a domain, leave the team, get delayed, etc. If everybody is fully booked for a long time, there isn’t slack to help them, and it suddenly becomes a Big Deal to assign someone off a domain (because the person struggles for months and messes up a big project, rather than identifying they are messing up after weeks and course-correcting by putting them on something they can be more productive working on), and every project with more than a few people gets delayed because there’s no way to fix one or two engineers on the critical path dropping the ball. What both this article and agile touch on is the benefit of having a flexible planning structure and not over-committing or trying to plan too far in advance. IMO, that is the key to getting shit done. I think you can do that without taking it to the extreme of having only one project in-flight though.