IIRC, they only standardized the interfaces, not the implementations. You could write your team's code any which way you wanted, but you had to expose a consistent REST api in front of it all and publish its specification to the rest of the company.

They didn't standardize the software, they standardized that all software should be accessible by API and that all software should be designed in such way to be openable to third party users if need arises.

Right, the right way to do standardization! It a shame that the author didn't add this very specific requirement though - some readers might think that the interfaces should be messy too...

That's what I was thinking when I read the article.

When I worked at Amazon, everyone worked out of the same repo(s), used the same build system (Brazil), deployment system (Apollo), deployed to the same place (EC2), most APIs were written using the same framework (Coral), etc. This is not that unlike the other large tech companies, and now that I'm back at a large non-tech company where everyone builds their own slightly-incompatible tools and deployment pipelines, I do miss that standardization.

Sure, some people chose to use different tools here and there, but most people wouldn't choose to reconstruct the universe just to stand up a microservice. It's not like all the "two-pizza teams" were all doing completely different things with incompatible tooling.

It's been a while since I worked there, so things might've changed completely since then. But as a shareholder, I hope not.

If standardized means APIs, yes. If standardized means anything to you about implementation, even at the level of “don’t reimplement what another team - or even another part of your own team - already implemented” then no.