I don't believe a team should have that much say in their technology, unless they themselves are also responsible for hiring, training, etcetera - so it kinda depends on how autonomous a team is.

That said, as the article also mentions, "micro" can be a bit of a misnomer; you could have a 50 person team working on a single "micro" service, in which case things like hiring and training are much more natural. (to add, I've never worked in a team of 50 on one product; 50 people is A Lot)

I've seen this play out for reals at a place a few years ago. Every team used a different tech, and all of them selected because of resume-driven development. People moving teams to get a particular tech on their resume. No common method for deployment, and endless issues getting things deployed. Everyone's a newbie because we were all learning a new, cool, stack. And everyone making stupid newbie mistakes.

Never again. When I build teams forevermore, I pick the tech stack and I recruit people who know that tech stack, or want to learn that tech stack. And we stick to that tech stack whenever possible.

The worst part about this type of org (speaking as an SRE / DBRE) is that they also don’t do SRE correctly, so these piles of shit get yeeted into prod, fall apart, and then the already over-burdened SREs and DBREs have to figure out how it works so they can fix it.

I didn’t know how to troubleshoot Node, but I did know how to read docs. Suddenly I can troubleshoot Node. Hooray.

I concur with your sentiment, and would also be an absolute dictator for tech stack and workload management. We’re not using Node, we’re avoiding React if at all possible, every dev touching the DB in any way will know SQL, and no one is using Scrum.

Indeed, I am also an advocate of having the organization define a specific set of languages.

Even with just one, it isn't really a single one.

To pick on JS as example, not only there is JavaScript to learn, TypeScript might also be part of the stack, then there is the whole browser stack, and eventually node ecosystem as well.

Take the remaining UNIX/Windows related knowledge to get development and deployment into production going, SQL and the related stored procedures syntax for RDMS backends.

Eventually the need to know either C or C++, to contribute to V8 native extensions or WASM.

Now those folks need to learn about Go, Go's standard tooling, Go's ecosystem, IDE or programmer's editor customizations for Go code, and how to approach all the development workflows they are confortable of from the point of view of a Go developer.