Here's the deal: Making software is not challenging. A CS graduate from 2002 could build Teams. And it would be faster! You can hire dozens of engineers based

Here's the deal: Making software is not challenging. A CS graduate from 2002 could build Teams. And it would be faster! You can hire dozens of engineers based on whiteboard problems, throw them into a disjointed cacophonous open-plan work environment, give them arbitrary deadlines and 10 layers of middle management, and somehow, somehow, software will still be built! There's no reason to streamline the architecture, or the workflow of the team. If the software is going to be made regardless, why bother? Just do whatever feels normal. Contrast this with the engineers who built the Saturn V. I'm sure a lot of brainpower went into thinking about the overall architecture of the rocket, and how the teams would be structured, and how they would communicate. Tons of process. Anyway, as a result of this lack of organization, software teams usually self-structure into a network of arbitrary mini-siloes. The way this works at FAANGs is you'll have the Foobar Core team, the Foobar Presence team, the Foobar Video team, the Foobar Audio team, the Foobar Notifications team, etc. etc. It's like microservices for teams. And they barely communicate (unless two of these teams are lucky enough to share the same corner of the same open-plan floorspace!) Anyway, these mini-siloes ensure that there are lots of seams between modules, and no one can optimize across boundaries easily, without stepping on the toes of someone else's team. And unless customers are actually switching to other products, there's no political willpower to do that toe-stepping in the name of saving the product.