Internally it was sold as: working together with other teams is too inefficient due to dependencies and differing priorities. It's faster to build it again independently than integrate with the existing service.

Not all teams are created equal. Having multiple teams with an extremely similar charter promotes competition, harder work, and deeper search for synergies elsewhere. A single team with a guarded remit is not going to try as hard and they may outright fail on their mission even if they do have internal competition.

It makes a lot of sense if you can afford it.

In environments where missing deadlines can have huge cascading effects it isn't unheard of to do redundant work so that you have a better shot of meeting your deadline and in a good case you have multiple successful options to pick from. When your deadlines are potentially expensive enough (think capital investment that need to be bought in time to be built out before old ones become uneconomical to operate) this approach can be well worth it.

This approach was made popular by Steve Jobs at Apple. He would have multiple teams competing to who's solution would survive, while the other teams products were thrown away

This goes all the way back to his early days (I think I remember a scene about this in The Pirates of Silicon Valley), but also reportedly multiple teams were building very different original iPhones

I think this approach makes sense for hardware but not pure software.

I think its easier to adjust pure software iteratively than hardware. So with hardware, it makes sense to have different teams working on similar but different things because variations of ideas need to be fleshed (and thoughts that spawn off those ideas) and it can be hard for one team to do this iteratively.

If you're right and this is where it came from, I think largely pure software teams doing this are wasting resources, but if its hardware I don't agree its wasteful

It was way before Jobs, IBM was using it ages ago.

Isn't this part of the premise of the book Hackers? Haven't read it in like 25 years, but that's what I vaguely remember.

I don't recall this coming up in Hackers: Heroes of the Computer Revolution, but it was definitely in The Soul of A New Machine, the story about Data General trying to build their first 32-bit computer.

Thank you... it was Soul of a New Machine. I don't think I even ever read Hackers!

Jobs gets credit for everything in computing the way Churchill gets credit for all the good quotes.

I think it was Mark Twain who said, “Hey, Churchill didn’t say that; that was me.”

Well played, Abraham Lincoln!

You spawn multiple teams working on very similar projects without them knowing about each other, let them grow for a while, then choose the most promising one (or with the highest traction) as your default solution and kill off the rest. Pretty normal exploration strategy.

Amazon has about 75,000 engineers. That's the equivalent of a large town. It's completely reasonable that many people would end up duplicating the work of other teams simply because they never communicate with them.

The philosophy is "1 > 2 > 0". This means ideally you'd prefer a single thing but single things often bottleneck delivery from different orgs as they have differing requirements. In that case you'll accept overlap/duplication if it keeps those orgs decoupled and both delivering faster.

I ran into this a couple years ago with partially duplicating a service that existed under another SVP org. It didn't feel good at the time but in hindsight it was probably less effort and higher chance of success than trying to align priorities across SVP orgs and making their thing work for our slightly different use cases.

Speculative execution .... which ever team moves fast wins ... heck sometimes its not even the team with the best features that wins ... teams with just enough features but who can move fast win sometimes and its bad for the long run. Most big companies have been doing this for a long time now.